Skip to main content

Documentation Index

Fetch the complete documentation index at: https://userstory.zeroemdashes.com/llms.txt

Use this file to discover all available pages before exploring further.

Early in my career, I thought the job was to ship features. Someone (usually a stakeholder with a very strong opinion and a very short patience) would say “we need this”, and off we’d go - design, build, release, repeat. Spoiler alert: most of those features didn’t move the needle. Some made things worse. A few were never used at all 😬 That’s the world without product discovery. Product discovery is the process of figuring out what to build - before you build it. It’s a structured way of answering the most important question in product management: are we solving a real problem for real people, in a way that actually works? It lives in the space between “we have an idea” and “let’s start the sprint”. It’s research, experimentation, validation, and a healthy dose of “wait, are we sure about this?”. Done well, it means your team builds things people actually want, instead of things that looked good in a slide deck. Here’s the uncomfortable truth: most product failures aren’t engineering failures. The code worked. The design was clean. The problem was that nobody wanted it - or at least not in the form it was built. Discovery is how you catch that before it costs you six months and a lot of goodwill. What does discovery actually look like in practice? It depends on the stage and the problem, but at its core it involves:
  • talking to customers (and listening more than you talk)
  • understanding the problem deeply before jumping to solutions
  • generating multiple ideas and testing the riskiest assumptions fast
  • building small prototypes to learn, not to ship
Notice what’s not on that list: building the full thing first and hoping for the best. The other thing worth saying upfront - discovery isn’t a phase you do once at the beginning of a project and then forget about. The best teams I’ve worked with treat it as a continuous habit, running in parallel with delivery. Teresa Torres calls it “continuous discovery” - she wrote the book on it, literally (Continuous Discovery Habits) - and honestly, once you work that way, going back feels like flying blind. So if you’re new to this - welcome 👋 You’re about to save yourself (and your team) a lot of wasted effort. The rest of this section breaks down the frameworks, tools, and techniques that make discovery work. Start anywhere, but maybe start with the Opportunity-Solution Tree - it changed the way I think about problems entirely.