Roles, Competencies & Organisation8 min read

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.

A critique table compares product artefacts using references, context and deliberate restraint.
On this page
  1. 1.What product taste includes
  2. 2.Taste makes four decisions
  3. 3.Taste and evidence are partners
  4. 4.How to develop taste deliberately
  5. 5.The taste review
  6. 6.Cognitive surrender
  7. 7.Anti-pattern: generated coherence

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.

DecisionCore question
ProblemIs this pain important enough, frequent enough, and timely enough to deserve intervention?
StandardWhat must be true before this is good enough to use, trust, and support?
FormWhich interaction, artefact, or workflow expresses the value with the least unnecessary burden?
Trade-offWhich 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

Two different inspection tools assess the same product sample.

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:

  1. State the decision you expect to be right.
  2. Explain which observations and principles support it.
  3. Identify what would change your mind.
  4. Observe the consequence after shipping.
  5. 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.

DimensionReview question
ProblemAre we solving an observed pain or expressing our excitement about a capability?
UserWhose context and consequence are driving the choice?
CoherenceDoes this strengthen the product's point of view or add another disconnected option?
NoveltyWhere should the experience be familiar, and where must it be distinct?
FoundationWhat operational, technical, or organisational debt sits under the surface?
RestraintWhat can we remove without weakening the outcome?
AccountabilityWho 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