Product Discovery
Product Discovery is the iterative process of validating customer problems and de-risking ideas before engineering build.
“The most expensive way to discover whether a product works is to build it.”
Writing software is expensive; writing the wrong software is catastrophic. Product discovery ensures that engineering teams build only what customers will buy, adopt, and retain.
Multi-Hop Causal Traversal Engine
Explore how concepts dynamically feed into each other across 1-hop, 2-hop, and 3-hop transitive relationships. Click any node to navigate the causal highway.
Product Discovery
Product Discovery is the iterative process of validating customer problems and de-risking ideas before engineering build.
Direct Relationships (4)
Transitive Neighbors (Connected via Hop 1)
Extended Causal Ripple Effects
Richard Ewing’s Research Thesis
We must validate customer value and de-risk core assumptions before committing engineering capital.
Why This Specification Exists
Engineering teams spend months building features that customers never use or adopt.
Traditional Waterfall specification documents or unvalidated Agile sprint backlogs.
No structured mechanism for de-risking customer demand and business viability prior to engineering build.
Continuous Product Discovery embedding four-risk validation into weekly squad routines.
What Changes If You Believe This?
Tech leads contribute feasibility insights early, preventing dead-end architectural designs.
Protects R&D capital by ensuring only validated, high-conviction features enter delivery.
Product designers and PMs build continuous customer empathy through direct, weekly user interactions.
Evaluates compliance and privacy constraints during the discovery phase before system architecture is locked.
Recommended Action by Role
Establish a weekly cadence of at least 2 customer discovery interviews with your tech lead and designer.
Audit Interview Scorecard
Evaluates candidate discovery and assumption testing skills.
Frequently Asked Questions
Q:What are the 4 big risks in Product Discovery?
1. Value Risk (will users buy/use it?), 2. Usability Risk (can users figure out how to use it?), 3. Feasibility Risk (can engineers build it?), and 4. Viability Risk (does it work for our business/legal/finance?).
Q:How is Product Discovery different from Delivery?
Discovery decides what to build through hypothesis testing; Delivery builds production-grade software ready for release.
Canonical Specification Origin
Product discovery de-risks value, usability, feasibility, and viability.
Corpus Interconnections
Richard Ewing artifacts developed around this canonical framework, including publications, execution tools, and diagnostic models.
External Adoption & Peer Citations
Documented instances where independent researchers, engineering teams, and publications have cited, implemented, or referenced this concept outside Richard Ewing’s ecosystem.
External Evidence: No independently verified references recorded yet.
This concept is part of Richard Ewing’s original baseline canon. External citations and implementations are added only upon rigorous empirical verification.
Inspectable Evidence Ledger
Classified evidence items supporting, extending, or refining this canonical research specification.
| Evidence Item | Publisher | Evidence Type | Strength | Role | Action |
|---|---|---|---|---|---|
| The 3 Financial Metrics Every PM Needs on Their Scorecard | Mind the Product | Industry Article | ★★★★★ | Origin | Inspect ↗ |
Recommended Citation
Ewing, R. (2026). "Product Discovery." Richard Ewing Research Canon. Available at: https://www.richardewing.io/concepts/product-discovery
@article{ewing_product_discovery,
author = {Ewing, Richard},
title = {Product Discovery},
journal = {Richard Ewing Research Canon},
year = {2026},
url = {https://www.richardewing.io/concepts/product-discovery}
}