Stop building features, start solving problems

It starts innocently. A client asks for something. You estimate the time, cost, and complexity. You build it. You ship it. Then the client tells you it doesn't meet their needs because of something you didn't know about. So you move on to the next request, or gloss over it, or say you'll come back to it later.

The cycle repeats. Over time, you accumulate a product full of features that were built to spec but don't actually solve the underlying problems. You're shipping, but you're not learning.

A problem is an unmet need, want, or desire of a customer. It's often expressed as an opportunity for a solution — but the solution the customer suggests and the problem they actually have are frequently different things.

Not all problems have solutions. Not all solutions provide value to the company. Both of those things are OK. The discipline is in understanding the problem deeply enough to know which category you're in before you start building.

A company wanted to encourage staff to cycle to work, but uptake was poor. They asked employees what they needed. The answer: ebikes. The assumption was that staff were lazy.

But when they conducted proper interviews and really examined the answers, a different picture emerged. Staff wanted to cycle. They'd benefit from the exercise. But they arrived sweaty. The problem wasn't laziness — it was hygiene. The company installed showers.

If they'd just bought ebikes, they'd have spent more money solving the wrong problem.

In product management, you hear this constantly. "When transferring a ticket, I should be able to set the transfer date for gifts" sounds specific and actionable. But it's a solution, not a problem.

The actual problem might be: "customers want to gift experiences to friends or family but don't know what dates they'll be available." That reframing opens up entirely different solution spaces — and reveals that the original feature request might not even solve the real need.

The first scenario also ignores the benefit. If the real problem is that customers don't know availability, a date-setting feature won't get used, and the potential revenue benefit is lost.

Breaking out of feature factory mode requires a repeatable process. Start with customer discovery — talk to customers about their problems before you talk about solutions. Feed those insights into a thematic roadmap that gives you space to ideate over a defined period.

Design and deliver a solution, review it internally and with clients, then gather feedback to start the cycle again. Discovery, roadmap, ideation, design, review, feedback. Over and over. The process matters because it forces you to understand the problem before you commit to a solution.

When you focus on problems instead of features, the product you build changes shape. Instead of a Swiss Army knife — a collection of tangentially related capabilities — you build a toolbox of precise instruments, each crafted to cut to the heart of a specific problem.

Your customers don't need a product that does everything. They need a product that does the right things exceptionally well. That only happens when you understand what "right" means, and that only happens when you start with the problem.