Who Doesn't Want Ice Cream?

Everybody wants ice cream.

Kids want it. Adults want it. Boards want it. Your CEO wants it badly, and they want it by the board meeting in three weeks. Nobody in the history of product development has ever walked into a room and said, "Actually, let's not have the ice cream."

That's the problem.

I've spent the last year watching product teams sprint toward AI the way a five-year-old sprints toward an ice cream truck. Sirens playing, bell ringing, someone waving a menu board with flavors that didn't exist eighteen months ago. And I get it. The technology is genuinely remarkable. But I've also watched a lot of teams eat the whole tub in one sitting, get sick, and blame the ice cream instead of themselves.

So let's talk about ice cream. What it's good for, what it isn't, and how to enjoy it without the stomachache.

The Two Teams

I keep coming back to this framing because it keeps showing up, in every domain, every time a powerful new capability arrives. There are two kinds of teams right now.

The first team sees AI as a flavor. Something you add to the existing menu because customers are asking for it, competitors are shipping it, and the board wants a slide that says "AI-powered" on it. This team bolts a chatbot onto the product, slaps a summarization feature on the dashboard, and calls it a strategy. They're not solving a customer problem. They're serving a scoop because everyone else is.

The second team sees AI as an ingredient. Something that changes what's possible in the kitchen, not just what's on the menu. This team starts with the customer problem, the same discipline that's always separated good product work from bad, and asks a harder question: does this new ingredient let us solve that problem in a way we genuinely couldn't before? Sometimes the answer is yes, and it's transformative. Sometimes the answer is no, and they don't build it, no matter how loud the FOMO gets.

Both teams will ship AI features this year. Only one of them will have customers who actually want seconds.

You can usually tell which team you're on by how the roadmap conversation starts. If the conversation begins with "AI can now do X, what should we build with it," you're probably on the first team, working backwards from a capability toward a justification. If the conversation starts with "customers are stuck at this exact point in their workflow, and here's why nothing we've tried has fixed it." AI happens to be part of the answer, and you're on the second team, working forward from a real problem toward whatever tool actually solves it. The order matters more than people want to admit. Capability-first thinking produces features. Problem-first thinking produces products. Only one of those survives contact with a renewal conversation.

What's Genuinely Great About the Ice Cream

I don't want to be the guy standing outside the ice cream shop with a clipboard telling everyone about lactose intolerance. The capability is real. Let's be honest about what's good here, because pretending otherwise is its own kind of dishonesty.

It removes real friction. For certain classes of problems, especially ones involving synthesis, drafting, and pattern recognition across large amounts of unstructured information, AI collapses work that used to take hours into work that takes minutes. That's not hype. That's an engineer generating a first draft of a data migration script, a support rep getting a summarized history of tickets instead of scrolling through 40 replies, or a founder getting a rough cut of a competitive landscape in an afternoon instead of a week.

It lowers the cost of exploration. Product discovery has always been expensive, which is exactly why so many teams skip it. AI makes it cheaper to prototype, cheaper to test a concept with a handful of users, and cheaper to throw an idea away on day two instead of day sixty. Anything that makes discovery cheaper is a gift to product teams, full stop.

It's genuinely good at certain kinds of judgment. Not all judgment. But for narrow, well-scoped judgment, on well-bounded problems with good data, it can be excellent. For example, categorization, triage, first-pass drafting, and anomaly flagging. These are real capabilities, not demos.

That's the good scoop. Now let's talk about what happens after the sugar rush.

What Teams Conveniently Forget to Mention

The cost doesn't show up on the receipt at the counter. I wrote about this in a piece I called "Code is Cheap, Judgement Isn't.", and the ice cream analogy holds up well there too. The first scoop is cheap. AI-generated code, AI-generated content, or AI-generated anything. It's fast, and it's nearly free at the point of creation. But somebody has to maintain it. Somebody has to understand it well enough to debug it, extend it, and explain it to a new hire eight months from now. Teams that treat generation speed as the entire cost of ownership are the same teams that will be paying it back with interest for years.

It melts the moment you stop paying attention to it. AI outputs are only as good as the humans checking them, and there's a very seductive failure mode where teams start skipping the checking because the outputs have been right the last dozen times. Confidence creeps up faster than competence does. I've talked to teams shipping AI-drafted customer communications, AI-summarized legal terms, or AI-generated financial projections, with a review process that's basically a rubber stamp at this point. That's not a technology problem. That's a discipline problem, and it existed long before AI did. AI, however, makes it faster to be wrong at scale.

