CTO vs CPO: Who Actually Owns the Roadmap?

The question nobody wants to answer clearly

Every scaling company hits this moment. The CPO presents a roadmap. The CTO looks at it and thinks: "This ignores half our technical debt, assumes infinite capacity, and commits us to timelines we never agreed to." The CPO thinks: "Engineering keeps sandbagging estimates and sneaking in refactors nobody asked for."

We've all been in that room.

The honest answer to "who owns the roadmap?" is: neither role owns it alone, and pretending otherwise causes real damage. But that answer is unsatisfying, so let's get specific about why this tension exists and what we've seen work.

Why this fight keeps happening

The CPO role is optimized for market signal. What do customers want? What moves retention? What opens a new segment? The CPO lives in discovery, user research, competitive analysis. Their job is to maximize the value of what gets built.

The CTO role is optimized for system capability. What can we actually build? What's the cost of building it on top of the current architecture? What breaks if we keep ignoring that migration? The CTO's job is to maximize the ability to keep building, sustainably.

These two optimization functions conflict. That's not a bug. It's the entire point.

The problem starts when one side wins by default — usually because of org design, founder preference, or whoever got hired first.

What happens when one side dominates

CPO owns it all: The roadmap becomes a feature factory. Technical debt compounds silently. Six months in, the team can't ship a login change without a two-week regression cycle. We watched a Geneva-based B2B SaaS company go through exactly this — their CPO ran a tight quarterly roadmap with zero infrastructure investment for nearly a year. When they finally needed to integrate a major payment provider, what should have been a three-week project took four months. The architecture couldn't support it. Two senior engineers quit during the process.

CTO owns it all: The roadmap becomes an internal engineering wishlist. Beautiful architecture, immaculate CI/CD pipelines, zero customer-facing progress. The board starts asking uncomfortable questions. Sales has nothing new to sell. The CPO, if one even exists, becomes a glorified ticket writer.

Both failure modes are common. Both are preventable.

What actually works

Shared ownership with clear accountability

The roadmap is a shared artifact. 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 prioritization. Not a veto. Not a rubber stamp. A seat with data.

A capacity split everyone agrees on

Most teams we talk to in Romandy land somewhere around 70/30 or 80/20 — product work vs. engineering-driven work. The exact ratio matters less than the fact that it's explicit and reviewed quarterly. When it's implicit, engineering-driven work gets squeezed to zero, then everything breaks at once.

Joint ownership of outcomes, not just outputs

If the CPO is measured on feature delivery and the CTO is measured on uptime and velocity, they'll optimize against each other. We've seen better results when both roles share accountability for something like "time from idea to customer value." That metric forces collaboration because it captures both what gets built and whether the system can support building it.

Regular, structured friction

One CTO in our community runs a monthly "roadmap tension" session with their CPO. They literally review where their priorities conflict, score the trade-offs, and document the decisions. No passive-aggression. No hallway politics. Just structured disagreement with a resolution mechanism.

It sounds simple. Almost nobody does it.

The org chart isn't the answer

We sometimes get asked: "Should the CPO report to the CTO? Or the other way around?" In our experience, the reporting line matters far less than the operating model. Two peers who have a clear framework for resolving tension will outperform any hierarchical setup where one role subordinates the other.

The roadmap is the single highest-leverage artifact in a product company. Letting it become the territory of one function is how you end up rebuilding things you shouldn't have built in the first place.

The takeaway

The roadmap isn't a product document or a technical document. It's a business document that requires both perspectives to be worth anything. Define the split, structure the disagreement, and measure shared outcomes. The companies that get this right ship faster and break less. The ones that don't just argue about it until someone leaves.