Name the Problem Before You Build the Fix

Your backlog is full of features. Some came from a sales call. Some came from a loud stakeholder. Some came from a brainstorm nobody remembers. The trouble is, none of them point back to a real customer problem. So the team builds, ships, and nothing moves. The fix is not more ideas. It is a habit: tie every idea to a named opportunity before anyone writes a spec.

The deep cut

• Opportunities come before solutions, always. Stephan Beyer's opportunity solution tree starts at the outcome, not the feature list.
• A feature with no problem is dead weight. Moataz Samy warns teams stack features and call it progress.
• Pick the tool that fits your stage. Marty Cagan splits Lean Canvas for new bets from Opportunity Assessment for existing products.

Start with the outcome, not the idea

Most backlogs grow from the bottom up. Someone has an idea, it gets a ticket, and the pile swells. The better order runs the other way. You set a desired outcome first, then find the customer problems that block it, then propose solutions for those problems.

That is the spine of an opportunity solution tree. You put the outcome at the top. Below it you map opportunities, the real pain points customers hit. Only below those do you hang possible solutions, and below each solution, the assumptions you still need to test. An idea with no opportunity above it has nowhere to attach. That is the point. The tree shows you which features are orphans.

Features are not the same as value

It is easy to confuse shipping with solving. A team feels productive stacking features, but a longer feature list is not a better product. Moataz Samy asks the question that cuts through it: are you solving problems or just adding features?

Run that check on your own roadmap. For each item, point to the customer value it delivers and the problem it closes. If you cannot, you have found something to cut. This is not about saying no to be tough. It is about freeing up the team's time for work that ties to an outcome. A short list of problems worth solving beats a long list of features nobody asked for.

Know which research the opportunity needs

Not all opportunities get examined the same way. Andrew Harder splits them in two. If your idea fits behavior users already have, like moving fashion shopping online, you can involve them closely and dig into their pain with current tools. If your idea asks for brand new behavior, users cannot tell you what they do not know yet. There you prototype first, then test the prototype and listen to the feedback.

The practical lesson: match your research method to the kind of opportunity you have. And do it early, before you have built anything. Early research is cheap. Late research just confirms what you already shipped.

Pick the canvas that fits the stage

Teams reach for the wrong tool and then wonder why it feels like busywork. Marty Cagan draws the line cleanly. A Lean Canvas is for a new business or product line, where you still have to prove the value prop, the money model, and whether a market exists at all. For an existing product, most of that canvas is dead space. You already have distribution and pricing.

There you want an Opportunity Assessment, a lightweight tool that asks three things: what problem are you solving, who exactly has it, and how will you measure success. Michael Loboyko maps four canvases to stages for the same reason, and Lalatendu Satpathy blends How Might We with a value prop canvas when pure HMW feels too vague. The rule holds across all of them: keep it lightweight, and use the one that matches your stage.

Break big opportunities down and say no

A fat opportunity is just another place to hide vague work. Susan Stavitzski offers a sharper move: break a big opportunity into smaller pieces, decide which ones deserve research, and get comfortable saying no to the rest. That is how you stop drowning in suggestions and start picking.

Picking means pulling people in. Brady Simpson frames opportunity work as cross-functional, walking a team from goal to a real problem to a list of opportunities, with the right partners at the table. The decision does not belong to one PM alone. Name who needs to be in the room before you commit the team to anything.

Three questions for your team

• Pull up the backlog. For each item, can we point to the customer problem above it? Anything with no problem attached is a candidate to cut.
• For the opportunity we are chasing next, does it fit existing user behavior or ask for new behavior? That answer decides whether we interview users or prototype and test.
• Are we using the right tool for our stage, a Lean Canvas for a new bet or an Opportunity Assessment for the product we already have? And are we keeping it lightweight?