Discovery – Excuses

Marty Cagan argues that product teams often use a predictable set of excuses to avoid doing real product discovery, and that these excuses usually reflect a misunderstanding of discovery rather than a genuine constraint. He walks through common rationalizations such as 'there's no demand,' 'customers hate change,' regulation, a new product type, restricted customer access, untestable ideas, and lack of time. For each, he explains why the excuse is convenient but weak and offers a reframing. The core point is that discovery is a core competency every strong product organization needs, and that testing an idea should take an order of magnitude less effort than building it.

01Key takeaways

• Check whether a weak result reflects a weak solution rather than absent demand before concluding the market isn't there.
• Treat regulatory and industry constraints as factors to design around, which also raise barriers to entry for competitors.
• Test new product ideas with real users by choosing the right prototype type rather than assuming a novel product cannot be tested.
• Work with sales leadership to agree how customer conversations will happen instead of avoiding customers altogether.
• Aim to test risky ideas in at least an order of magnitude less time and effort than building them.
• Build discovery skills as a core competency alongside delivery skills in any strong product organization.

02Key sections

Blaming the market and customers

Teams often claim there is no demand or that customers hate change when their solution is simply not seen as better than alternatives. Customers change readily when something genuinely improves their lives.

Blaming regulation and product novelty

Regulation is used as an excuse even though nearly every industry has constraints, and novel products are usually just new approaches to a solution that can still be tested with real users.

Blaming access and feasibility

Claims that teams cannot talk to customers or cannot test an idea without building it are typically resolved through conversations with sales and by using the various prototype and qualitative and quantitative techniques available.

Blaming time

The most common excuse is lack of time, but risky ideas need iteration, and if testing takes weeks or months, the team is doing something fundamentally wrong.

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.