Four labelled boxes stepping down across the frame, reading Frame, Uncover, Size, Execute

Long before models entered my workflow, I used canvases, one-pagers, and intake forms to structure product decisions. Business model canvas, lean canvas, opportunity canvas, whatever the team had adopted that year. The boxes mattered less than the questions behind them. So I kept my own list of those questions, a short decision checklist, and ran it before committing a team to anything. When the answers were specific, consistent, and backed by evidence, I felt better about the decision. When they were not, I took it as a reason to slow down.

David Pereira published a piece this month, "7 Weak Product Management Signs", revisiting something he wrote in 2021. The signs had not changed, he found, but the cost of ignoring them had. One line stuck with me: "In 2026, weak product management is fast and comfortable. You ship your way through it, one prompt at a time, and it all looks like progress." That sent me back to my own list.

I hadn't opened it in a long time, so I dug it out and rewrote it. Most of it still held. What changed is when it matters. It used to be a sanity check before a long build, and the build was slow enough to catch a bad decision on the way. Now a working version of the wrong thing can exist before anyone has questioned the premise, and a working solution can still solve the wrong problem.

The questions fell into four groups: Frame, Uncover, Size, and Execute. That spells FUSE, which is the only reason I remember it. I usually take them in that order, but the work is iterative and going back a step is normal.

  1. Framethe problem
  2. Uncoverthe options
  3. Sizethe investment
  4. Executeand measure

A problem that is still there goes back to Frame, a wrong solution goes back to Uncover, and a cost much larger than expected goes back to Size.

I usually take the four steps in order, but Execute can send the decision back to any of the first three.

What follows is a slice of that list, four to seven questions per step. I kept the ones that have changed an answer for me.

None of this is one person's job

A product manager is often well placed to run it, but no single role holds all the inputs. A solution can be excellent for the user and unaffordable, or commercially attractive and unbuildable, or easy to build and wanted by nobody. When one of these five is missing, its blind spots are less likely to be challenged before release.

  • UserIs this a real problem for them?
  • ProductDoes it fit the product, its workflow, and its strategy?
  • BusinessDoes it make economic or strategic sense?
  • TechnologyIs it feasible, scalable, and reasonable to build?
  • DeliveryCan we ship it, run it, and keep it alive?
The same five points of view sit at every step.

Frame ends with a problem, not a request

The first task is to be sure I know which problem I am solving, and why it is worth solving now. The solution comes later.

"We need an AI assistant that can answer questions about card disputes" is not a problem. "A customer cannot tell what is happening with a dispute that may stay open for weeks" is. The first sentence ends the search before it starts. The second leaves room for an assistant, for clearer messages, or for a notification every time the case changes state. The case that runs through the rest of this piece is a composite, and the details are illustrative.

These are the questions I work through:

  • Can I describe the problem without naming a solution?
  • Who exactly runs into it, and how often?
  • How do they cope with it today?
  • What is the cause and what is only a symptom?
  • Why does this matter now, and what is it costing us while we wait?
  • How will we know it has been solved?

The first and the last are the two I spend the most time on. One tests the framing, and the other forces a definition of done that is about the user rather than about a release.

A customer disputes a card transaction, gets a confirmation, and then hears very little. They do not know whether the bank needs documents from them, when the next decision is due, or what the internal status actually means. That uncertainty can drive customers to contact support simply to ask what is happening. The problem is not the absence of a chatbot. It is that customers cannot understand where they are in a process that may take weeks. We would know we had improved it if a customer could see the current status, the next expected step, and whether anything is waiting on them, without calling anyone.

Worked example: the request becomes a problem

Uncover treats the first idea as a candidate

Once the framing is stable, the question becomes how we could solve it rather than how we would build the feature someone already pictured. The point is to have more than one path on the table before anyone commits people and money.

The answer might be a new feature. It might also be a workflow or process change, an automation, an integration, or a UX change. It might be better data, a configuration change, training, a manual process, a tool that already exists, or a decision to build nothing at all. AI belongs on that list too, as one of the options and not the default one.

So I push for alternatives:

  • Can we solve it without building a new feature at all?
  • What is the simplest version that would work?
  • Does AI give us a real advantage here, or would simpler technology do as well or better?
  • What would we propose if the budget were very small, or if we could not write a single new line of code?
  • Is deciding to build nothing a reasonable option here?

The last two are there to break the pull of the first idea. A constraint can expose an option nobody had written down, and making "do nothing" explicit keeps it available as a real choice.

The assistant was one option. Rewriting the confirmation and the status messages in plain language was another. A third was a notification whenever the case changed state, and a fourth was a simple timeline inside the transaction view the customer already opens. Operations then pointed out that several internal statuses do not map cleanly to anything a customer should see. An assistant would not remove that ambiguity. It would have to explain it.

