How design sprints and problem framing power Marty Cagan’s Product Operating Model

April 13, 2025
John Vetan

A practical guide for product leaders, heads of product, and innovation managers trying to operationalize Marty Cagan's Product Operating Model at scale. Covers what the model gives you, what it does not, and the two structured methods — Problem Framing and Design Sprints — that turn its principles into something product teams can actually run.

You will leave with a clear map of where each method fits inside Cagan's three dimensions, the cadence that works in real product organizations, the team and facilitator setup that makes adoption stick, and the AI-era extension when the work involves AI initiatives rather than traditional product problems.

Why Marty Cagan's Product Operating Model needs methods, not just principles

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:

  1. How products are built (delivery)
  2. How to decide which problems to solve (strategy & leadership)
  3. 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.

🔗 Learn Problem Framing

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.

🔗 Learn Design Sprints

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

POM + Problem Framing + Design Sprints

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:

  1. Train them in both Problem Framing and Design Sprints
  2. Provide toolkits, templates, and checklists to ensure consistency
  3. Help them run their first real workshops with guidance and support
  4. 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

Two product organizations that demonstrate what this looks like at scale:

The World Bank has introduced Problem Framing and Design Sprints knowledge and practice to their IT teams. Read the case study.

StepStone built a self-sustaining innovation practice on top of Design Sprints. Their product teams use sprints regularly to de-risk and inform the product roadmap. The cadence is now part of how the organization decides what to build. Read the case study.

How does the Product Operating Model extend to AI work?

The argument so far is straightforward. Cagan's Product Operating Model gives you the principles. Principles do not scale without methods. Problem Framing and Design Sprints are the methods that make the model real.

In 2026, the place where this argument hits hardest is AI work.

Cagan's principles still apply. Teams should be given problems, not AI solutions. Discovery should still split into problem discovery and solution discovery. Outcomes still matter more than output. None of that changes when the work involves AI.

What changes is the failure mode. Problem Framing was designed to align stakeholders on a strategic business problem. Design Sprints were designed to validate product solutions with customers. Both still work for those use cases — but neither was designed for the specific shape of an AI initiative.

An AI initiative usually arrives at the team in one of three messy shapes:

  • A leadership mandate ("do something with AI") without a defined problem
  • A portfolio of twenty or thirty AI use cases that nobody knows how to compare
  • A workflow redesign question — what should the work look like if AI is embedded in it? — that does not map cleanly to a product prototype

Those three shapes are not what Problem Framing or the Design Sprint were built for. So the lineage extended. Same principles, same structural logic, two new methods designed for the specific shape of AI work:

  • AI Problem Framing — the Problem Discovery method for AI. A one-day workshop for cross-functional teams to move from a vague AI mandate to a clear, prioritized AI use case. It is what Problem Framing becomes when the question shifts from which business problem should we solve to which AI use case should we build.
  • AI Workflow Sprint — the Solution Discovery method for AI. A four-day workshop for redesigning a workflow around AI and validating it with the people who would actually use it. It is what the Design Sprint becomes when the prototype is not a customer-facing product but a redesigned way of working.

If you are running Cagan's model and trying to figure out where AI fits, the answer is to keep the same two-phase logic: decide what to solve, then figure out how to solve it. The methods that operationalize the logic simply need to be built for the new failure modes. AI Problem Framing and the AI Workflow Sprint are those methods.

Turning Cagan's principles into a working product organization

The Product Operating Model offers a strong foundation. It defines how empowered product teams should operate, how product leaders should set direction, and how organizations should move beyond the feature factory. Cagan does the philosophical work better than anyone in the field.

What the model deliberately does not do is tell teams how to run a discovery process, how to align stakeholders on a problem, or how to validate a solution. Those are the how questions that every product organization has to answer for itself.

Problem Framing and Design Sprints are the answer that works in practice. They are structured, repeatable, scalable. They give teams a way to live the model rather than admire it. They help teams:

  • Align with stakeholders on what matters and earn the credibility to be given problems instead of solutions
  • Define and prioritize the right problems for both the business and the customer
  • Test and validate solutions with real users before engineering investment
  • Make better product decisions, faster, with evidence

