Why you can't frame a problem without an outcome

Executive Summary

Teams rarely skip problem framing on purpose. They write a problem statement, nod, and move to solutions because a single sentence gives them nothing concrete to argue with. When the project later stalls, the problem gets reframed by whoever is most senior in the room.

This session introduced the Problem Framing Map, a one-page tool that maps who is affected, what they are trying to accomplish, what today's reality looks like (what is broken and what already works), what success would look like, and how you would measure it. It also introduced the Problem Framing Playbook, which takes a team from a first map through stakeholder interviews to a framing backed by evidence. A worked example from the 2013 US healthcare website and a live account from the Hessen Police Force showed the tool in use.

The clearest takeaway: there is no such thing as a problem without a desired outcome. Define the job and the outcome first, and then treat everything you write on the map as a hypothesis to test before you discuss a single solution.

"Before you talk about the problem, and before you talk about a solution, you need to talk about what people are trying to get done and what good looks like. Otherwise, you don't even know whether it's a problem or not." — Alex Osterwalder, Strategyzer Founder and CEO

Introduction

Picture the kickoff meeting for an important project. Someone reads out the problem statement that was agreed upon in the last steering committee. Everyone nods. Twenty minutes later, the whiteboard is full of solutions, and nobody has asked whether the statement was true.

During the session, the hosts polled the audience on their organization's problem-framing personality: detectives who frame first and don't move until they have nailed it; pragmatists who usually frame but let deadlines get in the way; speed walkers who nod at the problem and keep going; and sprinters who go straight to solutions. Quite a few people admitted to being sprinters. Osterwalder's response was that investigating the problem first "feels slower, but it actually makes you faster."

The reason teams sprint is not laziness. A problem statement is simply hard to work with. Kurt Bostelaar, playbook designer at Strategyzer, put it this way: "Many people use something like a how-might-we statement and lean on that single statement, but you can't jointly define the problem in a concrete, tangible, and practical way with it."

The Problem Framing Map replaces that single statement with a map you can take apart sticky note by sticky note. The full recording is embedded above; the rest of this post sets out what the map changes, how it was built, and what happened when two very different organisations used it.

1. A problem only exists relative to where you want to go

Partway through the session, several attendees asked the same question in the chat: where is the "problem" box on the Problem Framing Map? There isn't one, and that is deliberate.

Osterwalder explained that most problem-framing tools and concepts never look at what people are trying to get done or what outcome they want. They go straight to the pain. But a pain is only a problem if it stops you from reaching somewhere you want to be. "The problem is when you can't get to where you want to go. If you haven't defined the outcome and are just pontificating around a 'problem,' in quotes, that's not great at all."

That is why the map's logic runs from left to right. Stakeholders pursue jobs. Those jobs run into a current reality, which contains both blockers and enablers. The current reality shapes the desired outcome, and success metrics tell you whether you have arrived. The problem is the gap between the current reality and the desired outcome, not a box you fill in first.

Osterwalder described the metaphor that finally made the tool easy to explain: "If there's a cliff in between, we have a problem. If not, we're fine. We're trying to build the bridge to get from the left to the right."

Watch-out: If your framing session opens with "the problem is…", you have already skipped two steps. Start with who is affected and what they are trying to accomplish. The problem will become visible once the outcome is on the map.

2. The map took a living room, a sparring partner, and a few arguments

The map did not arrive fully formed. Osterwalder walked the audience through its origins, which say a lot about how Strategyzer tools get made.

It started with research, including a lot of back-and-forth with LLMs, followed quickly by rough prototypes on sticky notes and paper. The early sketches had three columns: an objective or goal ("the job we are trying to get done"), a problem column that already split into what was negative and what was "GOOD", and an outcome column asking "what good looks like if we get the job done well."

Then came what Osterwalder called the move "from AI to real intelligence." "I have a sparring partner in ChatGPT or Claude, but my favorite sparring partner is Yves Pigneur, who is really behind the iterations we came up with." Pigneur took the concepts apart and rebuilt them with more rigour: stakeholders, jobs, current reality, desired outcomes, with metrics added later to make the tool practical.

The layout went through at least three versions on the slides. Version one had four equal columns. Version two renamed them "Today's reality" and "Tomorrow's outcomes" with pain points and bright spots underneath. Version three moved stakeholders into a header running across the top, with jobs, current reality, and desired outcomes in three zones below it. Osterwalder admitted the two co-authors did not agree at every step: "It wasn't fists flying, but it was probably the first time we didn't immediately agree."

The final version turns each area of the map into a question:

1. Stakeholders — Who are the people or groups affected by this situation?
2. Jobs to accomplish — What are stakeholders trying to accomplish?
3. Blockers — What are the pains, frictions, failures or gaps?
4. Enablers — What is currently working well?
5. Desired outcomes — What would success look like?
6. Success metrics — How will we know we've succeeded?

