How Design Sprints and Problem Framing Power Marty Cagan’s Product Operating Model
Marty Cagan’s Product Operating Model (POM) is quickly becoming a benchmark for modern product organizations. It outlines what high-performing product teams look like and how they work. The goal is clear: move away from feature factories and empower teams to solve real problems and deliver value for both the customer and the business.
More and more organizations are rolling out the model — or at least trying to. But turning this aspiration into day-to-day practice isn’t easy.
The Challenge
Cagan’s Product Operating Model is grounded in principles. It’s conceptual, not procedural.
It’s not a framework, not a playbook, not a process.
It doesn’t tell you how to do product strategy, or what a good discovery process looks like. It gives you the “why,” and in some cases, the “what.”
Cagan himself says “principles over process.” And I get that — and agree, for the most part. But when you're trying to implement this at scale — across dozens (hundreds?!) of teams — principles alone are not enough.
Teams need repeatable, structured ways of working that align with those principles.
That’s where Problem Framing and Design Sprints come in.
Before we dive into how they help, let’s first look at how the model is structured.
A Quick Overview of the Product Operating Model
Cagan’s model is built around three dimensions:
- How products are built (delivery)
- How to decide which problems to solve (strategy & leadership)
- How to solve those problems (discovery)
Problem Framing and Design Sprints directly support the last two dimensions — deciding what to solve and figuring out how to solve it.
He also defines five core product concepts:
- Product Culture
- Product Strategy
- Product Teams
- Product Discovery
- Product Delivery
With that in mind, let’s explore how Problem Framing and Design Sprints help bring the model to life.
How to Decide Which Problems to Solve
Most organizations struggle with this. In traditional models, problems come pre-packaged as solutions from stakeholders (of course, there are exceptions), and the team’s job is to deliver. This leads to a feature factory mindset—high output, low impact, and a lot of waste.
The Product Operating Model flips that: teams should be given problems, not solutions. It’s the job of product leaders and managers to represent stakeholders, understand business goals, and identify opportunities worth solving.
That’s easier said than done.
Stakeholders won’t just step aside and let product managers speak on their behalf. They still have business needs and constraints they want reflected in the product. If product leaders want to earn the trust to represent them, they need to prove they understand the business first.
On the flip side, ask 100 product managers what their biggest challenge is — and most will say “stakeholder management.”
Both sides have a point.
So how do you build mutual trust?
And how do you get alignment around the right problem?
How do you move from vague business goals and stakeholder opinions to a shared understanding of a real user challenge?
Enter Problem Framing
Problem Framing is a structured decision-making process that combines product discovery with a high-stakes alignment workshop — helping teams align on the right problem before jumping into solutions.
With Problem Framing, product leaders and PMs can:
- Map out stakeholder expectations
- Surface assumptions and business constraints
- Synthesize insights from customer research and data
- Understand the competitive landscape and trends
Most importantly, they help stakeholders make informed decisions — defining and prioritizing opportunities that matter through the Problem Framing Workshop that concludes the process. PMs become decision-making facilitators — and that’s how they earn trust and buy-in from stakeholders.
Problem Framing is the bridge between business strategy and product discovery. It ensures teams don’t jump into solution mode without knowing what problem they’re solving — and why now.
How to Solve Problems
Once teams are handed a clear problem, the clock starts ticking.
Stakeholders expect results. You also want to get your ideas in front of the users sooner than later, because that’s when real learning begins.
Therefore teams need to explore options and do it fast. Customers need to be brought into the process. In the Product Operating Model this happens through Product Discovery.
Cagan breaks discovery into two parts:
- Problem Discovery → What’s the real need?
- Solution Discovery → What’s the right solution?
Problem Framing covers the first part.
Design Sprints take care of the second.
Enter Design Sprints
A Design Sprint is a rapid problem-solving method that brings together people with diverse expertise and gives them focused time to collaboratively solve a specific challenge in just four days.
It’s a framework for quickly validating new ideas by directly testing them with end users.
It’s fast, structured, and focused — the perfect tool for empowered teams (see what I did here 🙂) working under pressure.
With Design Sprints, teams can:
- Generate multiple solutions in a short time
- Align on a direction without endless debate
- Prototype and test with real users in days, not months
- Create evidence to inform product decisions
Design Sprints also embody key aspects of Cagan’s Product Teams concept:
- Cross-functional collaboration — PMs, designers, and engineers solving problems together
- Outcomes over output — solving for user and business impact, not just delivering features
- Empowerment and ownership — in a design sprint teams are responsible for finding the best solution
In other words: they don’t just help teams solve problems — they help them work like true product teams.
Turning Principles Into Practice
The Product Operating Model offers a strong foundation based on a set of core principles.
But principles alone don’t scale. You need systems and methods that teams can apply consistently, effectively, and at speed.
The Product Operating Model gives you the philosophy. Problem Framing and Design Sprints give you the system.
They help teams:
- Align with stakeholders on what matters (and earn their trust)
- Define and prioritize the right problems (for both business and customers)
- Test and validate solutions early (with real users)
- Make better decisions, faster (with confidence).
They’re structured, repeatable, and scalable — designed to adapt to the messy reality of product work.
If you want your teams to live the Product Operating Model—not just admire it—you need to give them the tools to do so.
Mapping Design Sprints and Problem Framing to Product Operating Model
.png)
How We're Helping Organizations Do This
To run Problem Framing and Design Sprints, teams need someone who knows how to prep and facilitate the workshops. That role is called the Facilitator.
In the Product Operating Model, core roles include product managers, product designers, tech leads, and product leaders. The facilitator role can be taken by any of them — and in our experience, it often is. PMs, UX designers, agile coaches, and scrum masters all make great facilitators because they already operate in the right spaces.
Most companies we work with add facilitation on top of an existing role.
My personal preference? A dedicated team of facilitators. That’s all they do. And you don’t need many — one facilitator can support 3–4 product teams.
Once companies decide who will lead facilitation, we:
- Train them in both Problem Framing and Design Sprints
- Provide toolkits, templates, and checklists to ensure consistency
- Help them run their first real workshops with guidance and support
- Ongoing support and coaching by creating internal Communities of Practice
Now, both Problem Framing and Design Sprints are quite intense processes. They require a fair amount of preparation, planning, and time and focus from the teams during the workshops.
Which is why you will not make them daily rituals. But instead, use them smartly when needed.
We recommend a quarterly Problem Framing workshop to:
- Surface the top opportunities
- Refine the roadmap
- Update product strategy
And 1–3 Design Sprints per team per quarter to tackle the riskiest ideas.
That cadence helps teams and stakeholders get into a rhythm — and start trusting the system.
Real-World Examples
World Bank makes it mandatory for all their product teams to know how to run Design Sprints and Problem Framing.
StepStone’s product teams made Design Sprints a regular practice and use them to de-risk and inform their product roadmap.