If you want your teams to run the Product Operating Model, you have to give them the tools to do so. Cagan supplies the philosophy. Problem Framing and Design Sprints — and their AI-era extensions — supply the practice.

FAQs

Does Cagan's Product Operating Model work for AI initiatives?

Yes. The principles apply directly. Teams should be given problems, not AI solutions. Discovery should still split into problem discovery and solution discovery. Outcomes still matter more than output.

What changes is the method needed to operationalize those principles when the work involves AI. Problem Framing and Design Sprints work for traditional product problems but were not built for the specific shape of AI initiatives — vague mandates, incomparable use cases, workflow redesign rather than product design.

For AI work, the two-method extension is AI Problem Framing for the discovery side and the AI Workflow Sprint for the validation side. Same principles, methods built for the new failure modes.

How does Problem Framing fit into the Product Operating Model?

Problem Framing sits in the Product Discovery dimension of Cagan's model — specifically, the Problem Discovery half. Cagan splits discovery into Problem Discovery — what is the real need? — and Solution Discovery — what is the right solution?

Problem Framing is the structured method for Problem Discovery: a one-day workshop that brings senior stakeholders together to align on which problem is worth solving, before any solution work begins. It is also the practical bridge between business strategy — deciding what to solve — and product discovery — figuring out how.

Without it, product teams either inherit pre-packaged stakeholder solutions or burn weeks trying to align on direction through meetings.

What is the difference between Problem Framing and Design Sprints in the context of the Product Operating Model?

Problem Framing decides what to solve. Design Sprints validate how to solve it. They cover different halves of Cagan's discovery dimension, and they are not interchangeable.

Problem Framing is upstream — it is where you align stakeholders on which problem matters, what business outcome you are chasing, and what the user evidence supports. Design Sprints come downstream — once the problem is defined, the sprint generates and tests solutions with real users in four days.

Running a Design Sprint without Problem Framing is a common failure mode: the team prototypes fast, but they prototype the wrong thing. Running Problem Framing without a follow-through method means the alignment dissipates before solutions get tested. Both methods earn their place because they cover complementary parts of the same arc.

Read more about what’s the difference between Problem Framing and Design Sprints.

Where do AI Problem Framing and the AI Workflow Sprint fit?

AI Problem Framing is the AI-specific evolution of Problem Framing — same one-day structure, same decision-maker focus, but framed around defining and prioritizing AI use cases inside a strategic opportunity area.

The AI Workflow Sprint is the AI-specific evolution of the Design Sprint — same four-day structure, but the prototype is a working AI agent or AI-enabled workflow rather than a clickable mock-up.

The decision logic in this article applies in both directions: when the AI problem is unclear, run AI Problem Framing first; when the AI use case is clear and you need to validate the solution with users, run an AI Workflow Sprint. The Product Operating Model is the umbrella. AI Problem Framing and the AI Workflow Sprint are the methods that make it work when the work involves AI.

How often should a product organization run Problem Framing and Design Sprints?

Both methods are designed to be high-leverage moments, not daily rituals. The cadence that works inside organizations running the Product Operating Model: one Problem Framing workshop per quarter per major product area, used to surface opportunities and refine the roadmap; and one to three Design Sprints per product team per quarter, used on the riskiest solution ideas where the cost of building the wrong thing is highest.

This cadence creates a rhythm that teams and stakeholders can plan around, and it gives the methods enough air to compound over time.

Does every product manager need to be trained in facilitation?

Not necessarily. Two patterns work. The first is to embed facilitation into existing PM, designer, and coach roles — anyone who already operates in alignment-and-decision spaces can pick it up with training. The second is to build a small dedicated facilitator team that serves the whole product organization.

One facilitator can support three to four product teams. Smaller organizations usually start with the first pattern. Larger product organizations with serious adoption goals usually end up at the second within a year.

What is the relationship between the Product Operating Model and the Design Sprint specifically?

The Design Sprint operationalizes the Solution Discovery half of the Product Operating Model's discovery dimension. It encodes several of Cagan's Product Teams principles directly into the way the workshop runs — cross-functional collaboration in the room, outcomes-over-output framing for the goal, and team ownership of the decision.

A Design Sprint that follows from a clear problem statement — ideally produced by Problem Framing upstream — is the single sharpest way to put Cagan's discovery principles into practice on a real product decision.

Next steps