Not every flavor belongs on your menu. This is the FOMO trap. An available capability doesn't mean it's the right capability for your product, your customers, or your team's actual constraints. I see roadmaps now with an "AI feature" sitting on them not because it maps to a validated customer problem, but because leadership needed something to say publicly. That's marketing wearing a product hat. It's the same mistake teams have always made with any hot technology, going back to blockchain, big data, or whatever the shiny thing was in whatever decade you started your career. While the tech changes. The mistake doesn't.

Someone must taste it before you serve it to customers. I keep meeting teams who've automated their way past their own judgment. They've built a pipeline where AI drafts something, another AI reviews it, and a human glances at a dashboard once a week. That's not oversight. That's outsourcing your taste buds to a machine and hoping it likes what your customers like. It sometimes does. It sometimes very much does not, and you find out from an angry customer, not from your own review process.

The team that eats fastest isn't always the team that eats best. There's a real cultural cost to moving at AI speed without the underlying discipline to match it. I've seen product teams start skipping discovery entirely because "we can just build it and see," treating AI-accelerated development as a replacement for talking to customers rather than a tool that should free up more time for it. That's backwards. The teams getting real advantage from AI are using the time savings to do more discovery, not less. The teams getting hurt are using it as an excuse to skip discovery altogether.

How to Actually Partake Responsibly

None of this means don't eat the ice cream. It means eat it like an adult who's had ice cream before and knows what a stomachache feels like.

Start with the problem, not the flavor. Before any AI feature gets a line on the roadmap, it must answer the same question every other feature must answer: “What customer problem does this solve, and how do we know it's a real problem worth solving?” If the honest answer is "Customers keep asking if we have AI.", that's not a customer problem. That's a perception problem, and perception problems deserve perception solutions, not engineering ones.

Keep a human in the loop who's actually qualified to be there. Not a rubber stamp. Not a glance at a dashboard. A real reviewer with real domain expertise, checking real outputs, with real authority to say no. This is more expensive than it sounds, and that expense is the point. If you can't afford proper oversight of an AI-driven process, you can't afford the process, no matter how cheap the generation step looks.

Separate the demo from the product. A great demo tells you the capability exists. It tells you almost nothing about whether it's reliable, whether it fails gracefully, or whether it holds up outside the three examples you tested. Teams that confuse demo-readiness with production-readiness are the ones who ship something impressive in a sales call and embarrassing in production three weeks later.

Budget for the second scoop, not just the first. Every AI-generated asset, whether it's code, content, or a customer-facing decision, carries an ongoing cost of understanding, maintaining, and correcting it. Build that into your planning honestly. If a feature makes financial sense only because you're ignoring its maintenance cost, it doesn't actually make financial sense.

Let AI buy you back discovery time, not delete it. The single best use of AI-driven efficiency I've seen in product teams isn't shipping more features faster. It's reclaiming hours that used to go to grunt work and reinvesting them in actual conversations with actual customers. If your AI adoption is making your discovery process thinner instead of deeper, you've got the equation backwards.

Ask who actually wanted this, and be honest about the answer. Not "Who will use this if we build it?", but who asked for it, unprompted, with a real problem attached. If the honest list of names is short and mostly internal, that's useful information. It doesn't mean don't build it. It means know exactly why you're building it, and don't fool yourself into thinking customer demand exists when what actually exists is competitive anxiety.

Write down what "good enough" actually means before you ship. One of the quieter failure modes I see is teams that never define an acceptable error rate, an acceptable failure mode, or a clear line for when a human needs to step in. Without that line established in advance, it will drift downward every time the team gets comfortable. Decide in writing what you will and won't tolerate before launching. Revisit it deliberately. Don't let it erode by default.

The Stomachache Is Optional

Here's the thing about ice cream. It's not dangerous. It's not the enemy. The stomachache is never really the ice cream's fault. It's the portion, the pace, and the complete absence of anyone asking whether you actually needed a second bowl.

The teams that will look smart in two years aren't the ones who ate the fastest in 2026. They're the ones who ate with some discipline, kept their judgment intact, and used the extra time and margin AI gave them to get closer to their customers instead of further away.

Everybody wants ice cream. That was never the interesting question.

The interesting question is who's still going to want what you're serving after the novelty wears off, and whether you'll have anything left in the tank, or the team, or the customer relationship, to find out.