Discovery – Judgement

Marty Cagan argues that product discovery depends heavily on judgement, which many product people try to replace with frameworks and templates. He identifies four areas where judgement is required: assessing risk, deciding how much evidence is enough, gauging the scope of the work, and determining how much documentation is necessary. The core point is that treating every risk as major, demanding maximum evidence, or producing templated documents all waste time and slow teams down. Judgement should be exercised with input from engineers and designers, and experience is a key factor in developing it.

01Key takeaways

• Judge each risk's severity and consequence separately instead of treating all risks as equally significant.
• Consult engineers on technical feasibility and designers on usability before settling risk estimates.
• Match the level of evidence to the risk and consequence, saving expensive live tests for high-stakes decisions.
• Expect projects and initiatives to be risky and give them proportionally deeper discovery.
• Ask engineers what documentation they need for each case rather than relying on a standard template.
• Rely on experienced team members and managers to coach newer people in developing product judgement.

02Key sections

Assessing risk

Every initiative carries value, usability, feasibility, and viability risks, but these vary in significance. Judging both severity and consequence determines where discovery effort belongs.

Assessing necessary evidence

Evidence ranges from a few qualitative opinions to statistically significant A/B results. Teams should reserve costly, large-scale tests for high-consequence risks and rely on faster qualitative tests for most decisions.

Assessing scope of work

Work ranges from minor bug fixes to large initiatives, and scope usually but not always tracks consequence. Projects and initiatives are inherently risky and need focused discovery attention.

Assessing necessary documentation

Co-located teams need little documentation because engineers stay involved and prototypes communicate behavior. Remote teams may need more, but documentation should be tailored to what engineers actually need rather than standardized templates that grow into overhead.

03From the post

“A partnership dedicated to teaching best practices to product teams and product leaders”

04Frameworks mentioned

Summary and takeaways written by PM Atlas; quotes are short excerpts. © the original author.