On Product Judgment
Or why “Taste” isn’t actually where humans are needed in product development
As AI coding tools have gotten more capable and more expected in the product development process, there’s been a lot of conversation about what humans still bring to the table. Two questions keep coming up: how do the three core functions of product, design, and engineering operate in this new world, and where is human involvement still actually needed?
Most of the time, that conversation lands on taste. Humans have taste. AI doesn’t.
I think taste gets brought up so often because it’s vague enough to avoid scrutiny. It can mean entirely different things to different people. And when I push on what people usually mean by it, the answer is roughly: the ability to look at a user’s problem and land on the right solution more often than not.
That’s not a bad description. But it obscures more than it explains. It makes product quality feel intrinsic. You either have taste or you don’t. It treats judgment as something you’re born with rather than something you build.
What people are actually pointing at when they say taste is product judgment. And product judgment is a lot more specific.
Product judgment means having a repeatable process to understand a user’s problems and root causes so deeply that you can reliably identify solutions that help them reach their desired outcome. It means being able to validate those solutions through experimentation, collaboration, and yes, intuition built from experience. And it means doing that well enough, often enough, that you start to recognize patterns.
Those patterns matter. They’re what let you distill a messy set of user problems into the key insight about what’s actually causing them. They’re what let you connect solving that root cause to a clear user outcome. And they’re what let you describe a solution at enough resolution that design and engineering can actually work from it.
That last part is worth dwelling on. A product decision doesn’t just have to be right. It has to be communicable. The problem needs to be defined clearly, not just to you but to your collaborators. The solution needs to be articulated in a way the user can understand. The feature needs to be described at a level of detail where design can work through the interaction model and engineering can assess what exists today versus what needs to exist tomorrow, including the edge cases that make delivery reliable over time.
All of that design and engineering work is downstream of product judgment. Understanding what the problem is. Understanding what the user is trying to accomplish and what’s getting in their way.
Understanding what a good solution looks like, and how it fits within the broader product experience the business already delivers.
None of that is taste. Taste implies you just perceive the right answer. Product judgment means you’ve done the work to earn it.
That work is at bats. Repeat exposure to user problems, enough times and across enough different contexts, that you build real pattern recognition. The product builders with strong judgment aren’t just perceptive. They’ve been wrong enough times to understand why, and right enough times to know what that process looks like when it’s working.
Taste obscures the need for at bats. Product judgment requires them.
The reason this distinction matters now is that AI tools are genuinely changing what the job looks like. They can write code. They can generate designs. They can prototype ideas quickly. The parts of product development that used to require a large team and a long timeline can now move much faster.
But none of that changes what judgment is, or who has it. The AI doesn’t know which problem to solve. It doesn’t know whether the solution fits the user’s mental model. It doesn’t know whether the feature coheres with the rest of the product, or whether the business can feasibly deliver it on a timeline that makes sense.
Those are still human questions. And the ability to answer them well, consistently, is what product judgment means.