Product thinking and discovery
Riskiest assumptions
State what must be true for an idea to work, then test high-hurt and high-uncertainty beliefs first.
Every solution carries hidden bets. Discovery's job is to turn those bets into sentences that can be wrong, then retire the riskiest first.
"Users will love it" is not testable. "Enterprises will allow Chrome extensions" is. Engineers often start with the assumption that is easiest to confirm in code. If a desirability assumption could kill the whole bet, start there instead.
Concept
An assumption is a belief that must be true for your idea to succeed, stated so it can be wrong. Score roughly on how wrong it would hurt × how uncertain you are. Test high-hurt, high-uncertainty first.
Walking through four lenses
Cagan's risks (see product thinking) give you four columns:
| Risk lens | Example assumption |
|---|---|
| Desirability / value | Freelancers will trust an AI-suggested rate |
| Usability | They can complete the client payment form on mobile Safari |
| Feasibility | We can get reliable rate data for their niche |
| Viability | Suggesting rates will not create legal or brand liability |
Solution: "AI price suggest on invoice create." Assumptions: (1) users want help pricing, (2) they will accept a suggestion often enough to matter, (3) you can show a suggestion in under 2 seconds, (4) bad suggestions will not destroy trust. If (1) is false, perfect latency does not help. Test (1) with a fake door or interview probe before building a model pipeline.
Write kill criteria before the test — "If fewer than 10% of activated users click within two weeks, we drop this solution and try another under the same opportunity." Without kill criteria, every test "needs more data" forever.
After a test: mark the assumption validated, invalidated or still uncertain; update the tree; then build a thin slice, iterate the test, pivot to another solution, or park the opportunity. Tell stakeholders with quotes and rates, not vibes.
Killing ideas early is a feature. A week-long concierge that proves nobody will pay for price suggestions saves a quarter of ML work. Celebrate killed ideas in retros the same way you celebrate launches.
Common mistakes
- Testing what's easy. Spikes without desirability tests.
- No kill criteria. Zombie tests and fake doors left rotting in production.
- Vague assumptions. "They'll love it" cannot fail, so it cannot teach.
Check yourself
The team wants to spike the model pipeline first because "we'll learn if it's feasible." What's the risk?
If nobody wants AI pricing, perfect feasibility is wasted. Test desirability first when it is high-hurt and uncertain.
Write a testable version of "users will love suggested rates."
"At least 10% of activated users click Suggested rate within two weeks" — or whatever kill bar you pre-commit.
Key takeaways
- List assumptions across desirability, usability, feasibility and viability.
- Test high-hurt × high-uncertainty first, not the easiest code path.
- Write kill criteria before the test. Celebrate early kills.
Further learning
Next, pick a cheap test in cheap discovery tests.
Related
Continuous discovery and assumption testing
Weekly customer contact, opportunity solution trees and cheap tests before building.
Opportunity solution trees
A living map from outcome to opportunities to solutions to tests — so you compare ideas under the same customer need.
Product thinking for engineers
Outcomes over output — why engineers who understand users and business build better software. Start here for the map.