The Product Operating Model: A Practical Guide From Inside Cagan's Trainline Case Study

Most companies think they’re doing product management. They have people with “Product Manager” in their title. They run sprints. They have a backlog. They might even have OKRs pinned to the wall.

But they’re not running a product organisation. They’re running a project organisation with product job titles.

The difference isn’t semantic—it’s the difference between a company that builds what stakeholders ask for and a company that solves problems customers actually have. Between a company where engineers are told what to code and one where engineers are the people closest to the technology and therefore best placed to determine the right solution. Between a company that measures success by features shipped and one that measures success by outcomes achieved.

Marty Cagan calls this difference the product operating model—or simply, “how the best tech-powered companies work.” It’s the set of principles, practices, and competencies that companies like Amazon, Spotify, Stripe, and Netflix use to build products. Not a process. Not a framework. Not a methodology you can buy from a consultancy. A way of working rooted in first principles.

I know this because I lived it. As CTO at Trainline , I was part of the leadership team that transformed the company from an old-school, specs-over-the-wall operation into what Cagan describes in his book Transformed as “one of Europe’s best examples of tech-powered product innovation.” Trainline went on to IPO on the London Stock Exchange in June 2019 in one of the UK’s biggest IPOs that year.

And RoadmapOne exists because of what I learned during that transformation. It’s the tool I wish we’d had from day one.

Sign up (free) to build outcome-based roadmaps with the product operating model

What the Product Operating Model Actually Is

The product operating model isn’t a single thing you “implement.” Cagan describes it as five interrelated concepts:

1. Product Culture

The foundation. A product culture emphasises products and outcomes rather than projects and dates. It values learning over failure, innovation over predictability, trust over control, and principles over process.

This is where most transformations stall. You can hire great product managers, restructure into squads, and adopt every practice in the book—but if the culture still rewards hitting dates over solving problems, you haven’t changed anything. The teams will learn to game whatever system you put in front of them.

Cagan’s cultural principles are worth memorising:

• Principles over process — focus on what’s important, not on rituals
• Trust over control — teams can only be empowered when they’re trusted
• Innovation over predictability — “100% predictability = 0% innovation”
• Learning over failure — failure only occurs when you neglect the opportunity to learn

2. Product Strategy

Strategy isn’t a 50-page document. It’s a quarterly decision about which problems matter most, informed by four principles: focus (saying no to most things), insights (from data, customers, and technology), transparency (everyone understands the “why”), and strategic bets (acknowledging uncertainty and managing portfolio risk).

The strategy layer is where leadership earns its keep. In an empowered team model, leadership doesn’t tell teams what to build. They tell teams which problems matter most and why. That requires genuine strategic thinking—not just aggregating feature requests from sales.

This is also where objective tagging becomes critical. When you can see your roadmap breakdown by Run/Grow/Transform , by Innovation Ambition , by SVPG risk type —that’s strategy made visible. Leadership can see whether the portfolio is balanced without micromanaging individual teams.

3. Product Teams

The atomic unit of the product operating model is the empowered product team: a cross-functional group of product manager, product designer, and engineers, assigned problems to solve rather than features to build.

Cagan distinguishes three types of teams, and the distinction matters:

Most companies believe they have empowered product teams. Most actually have feature teams—teams that receive prioritised roadmaps of features to build, with dates attached, and are measured by whether they shipped on time. The product manager in a feature team isn’t a product manager at all—they’re a project manager who happens to sit in the product org.

The diagnostic is simple: do your teams talk about what they’re going to build, or what they’re going to achieve?

4. Product Discovery

Before building anything, empowered teams must address four risks:

• Value risk — will customers buy it or choose to use it?
• Usability risk — can users figure out how to use it?
• Feasibility risk — can we build it with the time, skills, and technology available?
• Business viability risk — does it work for the business (legal, financial, operational)?

Discovery is the practice of testing solutions against these risks before committing engineering capacity to build them. It’s rapid, experimental, and cheap. The alternative—building features and hoping they work—is slow, expensive, and the primary source of waste in most product organisations.

For more on how discovery integrates with roadmapping, see our guide to product discovery in roadmaps and common discovery mistakes to avoid .

5. Product Delivery

Small, frequent, uncoupled releases. Instrumentation to measure what matters. Monitoring to track system and product health. Deployment infrastructure that makes releases boring and reliable.

Delivery in the product model isn’t “Agile ceremonies.” It’s the engineering capability to ship validated solutions quickly and safely. Without it, discovery is academic—you can validate all you want, but if it takes three months to ship, the insights are stale before they reach customers.

Sign up (free) to see your product teams’ outcomes on a single grid

