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 end up with a product full of features that were built to spec but don't solve the underlying problems. You're shipping without learning anything.

A problem is an unmet need, want, or desire of a customer. Customers often describe it as a solution, but the solution they suggest and the problem they 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.

When they ran proper interviews and looked closely at the answers, a different picture emerged. Staff wanted to cycle and would benefit from the exercise, but they arrived at work sweaty. The problem 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.

The underlying problem might be: "customers want to gift experiences to friends or family but don't know what dates they'll be available." Framed that way, it opens up quite different solutions, and shows that the original feature request might not meet the need at all.

The first scenario also ignores the benefit. If the underlying 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, and round again. The process matters because it makes you 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 full of loosely related capabilities, you build a toolbox of precise instruments, each made for a specific problem.

Your customers want a product that does the right things very well, and you can only know what "right" means if you start with the problem.