[HN Gopher] Launch HN: Fable (YC W21) - Collaborate on product s...
___________________________________________________________________
Launch HN: Fable (YC W21) - Collaborate on product specs, sync to
issue trackers
Hi HN. Aravindh and Alex here, co-founders of Fable
(https://www.tryfable.com). Fable allows product teams to
collaborate on product specs, which it automatically syncs to issue
trackers like Jira and Linear. Here's a demo video:
https://www.loom.com/share/a34eebc263f949db90f2e17aa7ffe104
Product teams painstakingly craft their product specs to ensure
they're building the right thing. Unfortunately, the pace of modern
product development is so fast that the minute a product spec is
written, it's no longer relevant. People waste time copy/pasting
this content into issue trackers, because the engineers need
tickets to work on. Worse yet, these stale artifacts result in bad
decisions and ultimately the wrong product going out the door.
Alex and I have been PMs at companies of varying sizes and
industries--from Microsoft to Budweiser to Zocdoc. This idea came
to mind when I was a PM at TpT (Teachers Pay Teachers). I was
wasting hours copy/pasting from my spec into Jira, time that I
could have spent doing more valuable things like talking to users.
Then after creating those Jira tickets, I'd get the link and paste
it back in the spec. Problem was that I didn't have time to keep
updating the spec, which is the only place that my teammates on
marketing and sales looked at. They didn't want to go into Jira.
Fable gives product teams a place to collaboratively write their
specs. What's unique is that once the spec is written, teams can
push a button to sync the content with their issue tracker
(currently Jira and Linear are supported but we're adding more).
It's a two-way sync--meaning if content changes in the issue
tracker, it comes back to Fable and vice versa. You can start
writing your spec in Fable, push a button to sync with the issue
tracker, and _maintain accuracy_ even as the content changes in the
issue tracker. Other document editors allow users to embed a Jira
or Linear ticket, but it's not a two-way sync. Building two-way
sync was an engineering challenge since we had to account for
offline issues, errors, etc that could cause conflicts between the
two versions. We've designed our conflict resolution engine to be
smart about handling these scenarios, and when we can't come to a
decision on what the source of truth is, we prompt the user to
select one. We've built Fable from the ground up for product
teams, emphasizing ease of use (no complicated setup or learning
curve) and speed (you don't have to wait a few seconds every time
you want to edit a doc). The foundation is a powerful document
editor built on Prosemirror. It allows users to dynamically embed
content from sources including Figma, Google Drive, and Airtable.
Fable makes product definition a more collaborative process,
involving teammates all the way from ideation to creating tickets
on issue trackers, and letting everyone keep track of what is being
built and its status. No more sales and marketing people going into
the issue tracker and throwing their hands up because they don't
know how to parse through all the tickets. Later, the Fable doc
serves as a record of what was built, so teams can look back later
to understand the thought behind live features. We charge per
"maker", meaning people who are actively creating content. This
tends to the product manager, and sometimes also the designer and
engineering manager. Anyone who just wants to view and comment on
the doc (marketing, sales, etc) gets access for free. We're
looking forward to feedback from the community!
Author : addorai
Score : 49 points
Date : 2022-01-18 15:02 UTC (7 hours ago)
| tekacs wrote:
| The decisions feature here feels a lot like Threads
| (https://threads.com/) and the document feature like Notion
| (though I see the use of ProseMirror).
|
| I can't necessarily say that I understand the value of two way
| syncing the content in Fable doc into the ticket body (rather
| than simply linking to a Notion doc in the page of a Linear/Jira
| ticket, which I've seen commonly done). That way the entire team
| can see a spec, collaboratively edit it and engineers just click
| the link to go across.
|
| I could also very much see Linear adding a Notion integration or
| support, which would further simplify that process. Notion also
| added the reverse direction for Jira recently too, so it's super
| easy to embed live ticket information on Notion now!
|
| Would love to understand that use case a little better!
| addorai wrote:
| The workflow that many teams use (myself included) is to
| iterate on detailed requirements in a doc, often in a table.
| They do this so that they can iterate on them in a more
| collaborative place vs Jira/Linear. It's also more accessible
| to the broader team (sales, design, marketing, etc).
|
| Then after aligning they copy + paste those requirements into
| the issue tracker. They often also include a link back to the
| doc. But then you have two places that show the same
| requirements, one for eng and one for others and they almost
| always get out of sync. Plus it's a bit annoying for eng to
| have to parse thru the spec to map requirements for a specific
| ticket.
|
| This is the workflow we're solving for!
|
| As for Linear + Notion or Jira integration, it's entirely
| possible they add it but our approach is to focus on a few
| product team focused integrations and go deep on them
| rememberlenny wrote:
| This feels like the missing tool in our remote team workflow. I
| love that you recognize there is a need for proper syncable docs
| that help manage project luck-off/monitoring processes.
|
| Can you share a bit about your upcoming prioritized integrations?
| addorai wrote:
| Thanks! We're exploring additional integrations with tools like
| Asana, ClickUp, and also Github to track features thru code
| complete.
| [deleted]
| antidnan wrote:
| Congrats on the launch!
|
| Building the conflict resolution engine sounds like a fun
| challenge.
| addorai wrote:
| Haha yes, it was quite the challenge! Most of the time it just
| works, but in rare situations we'll ask the user to pick b/w
| the Fable version and the version on their issue tracker.
| lukasfischer wrote:
| Looks cool. What do you differently to productboard?
| addorai wrote:
| Productboard does a great job helping prioritize features based
| on customer feedback. Fable comes in when you want to define
| _how_ that feature should work. We let teams collaborate on
| rich product specs for those features, then sync it over to
| issue trackers. We also have a decision feed that integrates
| with Slack and doc comments to make sure decisions made during
| product development aren 't lost.
|
| We have companies that use ProductBoard + Fable in conjunction.
| [deleted]
| kaino128 wrote:
| Looks interesting, well done for launching and good luck.
|
| One question - not as a potential customer but as just another
| founder - how are you offering 24 hour a day support? Do you have
| a remote team that just naturally covers enough time zones or
| have you specially hired people or a service for this? It looks
| really impressive for a new product to launch with 24 hour
| support! I'd love to do this with my services but not a big
| enough team yet...
| addorai wrote:
| Our team is across several time zones and we're all well versed
| in the product of course :)
| dchuk wrote:
| (Not trying to discourage you)
|
| For those companies that have sufficiently consumed the Atlassian
| Kool-Aid, what differentiates this product from just using
| Confluence? Confluence has pretty robust widgets/embedding
| options, plus there's the plugin ecosystem to unlock embedding
| external things like designs/etc. And obviously it easily
| connects to jira for tickets.
| addorai wrote:
| Interestingly, Confluence doesn't have a 2 way sync with Jira.
| You can embed Jira tickets but you can't _push_ content from
| Confluence to Jira and automatically create tickets.
|
| Aside from that, we've designed Fable to be customized for the
| product team workflow - with features like the decision feed,
| zippy content editing, etc.
|
| We also work with Linear, which has a fast growing user base
| bberenberg wrote:
| You can push content from Confluence into Jira, it's been
| around for years [1] but this functionality does need to
| improve. At the same time, Atlassian has also has created
| Jira Product Discovery which is currently in closed beta [2]
|
| 1 https://confluence.atlassian.com/doc/use-jira-
| applications-a...
|
| 2 https://www.atlassian.com/software/jira/product-
| discovery/wa...
| addorai wrote:
| Sorry, I should have been more clear. In Confluence you can
| highlight content and create a ticket - it just prefills
| the title of the ticket to be the highlighted content. You
| still have to fill in the description. Then after pushing
| it to Jira there's no ongoing sync.
|
| Fable has a true push + sync, where the live content in the
| editor is continuously sync'ed with Jira. This means you
| can keep editing product requirements in the place that
| your whole team lives (marketing, design, sales, of course
| eng) and not worry about tickets going stale
| product1087 wrote:
| > Product teams painstakingly craft their product specs to ensure
| they're building the right thing. Unfortunately, the pace of
| modern product development is so fast that the minute a product
| spec is written, it's no longer relevant.
|
| I think the missing insight is that while the final outcome is no
| longer relevant, the process of reaching the outcome is critical!
| When I am trying to understand a feature, I find myself spending
| most my time in the version history of Google Docs (something
| that team has treated as a secondary feature) - learning how the
| feature team's collective understanding has evolved. I think
| Decisions in Fable is a step closer, but not far enough.
|
| One thing I would love to see is product spec editing /
| collaboration focused around version history. The real "work" of
| building product specs is building shared context between PM,
| Eng, UX through evolution of the requirements. However unlike
| devs who can see the diff of a code file, PM rarely "show their
| work" - and it makes it hard for everyone to see how the final
| requirements were reached. I still haven't seen any PM tool with
| this paradigm in mind.
| addorai wrote:
| This is a great point. It's particularly useful to have that
| context into how the thinking evolved when you're looking back
| at a feature built months or years ago, to help you avoid doing
| something that was skipped in good reason OR make the same
| mistakes again.
|
| We agree our decision feed is just step one to get there, we're
| also exploring other ways to show the evolution of work.
___________________________________________________________________
(page generated 2022-01-18 23:01 UTC)