AI made the kitchen faster. The guest still eats one meal.

AI makes the kitchen faster. The guest still eats one meal.

Every product team I talk to builds faster this year than last year, and AI is a large part of the reason. An idea that waited on the shelf for two quarters now becomes a working prototype in an afternoon, and I like that.

The trouble starts when "we can build it quickly" turns into "we should put it in the product", because those are two separate decisions and only the first one got cheaper.

Think of a restaurant kitchen that gets a machine which cooks any dish in five minutes. The chef can now put sixty dishes on the menu instead of twelve, and from inside the kitchen that looks like progress. The guest still has one stomach, one evening, and one menu to read before the waiter comes back. A sixty-dish menu asks more of the guest and still gives them one meal.

Your customer does not get the machine

Your team may ship more features this month than it did last year. Your customer still has the same job, the same working day, and the same amount of attention. Every new feature asks something of them: they have to notice it, understand it, decide whether it matters, change a habit or learn a new workflow, and work out which of the options solves their problem.

Each feature can make sense on its own while the sum of them buries the customer, in the same way that every dish on the sixty-dish menu can be good while the guest leaves without knowing what the restaurant is for. The work of keeping things simple belongs to the team. We do that work before we ship, by deciding what stays off the menu, so the customer never has to do it for us.

A prototype is a tasting spoon

A prototype lets you explore an idea, the way a chef tastes a sauce from a spoon before it goes anywhere near a plate. A product is a promise to every guest who orders it, every night. It has to work reliably, fit into what is already there, respect security and privacy, and keep working as the business grows. Around the code sits everything else: explaining the feature, supporting it, maintaining it, and keeping the promise you made when you released it.

When the feature is wrong, the cost goes further than wasted development time. Customers get confused, the reason to buy your product gets harder to explain, and trust drops. AI lowers the cost of making something you can touch. It does not lower the cost of making it dependable, or the cost of putting the wrong thing in front of people. A cheap prototype is a reason to taste more often, and each taste still needs someone who knows what the sauce should taste like.

Research does more than save engineering time

When development was expensive, research had an easy argument: find out what matters before you commit a team to a costly build. Now that some development is cheap, that argument looks weaker, and teams start to ask why they should interview customers when they could build something and see what happens.

Sometimes building is the right way to learn, because a small experiment you can undo shows things a conversation cannot. That experiment still needs a question behind it: who it is for, which uncertainty it removes, and what result would count as evidence. Without those three answers, "build to learn" turns into "ship and hope", and the fix costs ten minutes: write the three answers down before anyone opens the editor.

Research also tells you where you deserve a place in your customer's working day. What are they trying to get done? Where do they get stuck? What did they already try, and why does their workaround survive? What would make a change worth the effort for them? Those questions matter even when the first version costs almost nothing to build.

The cheaper it gets to build, the more a customer interview is worth.

Go deeper before you go wider

As neighbouring features get easier to produce, the pull to add them gets stronger. You solve one problem, and then you could add messaging, reporting, an assistant, another workflow, and another dashboard. Each addition sounds reasonable, and together they make it harder to say what your product is for.

The chef who stays good does not keep the menu short out of principle; they cook fewer dishes and know why each one is there. Your product is one piece of the customer's larger puzzle. Your job is to understand the gap well enough that your piece fits, and you can leave the rest of the puzzle to others.

That takes more than asking customers which features they want. A guest who hears "which dish are you missing?" will name one, you will cook it, and nothing about their evening changes. You learn more from the plates that come back half full: the trigger that made someone look for help, the struggle, the alternatives they tried, and the outcome they wanted. Depth shows in how much difficulty you remove for the customer, and a settings page with forty options removes none.

Better research starts with a better conversation

A customer interview in the calendar is not research yet. I see three habits that turn interviews into confirmation research, which is a confident summary of what the team already believed: a fixed discussion guide, the question "what feature are you missing?", and nobody looking back at the interview afterwards. The fix for the first two habits is to ask about events that already happened:

"Tell me about the last time this happened."

"What made you look for a different solution?"

"What did you try?"

"What made that hard?"

The fix for the third habit is to listen back to the interview, or have someone else mark it, and then to look across several conversations for patterns before any request becomes a backlog item.

With AI, talking to humans is the only skill left. AI can sort and summarise your interviews, but it cannot sit with your customer, hear the sentence nobody expected, and decide what it means.

For customer-facing work, one test helps: can you link this backlog item to several customers who struggle with the same thing? That test is no voting rule, because technical obligations and strategic bets need their own reasons. It does show quickly when a backlog has drifted away from the people it is for.

What I do not know yet

I do not know yet whether faster building will make teams ship more, or whether some teams will spend the saved time talking to more customers. I also have no number for how much attention a customer has left for one more feature. I suspect it is less than most roadmaps assume, and I would like to measure it.

The kitchen decides what reaches the table

Faster building gives a team more options and tells it nothing about which options are worth choosing. The product team still decides where to focus, what to leave out, and how to turn complexity into something a customer can use, in the same way the chef decides what leaves the kitchen. Research matters more as production gets cheaper, because research is the ongoing line between what customers live through and what the team decides, and that line only holds when someone checks whether the conversations are any good.

When did your team last take a dish off the menu?