Product Taste

Product taste is the ability to judge which of many possible things is worth building, how to build it well, and what a delightful user experience looks like. Cat Wu identifies it as the most durable PM skill in an era where code is becoming cheap to produce.

The core argument

As AI makes code generation cheaper, the scarce resource shifts from the ability to build to knowing what to build. Claude Code teams at Anthropic receive tens of thousands of GitHub issues. Every one of them is a potential feature. The valuable judgement is: which of these should we build, in what form, for which users?

Cat Wu: ‘As code becomes much cheaper to write, the thing that becomes more valuable is deciding what to write.‘

What product taste includes

User empathy — deeply understanding who the user is, what problem they actually have (vs. what they say they want), and what will be delightful.
Prioritisation judgement — knowing which of many competing possible features is worth the team’s time.
UX intuition — sensing the right form for a feature; ‘what is the most delightful way a user can experience it?’
Scope discipline — knowing when something is too ambiguous to build without more definition, and when it is simple enough to just do.

Where it comes from

Cat Wu argues product taste ‘can come from any background’ — engineering, design, traditional PM. She does not treat it as tied to a specific credential or role. However:

An engineering background currently adds one additional signal: a sense of how hard something is, which affects prioritisation decisions. If building X takes an hour, skip the debate and do it. If it takes months, the prioritisation conversation is load-bearing.
She adds ‘for the next few months’ as a deliberate hedge — the valuable skilsets shift frequently as model capabilities change. Large shifts happen every few months.

How to develop it

Cat Wu’s implicit guidance from the talk:

Spend extensive time using frontier models yourself; understand their actual capability versus the hypothetical future capability.
Build things you will use daily — not prototypes you never return to.
Ask the model to introspect on unexpected behaviour: ‘why did you do this?’ — reveals what misled it and what harness adjustments matter.
Find 5 trusted users who can articulate model quality precisely; their feedback is more valuable than aggregate volume.

Relationship to the PM role

Product taste is the argument for PMs remaining necessary even as engineers take on more product responsibilities. Cat Wu’s Anthropic team includes engineers who can go from ‘user feedback on Twitter’ to ‘shipped product’ end-of-week with no PM involvement. The PM’s remaining value is: which of those things should they be building?

Guillermo Rauch: exposure hours and eloquence

Guillermo Rauch on v0 and the Future of Building provides the most concrete operationalisation of taste-building in the wiki.

Exposure hours is Vercel’s internal operating principle: quantify how much time you spend watching real users interact with your products (and other products). The inertia is always toward thinking you know how the product works; exposure hours is the deliberate counter-force.

‘Taste, sometimes I think we think of as this inaccessible thing that, “Oh, that person was born with taste.” I see it as a skill that it can develop.’

Practical mechanisms at Vercel:

Customer meetings: Guillermo reserves ~a third of his calendar for customers; he uses their products live rather than discussing features abstractly.
Demo Fridays: weekly ritual where anyone demos what they built with AI tools — creates space for unexpected generalism.
Invite customers to demo how they use the product to the whole company; always reveals friction and unintuitive behaviour.

Eloquence as taste’s practical expression: in an AI-mediated product world, taste manifests as knowing the right tokens to steer models toward intent. Knowing that ‘turbulence effect’ and ‘sepia filter’ are the right words gets you the exact visual you want; not knowing them means describing it badly and getting something approximate. This is taste-as-vocabulary: building a rich mental map of what exists, what it is called, and what it looks like.

Alex Komoroske: taste as LLM differentiation

Alex Komoroske on Strategy and Complexity offers the sharpest operational definition for the AI era:

‘Taste is the most important thing. Differentiate from what the LLM would have written if given the same prompt. How distinctive is what you have to say.’

Komoroske frames taste as the antidote to the cacophony created by cheap content production. In a world where anyone can generate reasonable-quality output at near-zero cost, the scarce resource is a distinctive perspective that resonates with diverse audiences. Good taste is individual and compelling to others — resonance across people with very different backgrounds is the test, not just internal confidence.

