Taste in product management is the ability to sense what will feel right to users before any dataset can confirm it — a trained pattern-recognition skill built from thousands of deliberate exposures to products, decisions, and their outcomes, not a gift some PMs are born with. Data tells you what already happened. Taste tells you what to build next, and it's the single most underdeveloped skill on most consumer product teams.
Taste is not intuition, luck, or personal preference dressed up in nicer language. It is pattern recognition, built the same way expertise is built in any craft: through repeated, deliberate exposure to good and bad work, paired with active reflection on why one choice beats another.
What Taste Actually Means in Product Work
Taste is the compressed judgment that lets a PM look at two versions of a screen, a flow, or a sentence and know — before a single user sees either — which one respects the person on the other end. It is built, not inherited, and it decays without practice just like any other skill.
This is the essence of consumer product judgment: recognizing what will feel right before the data exists to prove it. Don Norman's framework in Emotional Design gives useful vocabulary here. He describes three levels of processing: visceral (immediate, sensory reaction), behavioral (does it work, is it usable), and reflective (what does using this say about me, how do I feel about it afterward). Data-only PMs are fluent in the behavioral level — conversion, completion, error rate. Taste operates mostly at the visceral and reflective levels, which A/B tests are notoriously bad at capturing because they measure clicks, not meaning.
Anders Ericsson's research on expertise, popularized (and somewhat oversimplified into the "10,000 hours" shorthand) in his book Peak, found something more precise: expert performers across domains built judgment through years of deliberate, feedback-rich practice — not raw exposure or natural talent. The same holds for product taste. Using a hundred apps passively teaches you less than dissecting ten apps on purpose.
If you're newer to the discipline generally, the complete guide to the consumer PM role covers the fundamentals this article builds on, including how consumer PM work differs structurally from enterprise product roles.
Taste Is Not the Same as Opinion
A PM with taste can articulate why a choice works and predict how a different audience might react differently. A PM with only opinions just prefers one thing over another and calls it insight. The test is simple: can you defend the choice to someone who disagrees, using a reason that isn't "I like it"?
- Opinion: "This shade of blue feels more premium."
- Taste: "This shade of blue reduces contrast with our error states, which matters because our users scan for red before they scan for anything else — the same reason airlines never use blue as a warning color."
Where Taste Matters Most Across the PM Landscape
Taste is not evenly distributed in importance across PM archetypes, because it's a function of how directly the PM's decisions touch a human's felt experience.
- Design PMs live almost entirely in taste — it's arguably the core competency the design PM role is built around, since design PMs are hired specifically to be the taste check on a team.
- Enterprise PMs can often ship on logic and ROI math alone, because the enterprise PM role usually separates the buyer from the daily user — taste matters, but it competes with procurement and compliance for priority.
- DevTools PMs need a narrower but sharper form of taste: developer experience. The devtools PM role rewards PMs who can feel when an API's naming or an error message will make an engineer trust or abandon a product in the first five minutes.
- Mobile PMs live and die by micro-interactions — the haptic on a swipe, the easing on a transition — which is why the mobile PM role treats taste as closer to table stakes than a bonus skill.
Consumer PMs sit at the highest-stakes intersection of all of these: no procurement buffer, no developer forgiveness, and a user who will simply leave without complaint if the product doesn't feel right.
The Data-Only PM vs. the Taste-Driven PM: A Streak-Loss Case Study
The clearest way to see the difference between data-only and taste-driven product judgment is to watch two PMs solve the same small, ordinary problem: what happens on screen when a user breaks their daily streak in a habit-tracking app. Both PMs have the same data. They make different decisions and defend them differently.
The data-only PM runs an experiment: a red badge, a countdown timer, and copy that reads "Don't lose your streak!" against a control with no urgency treatment. The variant lifts short-term re-engagement and premium upsell clicks, so it ships. The funnel conversion rate improved; the decision looks settled.
The taste-driven PM asks a different first question: what does this moment mean to the person experiencing it? They've used enough habit apps, journaled enough teardown notes, and watched enough friends quietly delete apps that guilt-tripped them, to recognize the pattern before it needs a test. They propose a warmer variant — acknowledging the miss without manufacturing anxiety — and argue for tracking 90-day retention, not two-day clicks, as the real scoreboard.
| Signal | Data-only PM | Taste-driven PM |
|---|---|---|
| What they measure first | funnel conversion rate, click-through on the urgency badge | Reflective response — does this build trust or extract it |
| Time horizon | 48-hour experiment window | 90-day retention and word-of-mouth sentiment |
| Reference point | The winning variant in isolation | Dozens of comparable apps' streak/guilt patterns, journaled over time |
| Risk if wrong | Optimizes a local metric while eroding long-term brand trust | Slower to validate, harder to defend in a metrics-only review |
| Underlying framework | Standalone A/B test | Kano model attractive-quality thinking + emotional design |
Neither instinct is wrong on its own — the mistake is only trusting one. The taste-driven PM still wants the data; they just refuse to let a 48-hour lift override a pattern they've seen fail on a dozen other products before. This same tension, mapped across a full user journey, is covered in our piece on the emotion curve at consumer scale, which shows how a single high-friction moment can undo months of accumulated trust.
Why A/B Tests Can't Tell You What to Build Next
A/B tests are unmatched at answering which of two existing things performs better, and almost useless at answering what the third, unbuilt thing should be. They optimize what already exists on the roadmap. They cannot originate the option nobody has proposed yet, which is where taste has to lead instead of follow.
This is precisely the gap Noriaki Kano's model was built to name. Kano's original research sorted product attributes into three buckets: must-be (its absence causes dissatisfaction, its presence is barely noticed), performance (more is linearly better), and attractive (delighters nobody asked for, which is where taste lives). You cannot survey your way to an attractive-quality feature, because customers can't request what they've never imagined — someone has to have the taste to propose it first, and only then can data confirm or kill it.
Three structural limits explain why testing alone stalls a roadmap:
- Local maxima. Optimizing button copy or color forever improves a metric by fractions of a percent while a fundamentally better flow goes unexplored.
- Novelty and regression effects. Short experiment windows reward whatever is newest, not whatever is best, which is why so many "winning" variants quietly decay after a few months.
- You can only test what you can imagine to build. Malcolm Gladwell's Blink describes how experts make fast, accurate judgments — "thin-slicing" — built on the same trained pattern recognition that lets a taste-driven PM propose an option worth testing in the first place.
Rick Rubin makes a related point in The Creative Act: taste is less about generating more options and more about noticing, faster than anyone else in the room, which of the available options is actually good. That noticing has to happen before the test, not instead of it.
The Taste Regimen: Three Practices That Build Judgment
Taste is trainable through a specific, repeatable regimen — not a personality trait you either have or don't. Three practices, done consistently, build the pattern library that lets a PM recognize quality quickly: teardown journaling, a reference library, and articulation practice.
1. Teardown Journaling
Pick one product interaction a day — a checkout flow, an onboarding screen, an error state — and write down what it does, why it probably works, and what you'd change. The habit matters more than the depth; five minutes daily compounds faster than one deep session per month.
2. A Reference Library, Organized by Feeling
Most PMs bookmark competitors. Fewer organize references by the emotional job the pattern does — "reassurance after an error," "delight on first success," "graceful decline of a request." Tag by feeling, not by category, and the library becomes searchable the moment you need it.
3. Articulation Practice
The discipline that separates taste from vibes is being able to say, out loud, in a sentence a skeptical engineer or a data-driven exec would accept, why something feels right. If you can't articulate the reason, you don't have taste yet — you have a preference.
| Practice | Cadence | Output | Builds |
|---|---|---|---|
| Teardown journaling | Daily, 5-10 min | One written note per teardown | Raw pattern exposure |
| Reference library | Weekly curation | Tagged screenshot/clip collection | Searchable pattern memory |
| Articulation practice | Every decision review | One-sentence rationale, defensible without "I like it" | Communicable judgment |
| Calibration with peers | Biweekly | Disagreement resolved with reasons, not seniority | Shared team taste |
A fourth practice worth adding once the first three are habits: calibration sessions with other PMs or designers, where you each defend a taste call and argue the disagreement out loud. Developing product taste that only lives in one person's head doesn't scale to a team's roadmap.
Building the Observation Habit in the Wild
The regimen above only works if the observation happens in the moment, in the wild — not reconstructed from memory during a Monday retro when the specific friction has already faded. The gap between noticing something and writing it down is where most taste-building intentions quietly die.
None of this replaces the discipline of the regimen — you still have to review the entries, look for repeat patterns, and force yourself to articulate why something worked. But the entries have to exist first, and reliably enough, before any pattern recognition can compound.
Key Takeaways
- Taste is trainable pattern recognition, not an innate gift — it compounds through deliberate, structured repetition, the same way Ericsson's research shows expertise compounds in any craft.
- Data tells you what happened; taste tells you what to build next —
A/B tests optimize existing options but cannot originate the option nobody has proposed yet. - The Kano model's "attractive quality" category explains why delighters can't be surveyed into existence — someone with taste has to propose them before data can confirm them.
- A concrete regimen beats vague aspiration: developing product taste happens through teardown journaling, a feeling-tagged reference library, and forced articulation — the three practices that build judgment fastest.
- Taste needs a defensible reason, not just a preference — if you can't explain why something feels right to a skeptical stakeholder, it isn't taste yet.
- Consumer PMs carry the highest taste burden of any PM archetype, because there's no procurement buffer or developer goodwill standing between a bad decision and a user who quietly leaves.
Frequently Asked Questions
Can product taste be learned, or is it innate?
Product taste is learned, not innate — it's trained pattern recognition built through repeated, deliberate exposure to good and bad product decisions, the same mechanism behind expertise in any skilled craft. PMs who assume taste is a fixed trait tend to stop practicing it, which is precisely why it stays underdeveloped.
How do you develop product taste as a PM?
Developing product taste happens through a repeatable regimen: daily teardown journaling of real product interactions, a reference library organized by the feeling a pattern produces rather than its category, and forcing yourself to articulate a defensible reason for every taste call. Consistency over months matters more than any single deep dive.
How do you defend a taste-based decision to data-driven stakeholders?
Defend a taste-based decision by naming the specific pattern you've observed elsewhere, the framework it maps to (like Kano model attractive quality or JTBD emotional job), and the metric horizon a short experiment can't capture, such as 90-day retention over 48-hour clicks. Pair the case with a plan to instrument the longer-term signal, not just an assertion.
Is taste more important for consumer PMs than for enterprise PMs?
Taste matters more directly for consumer PMs because there's no buyer standing between the decision and the person who feels it, whereas enterprise PMs, as covered in the enterprise PM role guide, often answer to a procurement process that weighs taste against contractual and compliance priorities.
What's the difference between design taste and product taste?
Design taste focuses on visual and interaction quality — spacing, motion, typography — while product taste extends further, into judging which problem is worth solving and which small emotional moment in a flow will make or break trust. The design PM role guide covers where these two skill sets overlap and diverge.