What the Product Operating Model Replaces

When I joined Trainline in 2014, we were executing in a way that would be instantly recognisable to anyone who’s worked in a traditional enterprise. Marketing was nominally responsible for “product.” They produced large specification documents that were handed to outsourced engineering teams to build. We acted like an old, slow-moving business—very much in the mould of the UK rail industry we served.

This is what Cagan calls the feature team model (or worse, the delivery team model). It looks like this:

1. Stakeholders or executives decide what to build — based on customer requests, competitor moves, or gut feel
2. Someone writes a spec — a PRD, a requirements document, a “brief”
3. Engineering estimates and delivers — acting as an internal agency
4. Success is measured by delivery — did we ship on time and on budget?

The fundamental problem isn’t execution. Teams in this model can be perfectly efficient at building the wrong things. The problem is that nobody is accountable for whether the thing that was built actually solves a customer problem or achieves a business outcome.

I’ve seen this pattern repeatedly—not just at Trainline but at every company I’ve been brought in to transform. And the root cause is almost always the same: leadership sees technology as a cost to be managed, not an engine for growth. When the CEO views engineering as a cost centre, you get outsourcing, specs over the wall, and feature teams. When the CEO views engineering as the company’s competitive advantage, you get empowered teams, discovery, and outcomes.

Why Companies Stay Stuck

Nobody actively decides to run a feature team model. It’s inertia. “The way things are done around here.” The org chart crystallised five years ago around projects, not products. The planning process assumes someone in a corner office knows what to build. The board deck tracks features delivered, not outcomes achieved.

The hardest conversation in any transformation is with the CEO. We’re asking for empowered teams—teams that are given problems and trusted to find the right solutions. To a CEO who hasn’t seen this work, that sounds like handing the keys to the engineers and hoping for the best. It sounds like the organisation descending into chaos.

The fear isn’t irrational. Empowerment without competence is chaos. Cagan is explicit about this: you need strong product leadership first, you need to raise the competence bar, and you need to earn trust incrementally. As he puts it: “It’s not less management, but better management.”

The transformation sequence matters. You can’t flip a switch.

The Transformation Playbook

Here’s the sequence that worked at Trainline, and that I’ve seen work at other companies since.

Step 1: Hire Exceptional Product Leaders

This is the first and most critical step. At Trainline, one of the first things I did was help bring in Jon Moore as Chief Product Officer. Jon is now a Partner at SVPG—and at the time, Marty Cagan was his mentor. We didn’t make an explicit decision to “adopt the SVPG model,” but with Jon’s leadership and Cagan’s mentorship, we absolutely adhered to the principles that are now codified as the product operating model.

The quality of product leadership determines everything that follows. You need people who see product as a career, not something they fell into. People who read the literature, who love talking to customers, who care about crafting beautiful things. People who understand that their job is to identify the most important problems and empower teams to solve them—not to write specifications.

Cagan’s research in Transformed confirms this pattern. Rather than replacing the existing team wholesale, Jon discovered many existing staff at Trainline were eager to learn modern product practices. The transformation prioritised three disciplines: engineering, product management, and design.

Step 2: Restructure Into Squads

With strong leaders in place, restructure around durable, cross-functional teams. Each team needs a product manager, a product designer, and engineers—assembled around a meaningful area of the product or customer journey.

The optimal squad size matters. Too small and you can’t sustain delivery alongside discovery. Too large and coordination overhead kills velocity. The teams need to be durable—not assembled and disbanded per project, but persistent, building deep expertise in their problem domain.

Step 3: Outcome-Based Roadmaps

This is where it all comes together—and where it nearly fell apart for us at Trainline.

With 650 people in product and engineering, organised into squads, pursuing outcomes rather than features, we had a new problem: how do you maintain alignment at scale? How does the CEO see what all these empowered teams are actually working on? How do you spot cross-team dependencies? How do you ensure that the highest-priority business objectives have sufficient capacity allocated to them?

Cagan is often characterised as “anti-roadmap.” That’s a misreading. He’s against feature roadmaps—lists of features with delivery dates that tell teams what to build rather than what to achieve. His alternative is: product vision → product strategy → team objectives → high-integrity commitments.

But that alternative needs to be visible. Leadership needs to see it. The board needs to see it. The CEO—the person you’re asking to trust empowered teams—needs to see that the teams are pursuing the right business outcomes with appropriate resources.

That’s what the roadmap is in the product operating model: the handshake with the business. Not a feature list. Not a Gantt chart. A visual representation of which teams are pursuing which outcomes, with what capacity, across which time periods.

