You Can't AI Automate Product Taste
Why judgement, not velocity, builds better products
In my last post, I wrote about how AI won’t replace product managers; it will simply expose whether a team is thinking clearly or just shipping outputs. That post ended with a question I couldn’t stop thinking about:
If speed isn’t the differentiator anymore, and if AI can generate features, documents, and test cases, then what actually separates a strong product team from a busy one?
For me, it comes down to product taste.
Not aesthetics. Not instinct. Not “strong opinions on design.”
I’m talking about the ability to make sound product decisions when things are ambiguous, data is incomplete, people are pulling in different directions, and delivery pressure is high. The ability to decide what should be built, what shouldn’t be built, and why.
That’s product taste.
The first time I heard someone use that term out loud was Shreyas Doshi during a live session with Lenny Rachitsky. He described taste as discernment — built from exposure, reflection, and foresight — the ability to recognize what is truly good before the metrics or market prove it. I had already seen this in product work, but hearing Shreyas name it so clearly — product taste — gave language to something I had felt for a long time but never described this way.
What Product Taste Actually Is
Product taste isn’t about who has the boldest ideas in the room or who speaks with the most confidence. It’s not about having perfect instincts. It’s the ability to make thoughtful product decisions when the answer isn’t apparent.
It shows up in moments like:
Choosing not to build something, even when it’s easy or politically popular.
Seeing a feature request and asking, “What problem is this solving? For whom? And what happens if we don’t do it?”
Knowing when data matters, and when waiting for perfect data becomes an excuse not to act.
Being able to explain a decision clearly to stakeholders, users, and engineers — not with buzzwords, but with logic.
To me, product taste is a mix of:
Understanding users deeply: not through personas but real behavior, pain, and workarounds.
Domain and systems awareness: how your product fits into a larger ecosystem of tools, constraints, processes, policy, and operations.
Discernment: sensing when something is off, even if you can’t prove it yet.
Courage: saying “this isn’t right” when it would be easier just to deliver.
Focus: being able to say this matters right now; this doesn’t.
Why Product Taste Is Rare (And Often Punished)
In most companies, product taste doesn’t disappear because people aren’t capable. It disappears because the system doesn’t reward it.
I’ve seen this repeatedly:
Delivery is praised more than decision quality.
Asking “why” is seen as slowing things down.
PMs sit in meetings, build slide decks, and update JIRA, with zero time to think.
Data is used to justify decisions that were already made, not to learn from experiments.
Success is measured by the number of features shipped, not by behavior changed or outcomes delivered.
And when someone shows judgment by slowing down or asking better questions, they get labeled “difficult” or “not a team player.”
So people stop trying.
Product taste doesn’t die from lack of intelligence. It dies from lack of oxygen.
The Glimmer of How Taste Starts
Taste almost always begins as a shift in attention. A PM stops writing user stories without context. They stop accepting every request as a requirement.
They start asking:
Who is this for?
What problem are we solving?
Why now?
What does success look like?
What happens if we don’t do this?
They notice friction in the user experience. They pick up when a feature solves a stakeholder request, but not a user problem. They feel bothered when something “almost works” but not quite.
This early awareness is fragile. If encouraged, it grows. If ignored, it disappears.
How Product Taste Matures
This growth isn’t a title change. It’s not a promotion. It’s a progression in how someone thinks and makes decisions.
Here’s a simple way to describe the Stages of taste and how it show up:
Compliance: “Tell me what to build.” Executes tasks. Measures success by delivery.
Curiosity (the glimmer): Starts asking why, for whom, and what problem.
Problem Clarity: Can define the real problem and how people solve it today without us.
Outcome Thinking: Moves from output (“we shipped it”) to outcome (“did it change behavior or value?”).
Systems Thinking: Sees second-order effects — operations, support, risk, timing, team energy.
Strategic Taste: Can clearly say what not to build, shapes priorities, and aligns teams to outcomes.
It is important to note that this isn’t a certification or status symbol. No one crowns you “Strategic Taste Level 6.”
You can operate with ‘strategic taste’ in one decision and slip back into ‘compliance’ in another.
It’s not authority, it’s a pattern of behavior and habit of intentionality.
What Mature Taste Looks Like in Real Product Work
When product taste develops, it doesn’t sound loud or theoretical. It shows up in small, consistent decisions:
When a feature request arrives, a PM doesn’t jump into timelines; they pause to understand the goal, who benefits, and what saying yes will cost in time, focus, debt, or operational pain.
When data is incomplete, they don’t wait for certainty. They run a test, prototype, or phased rollout.
When leadership pushes something misaligned, they don’t escalate emotionally; they bring the conversation back to outcomes and impact.
They can explain why not now just as clearly as why now.
They think in systems, not just their feature or dashboard.
A Personal Reflection
I’m not writing about product taste as someone who has mastered it. I’m writing about it because I know how easy it is to lose without intentional practice.
In my work, I’ve seen what happens when teams don’t make space to think. We build features that tick every box except the one that matters: did it solve a real problem for a real person? That’s not a failure of process. That’s a lack of product taste.
The changes I’ve pushed for in teams — moving from PI planning to continuous planning, structuring teams around problems rather than projects, measuring outcomes rather than delivery — weren’t about taste specifically. They were about creating the conditions for better decisions to happen more often.
Even then, it’s not automatic. Product taste isn’t something you acquire once and keep forever. It’s something you practice every day, or it slips. It takes effort to ask the harder question rather than run with the easy answer. It takes effort to pause, to think, to say “this doesn’t feel right” when everyone else just wants to move forward.
Some PMs leaned into that practice. They asked better questions, got curious, read more, experimented more. Others did the opposite — stayed in project mode, managed timelines, escalations, and outputs. Same environment. Very different mindset.
That’s the point: taste isn’t a title or a level. It’s how you choose to approach the work, especially when no one is asking you to.
Where This Leads
If AI removes the excuse of “I don’t have time to think,” then the only real differentiator left is judgment. Taste.
Not everyone will develop it. Not everyone wants to.
But the teams that do, don’t just ship faster, they ship things that matter.
In the next post, I’ll write about how to actually practice product taste — especially when you don’t have direct access to users, time is limited, and you’re still expected to deliver.