When the CEO is not genuinely committed, the transformation hits a ceiling almost immediately. Executives revert to raising feature requests because nobody above them has signalled they should stop. Finance continues to fund projects rather than teams because the budgeting model has not changed. The product team gets restructured but the surrounding organisation continues to operate on project logic, and squads cannot move because they are still dependent on functions that have not changed.
When the CEO is fully bought in, the whole system aligns. They set outcome goals and hold the C-suite to them. The finance model follows. The culture shifts because the person at the top is modelling the new behaviour and backing the squads when the old patterns push back.
That difference — not the framework, not the squad design, not the hiring — is what separates transformations that take hold from those that stall.
How the C-suite connects to the model
In a scaling company, the C-suite relationship with product is one of the most important things to get right — and one of the most commonly broken. The shift required is from C-suite as feature requestors to C-suite as outcome sponsors. Each executive owns a set of business outcomes. Those outcomes become the mandates for squads. The squads decide how to achieve them. The CPO is the interface — translating strategic goals into squad mandates, and translating squad capability into strategic options for leadership.
Chief Revenue Officer
The CRO owns the revenue targets that become outcome metrics for revenue squads. In a scaling company, the CRO is often the most influential voice on what gets built — and the most likely to bypass the PM and raise requests directly to engineering.
The product model reframes this relationship: the CRO defines what needs to move (new business rate, renewal rate, time to close) and shares pipeline intelligence with PMs — what is blocking deals, what customers are asking for, where the conversion drop-off is. The PM takes that signal into discovery and decides how to respond. The CRO does not own the roadmap. They own the goal.
One assumption worth challenging here: the CRO is not the voice of the customer. The CRO is the voice of the buyer. In B2B, those are frequently different people. The CRO knows what closes deals. The PM needs to know what serves users — treating the CRO as a proxy for the customer will steer the product in the wrong direction. Products built primarily on what the CRO is hearing win the first contract and lose the renewal.
Products built primarily on what the CRO is hearing win the first contract and lose the renewal.
Chief Marketing Officer
In a B2B scaling company, marketing operates on long sales cycles, account-based relationships, and broker or intermediary networks. The CMO's primary job is building pipeline credibility and supporting the commercial relationship. That context changes how marketing and product should work together.
The most valuable thing the CMO brings to product is market intelligence: what is resonating in conversations with prospects, which objections keep appearing, what competitors are doing, how the brand is perceived by the decision-makers who actually buy. In B2B, this intelligence is rich and specific — and it rarely makes its way into product discovery systematically.
The PM and CMO should be working closely on go-to-market sequencing for new capabilities: not as a handoff but as a joint process. In enterprise B2B, how a new feature is positioned to a CFO or procurement team is as important as what it does. Marketing insight should be shaping what gets built. Product insight should be sharpening how it is sold and communicated.
The CMO does not own the launch timeline or the roadmap. They own the market signal.
Chief Operating Officer
In B2B fintech, the COO often owns the post-sale customer journey — implementation, onboarding, and support. That makes them the first person to feel the downstream consequences of a bad product decision, and they feel it in operational terms: implementation that takes three times as long as it should, support volume that climbs after every release, manual workarounds that calcify into permanent headcount.
A well-designed product reduces that cost. A poorly designed one passes the complexity to the operations team and shows up as extra headcount, slower implementations, and a support function that is permanently firefighting.
The COO should be feeding that operational intelligence back into product discovery: where implementations consistently get stuck, what generates the most support tickets, which customer scenarios require manual intervention every time. That signal is as valuable as anything the CRO is hearing from the sales floor — and it is almost never flowing systematically into product.
The outcome contract for the COO: they define the operational metrics that matter — implementation time, cost-to-serve per customer, support resolution rates — and the squads work out how to move them. The COO does not specify the solution. They own the problem.
Chief Technology Officer
In a scaling company, the CTO is often deeply technical and directly involved in engineering decisions. They typically own the platform squads and set the engineering standards — hiring, architecture, tooling — that all squads operate within.
The CTO and CPO relationship is the most structurally important in the model. The CTO owns how the product is built. The CPO owns what gets built and why. Those two functions need to be tightly aligned and deeply collaborative.
The CTO should not be directing sprint content or backlog priorities for revenue squads. Their influence on squads runs through the Engineering Leads they have hired and the standards they have set. The revenue squad's Engineering Lead is the CTO's technical proxy inside the squad — accountable to the squad's PM for delivery, and accountable to the CTO for technical quality.
The most common source of misalignment is capacity. The CTO controls where engineers work. In a product model, that capacity should serve squad outcomes and platform health — but CTOs often run technical programmes alongside the product roadmap without explicit alignment with the CPO. Squads find themselves short of engineers they expected, and commitments slip.
The pressure runs the other way too. A CPO focused on shipping features can underestimate what it costs to defer investment in engineering foundations — the CI/CD pipeline, automated testing, deployment reliability. The CTO's job is to hold that line. If the foundations are not being maintained, squad autonomy is theoretical: features ship, things break, and the operations team absorbs the cost quietly.
The CTO does not own the roadmap. They own the engineering foundation that makes the roadmap possible.
The leadership contract
The model only works if the C-suite agrees to a different type of involvement. More influence earlier — in outcome-setting, strategy, and discovery — and less influence later, once the squad is executing.
What changes for the C-suite
How they influence product — Old model: raise feature requests, attend roadmap reviews. Product model: set outcome goals, share intelligence, review metrics.
When they get involved — Old model: at delivery (reviewing what was built). Product model: at discovery (shaping what problem to solve).
What they are accountable for — Old model: project milestones. Product model: business outcomes.
How they measure the product team — Old model: velocity, features shipped. Product model: outcome metrics moved.
This is a harder ask for executives who are used to having direct influence over what gets built. Most find the shift harder than expected — not because they disagree with the principle, but because stepping back from day-to-day product decisions feels like losing influence. The opposite is true. Executives who own outcomes rather than features have more leverage, not less. The payoff is that squads move faster, make better decisions, and deliver outcomes that actually move the business — because they were given the problem to solve rather than the solution to build.
Executives who own outcomes rather than features have more leverage, not less.
The principles I always come back to
Three articles, one argument. Part one covered the foundation. Part two covered what gets in the way. Part three covered the leadership layer that determines whether any of it holds.
The failure modes in part two are not unusual. They appear in almost every transformation, in some form, at some point. That is not a reason to be discouraged — it is a reason to understand why leadership matters so much. A product team that knows the model and is trying to do the right things will still hit investor pressure, shadow backlogs, unclear decision rights, and the people conversations everyone avoids. What determines whether those obstacles break the transformation or just slow it down is whether the CEO is genuinely in it with them. The product team cannot do this alone. It was never supposed to.
Building that relationship is the CPO's job, not the CEO's. The CEO has to be willing. The CPO has to make it easy for them — by speaking in outcomes not features, by bringing the CEO into the hard conversations early, and by making the case for why this matters for the business, not just for the product team.
Outcomes before structure. Name what you are trying to change in the world. Then design the structure to own it. Never start with the org chart.
Revenue squads on a shared platform. Revenue squads own the results. Platform and data squads make it possible. The flow is upward — platform serves outcomes, not the other way round.
Every role in a squad owns something. If a role exists primarily to coordinate between people who have knowledge, it is a handoff. Handoffs slow everything down and dilute accountability.
Real autonomy within real alignment. The organisation sets the outcome metrics and the strategic direction. The squad decides how to get there. Dictating the how turns product teams back into delivery teams.
Champions navigate. Squads execute. Institutional knowledge and governance expertise belong in a thin expert layer. The doing belongs in the squads.
Engineering practices are not optional. Continuous delivery, automated testing, and small frequent releases are not engineering preferences. They are the foundation the product model sits on.
Small, stable teams beat perfect org charts. Five to seven people who have worked together long enough to trust each other will outperform a theoretically perfect structure that keeps reshuffling. Stability is a feature.
The product team can design the right model. Only the CEO can make it stick.
Every one of these principles sits on a foundation. The CEO is the transformation's sponsor — not the product team's cheerleader, but the person who sets the culture, holds the C-suite to the new model, and backs the squads when the organisation's old habits push back. The product team can design the right model. Only the CEO can make it stick.
