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.