A few weeks ago I was asked to spend a few hours with a team inside a large financial services institution. They were trying to move from a project and change delivery model to something more product-led — and they wanted a second opinion on how they were thinking about their team structure.
What was supposed to be a short conversation ended up being something I kept thinking about afterward. Not because the situation was unusual, but because it was so recognisably familiar. The patterns I saw were the same ones I have encountered in multiple organisations making this transition. The language had changed — squads, product owners, agile ceremonies — but the underlying logic had not. Priorities still flowed top-down. Teams were still accountable for delivery, not outcomes. The structure had been renamed. The thinking had not.
I wrote this piece partly to capture that thinking clearly, and partly because I suspect the same questions are being asked in a lot of organisations right now. It draws on frameworks I have found genuinely useful, what I have seen work, what I have seen fail, and how I approach these transitions when I am brought in to help.
Think of it as a framework, not a formula. Every organisation is different, and the right structure always depends on context. But the principles that make a product operating model actually work — rather than just look right on a slide — are more consistent than people think.
What I typically walk into
Most organisations that say they want to be product-led are not product-led yet, and may not understand what that actually means. It does not mean that the product team is in charge or that it is just the product team that needs to change. That is not a criticism — it is where they are in a genuine transition. But the patterns I see when I arrive are usually variations of the same thing: a governance-heavy structure that has adopted the language of product without changing the underlying logic of how decisions get made and who is accountable for outcomes.
Product-led is not a team design. It is an operating model.
Being product-led means the organisation structures itself around outcomes — specific, measurable changes in user behaviour or business performance — and gives teams genuine authority to decide how to achieve them. Finance funds teams rather than projects. Sales and marketing work from the same outcome metrics as the product team. Executives set goals and stay out of the how. The CRO and CMO are in discovery conversations, not just launch announcements.
That is not a change to the product team. It is a change to the whole organisation: how strategy is set, how budgets are structured, how success is measured, and how every function relates to the product. The organisation structure, the governance model, the hiring profiles, the way performance is tracked — all of it needs to shift. A product team cannot lead that change from inside a function. It requires the CEO to own it.
CEO sponsorship is not optional.
The most consistent difference I see between product transformations that take hold and those that stall is whether the CEO has genuinely committed to a different way of running the company. Not just approving a restructure but personally changing how they engage with product decisions, and holding their leadership team to the same standard.
I have seen well-designed product structures fail because the CEO remained a feature requester. I have seen imperfect structures succeed because the CEO was fully bought in and willing to hold the line when the model was challenged. The CEO is not the CPO's sponsor. They are the transformation's sponsor.
Three specific patterns appear at this stage.
The three patterns that hold organisations back
1. Enabling capabilities as gatekeepers
The first pattern is a set of enabling capabilities — typically cloud infrastructure, data and analytics, compliance, and security architecture — that have been positioned as a separate governance layer above the product teams rather than as services those teams consume. The intention is coordination and consistency. The effect is dependency.
In a product operating model, these capabilities should either be platform teams that product teams can self-serve from, or they should be embedded within the squads themselves. A cloud infrastructure function that product teams have to go through, rather than access directly, is not an enabler. It is a bottleneck with a polite name.
The test is simple: does this capability serve product teams, or does it gate them? If a squad has to raise a request and wait for a response before it can move, that is a project-era dependency wrapped in product-era language.
2. Agile bureaucracy
The second pattern is what happens when organisations implement agile at scale without giving teams real autonomy. The result is a layer of roles — portfolio managers, demand managers, agile coaches, scrum masters, agile analysts — whose function is to manage the agile process on behalf of teams that are not trusted to manage it themselves.
This is sometimes called agile governance. It is more accurately described as waterfall with better terminology. In an empowered product organisation, the Product Manager owns prioritisation. The Engineering Lead owns delivery. The team self-organises. Agile coaching has genuine value when it is teaching teams to reach that state — and none at all when it is coordinating a process those teams should be owning.
The number of agile governance roles in an organisation is inversely proportional to how much it trusts its product teams. A large agile governance layer is not a sign of agile maturity. It is a sign that the transition has stalled.
3. Project roles inside product squads
The third pattern is the most insidious because it is invisible until you look at what is actually in the squads. The team structure might be called squads or product teams. But inside each one you find: a Product Owner who curates a backlog rather than owning an outcome, a delivery manager who runs the sprint ceremonies, and a Business Analyst who captures requirements from stakeholders.
These roles are not wrong in themselves. They are wrong in a product context because of what they signal about where decisions are being made.
A Product Owner in the SAFe sense is a backlog administrator — someone who receives priorities from above and translates them into stories. A Product Manager in the empowered sense is someone who talks to users, forms hypotheses, runs experiments, and decides what to build based on evidence. The gap between those two roles is the gap between a delivery team and a product team.
| Role typically seen | What it signals | What it should be |
|---|---|---|
| Product Owner | Priorities come from above; PO translates them into stories | Product Manager: owns the outcome, owns discovery, challenges what to build |
| Agile Delivery Manager | Delivery is managed separately from the people doing it | Engineering Lead: a senior engineer who also leads — one role, not two |
| Business Analyst | Requirements are captured from stakeholders and handed to engineers | Removed: the PM talks to users directly and the team builds from that understanding |
My framework for the right model
The alternative is not complicated in principle, though it takes discipline to implement in organisations with real governance, regulatory and political constraints. It has three components.
1. Name outcomes, not features
Before touching the structure, I reframe what each part of the organisation is trying to achieve. Product areas are almost always named after the technology they use or the feature they deliver. The shift is to name them after the business result they create.
This matters because it changes everything downstream: what you measure, what you hire for, what the squad is accountable for, and how you know if it is working. A squad called "Data Platform" owns technology. A squad called "Decision Intelligence" owns the quality of decisions being made across the business. Those are fundamentally different mandates.
If you cannot state what your squad is trying to change in the world in one sentence, you do not yet have outcome ownership. You have a delivery team with a new name.
2. Two types of squads
| Squad type | Purpose | Examples |
|---|---|---|
| Revenue squads | Own an outcome end to end — discovery, delivery, measurement. The majority of squads in a healthy product org. | Customer experience, growth, process efficiency, workforce automation |
| Platform and data squads | Serve revenue squads by providing shared capabilities. Remove dependencies rather than create them. | Cloud infrastructure, data and analytics, AI tooling, API layer, compliance capability |
Champions sit outside both squad types. They are individuals, not teams — people who hold the institutional knowledge that squads need to navigate governance, regulatory requirements, and organisational complexity. They guide. They do not gate.
2.1 What goes inside a revenue squad
An outcome squad is built around three distinct disciplines: product, design, and engineering. Each of these is a full-time commitment. Not half a person shared across squads. Not someone who covers the role alongside something else. A squad without a dedicated PM has nobody owning the outcome. A squad without a dedicated designer has nobody owning usability. Engineers split across multiple squads are not a squad — they are individuals with divided attention and no clear accountability.
The instinct to share specialist roles is understandable, especially early in building a product function. A designer supporting three squads looks efficient on paper. In practice it means every squad is waiting for design input, design reviews become the bottleneck in every sprint, and the designer has no continuity with any single outcome. Shared roles create shared accountability, which is functionally the same as no accountability.
| Role | What they own | Risk they cover |
|---|---|---|
| Product Manager | What to build and why. Discovery, prioritisation, outcome tracking. Owns the outcome metric. | Value: will this change behaviour? Viability: does it work for the business? |
| Designer | User experience for the squad's capability area, not just UI. | Usability: can people use it? |
| Engineering Lead | How to build it. A senior engineer who leads delivery — not a separate management layer. | Feasibility: can we build it? |
| Engineers | Building. | Feasibility |
| QA Engineer | Writes automated tests, quality built in throughout — not a sign-off gate at release. | Feasibility |
Five to six people. Every one of them reducing a specific risk. No coordination roles. No handoff roles. No roles whose job is to pass information between people who have knowledge.
Discovery is the process of figuring out what to build before building it. A PM doing discovery is talking directly to users: observing how they work, understanding where they get stuck, testing whether a proposed solution actually changes their behaviour. They form a hypothesis, run a lightweight experiment, and let the evidence shape what goes into the next sprint. It is the opposite of collecting requirements. Instead of asking stakeholders what they want, the PM is diagnosing what users actually need. The distinction sounds subtle. The output is completely different.
2.2 The champion layer
Regulated industries have real governance requirements. There are boards to go to, risk committees to satisfy, compliance steps to follow. Pretending these do not exist produces squads that cannot ship. Building a large central team to manage them produces squads that cannot self-serve.
The solution is a thin layer of champions: individuals (not teams) who hold the institutional knowledge and make the path clear for squads. They navigate. The squad executes. The champion is accountable for the standard and the guidance. The squad is responsible for the execution.
| Champion role (1 person each) | What they hold | What the squad does |
|---|---|---|
| Adoption Champion | Rollout strategy, market sequencing, stakeholder navigation | Delivers its own onboarding activity for its capability area |
| Delivery Practice Champion | Ways of working standards, retrospective facilitation | Self-organises and continuously improves within those standards |
| Governance and Compliance Navigator | Regulatory requirements, risk committee processes, approval steps | Completes the approvals, fills in the forms, attends the boards |
3. Engineering practices as the foundation
A product operating model cannot function without the engineering practices that support it. The most important of these is CI/CD: Continuous Integration and Continuous Deployment.
When teams are doing large, infrequent, high-risk releases, they need Release Managers and UAT sign-off cycles. These are not inefficiencies — they are rational responses to the risk of releasing infrequently. The solution is not better release management. It is smaller, more frequent releases through automated pipelines.
CI/CD means automated testing runs on every code change. Deployment is automated. Releases are small and frequent. The risk of any one release is low. And the roles that exist to manage the risk of big releases — Release Managers, UAT Testers — become unnecessary.
Every UAT Tester and Release Manager on the roster is an ongoing cost of not having invested in automated pipelines. In regulated environments, the pipelines need to be built to meet compliance requirements — which is a one-time investment against a recurring overhead.
A framework, not the finish line
Every organisation arrives at this transition from a different starting point — with existing teams, existing debt, existing politics, and existing customers who cannot wait for the structure to be perfect before they are served. Nobody is building this on a greenfield. The goal is not to implement it perfectly. It is to move in the right direction, deliberately, and to keep optimising as you go.
The framework gives you the model. What it cannot do is clear the path. In practice, there are obstacles — some structural, some cultural, some commercial — that get in the way of even the most well-designed transition. Seeing them clearly is half the work. Getting over them is the other half. Part 2 works through the ones I encounter most often.