When we got this right at Trainline, something remarkable happened. Teams started talking about what they were going to achieve rather than what they were going to build. And the CEO could see business outcomes on the roadmap—conversion rate improvements , churn reduction, market expansion—and start to build trust that empowered teams were pursuing the right things.

The roadmap became the bridge between empowerment and accountability. Teams were free to discover the best solutions. Leadership could see that the solutions were aimed at the right problems.

Build your outcome-based roadmap in RoadmapOne—free sign-up

The WIP Wall: Where RoadmapOne Came From

We spent a long time at Trainline failing to manage work in progress across the teams and ensure consistent focus. With 650 people, the challenge wasn’t individual team productivity—it was organisational alignment. Were multiple squads accidentally working on the same problem? Were there cross-team dependencies that nobody had spotted? Was the board’s highest-priority objective actually getting sufficient engineering capacity?

So we built a spreadsheet. We called it “The WIP Wall.”

The WIP Wall was a grid with squads in rows and sprints in columns. Each cell showed what a squad was focused on in a given sprint—not features, but objectives. You could see at a glance whether the company’s top objectives had teams allocated to them. You could see where multiple squads were collaborating on the same outcome. You could see when a squad’s focus was scattered across too many objectives, diluting their impact.

It was ugly. It was a spreadsheet. But it worked. For the first time, 650 people in product and engineering were aligned around a shared view of what mattered, what was being worked on, and where the gaps were. The board could see the allocation. The CEO could see that empowered teams were focused on the right outcomes. Trust built incrementally.

RoadmapOne is the WIP Wall, productised. The same grid—squads in rows, sprints in columns —with Objectives allocated to specific teams and time periods. The same capacity-based planning that prevents over-allocation. The same analytics that show the board how resources are distributed across strategic priorities.

The difference is that it’s not a spreadsheet that breaks when someone accidentally deletes a formula. It’s purpose-built software that encodes the roadmapping principles we learned at Trainline—the same principles Cagan describes in Transformed.

OKRs in the Product Operating Model

A word of caution on OKRs. Cagan has become increasingly sceptical of how most companies implement them. Despite being a long-time advocate for the technique, he’s observed that the majority of implementations fail—not because the concept is flawed, but because OKRs require empowered teams as a prerequisite.

His diagnosis: “Those successful companies aren’t successful because they use OKRs. They use OKRs because it is designed to leverage the empowered product team model.” When feature teams try to adopt OKRs, the result is what Cagan calls “a contrived mashup of outcomes and features”—teams list deliverables as key results instead of outcome measures, and the whole exercise becomes theatre.

The three prerequisites for OKRs to work:

1. Empowered product teams — not feature teams relabelled
2. Team objectives only — eliminate manager and individual objectives; OKRs belong to cross-functional teams
3. Active leadership engagement — leaders must provide strategic context, coach teams, and stay involved

When these prerequisites are met, OKRs are powerful. Leadership provides the objectives—the problems to solve. Teams provide the key results—specific, measurable outcomes with targets and timeframes. The team owns the commitment because they defined it.

This is exactly how RoadmapOne handles OKRs . Objectives are business outcomes set by leadership. Key Results are defined by the teams themselves. The roadmap shows which teams are pursuing which objectives, making the OKR structure visible at portfolio scale. For more on structuring effective OKRs, see from Objectives to Key Results .

Common Failure Modes

Transformation by Relabelling

The most common failure: rename “project managers” to “product managers,” rename “projects” to “products,” keep everything else the same. The org chart changes. The way of working doesn’t. Teams still receive feature requests. They’re still measured by delivery velocity. The product managers still spend their days managing Jira tickets.

This is what Cagan calls the difference between “doing Agile” and “being agile.” Process people took over Agile and today most companies follow the processes but aren’t even close to living the principles. The same risk applies to the product operating model—you can adopt the vocabulary without adopting the substance.

Empowerment Without Competence

Giving teams autonomy before they have the skills to use it well. If your product managers don’t know how to do discovery, if your designers have never done customer research, if your engineers have never been part of problem-solving—empowerment is just another word for chaos.

The fix is what Cagan describes in Transformed: start with a handful of pilot teams. Give them intensive coaching. Let them refine the practices and demonstrate results. Then expand.

The Roadmap Trap

Replacing your feature roadmap with… a different feature roadmap that uses the word “outcomes.” If your roadmap still lists specific features with delivery dates, you haven’t changed the model—you’ve just changed the formatting.

The test: does your roadmap tell teams what to build, or what to achieve? If it says “Build mobile checkout redesign by Q3,” that’s a feature roadmap wearing an outcome costume. If it says “Increase mobile conversion from 4.2% to 5.0%,” that’s an outcome—and the team is empowered to discover the best way to achieve it.

