Two-Truth Product Definition
Define the two or three outcomes users must rave about before building
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 6
- Confidence
- 94%
Before engineering begins, define the product with only two or three outcomes that matter intensely to a specific target customer. Make those outcomes concrete enough to guide invention and exclude distracting features. Apple's iPod definition was a thousand songs with any song reachable in four seconds; the fact that existing hardware and software could not deliver it became the invention agenda rather than a reason to weaken the definition. Build, polish, and test against those few truths. The first market signal is whether customers rave about the result without requiring heavy marketing. If they do not, revisit the defining outcomes rather than masking weak product-market fit with more features or spend.
Origin
McNeill recounts Steve Jobs's former chief of staff explaining that the difficult product work happened up front, illustrated by the two-part definition used for the iPod.
Core principles
- 01The hardest simplification happens before engineering
- 02A product needs only a few defining outcomes
- 03Ambitious definitions can force useful invention
- 04Unprompted customer advocacy is a product signal
How to run it
- 1
Choose the target
Specify the customer whose unmet need the product will serve.
Pro tip Narrow enough that the team can learn what this customer truly values.
- 2
Study the current failure
Identify what makes existing alternatives inadequate, clunky, slow, or unattractive.
Watch out Do not define the product from internal capabilities alone.
- 3
Write two or three truths
State the few measurable outcomes the finished product must make true for the target customer.
Pro tip Use a memorable sentence rather than a feature inventory.
- 4
Build to the definition
Focus engineering and design on satisfying those truths, inventing missing capabilities when necessary.
Watch out Do not dilute the definition merely because the solution is difficult.
- 5
Test for raving
Observe whether target customers enthusiastically advocate for the product and whether that reduces dependence on paid marketing.
Pro tip Look for unsolicited recommendation, not polite satisfaction alone.
- 6
Redraw when necessary
If customers do not rave, revisit which two or three outcomes matter instead of layering on unrelated features.
In the wild
Apple defined the iPod as holding a thousand songs and finding any song in four seconds. Engineers initially lacked both the required hard drive and software, so those two truths focused what the team needed to invent.
→ A two-part definition converted a broad music-player project into a concrete engineering agenda.
Common mistakes
Starting with a feature backlog
A long list hides which outcomes are essential and spreads scarce product effort.
Confusing courtesy with advocacy
Customers saying a product is fine is weaker evidence than customers actively raving about it.
Is it for you?
Best for
Zero-to-one teams seeking product-market fit with limited capital and no large marketing budget.
Not ideal for
Mature commodity products whose purchase is driven mainly by distribution, regulation, or switching costs.
From the transcript
“What has to be true about this product?”
“we want our music player to have a thousand songs and it only takes four seconds to find a song.”
“if they don't rave about it, then you haven't gotten those two or three things right.”
From the episode
Episode 541: Jon McNeill: Why "Less" and "Simple" are the Smartest Growth Strategies
Jon McNeill