This framing positions taste less as aesthetic sensitivity and more as identity strength: knowing what you specifically think, as distinct from the statistical average. It makes taste trainable (via reflection practice, idea-testing, exposure) rather than innate.

Dylan Field: intuition as hypothesis generator

Dylan Field on Figma and Product Taste offers the most operational definition of how taste functions in decision-making:

‘Intuition is like a hypothesis generator. You’re constantly generating these hypotheses and others are generating hypotheses as well. You put them forward, debate them, try to find data to support or negate them, then winnow it down into a working hypothesis.’

This reframes taste from aesthetic verdict to epistemic input. The person with taste generates more relevant hypotheses, faster — but those hypotheses still need to be tested. The mechanism: constantly ingesting user feedback (reading every mention of Figma on the internet), asking follow-up questions to find root problems rather than surface requests, and demanding concrete artefacts before changing direction.

The practical expression of taste at Figma: furrowing his brow at complexity and insisting there must be something simpler. Not as a final answer, but as a forcing function for a specific question.

Dylan Field: the taste loop and taste-makers vs. framework-matchers

Dylan Field 2.0 on Figma provides the fullest structural account of how taste is built and deployed:

The loop:

Have an experience across any domain.
React: do I like it? Why?
Build the canon — understand the history and decisions that led to this thing.
Agree or disagree philosophically with that history.
Find cross-domain correlations; repeat.

Two-tier distinction:

Taste-makers (0.01%): create new frameworks — invent genres, find new aesthetics, expand the possibility space. Kurt Cobain’s sound, a new art movement. Cannot be reliably developed; can be recognised.
Framework-matchers (everyone else): learn to understand an established framework and execute within it with high fidelity. Trainable.

Most organisations need both: taste-makers set direction; framework-matchers execute. The most effective product designers can ‘turn taste on and off’ — hold their own aesthetic preferences while matching a brand’s established framework when needed.

Cross-domain exposure strongly predicts taste development: many people with strong product taste were formerly serious musicians. Connecting different fields builds the richer mental map that taste requires.

Max Schoening: taste as virtual machine

Max Schoening on Malleable Software, Agency, and Building Products in the AI Era provides the most operationally precise model of what taste does:

‘Taste is a simulation capability. Given an idea, a person with calibrated taste can run a simulation: for this specific in-group, in this specific context, will this idea resonate?’

The crucial distinction: taste is not ‘I like this.’ Universal aesthetic preference is different from calibrated domain prediction. The latter is learnable and trackable — you can test predictions and update them. The former is harder to train.

How to build it: deliberate exposure. Study world-class work in the domain. Attempt to replicate it. Examine the gap between your attempt and the original. The gap is the instruction.

The Bret Victor reference is central. Victor’s ‘Stop Drawing Dead Fish’ critique argues that tools should allow the creation of live, reactive, interactive things — not dead representations. The principle extends to any design domain: the best work is not a beautiful representation of a concept but a thing that does something. Taste, for Schoening, includes the ability to recognise that difference.

The product implication: taste-as-virtual-machine is useful for evaluating candidate ideas before building them. The question is not ‘do I like this?’ but ‘would my target in-group find this excellent, or merely adequate?’ This connects to the Vibe Coding cost-collapse: when building the first version is cheap, the value of accurate pre-simulation (taste) increases, because it determines which of the many now-buildable things is worth building.

Nan Yu: taste expressed through craft proximity

Nan Yu on Speed, IC-First Product Design, and the Extreme Version Method locates taste at the execution level, not the strategic one.

Her IC-first philosophy holds that the people closest to the pixels — the ICs who build the thing — are also the people best positioned to judge whether it is right. Moving to management abstracts leaders away from that judgement. The best product outcomes come from people with taste who remain close enough to execution to apply it directly, not from managers who try to project taste at a distance.

Her Extreme Version method is taste made operational: build the strongest possible version of an idea first, because attenuated versions leave open the question of whether the idea was right or the execution was weak. The test of whether a hypothesis has real force is whether its extreme form works — which requires enough taste to know what the extreme form actually is.