Why Product Teams Build the Wrong Features (And Why AI Might Make the Problem Worse)

A few weeks before The Problem-First Method launched, two teammates at Ambiki sat me down for what can only be described as an intervention.

Not a product meeting. An actual “Kevin, we need to talk” conversation. Those meetings are never fun.

The funny part was that things seemed to be going well. Really well. I was shipping code faster than at any point in my career. Features that would have taken weeks to prototype a year earlier were being built in days. Internal tools were appearing almost overnight. Documentation was getting written. Research that once took hours was taking minutes.

Like many software teams, we had embraced AI. And like many software builders, I found it intoxicating. For most of my career, software development felt constrained by time. There were always more ideas than engineering hours. More customer requests than development capacity. More opportunities than resources.

Then, seemingly overnight, those constraints started disappearing. AI didn’t remove all the work, despite what some headlines would have you believe. But it dramatically reduced the effort required to move from idea to implementation. And that was exactly the problem.

One of my teammates finally said what everyone else had been politely dancing around. “You’re building really fast.” I nodded. “But you’re not spending enough time understanding the problem anymore.”

The room got quiet. Not because they were wrong. Because they were right.

The irony wasn’t lost on anyone. I was weeks away from publishing a book called The Problem-First Method, and I had become the very thing I was warning people about. I had become solution-first.

What made the experience valuable wasn’t that it exposed a flaw unique to me. It exposed a flaw that exists in almost every product team I’ve ever encountered. We tend to assume that faster is better. Most of the time, it isn’t. At least not by itself. Speed is only useful when you’re headed in the right direction.

The Myth That Slower Is the Problem

For years, software teams have operated under the assumption that the primary obstacle to success is velocity. We need more engineers. We need better tools. We need fewer meetings. We need more automation. We need to move faster.

There is some truth to all of that. I’ve certainly spent plenty of my career wishing projects moved more quickly. Nobody enjoys spending six months building something that could have been completed in six weeks. But hidden underneath those complaints is an assumption we rarely challenge.

We assume the thing we’re building is worth building. We assume the destination is correct. We focus almost entirely on reducing the time required to get there.

Imagine getting into a car in New York and deciding you want to reach Los Angeles. Then imagine accidentally driving toward Miami. Would driving faster help? Of course not. In fact, it would make the mistake worse. You’d arrive further from your destination in less time.

Yet that’s often how product development works. Teams become obsessed with speed while spending surprisingly little time validating direction. The result is organizations that become incredibly efficient at building the wrong things.

Why Smart People Fall Into the Solution Trap

One of the reasons solution-first thinking is so common is that solutions are easy to discuss. Problems are not. When a customer says, “We need a dashboard,” everyone immediately understands the conversation. You can sketch it. You can estimate it. You can put it on a roadmap. The request feels concrete.

Compare that to a customer saying, “We’re struggling to understand what’s happening across our organization.” Now things become messier. What information are they missing? How often does the problem occur? What decisions are affected? Who experiences the issue? What are they doing today? How severe is the impact?

The conversation becomes harder. There are more questions than answers. Most teams prefer the first conversation because it feels productive. The second conversation feels slow. Ironically, the second conversation is usually the one that matters.

A few years ago, a customer asked us for a large reporting dashboard. They had a long list of metrics they wanted displayed, organized, and visualized. It sounded reasonable enough. The easy path would have been to start discussing charts. Instead, we started asking questions.

Eventually, we discovered the customer wasn’t actually struggling to see data. They were struggling to make staffing decisions. The dashboard wasn’t the problem. It was simply the first solution they had imagined.

Once we understood that, dozens of possible solutions emerged. Some involved reports. Some involved alerts. Some involved forecasting tools. Some involved workflow changes. The dashboard had felt specific. The underlying problem was far more interesting.

Customers Often Hand You Solutions

This is one of the most important lessons I’ve learned in product development. Customers are usually experts in their problems. They are not necessarily experts in solutions. That’s not a criticism. It’s true for all of us.

If my car makes a strange noise, I can tell a mechanic exactly what I experienced. I can explain when it happens, how frequently it occurs, and why it’s frustrating. What I probably shouldn’t do is insist on which part needs replacing. Yet that’s exactly how many product conversations unfold.

Customers arrive with requests. “We need a mobile app.” “We need AI.” “We need custom reporting.” “We need an integration.” Those requests may eventually become the correct solution. But they shouldn’t become the starting point.

The starting point should always be curiosity. What is happening today? What frustration are you experiencing? What outcome are you trying to achieve? How are you handling this problem now? The answers to those questions are often far more valuable than the feature request itself.