The same request, four ways

This is also where engineering should already be in the room. In the weak version it arrives last and is asked only how long the thing will take. But the people who know the architecture, the data, and what already exists are often the ones who can see a cheaper path. Asking them only for a number wastes the most useful thing they have.

Size is the missing step between discovery and delivery

Plenty of teams have something they call discovery and something they call delivery. What often gets no deliberate step of its own is the moment between them, the point where a good-looking solution turns into a commitment.

Size is that moment made explicit. The question is not just how many sprints it will take. It is what this option would actually cost, and whether that cost is worth it.

This is where I slow down and ask:

  • Would we still do this if it were not already on the roadmap, or if that particular stakeholder had not asked for it?
  • What value could each option bring, for the user and for the business?
  • How much work is this for every team it touches, and not only for engineering?
  • What does it cost beyond implementation, once we count infrastructure, APIs, licenses, support, and monitoring?
  • What will it cost to keep running a year from now, and who pays for that?
  • How much complexity does it add, and does it need new data, a migration, or a skill the team does not have yet?
  • What are we giving up by choosing it, which assumptions would change the decision if they were wrong, and is there a smaller version that tests them first?

For me, the roadmap question is often more revealing than the score it would produce.

The copy change would be small, and it could only reach the first few days of the process. Event-based notifications would require an integration with the dispute system and careful handling of regulated and time-sensitive customer communications. The timeline would reuse that integration and add interface work. The assistant would need all of it, plus authentication, conversation history, monitoring, escalation to a person, and controls to stop it inventing an answer about someone's money. So we would rewrite the existing messages immediately, then start with the notifications and the timeline. They would answer the repeated question directly, and building them would force us to create the clean status model an assistant would need anyway. The assistant would remain an option if customers still struggled once the underlying information was clear.

What each one would cost

Execute does not end at the release

Execution is where the decision turns into a real change in the product, and in what people actually do. Scope, technical design, backlog, QA, release, and monitoring all sit here. Shipping is the part teams are usually set up to do well. The mistake is treating the release as the finish line.

"Released" is a statement about us, not about the user. The question the whole exercise exists to answer is whether the problem went away.

After the decision, I keep asking:

  • How will we check that the original problem went away, against what baseline, and by when?
  • What exactly did we decide to deliver, and what is explicitly out of scope?
  • Which signals would tell us to stop investing, and are we willing to cut or remove it when they appear?
  • Who owns it after the release, and when do we come back and look at the results honestly?

When we cannot say that the original problem went away, the loop points backward. If the problem is still there, frame it again. If the solution was wrong, go back to the options. If the investment turned out much larger than expected, size it again with what we know now.

We would compare status-related contacts per dispute before and after, and watch whether customers open the notification, visit the timeline, send the documents that were asked for, and come back to support a few days later anyway. Fewer calls on its own would not be enough, because a customer who quietly misses a required step also stops calling. If they still cannot read the status, that goes back to Frame. If they read it and still come back with recurring questions that could be answered safely and consistently, the assistant returns as an option.

How we would know

Where this sits next to what already exists

I am not reinventing anything here. Most of the parts are borrowed, and anyone who has read a few of these will recognize where the questions come from. The Design Council's Double Diamond runs Discover, Define, Develop, and Deliver, and it goes far deeper into the design work than a checklist can. Teresa Torres's opportunity solution trees map opportunities, explore several solutions for each, and make the assumptions underneath them testable. Hers is a method for finding options, where my second step only asks whether there is more than one.

Shape Up, from Ryan Singer at Basecamp, is one of the closest relatives. In outline it runs problem, appetite, shaped solution, bet, and build. One useful difference is the order in which the constraint appears. Shape Up decides how much time a problem is worth and shapes the solution to fit, which is deliberate and works well. I tend to find the options first and then compare what each would really take.

RICE and WSJF can both help rank candidates once their inputs exist, although neither builds maintenance or run cost into its formula, and RICE's own guidance treats a dependency as a reason to override the score. Scrum and Kanban support execution, learning, and flow, but neither replaces the investment decision. So this is a lightweight decision gate, and the methods above cover particular parts of discovery, prioritization, shaping, or delivery in far more depth. The checklist may prompt user research, root cause analysis, or an experiment, but it does not teach you how to run any of them. It only insists on stopping before you commit.

I cannot claim that this checklist produces better products. It is a practical habit, not a validated method, and the third step is the reason it exists. What I am reasonably sure of is that a short stop usually costs little compared with building the wrong thing, and that the cost of being wrong is now easier to hide behind a working demo. If you know what the last thing your team shipped costs to keep running, I would like to hear how you worked it out, and whether knowing the number earlier would have changed the decision.

Sources

← Back to blog