What happens before a good product decision
Framing, evidence, options, trade-offs and a pre-mortem: the unglamorous work that makes a product decision look obvious afterwards. Illustrated with a clearly hypothetical team.
In this story (6 sections)
General edition. , or use the switcher above.
The decision is the visible part. The judgement happens before.
This story walks through five steps using a hypothetical composite team. It does not describe a real project.
The short version
- Frame the decision as a question, not a proposal.
- Look for evidence that could disagree with the idea.
- Put at least three options on the table, including a cheap one.
- Write trade-offs openly and run a pre-mortem to convert risks into constraints.
A decision, reconstructed (as a composite)
Good product decisions look obvious afterwards. This story reconstructs the work that comes before one, using a hypothetical composite: a team deciding whether to add a saved-searches feature to an app. No real team, data or outcome is described.
1. Frame the question narrowly
“Should we build saved searches?” is a proposal. “Why do returning users repeat the same search?” is a question. The second keeps the team open to answers that aren’t the proposal, such as better recent-search history or smarter defaults.
2. Gather evidence that can disagree
A mix helps: observed behaviour (what people do), conversations (why they do it) and a look at what competitors do, which is weak evidence at best. The aim is not to prove the idea but to find the strongest reason it could be wrong.
3. Put at least three options on the table
If there are only two options, one of them is usually a straw man. A third, cheaper option often changes the conversation: here, showing recent searches without any new feature.
4. Write the trade-offs where everyone can read them
| Option | What it costs | What it risks |
|---|---|---|
| Saved searches | New screens, storage, notifications | Complexity for people who never needed it |
| Recent-search history | Small change to an existing screen | May not cover people who want to name or alert on searches |
| Do nothing, measure repeat searches | Nothing to build | Delays an answer by a quarter |
5. Run a pre-mortem
Ask the team to imagine it is a year later and the decision was a mistake: why? Reasons surfaced in advance (the feature competes for attention with search itself; support burden rises) turn into design constraints or stop rules rather than surprises.
Key takeaways
- 01A third, cheaper option often reframes the discussion.
- 02Make trade-offs readable by everyone in the room.
- 03Convert pre-mortem risks into stop rules or design constraints.
Your perspective
A better read starts with knowing what matters to you.
Three quick questions. A publication that adapts to your perspective.
Keep reading
All stories →The personalization paradox
When does tailoring an experience to someone make it better, and when does it become intrusive? An interactive look at four rungs of personalization.
The cost of not building
Budgets record what projects cost. They rarely record what it costs to leave an idea untested. A practical way to make “not now” a real decision.
What shipping products teaches you
Five practical observations about dates, first versions, measurement, release size and memory, written as field notes rather than rules.