The validation Osterwalder cared about most was not conceptual. It came when Tendayi Viki, senior partner at Strategyzer, saw the finished tool for the first time and, as Osterwalder recounted it, got it right away. Simplicity was the design goal, and Osterwalder was unbothered by the objection that the ideas are not new: "It's not about new, it's about getting things done."

3. Your first map is a set of assumptions, and that is the point

The most complete example in the session came from a video inside the playbook itself. Bostelaar used the launch of the US government's healthcare website in 2013. The initiative was meant to give all Americans access to healthcare online. On launch, the site crashed, and visitors were met with an error or a holding page.

Bostelaar mapped the situation from two stakeholders' points of view. For the US government: the job was to set up a working healthcare website; the desired outcome was that citizens could set up and access healthcare online; the blocker was that the website crashed at launch; the enabler was that certain aspects of the site were working correctly.

Then the website contractors. Bostelaar was explicit that this was a first pass built on guesses, his best step forward rather than something he knew. Their job, presumably, was to deliver projects on time and meet requirements. Their desired outcome, presumably, a successful web application. A blocker, presumably, coordinating with the other contractors on a large and complex build. An enabler, the resources backing them from the government.

That first framing leads somewhere specific. If the problem is "we don't have enough contractors," the solutions that follow are to hire more contractors or hire better ones.

Then Bostelaar did what the playbook asks every team to do: he went looking for evidence. "The initial Problem Framing Map is based on assumptions. We've just started putting sticky notes down, thinking this is true. We want to move to evidence."

Two sticky notes failed the test. When the contractors were asked what was holding them back, coordinating with other contractors never came up, because it was not part of anyone's scope. And their desired outcome was not a successful web application. Each contractor had been handed a piece of the whole, so their outcome was to finish their own piece of the puzzle.

That changes the problem entirely. The framing moves from "we don't have enough contractors" to "no one owns the entire system working together." The solutions change with it: coordinate the end-to-end flow between contractors, or put one contractor in charge of that flow. According to Bostelaar, that is what was eventually done, and the site was made to work. He was careful to say he was retrofitting the map onto a story that unfolded without one.

Bostelaar's point was not about healthcare. It was about what a map lets you do that a statement does not: "When you have sticky notes, you can investigate whether each one is true. With that zoomed-in view of a statement, it's too difficult to do that."

Watch-out: Do not let a first map become the official version of the problem because it looks finished. Treat every note as a claim someone could disprove, and decide which notes you would be most embarrassed to have wrong. Those are the ones to test first.

4. If you only frame the blockers, you will miss half the picture

Viki demonstrated the map live with Lili Sayce, former senior innovation manager at Gerresheimer and now an independent coach and advisor. Sayce works with PhD students and postdocs at the University of Basel who are trying to commercialise their science.

The map came together quickly. Stakeholders: scientists who "can talk about the science forever." Jobs: commercialize the idea, pitch to investors, learn to be an entrepreneur. Desired outcomes: a pharma partner, funding, and a team. Blockers: not knowing who to talk to in pharma, not understanding how a product fits the healthcare system, reimbursement and regulation, and not knowing how to get doctors to prescribe. Enablers: a university that brings in industry experts, regulatory and patent guidance, a room full of investors, and existing links to the big pharma companies in Basel.

The useful moment came when Viki asked Sayce what the exercise changed. "What this makes me realize, through introspection, is that I've maybe been trying to help with the blockers only, but the university helps with most of that. Where I can bring them value is in how to talk to the enablers they have within the university network, and in prioritizing what should come first."

Viki drew the general lesson: "When we're framing problems, sometimes we only frame the blockers." Osterwalder agreed that the enablers column matters most once you move toward solutions, because it tells you what already works and can be built on.

Viki also noted the limits of a live demo. In a real coaching context, each sticky note gets "double-clicked" and taken deeper, and the playbook includes a step on scoping the problem before the map is filled in at all.

Watch-out: A current reality with ten blockers and no enablers is not a complete picture; it is a complaint. Push for what is already working. It is where the cheapest solutions usually hide.

5. The people who know the problem best are the biggest risk to framing it well

The second real-world account came from Sebastian Mueller of the Hessen Police Force in Germany: a state police force of 22,000 employees, with an innovation unit, Innovation Hub 110, of around 250 people. Strategyzer is co-creating a custom problem-framing playbook with them. The specific challenge the first team is working on is confidential, so the session covered how the team worked rather than what they mapped.

Mueller described a highly hierarchical, bureaucratic organisation, a tanker that gives the state's citizens stability and security, which nevertheless needs an innovation engine because crime keeps evolving. His sharpest observation was about expertise. Police officers are experts on the problem, "but they are too much the experts."

