Product Thinking
Judge a design by the outcome it produces for a person and for the business, not by whether the request was delivered.
Definition
Product thinking is the habit of asking what problem a piece of work solves, for whom, at what cost, before asking how it should look. It is what separates a designer who executes requests from one who shapes what gets built.
Expert heuristic. A review criterion developed by practitioners. Useful and widely taught, but evaluated by judgement rather than measurement.
On this page
The questions that do the work
Asked early, these cost minutes. Asked after a build, they cost the build.
- Whose problem is this, and what do they do today instead?
- What happens if we do nothing? A problem with a tolerable status quo is a low priority regardless of how loudly it is requested.
- What would have to be true for this to work, and which of those do we actually believe?
- What is the smallest version that tests the risky assumption?
- What does this cost after launch: support, maintenance, migration, and the options it closes off?
- How would we know it worked, and what would make us remove it?
Output thinking and outcome thinking
| Framed as output | Framed as outcome | What changes |
|---|---|---|
| Add a bulk export button | Account managers need last quarter's numbers in a board deck | Opens up a scheduled email, a template, or an integration. |
| Redesign the settings page | People cannot find the setting they came for | Search across settings may beat any reorganisation. |
| Build a mobile app | People need to approve requests while away from a desk | A notification with an approve action may be the whole product. |
| Add a dashboard | Nobody notices when a client is at risk | An alert beats a page somebody has to remember to open. |
Practising it
Do
- Restate every request as the problem behind it, and check that restatement with whoever asked.
- Learn the economics: what a customer is worth, what support costs, where the margin is. Design arguments land differently with numbers attached.
- Name the trade-off you are making, out loud, in the review.
- Keep a record of what you predicted, so your judgement can improve against reality.
Do not
- Do not use product thinking as a reason to block work. The point is to improve the request, not to win the conversation.
- Do not assume the loudest customer speaks for the segment.
- Do not confuse a business goal with a user goal. Both are legitimate; conflating them produces deceptive patterns.
In practice
The feature that was a copy change
A repeated request for a comparison view turned out to be about one number people could not interpret. Labelling it with the period it covered removed the request, and the view was never built.
Removing a feature as a product decision
A rarely used capability that generated a disproportionate share of support load and blocked a data model change was worth removing, with a migration path for the small group who relied on it. Judged by output, it was a loss. Judged by outcome, it paid for itself twice.
Continue from here
Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.
Applied through
Where this shows up as a concrete interface decision.
- Jobs to Be DoneResearch method
- DiscoveryWorkflow
- Measuring UXWorkflow
- Prioritising Design WorkWorkflow
- Problem FramingWorkflow