A few years ago, the hardest part of building a product was building it. You hired the engineers, you funded the roadmap, you survived the integration, and if you ran the machine well, you won. The CEO's job was to fund execution and then get out of its way.
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. I have watched this happen inside my own orgs, and I have watched it happen to competitors who were a year behind and are now in front. When everyone can build anything, building is no longer the advantage. The advantage moves upstream, to the decision about what to build at all.
The short version
Taste is the last moat. 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. CEOs who stayed close to the product kept their taste sharp while the cost of building fell around them. The ones who delegated product judgment along with execution are now running companies they can no longer feel. The move is to protect and encode taste, not to hire around it.
For the operating system underneath this, see the Product Operating Model. For how judgment becomes the org's job once execution is automated, see PM as a Team of AI Agents.
What actually got automated
It is worth being precise about what AI took off the table, 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. The marginal cost of producing a candidate solution dropped toward zero. That is real and it is permanent.
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. Generation produces options. Selection is judgment about options. The more options you can generate, the more the bottleneck moves to the quality of your selection.
This is why I keep telling founders the same thing: AI did not replace product judgment, it raised the price of not having it. When you could only build three things a quarter, a mediocre instinct about what to build cost you a little. When you can build thirty, that same mediocre instinct compounds into thirty mediocre things and a brand nobody trusts.
Why this lands on the CEO specifically
Execution was always delegable. That is not a knock on it. Building a great engineering org, a disciplined release process, a clean handoff between design and build, those are hard, valuable, and entirely transferable. You write down how it works, you hire people who are better at it than you, and you step back. I did exactly this at Salesforce and again at Smartcat, and it worked.
Taste does not transfer that way. It is not a process. It is the compressed residue of having shipped real things to real customers and lived with the consequences. You cannot onboard someone into your taste in two weeks. You cannot put it in a Notion doc. And critically, you cannot get it back quickly once you have let it atrophy.
That is the trap. For a decade, the smart move for a scaling CEO was to delegate product down and out, to trust empowered teams, to resist the urge to be in the weeds. Good advice for its time. But a lot of CEOs delegated execution and taste in the same motion, and now that execution is commoditized, they are left holding the one thing that was supposed to be theirs and discovering it has gone soft.
How taste goes stale
It rarely happens in one decision. It erodes through distance. Three layers, in the order they usually accumulate:
First, you stop using your own product. You get briefed on it instead. The dashboard becomes the product in your mind, and the dashboard is a lossy compression of the actual experience.
Second, you stop sitting in customer conversations and start reading the synthesis. The synthesis is useful, but it launders out the texture, the hesitation in someone's voice, the workaround they built because your product failed them. That texture is where taste gets fed.
Third, you start seeing the work only after the metrics arrive. By then the bet is placed and the judgment that mattered already happened without you. You are now grading, not deciding.
Each layer is reasonable on its own. 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 you should not try. The fix is to protect the specific inputs that keep judgment sharp, and to build systems that extend your taste rather than replace it.
Three practices I hold myself to, and ask the product leaders I work with to hold:
Use the product every week, as a real user, on a real task. Not a demo. Not a walkthrough. Feel the friction your customers feel.
Sit in real customer calls, unedited, at least a few a month. Not the summary deck. The actual conversation, where the gap between what you think you built and what they experience shows up.
Review the work before the metrics do. Put your judgment in front of the bet, not after it. If you only ever see things post-launch, you have outsourced the decision that mattered.
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 is the bridge from personal taste to organizational standard. It does not clone your eye, but it keeps the bar from collapsing the moment you step back. For how that machinery works, see the eval-first product org.
The plain version
For twenty years the question was "can we build it." The answer is now almost always yes, and almost always fast. The question that decides who wins is "should we, and is this version actually good." That question is taste, and it is sitting on your desk whether you want it there or not.
You can delegate the building. You cannot delegate the judgment about what is worth building. Protect it like the asset it has become. 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.
If you are a founder or CEO trying to rebuild your proximity to the product without slipping back into micromanagement, that tension is most of the job now. Find me on LinkedIn.
Further reading
Also on Medium
Full archive →Frequently asked
What does 'taste' mean in a product context?+
Taste is the accumulated judgment about what to build, what is good enough to ship, and what looks impressive but fails in production. It is pattern recognition earned by shipping, being wrong, and feeling the cost. In an era where building is cheap, taste is the scarce input that separates products that win from products that merely exist.
Why can't a CEO delegate product taste the way they delegate execution?+
Execution is a process you can document, staff, and hand off. Taste is not. It is the residue of someone's experience and exposure to real customers. You can build systems that scale a leader's taste, but you cannot transfer the judgment itself by hiring around it. The leaders pulling away stayed close to the product on purpose.
How do I know if my product taste has gone stale?+
Three tells: you read dashboards instead of using the product, you get customer feedback as summaries instead of sitting in the calls, and you see the work only after the metrics come in. Each one is a layer of distance between you and the actual experience. Distance dulls judgment faster than anything else.
Can taste scale beyond one founder or CPO?+
Partly. You cannot copy a person's judgment, but you can encode the rules it produces into published eval rubrics, review rituals, and hiring filters. That turns one person's taste into a system the org can run against. It will not replace the founder's eye, but it keeps the bar from collapsing when they step back.
Isn't 'taste' just a vague excuse for not having metrics?+
No. Taste decides which metrics matter and what the experience should feel like before any metric exists. Metrics tell you whether you were right after the fact. Taste is what you use to make the bet in the first place. You need both, but only one of them can be automated, and it is not taste.
Comments (0)
Sign in with LinkedIn to leave a comment.
Sign in with LinkedIn