A problem is not the most important problem

Every product team I have worked with has a list of problems. Numbered, groomed, argued over. The list is never the issue.

The difference between a team that is busy and a team that is winning is not how many problems they solve. It is which problem they chose. And most teams never actually chose. The list chose for them, in the order things were shouted.

A request is a solution in disguise

“The app needs a redesign.”

That sentence arrives in every company at some point, usually from someone senior enough that it goes straight onto the roadmap. It sounds like a problem. It is not. It is a solution wearing a problem’s clothes, and nobody asked what it is meant to solve.

I have watched that sentence cost three months and four people, and at the end of it the number everyone cared about had not moved. The retro conclusion was “maybe we need more marketing”. Which is the next solution in disguise, queuing up behind the first one.

A real problem has a number on it

Compare that with: “68% of the people who sign up never reach their first order.”

That is a problem. It names the behaviour, it carries its own evidence, and a team can start work on it tomorrow morning without a single alignment meeting. Nobody argues with it in a corridor, because there is nothing to argue with. The number either moves or it does not.

The first test I run on any backlog is exactly this. Read each item and ask: is there a number in it? Items without a number are usually requests. Items with a number are usually problems. Most backlogs I open are eighty percent requests.

The question nobody asks

Even a real problem, with a real number, is not enough. The question that almost never gets asked is the one that matters most: is this the most important problem we have right now?

Teams skip it because it is uncomfortable. Answering it means telling someone their problem lost. It means the redesign waits. It means the feature the loudest customer asked for goes below the quiet leak that is costing ten times more.

But the gap between a problem and the most important problem is the gap between a quarter of work and a quarter of results. Both quarters look identical from the inside. Standups happen, tickets close, demos run. Only one of them moves the company.

The ladder

The discipline is a ladder with four rungs, and most work enters on the wrong one:

Request. What someone asked for. “We need a redesign.”

Problem. What is actually happening, with a number. “68% never reach first order.”

Most important problem. The one, ranked against every other problem, that costs the most right now.

Impact. The number, moved.

Every piece of work in the company sits somewhere on that ladder. The expensive habit is starting at the top rung and working down, building the request and hoping a problem was under it. The cheap habit is refusing to start work until it has climbed up: request, to problem, to most important problem. Then build.

Why this is the first thing we look at

When we run The Check, this ladder is most of week one. Not because prioritisation frameworks are clever, but because the most expensive gap in a growing company is rarely a missing tool or a missing hire. It is a team, working hard, on the wrong problem, with nobody holding the question of which problem is worth the quarter.

You can test your own company in one meeting. Take the current top three items on your roadmap and ask for the number behind each one. If the room goes quiet, the list chose for you.