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/a34eebc263f949db90f2e17aa7ffe104Product 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!
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.