The Competitor Feature Spiral

Another reason teams build the wrong features is competitor pressure. If you’ve worked in software long enough, you’ve heard some version of this sentence: “Your competitor has it.” At first glance, it sounds like compelling evidence. After all, if a competitor built something, there must be demand. Right? Not necessarily.

One of the strangest phenomena in product development is how quickly assumptions become accepted truths. A competitor launches a feature. Another competitor copies it. A third competitor follows. A few years later, everyone assumes the feature must be important because everyone has it. The original reason it was built has long been forgotten.

Nobody remembers whether customers actually wanted it. Nobody remembers whether adoption was high. Nobody remembers whether it improved outcomes. All that remains is feature parity.

The software industry has countless examples of companies chasing each other’s solutions while never stopping to ask whether the underlying problem was meaningful in the first place. This is how entire categories drift away from customer needs. Not through one catastrophic decision. Through thousands of small assumptions.

AI Has Made This Worse

AI is remarkable. It is also creating a fascinating new failure mode. For years, companies searched for solutions that justified blockchain. Then they searched for solutions that justified mobile apps. Then they searched for solutions that justified social features. Now many organizations are searching for problems that justify AI. The order matters.

When technology arrives first, teams often start looking for places to apply it. The conversation becomes: “How can we use AI?” The better question is: “What is frustrating our customers?”

Maybe AI becomes part of the answer. Maybe it doesn’t. But beginning with the technology almost guarantees that the technology will influence the outcome. Beginning with the problem leaves the door open to whatever solution makes the most sense. One approach starts with curiosity. The other starts with assumptions.

The Spreadsheet Test

Over the years, I’ve developed a strange habit. Whenever I visit a customer, I pay attention to spreadsheets. Not because I particularly enjoy spreadsheets. Because spreadsheets tell stories.

Every complicated spreadsheet exists for a reason. Someone built it. Someone maintains it. Someone depends on it. And most importantly, someone believed their existing software wasn’t solving an important problem.

Some of the best product opportunities I’ve ever encountered started with a spreadsheet. Not because spreadsheets are inherently valuable. Because they reveal unmet needs.

The spreadsheet isn’t the opportunity. The problem that created the spreadsheet is. That’s an important distinction. Too many teams focus on copying the workaround rather than understanding why the workaround exists.

Motion Isn’t Progress

One of the most dangerous aspects of solution-first thinking is that it creates the appearance of productivity. Roadmaps get filled. Features get released. Tickets get closed. Engineering velocity increases. Everything looks healthy. Until you measure outcomes.

Customers don’t buy features. They buy solutions to problems. A beautifully engineered feature that solves an unimportant problem is still a failure. A perfect implementation of the wrong idea is still the wrong idea. The market doesn’t reward effort. It rewards usefulness.

That reality can be uncomfortable because it means execution alone isn’t enough. The quality of the thinking matters. The quality of the problem definition matters. The quality of the assumptions matter.

Product teams often talk about innovation as if it’s primarily about generating better ideas. I’ve come to believe it’s more often about identifying better problems.

The Most Valuable Question

Whenever I find myself getting excited about a feature, a technology, or a customer request, I’ve started forcing myself to pause. Then I ask a simple question. “What problem are we actually trying to solve?” Not the feature. Not the implementation. Not the request. The problem.

Sometimes the answer is obvious. Sometimes it takes an uncomfortable amount of digging. Sometimes the feature request turns out to be unrelated to the real issue. Sometimes the real problem is much larger than anyone initially realized. And occasionally, the real problem barely exists at all.

Those discoveries are valuable. Even when they prevent us from building something. Especially when they prevent us from building something.

The Lesson From My Intervention

The intervention from my teammates wasn’t really about AI. It wasn’t even about speed. It was about discipline.

The ability to build quickly is an incredible advantage. I wouldn’t trade it away. Every product team in the world benefits from shorter feedback loops and faster iteration. But speed is a multiplier. It amplifies whatever direction you’re already moving.

If you’re solving the right problem, speed helps. If you’re solving the wrong problem, speed hurts. And as our tools become more powerful, the importance of problem understanding increases rather than decreases.

The future belongs to teams that can build quickly. But it belongs even more to teams that know when not to build at all. That’s the lesson my teammates reminded me of a few weeks before my book launched. And it’s the lesson I find myself returning to over and over again.

The challenge has never been figuring out how to build faster. The challenge is making sure we’re solving something worth building in the first place.