Intro to Product Discovery

What is Product Discovery?

Product Discovery is the structured process of figuring out what to build before you build it. It sits before delivery (design + engineering execution) in the product lifecycle and answers three questions:

• Is this problem worth solving?
• Will a solution be valuable, usable, feasible, and viable?
• How do we know — what evidence do we have, not just opinions?

Discovery is continuous, not a one-time phase. Strong product teams run discovery and delivery in parallel, every week, throughout a product's life — not just at the start of a project.

Discovery vs. Delivery

Discovery	Delivery
Decide what to build	Build it well
Fast, cheap, reversible experiments	Slower, costly, hard to reverse
Driven by Product, Design, Engineering together	Driven mainly by Engineering
Output: validated decisions	Output: shipped software

The Four Risks (Marty Cagan's framework)

Every product idea carries four risks that discovery must address:

• Value risk — will customers choose to use it?
• Usability risk — can users figure out how to use it?
• Feasibility risk — can we build it with the time, skills, and technology we have?
• Business viability risk — does it work for the business (legal, financial, marketing, sales)?

Why Discovery Matters

Most failed products don't fail because of bad engineering — they fail because teams built something nobody needed. Discovery exists to catch that before expensive delivery work begins.

• Reduces waste: cheap experiments (interviews, prototypes, surveys) are far less costly than building and shipping the wrong feature.
• Increases the odds of success: teams that validate assumptions ship features with far higher adoption and retention.
• Builds organizational learning: discovery generates evidence that informs strategy, not just a single feature.
• Aligns stakeholders early: surfacing risks and assumptions before a roadmap commitment avoids costly rework and politics later.

The Cost of Skipping Discovery

• Engineering builds polished, well-tested features that get low usage.
• Roadmaps fill with "obvious" ideas from leadership or competitors instead of validated customer problems.
• Teams discover problems with usability or feasibility only after launch, when they're expensive to fix.

A Mindset Shift

Discovery reframes the team's job from "ship the roadmap" to "solve the right problem, with evidence." It moves teams from being feature factories to being outcome-driven — measured by the customer and business results they create, not the number of features shipped.