Step 1 — Define the Problem

In the overview we said a backlog is built on problems, not features. Step 1 is where you find a real problem and define it.

Most teams do the opposite. Someone has an idea, the idea gets a name, the name gets a deadline, and now a team is building it. Nobody ever stopped to ask whether the problem underneath was real, understood, or worth solving at all.

Start the other way. Start with the problem, and fall in love with it.

I mean that literally. 90% of the startups I hop on a mentor call with are completely obsessed with their solution, while treating the problem their product is supposed to solve like the most annoying objection to get past. They have it backwards. Problems are everywhere and cheap to find. What's rare is someone willing to fall in love with one, get curious enough to chase it past the obvious answer, and stay with it long enough to actually understand it.

That's the whole job of this step. Get close to a real customer problem, understand it well enough to state it plainly, and only then let anyone talk about solutions.

Get close enough to feel it

You cannot define a problem you have never felt.

Years ago I ran a workshop for a company that made an injectable drug. A good drug, a genuinely life-saving one. But they had designed the injector for people with normal hands, and something like 40 to 45% of the people actually using it were 60-80 years old with arthritis. Their hands didn't work the way the design assumed. The people who needed the drug most had the hardest time using it, and the company had never really sat with that.

So I brought gloves. The kind that stiffen your hands into the hands of someone with arthritis. I had the leadership team put them on and try to use their own product. That was the workshop. For about ten minutes, they felt what their customer felt every single day.

That is empathy, and empathy is where this whole process starts. Not a survey. Not a persona deck. You go talk to people, watch them work, try to see yourself in their lives. Teresa Torres calls this continuous discovery, and the word that matters most is continuous: you talk to customers every week, not once a quarter when something is already on fire. You earn the right to write a problem statement by getting close enough to feel the problem first.

Interview for the truth, not the compliment

If you ask someone whether they like your idea, they will almost always say yes. People are kind. They don't want to hurt your feelings, and a leading question hands them an easy way to be kind. So you walk away with a yes that means nothing and build on it.

The fix is to stop asking about your solution and start asking about their life. Don't ask "would you use this?" They'll say yes. Ask what they actually did the last time the problem came up. What are they doing. Where does it break. What did they try. You want answers you didn't lead them to. There's a great little book for this, The Mom Test by Rob Fitzpatrick, and the idea is right in the title: ask questions even your mom couldn't lie to you about.

Solve the real problem, not the first one you hear

The problem someone hands you is usually not the real one.

A senior leader at one of my companies came to me certain we had a contracting problem. Contracts took too long to build, full stop. So I went and talked to a dozen people who build contracts for our customers all day. Turns out building the contract takes about ten minutes. That was never the problem. Everyone had been cramming every phase of the work into the word "contracting," and buried in there was the real one: scheduling the resources to actually do the job. Scheduling was the thing that took forever.

If I had taken the problem at face value, we would have built a faster contracting tool and solved nothing. Instead I reshaped the statement to the truth, that scheduling project resources is hard with the system we had, and once we understood that, we could go solve the right thing.

Nobody enjoys this part. The solution is the sexy thing. Understanding the problem is slow and unglamorous, so people skip it, jump straight to building, and then watch the thing flop because it never solved a real problem. A problem you actually understand is most of the solution.

Write it down so it holds

Once you understand the problem, write it as a problem statement. A good one does three jobs.

It focuses on the user. Lead with them, not you. Not "we need to build," not "the product should." Start with what the customer needs.

It stays broad. Leave room for more than one solution. The moment you name a specific feature, you have stopped describing a problem and started describing an answer.

It stays manageable. Broad, but not so broad you can't solve it. You can't boil the ocean. You can scoop a cup out of the ocean, put that on the stove, and that cup is where you start.

A good statement answers four questions: who has the problem, what it is, where it shows up, and why it matters. A format I use folds those into a single sentence:

When    [situation]
I want  [need]
So      [outcome]
But     [what's in the way]

Run a real one through it. Picture a business that bills its customers directly, except a third-party service it depends on forces all of that billing to route through them instead:

When I bill my customers, I want the bill to come from me, not a third party, So my customers aren't confused and can use the payment plans they have with us, But the service I rely on forces me to bill through them.

Read that and you know exactly who hurts, what hurts, and why it matters, and not one word of it says how to fix it. That's the point. The solution stays wide open, which is precisely where you want it heading into the next step. The late-paying customer we will follow through the rest of this section starts life as a statement just like this one.

Then, and only then

Now you have a real problem. Felt, understood, and written down, instead of a solution someone fell in love with on a Tuesday.

That's Step 1. Next you decide whether it is even worth solving.