What should product strategy start with?

Product strategy should start with the problem the customer has, not with a technology or a feature. Name what is broken, diagnose why it happens, choose the fix, and only then choose the tool to build it with. Starting with the tool means working backwards from an answer to find a problem that fits it.

Should we add AI to our product?

Only if the problem you've diagnosed calls for it. AI is a good fix for some problems and an expensive distraction for others. Sometimes removing steps from a flow does more for the customer than adding a model, so ask what's broken first and let the diagnosis decide.

What does problem, diagnosis, fix, tool mean?

It's an order for making product decisions. First name the problem specifically, then work out its cause, then decide what change would solve it, and finally choose what to build that change with. Each step narrows the next, so skipping ahead to the tool means the earlier steps never get tested.

How do I push back when my team wants to add AI to everything?

Ask a question the room can say yes to, such as "before we pick the build, what's broken for the customer?" That keeps the energy in the room and points it at the problem instead of opposing the idea. If the diagnosis still points to AI, you now have a reason for it; if not, you've saved the team from building the wrong thing.

What is product judgement?

Product judgement is the ability to decide what to build, what to leave out and why, especially when the evidence is incomplete. It shows up in the order you work in: understanding the problem before choosing the solution. When every problem gets the same answer, that answer has taken the place of judgement.

Product Strategy Starts With the Problem, Not the Tool

1

The full infographic, as a PDF

The exact one from the post, sized to print or keep within reach.

2

A copy in your inbox

The download link lands in your email too, so it's there when you need it. No follow-up campaign.

3

The Product System, weekly

My note on leading product in the AI era. One idea a week that compounds. Unsubscribe anytime.

Your product has a problem. Nobody asks what.

It doesn't matter, because the answer is already in the room: add AI. Then add more AI. Somewhere near the end of the table, one person says you should understand the customer first, and in the comic that goes with this piece, that person gets thrown out of the window.

It's a joke, and it's funny because most product people have sat in that meeting. The poster on the wall says product strategy: vision, goals, options, bet. The conversation skips all four and goes straight to a tool.

This piece is about the order that protects the decision, and why the person who asks what's broken is doing the most useful thing in the room.

The room answers the wrong question first

Here is the trap. Nobody knows what's broken yet, but the room has already answered a question. Just not the customer one. It has answered the technology question.

"We need to improve our product" is a real concern. Something isn't working. But "add AI" is an answer to "what should we build with?", not to "what's wrong?". Those are different questions, and only one of them tells you where to spend the next quarter.

A good answer to the wrong question still sends the team the wrong way.

When the tool becomes the strategy

When every product problem gets the same answer, the answer has stopped being a decision. It has become a habit.

That is what happens when "add AI" is the reply to everything. AI has become a substitute for product judgement. The work of looking at the customer, finding the real problem and choosing a fix gets replaced by a word that sounds like progress. Nobody decided to stop thinking. The pressure to look modern did it for them.

This is a system problem, not a people problem. Boards ask about AI and competitors announce it. The easiest way to look like you're moving is to put it on the roadmap. The meeting rewards the fast answer.

A tool on the roadmap is not a strategy. It's a purchase.

The order that protects the decision

My rule, and I build with AI every day: problem, then diagnosis, then fix, then tool.

Most meetings skip straight to the tool. The order matters because each step narrows the next one. If you know the problem, you can diagnose it. If you know the cause, you can pick a fix. Only once you know the fix does it make sense to ask what to build it with.

Start at the tool and you work the chain backwards. You have the answer, so you go looking for a problem it fits. You will always find one, because every product has problems, and that makes the choice feel justified when it was never tested.

Four steps, in order. The tool comes last because it's the easiest part to change.

Name what is broken

The first step is the one the comic's boss skips. "We need to improve our product" is a feeling, not a problem. The job is to turn it into something specific enough to act on.

Ask what's broken. Not the solution. The problem. Who is struggling, with what, and where do you see it? A problem you can point to in the product, the data or a customer conversation is one you can work on. A problem you can only describe in general terms is a mood.

If the room can't say what's broken in one sentence, it isn't ready to talk about fixes.

Diagnose before you prescribe

Once you can name the problem, find out why it happens. Two teams can see the same drop-off for completely different reasons. One has a confusing step. The other has the wrong customer arriving in the first place. Same symptom, different cause, different fix.

This is the step "understand the customer first" is really asking for. It isn't a delay. It's the part of the work that tells you which fix is worth building. Skip it and you're guessing, with a bigger budget.

A diagnosis is what turns a guess into a bet you can defend.

Choose the fix, then the tool

Sometimes the fix is AI. That's fine. When the diagnosis points there, build it well.

But sometimes removing three steps beats adding a model. The fix for a painful flow is often less product, not more. Fewer screens, fewer fields, one thing the customer no longer has to do. That fix is cheaper and faster to ship, and it never shows up if the tool was chosen before the problem was understood.

The best fix is the one the problem asks for, whatever it's built with.

Being the one who slows the room down

In the comic, the person who says "understand the customer first" gets thrown out. In real life it's rarely that dramatic, but it can feel like it. Slowing a room down when everyone else is excited costs you something in the moment.

It helps to ask the question in a way the room can say yes to. Not "this is wrong", but "before we pick the build, what's broken for the customer?" That keeps the energy and points it at the right thing. You're not blocking the idea. You're giving it a reason to exist.

The person who asks what's broken is the one protecting the roadmap.

The best decision this week might be not adding AI

Problem, diagnosis, fix, tool. The comic makes it look like a fight between the people who want AI and the person who wants the customer. It isn't really. It's a question of order.

Next time someone says add AI, ask what's broken first. Sometimes the answer will still be AI, and now you'll know why. Sometimes the answer will be to take something away. Either way, the decision is yours again. Asking what's broken first is how you take your product judgement back.

Comic credit: Pascal Bornet.

Download the one-page version and keep it where your team plans the next thing.

Questions people ask

What should product strategy start with?: Product strategy should start with the problem the customer has, not with a technology or a feature. Name what is broken, diagnose why it happens, choose the fix, and only then choose the tool to build it with. Starting with the tool means working backwards from an answer to find a problem that fits it.
Should we add AI to our product?: Only if the problem you've diagnosed calls for it. AI is a good fix for some problems and an expensive distraction for others. Sometimes removing steps from a flow does more for the customer than adding a model, so ask what's broken first and let the diagnosis decide.
What does problem, diagnosis, fix, tool mean?: It's an order for making product decisions. First name the problem specifically, then work out its cause, then decide what change would solve it, and finally choose what to build that change with. Each step narrows the next, so skipping ahead to the tool means the earlier steps never get tested.
How do I push back when my team wants to add AI to everything?: Ask a question the room can say yes to, such as "before we pick the build, what's broken for the customer?" That keeps the energy in the room and points it at the problem instead of opposing the idea. If the diagnosis still points to AI, you now have a reason for it; if not, you've saved the team from building the wrong thing.
What is product judgement?: Product judgement is the ability to decide what to build, what to leave out and why, especially when the evidence is incomplete. It shows up in the order you work in: understanding the problem before choosing the solution. When every problem gets the same answer, that answer has taken the place of judgement.