Death by Process

Adopting SAFe, or some other heavyweight framework, as your “transformation.” Cagan is explicit: the product operating model is principles, not process. Frameworks like SAFe risk creating more coordination overhead than they eliminate. If your teams are spending more time in ceremonies than building product, the framework is the problem, not the solution.

See our guide to WSJF for when SAFe-style prioritisation makes sense—and when it becomes bureaucratic religion.

The Product Operating Model in Practice

Here’s what a company running the product operating model actually looks like day-to-day:

Monday morning. A squad of six—product manager, product designer, four engineers—gathers for their weekly sync. They’re not reviewing a sprint backlog of features. They’re reviewing progress toward their objective: “Reduce new-customer churn from 8% to 5%.” They discuss three discovery experiments they ran last week, what they learned, and which solution direction looks most promising.

Quarterly planning. Leadership doesn’t hand down a list of features. They share the company strategy—three to five objectives that matter most this quarter—with the context of why these problems matter (market data, customer research, competitive intelligence). Teams propose Key Results—specific, measurable outcomes they’ll pursue. The roadmap shows the allocation: which teams are focused on which objectives, with what capacity .

The board meeting. The CEO doesn’t present a list of features shipped. They present the roadmap grid: “35% of capacity is targeting conversion (our North Star ), 25% on market expansion, 20% on platform reliability (KTLO ), 20% on transformational bets . Here’s how each objective is progressing against its Key Results.” The board sees strategic investment, not feature lists. Trust builds.

When the CEO has an idea. Rather than adding it to the top of the backlog (hello, priority whiplash ), the CEO frames it as a problem: “Our enterprise win rate dropped 15% last quarter. I think our reporting capability is falling behind competitors.” That problem enters the strategy conversation. If it’s important enough, it becomes an objective for a team. The team discovers the right solution—which might be better reporting, or might be something entirely different that addresses the underlying concern.

This is what Cagan means by “missionaries, not mercenaries.” Teams that care about solving the problem, not just executing instructions.

From Trainline to RoadmapOne

The product operating model isn’t theory to me. I built my career around it—at Trainline and before. I’ve seen what happens when it works: a company valued at a fraction of its potential transforms into one of Europe’s leading tech companies, IPO’s, and creates enormous value for customers and shareholders alike.

I’ve also seen what’s missing. The principles are well documented—Cagan’s Inspired, Empowered, and Transformed are essential reading. But the tooling hasn’t caught up. Teams adopt the product operating model and then try to run it on Jira, or spreadsheets, or a patchwork of tools that weren’t designed for outcome-based planning.

RoadmapOne exists to fill that gap. It encodes the practices we developed at Trainline:

• Objectives, not features — the roadmap is built around business outcomes, not feature lists
• Squads on a grid — squads in rows, sprints in columns, so everyone sees who is working on what
• Capacity-based planning — so you know whether your objectives are realistically resourced
• Teams define Key Results — leadership sets objectives, teams own the solutions
• Portfolio analytics — tag by Run/Grow/Transform , SVPG risk , Innovation Ambition , or any framework you choose
• Scenario roadmaps — model what-if scenarios without disrupting the master plan

It’s the WIP Wall, rebuilt as software. Built by someone who lived the transformation. Built for teams who want to run the product operating model—not just read about it.

Sign up (free) to run the product operating model in RoadmapOne

Conclusion

The product operating model is simply how the best tech-powered companies work. It’s not a process to install or a framework to license. It’s a set of principles about how product teams should be structured, how strategy should be set, how problems should be solved, and how trust should be built between empowered teams and the business.

The transformation requires courage. You’re asking a CEO to trust teams with problems instead of telling them what to build. You’re asking product managers to be strategic leaders, not project managers. You’re asking engineers to be problem-solvers, not code monkeys. And you’re asking the entire organisation to measure success by outcomes achieved, not features shipped.

At Trainline, we made that transformation. We went from marketing writing specs for outsourced engineers to empowered squads pursuing business outcomes. We aligned 650 people around a shared roadmap. We built trust with the board by making strategic allocation visible. And the company went from undervalued to IPO.

I built RoadmapOne because the hardest part of that transformation wasn’t the principles—Cagan’s books give you those. The hardest part was making it operational. Making 650 people’s work visible on a single page. Ensuring that the board’s priorities had sufficient capacity. Spotting cross-team dependencies before they became blockers. Managing work in progress so teams had consistent focus.

That’s what RoadmapOne does. It’s the operational layer for the product operating model—the tool that turns principles into practice.

The principles are proven. The playbook is documented. The only question is whether your leadership has the courage to trust empowered teams with problems worth solving.