CTO and product leadership are converging, but they are not the same job

For most of my career the constraint was capacity. There was more to build than people to build it, so technical leadership meant protecting throughput: architecture that would not collapse, a team that could ship, systems that stayed up. Being good at the job meant being good at execution.

That constraint has moved. Implementation is not free, but it is no longer the thing in shortest supply. What is scarce now is knowing which problems deserve the capacity — and being able to defend that answer against the many plausible alternatives a company generates every quarter.

That is why the CTO role keeps drifting toward product. Not because titles are being reshuffled, but because the decisions that determine outcomes moved, and technical leaders were already in the room where those decisions get made.

Why the two roles are converging

Three forces push a CTO toward product work.

Technology is now part of the product surface, not underneath it. When your product is a platform, an API, an SDK, or an agent-facing interface, the technical design is the user experience. Deciding how an API versions, what a rate limit means for a partner, or whether a capability is exposed as a product or an internal service is simultaneously an engineering and a product decision. Someone has to hold both. Splitting it produces a product plan that ignores physics and an architecture that ignores customers.

Feasibility judgment has become a strategic input, not a downstream check. The interesting question is rarely “can we build it” — it is “what does this cost us for the next three years.” Which options does this foreclose? What operational load does it create? What can we reverse cheaply? A product leader without technical depth cannot price those questions, and a technical leader who only answers them when asked has forfeited the position where they matter.

Execution quality is now mostly organizational. How teams decide, who is allowed to say no, how discovery hands off to delivery, how continuity work is funded — these determine outcomes more than framework choices. That is organizational design, which is neither traditional product management nor traditional engineering management. In practice it lands on whoever is willing to own it.

What stays genuinely different

Convergence at the level of judgment does not mean the accountabilities collapse. Four things still separate the roles, and pretending otherwise is how companies get hurt.

Discovery is a discipline, not an instinct. Talking to customers systematically, running evidence-generating experiments, distinguishing what people say from what they do, sizing a market honestly — a strong CTO does not automatically have this, and it does not appear because the org chart says it should.

Commercial ownership is a different muscle. Pricing, packaging, margin structure, channel economics, the specific way a business captures value. Engineering leadership does not build these reflexes. They are learnable, but they are learned, not inherited.

Technical risk needs an advocate whose incentives are not diluted. Security posture, reliability, upgrade paths, dependency decay, the boring work that only becomes visible when it fails. If the same person owns the roadmap and the technical floor, the floor loses — not through bad faith, but because roadmap pressure is loud and constant while technical risk is quiet until it is not.

Time is a real constraint. Both roles are full-time when done well. A merged role is not two jobs done at once; it is two jobs each done at maybe seventy percent. Sometimes seventy percent of both is the right trade. Often it is not.

Where merging works, and where it breaks

This is the part most discussions skip. Whether one person should hold both depends on the shape of the company, not on the ambition of the candidate.

Merging tends to work when: there is one primary product surface; the customer is technical, so product intuition and technical intuition largely overlap; the company is small enough that decision latency is the binding constraint and one owner removes it; the regulatory and operational surface is narrow.

Merging tends to break when: the operational surface is wide, so continuity work competes directly with product investment and needs a separate advocate; the business has heavy regulatory dependencies, where compliance is a permanent workstream rather than a project; there are multiple distinct customer segments, each generating its own discovery load; the company is scaling headcount fast, which makes organizational design a full-time job on its own.

I work in telecommunications, which sits firmly in the second column. Connectivity products carry a permanent operational floor — provisioning, activation, billing correctness, partner integrations — that does not pause while you build something new. A single owner for both roadmap and floor would quietly starve one of them.

What a CTO has to build to lead product

If the direction is real, the gaps are specific and worth naming plainly.

• Direct customer exposure. Not summaries, not dashboards. Conversations you are in, often enough that you develop your own priors and can tell when a summary is wrong.
• Commercial literacy. Enough fluency in pricing, margin, and channel economics to argue about them without deferring, and to notice when a technically elegant option is commercially unserious.
• Written strategy. Choices are only real when they are legible: what we are doing, what we are refusing, and why. If it lives only in conversation it is not a decision, it is a mood.
• Learning-speed instrumentation. Most engineering orgs measure delivery. Very few measure how fast they discover they were wrong. That is the metric that actually predicts outcomes.
• Restraint about implementation. The hardest one. Staying close enough to keep technical judgment sharp without pulling decisions back down to a level where you are comfortable.

Where I actually stand

I do not think every CTO becomes a CPO, and I would not argue that the roles should merge as a general rule. That framing sells better than it works.

What I think is narrower: as implementation stops being the constraint, the value of technical leadership shifts from controlling how things get built to shaping what gets built and how the organization decides. Some technical leaders will make that move and become product leaders who never lost their technical depth. Others will go deeper into platform and infrastructure, which remains a real and valuable path. Both are legitimate. What is not legitimate is claiming the product title while avoiding the discovery and commercial work that the title requires.

I am making the first move deliberately, and I would rather be judged on decisions and evidence than on a title.

Limitations of this argument

This is a position formed inside companies between roughly ten and a few hundred people, in Latin American markets, mostly in telecom, SaaS, and operationally heavy products. In a large enterprise with thousands of engineers and formal governance, the separation of concerns exists for reasons my experience does not test. I would also expect a consumer company with massive scale and a dedicated research function to weigh this differently: there, product discovery is industrialized in a way that changes the calculus.