Taste Is a System, Not a Vibe
How product taste combines judgement, cultural context, empathy, systems thinking, and restraint, and how to develop it deliberately.

On this page
TL;DR
- Taste is the ability to choose the right problem, standard, form, and trade-off when the evidence cannot make the decision for you.
- It combines comparative judgement, empathy, cultural context, systems thinking, and restraint. Visual polish is only one expression.
- Taste develops through exposure, prediction, critique, consequence, and revision. You can practise it, but you cannot outsource the final call.
AI can produce a hundred plausible options before a team has agreed what good means. That does not remove the need for taste. It makes the absence of taste expensive.
The weak version of taste is aesthetic preference: clean typography, polished motion, sparse interfaces. The useful version is broader. Product taste is the capacity to make a defensible choice under ambiguity, understand how that choice fits its users and culture, and recognise the second-order consequences before they become obvious.
Taste is not magic. It is a judgement system built from experience and used with intent.
What product taste includes
Taste has five components. Strength in one does not compensate for ignoring the others.
Comparative judgement
Taste starts with seeing differences that less experienced practitioners miss.
Two onboarding flows may both be usable. One asks for information at the moment its value becomes clear. The other asks because the database schema needs it. Two AI answers may both be factually correct. One gives the reader the decision they need; the other performs intelligence around it.
Comparative judgement requires a reference set. You need to know what excellent, ordinary, and harmful look like across many examples. Without that range, teams mistake novelty for quality and familiarity for proof.
Empathy and situational context
Good choices depend on who encounters them, what they are trying to do, and what happened immediately before.
The right experience for an analyst reviewing a valuation is different from the right experience for a homeowner checking a price estimate. The same confidence score, disclosure, or error may carry different consequences.
AI can synthesise customer evidence. It cannot accept responsibility for which customer, moment, and consequence should dominate the decision. That weighting remains product work.
Cultural context and novelty
Taste is partly cultural. A design can be coherent and still feel copied. A piece of content can be fluent and still feel synthetic. A product can follow every established pattern and become invisible because the market has already absorbed those patterns.
This makes novelty a judgement problem. Too little creates sameness. Too much imposes learning cost without creating value.
Keep familiar patterns where familiarity helps. Spend novelty where it changes the product's meaning, capability or emotional effect.
Systems thinking
A tasteful decision works beyond the screenshot.
It accounts for performance, accessibility, operations, support, cost, governance, and what the next team will inherit. A beautiful AI interaction built on brittle context and uncontrolled permissions is not good product work. It is a polished liability.
Systems taste asks what this choice makes easier or harder six months from now. That is why deep craft still matters when generation becomes cheap. Someone must recognise the crusty foundation under the impressive surface.
Restraint
Restraint is the willingness to remove a plausible feature, reject an attractive output, or stop an idea that has not earned further investment.
Cheap implementation weakens the natural limit on scope. Teams can now build all five options, so they often do. The cost returns later as fragmented experience, review load, maintenance, and indecision.
Taste turns abundance into a coherent product by deciding what does not belong.
Taste makes four decisions
Product taste becomes practical when it is attached to decisions.
| Decision | Core question |
|---|---|
| Problem | Is this pain important enough, frequent enough, and timely enough to deserve intervention? |
| Standard | What must be true before this is good enough to use, trust, and support? |
| Form | Which interaction, artefact, or workflow expresses the value with the least unnecessary burden? |
| Trade-off | Which cost, constraint, or imperfection are we deliberately accepting? |
Teams often discuss taste only at the form layer. By then, the larger decisions have already been made. A well-designed solution to a weak problem is still a weak product.
Taste and evidence are partners

Taste is not permission to ignore data. It is what you use when evidence is incomplete, conflicting, or unable to choose between values.
Evidence can show that users abandon a flow. It cannot decide whether to simplify the flow, change the promise, target a different user, or remove the capability. An experiment can show which variant wins this week. It cannot prove that the winning variant fits the long-term product.
Use evidence to calibrate taste:
- State the decision you expect to be right.
- Explain which observations and principles support it.
- Identify what would change your mind.
- Observe the consequence after shipping.
- Update the principle, not only the feature.
This turns taste from retrospective storytelling into a testable practice.
How to develop taste deliberately
Taste develops through accumulated decisions and consequences. The accumulation can be designed.
Build a reference library
Collect specific examples of excellent and poor product decisions. Include software, physical products, service experiences, writing, onboarding, pricing, support, and failure recovery.
For each example, record what works, for whom, under which constraint, and what was intentionally omitted. A folder of attractive screenshots trains imitation. A library of reconstructed decisions trains judgement.
Predict before reading the result
When reviewing an experiment, customer session, product launch, or case study, write down what you expect before seeing the outcome. Prediction exposes your model. Surprise improves it.
Passive consumption creates familiarity. Prediction creates calibration.
Run comparative critiques
Review multiple approaches to the same problem. Ask which one you would choose and why. Then force the group to identify the strongest argument for the rejected option.
Comparative critique should produce a clearer account of the trade-off, whether or not the group reaches consensus.
Seek consequence, not only feedback
Feedback tells you what someone thinks. Consequence shows what the decision caused.
Did users return? Did support load rise? Did the team need exceptions? Did the feature change behaviour or merely attract attention? Judgement improves when the loop reaches real outcomes.
Learn an adjacent craft deeply enough to be corrected
Write for publication. Build a working interface. Conduct customer research. Model pricing. Operate a production workflow.
Taste grows when another discipline can show you exactly where your intuition was shallow. Sampling tutorials is not enough. You need work that can fail.
Keep a decision journal
For consequential product calls, record:
- The decision
- The alternatives rejected
- The evidence available
- The principle used
- The expected consequence
- The date for review
Review the journal quarterly. Look for repeated errors: overvaluing novelty, underestimating operations, trusting loud customers, or keeping weak ideas alive.
The taste review
Use this rubric before a major product decision.
| Dimension | Review question |
|---|---|
| Problem | Are we solving an observed pain or expressing our excitement about a capability? |
| User | Whose context and consequence are driving the choice? |
| Coherence | Does this strengthen the product's point of view or add another disconnected option? |
| Novelty | Where should the experience be familiar, and where must it be distinct? |
| Foundation | What operational, technical, or organisational debt sits under the surface? |
| Restraint | What can we remove without weakening the outcome? |
| Accountability | Who will own the result if our judgement is wrong? |
This is not a scoring model. A weighted score would create false precision. The rubric exists to expose where judgement is being exercised without enough context.
Cognitive surrender
AI creates a subtle failure mode: the model proposes the options, frames the trade-offs, recommends one, and drafts the explanation. The human technically approves the decision while contributing very little independent thought.
That is cognitive surrender.
Prevent it by forming an initial view before asking the model, using AI to challenge rather than originate every judgement, and requiring the accountable person to explain why the choice fits the specific situation. If you cannot defend the decision without repeating the model's language, you have not finished thinking.
The AI accountability principle covers the ownership standard. Taste is the capability that makes the review substantive.
Anti-pattern: generated coherence
The team asks AI to produce the strategy, prototype, launch copy, and success narrative. Every artefact agrees with the others because they came from the same context and assumptions.
The package feels coherent. Nobody independently tested whether the underlying problem matters.
Coherence is useful only after the team has earned the premise. A fluent system can align perfectly around a bad idea.
The product builder expands who can make working software. Thinking in Bets explains how to test and stop ideas. Taste decides which possibilities deserve that machinery.
v3.1 · Updated July 2026