"They think they already know the solution, and the higher you go up the ladder of the hierarchy, the more you find people who think they already know the solution." — Sebastian Mueller, Hessen Police Force

The map and the playbook gave the team a way out of that trap. They used sailboat interviews, a structured interview format from the playbook, to go into the field and collect evidence rather than opinions. The team member were police officers, not innovation experts, so Mueller stressed that the entry point had to be simple and visual; their challenges were complex enough already.

He then offered the analogy that gives the whole approach its logic for a police force: "In the end, it's about coming from the crime scene to the courtroom. When you're in the courtroom, what matters? Assumptions? No. Evidence? Yes."

Osterwalder described what came out of it. The team started with a hypothesis and tried to boil the ocean. They went back to the map, treated it as the hypothesis, ran experiments, and found a challenge "that they would not have discovered if they hadn't gone through this discovery process." The rule they followed is the rule the playbook encodes: "We never talk solution until we have the evidence that gives us confidence to move forward on a specific challenge."

For Mueller, the stakes are not abstract. A police force is funded by tax money and its budgets are being reduced, so the question of which problems are big enough to invest in is the whole game. "Ideas are not the problem. The problem is that they don't have any evidence."

Watch-out: A map and a hypothesis are not the same thing. Viki drew the line in the Q&A: problems are the needs and challenges people have; hypotheses are whatever needs to be true for a solution to work. Frame and test the problem first. Hypotheses about solutions come later.

6. Why this ships as a playbook, not a book

Bostelaar framed the playbook with a simple image: a training session on one side, real-world application on the other, and a gap in between. "You could call that the theory-practice gap. With our playbooks we want to bridge it. We don't want a bunch of trainings you attended and saved notes from, and then you're left trying to do the work."

The Problem Framing Playbook runs in three sections on the Strategyzer platform:

1. Frame the problem. Short expert videos introduce the map, then a pre-structured activity walks a team through filling it in for a real project of their own.
2. Test your assumptions. An introduction to testing, then sailboat interviews with a workspace that guides each conversation, then the testing library for other experiments.
3. Refine your problem framing. Interview analysis with AI, generating interview insights, iterating the map, and arriving at a validated Problem Framing Map.

Each step is a short, just-in-time video or an activity rather than a course to sit through. Bostelaar described the videos as two, five or six minutes long, and the activities as something a team works through together on the platform.

The shift from books to playbooks is also about iteration. Bostelaar counted the changes to the playbook that will be released at the next webinar: "over the past two months Alex and I iterated on the content 10 times." A book has to be right before it is printed. A playbook can absorb what the team learned with the Hessen Police last month.

Teams can run the playbook in two ways. Coached: a Strategyzer coach guides each step and holds the team to account, which the slides recommend for first-time or high-stakes teams. Self-guided: the team follows the playbook with videos, templates and AI support, which suits scaling across many teams with internal champions.

Before you discuss a solution: a seven-question pressure test

Before your next important project moves past the problem, check whether your team can answer these question from the map, not from memory:

1. Who exactly is affected, and have you separated the stakeholder groups rather than lumping them together?
2. What is each group trying to accomplish, stated independently of any solution?
3. What is holding them back, as specific pains, frictions, failures or gaps?
4. What is already working well, and could be built on?
5. What would success look like for each group, and would they agree with your version of it?
6. How will you know you have succeeded, in a form you could measure?
7. Which of these sticky notes do you have evidence for, and which have you simply assumed?

If the answer to question seven is "none of them," you have a hypothesis, not a framing.

Conclusion

The Problem Framing Map is not a new way to describe a problem. It is a way to stop treating the problem as settled. By forcing the desired outcome onto the page before the problem, and by breaking the framing into claims small enough to test, it turns the vaguest part of any project into the most investigable.

Osterwalder was clear that the tool will be judged by whether people use it: "Tools are human-made, we design them, and the good tools take off, while those that are not so good, people vote with their feet."

Here is the first thing to do this week, with no purchase required. Take one project your team is currently solving, draw the map on a whiteboard, and write the stakeholders, their jobs and the desired outcomes before you write a single blocker. Then mark each sticky note with what you actually know versus what you assume. If the project survives that exercise unchanged, it was well framed. Most do not.

Download the webinar slides →

The deck includes every iteration of the map from first sketch to final version, the full HealthCare.gov example with both solution trees, and the six-question version of the map you can print and use.

Start the Problem Framing Playbook →

The playbook is where the method stops being a diagram. It takes your team from a first map through sailboat interviews to a validated framing, with the AI-assisted analysis workflow the Hessen Police team used. It is part of the Strategyzer Playbook Library, one subscription covering every playbook, with a 14-day money-back guarantee.