In Marty Cagan's Inspired, the canonical text of modern product management, the product manager is described as accountable for what gets built and the engineering function as accountable for how. The model has held for a decade in part because most software companies in the early 2010s built things that engineering could easily ship if product wanted them. The model is now under quiet stress, because the systems being built — agentic AI features, distributed data products, multi-tenant compliance-bound services — have ceased to be cheap to ship, and the cost of not investing in the platform is rising faster than the visible cost of building it.
That stress lands, in practice, on a single artefact: the roadmap.
The question nobody answers clearly
Every scaling company hits a recurring moment. The CPO presents a roadmap. The CTO looks at it and concludes, with reason, that it ignores the technical debt the team has been carrying since the last fund-raise, assumes infinite capacity, and commits the organisation to delivery dates the engineering function never agreed to. The CPO, also with reason, concludes that engineering keeps sandbagging estimates and routing investment into refactors nobody outside the team has asked for.
The honest answer to "who owns the roadmap?" is: neither role owns it alone, and treating it otherwise causes real and measurable damage. That answer is unsatisfying, which is why most companies decline to give it and instead settle the question implicitly through founder preference, hiring order, or which role reports closer to the CEO.
Why this fight keeps happening
The CPO role is optimised for market signal. What do customers want? What moves retention? What opens a new segment? The CPO operates in discovery, user research, competitive analysis. The job is to maximise the value of what gets built.
The CTO role is optimised for system capability. What can the organisation actually build? What is the cost of building it on top of the current architecture? What breaks if the team keeps deferring that migration? The job is to maximise the organisation's ability to keep building, durably.
These two optimisation functions conflict. That is not a bug. It is the entire structural point of having two roles. The DORA research programme — the longest-running quantitative study of software delivery — has documented for over a decade that the strongest performers maintain explicit investment in technical health alongside feature throughput, and that the weakest performers chronically under-invest in platform work until forced into emergency remediation.1 The 2024 report extended this finding to AI deployments, observing that organisations adopting AI tools without proportionate investment in the underlying delivery system saw a 1.5% decrease in throughput and a 7.2% decrease in stability for every 25% increase in AI adoption.2
The conflict is structural. It does not go away because the org chart is tidy.
What happens when one side dominates
The two failure modes are symmetric, common, and well documented in product-management and engineering-leadership literature.
When the CPO dominates: The roadmap becomes a feature factory. Technical debt compounds silently. The integration patterns hardening into the codebase reflect the shortest path to ship rather than the most maintainable path forward. Six months in, the team cannot ship a login change without a two-week regression cycle. Twelve months in, the company commits to a major integration — a payment provider, a regulatory reporting workflow, a new geography — and discovers that what should have been a three-week project takes four months. Senior engineers, who saw it coming, leave during the process. Will Larson's An Elegant Puzzle describes this pattern in detail; the recognition signature is that everything ships on time until suddenly nothing does.3
When the CTO dominates: The roadmap becomes an internal engineering wishlist. Architecture is immaculate; CI/CD is gold-plated; observability dashboards are publishable. Customer-facing progress lags. The board begins asking uncomfortable questions about commercial traction. Sales has nothing new to sell. The CPO, if one exists, becomes a glorified ticket writer. This pattern is less commercially explosive than the first but more strategically corrosive: the organisation gets out-shipped by competitors whose platforms are worse but whose product velocity is higher.
Both modes are preventable. Neither prevention is the org chart.
What actually works
The pattern observable across the strongest growth-stage companies has four components, each unglamorous and each implemented imperfectly.
Shared ownership, separated accountability. The roadmap is a shared artefact. The CPO drives the what and why — which problems to solve, in what order, based on customer and market signal. The CTO drives the how and at what cost, including the cost of not investing in the platform. This means the CTO has a real seat at prioritisation. Not a veto. Not a rubber stamp. A seat with data — capacity, debt, reliability targets, infrastructure cost curves. The CPO has the equivalent seat at architectural trade-offs: not approving them, but understanding the customer-impact translation of deferring or accepting them.
An explicit capacity split. Most companies' delivery health correlates well with an explicit declaration of how much engineering capacity is allocated to customer-driven roadmap work versus engineering-driven investment work. The exact ratio matters less than the explicitness — 70/30, 80/20, sometimes 60/40 in regulated environments with heavy compliance burden. The variable that distinguishes healthy organisations from troubled ones is whether the ratio is reviewed quarterly and visible, or implicit and squeezed to zero whenever delivery pressure rises.
Shared metrics that resist gaming. If the CPO is measured on feature delivery and the CTO is measured on uptime, they will optimise against each other under pressure. The DevOps research consensus is that the metric set that pushes both functions toward collaboration is some combination of deployment frequency, lead time for changes, change failure rate, and time to restore — the DORA four — paired with a customer-outcome metric like activation rate or feature-adoption-to-retention.1 When both functions share accountability for a metric like "time from validated idea to customer value realised in production," the metric forces collaboration because it captures both what gets built and whether the system can support building it.
Structured friction. A monthly "roadmap tension" session between CTO and CPO. Review where priorities conflict, score the trade-offs explicitly, document the decisions, name the deferred investment. No passive aggression, no hallway politics, no Slack-thread relitigation. Just structured disagreement with a documented resolution mechanism. Will Larson and Camille Fournier have both written about this practice as a defining habit of mature engineering organisations.34 It sounds simple. Almost nobody does it consistently.
The org chart is not the answer
A recurring question in CTO peer groups is whether the CPO should report to the CTO, the other way around, or both to the CEO. The reporting line matters far less than the operating model. Two peers who share a framework for resolving tension will outperform any hierarchical setup where one role subordinates the other. The McKinsey Tech Forward research on tech-and-product organisation design has reached the same conclusion across multiple cohorts: the structure of the relationship matters more than the org chart.5
The roadmap is the single highest-leverage artefact in a product company. Letting it become the territory of one function is the most reliable mechanism by which growth-stage companies end up rebuilding things they should not have built in the first place — and the most common reason the engineers they most wanted to keep choose to leave during the resulting cleanup.
What this means operationally
The roadmap is not a product document or a technical document. It is a business document that requires both perspectives to be worth anything. Define the split, structure the disagreement, measure shared outcomes, and resist the temptation to settle the conflict through the org chart. The companies that get this right ship faster and break less. The ones that do not just argue about it until one of the principals leaves.
The argument is not the failure. The failure is when the argument stops happening because one role has won.