Is taste the last moat in product?

THE SHORT ANSWER

Yes. When execution costs almost nothing, the scarce input becomes judgment: which problem is worth solving, which version is good enough to ship, which feature dazzles in a demo and dies in production. That judgment is taste, and unlike execution it cannot be cleanly delegated, because it is the accumulated pattern recognition of someone who has shipped, been wrong, and felt the cost. Generation got cheap; selection did not. AI did not replace product judgment, it raised the price of not having it. The move is to protect and encode taste, not to hire around it.

A few years ago the hardest part of building a product was building it. You hired the engineers, funded the roadmap, survived the integration, and if you ran the machine well you won. That world is ending faster than most boards have priced in. The cost of building has collapsed: a small team with the current agent stack ships in a week what used to take a quarter. When everyone can build anything, building is no longer the advantage. The advantage moves upstream, to the decision about what to build at all.

What actually got automated

It helps to be precise, because the imprecise version ("AI does product now") leads to bad decisions. What got cheap is generation: code, copy, mockups, first-draft analysis, the entire production layer. What did not get cheap is selection: deciding which candidate is worth shipping, which problem deserves a candidate in the first place, and which polished-looking output is quietly wrong. The more options you can generate, the more the bottleneck moves to the quality of your selection. AI did not replace product judgment, it raised the price of not having it. When you could build three things a quarter, a mediocre instinct cost you a little. When you can build thirty, that same instinct compounds into thirty mediocre things and a brand nobody trusts.

How taste goes stale

It rarely happens in one decision. It erodes through distance, in three layers: you stop using your own product and get briefed instead, you stop sitting in customer calls and read the synthesis, and you start seeing the work only after the metrics arrive. Each is reasonable alone. Stacked, they turn a founder with sharp instincts into an executive who approves things.

What to do about it

The fix is not to stop delegating; you still cannot personally build the product and should not try. The fix is to protect the specific inputs that keep judgment sharp. Three practices I hold myself to and ask the leaders I work with to hold: use the product every week as a real user on a real task, not a demo; sit in real customer calls unedited, at least a few a month, not the summary deck; and review the work before the metrics do, so your judgment is in front of the bet rather than after it. Then, because one person's taste does not scale, encode it. The rules your judgment produces (what good looks like, what we refuse to ship, what bar a feature has to clear) can be written into published eval rubrics and review rituals. That does not clone your eye, but it keeps the bar from collapsing the moment you step back.

For twenty years the question was "can we build it." The answer is now almost always yes, and fast. The question that decides who wins is "should we, and is this version actually good." Pick one of the three practices above and put it on your own calendar this week, before the next thing ships without your eye on it.

SOURCES

THE LONG VERSION

RELATED ANSWERS

Last reviewed 2026-07-31 · 3 min read