Should your CTO and CPO be one person or two people in distinct roles? There is no universal answer. The right structure depends on your product’s complexity, your team’s maturity, and how tightly your competitive advantage is bound to technical execution. What AI is changing is not the urgency of the question but the shape of it: when the boundaries between “what to build” and “how to build it” start dissolving, the traditional division of labor between these roles gets harder to maintain.
How should you think about CTO CPO CPTO roles and their convergence at your company? It is a question growth-stage companies have wrestled with for as long as these roles have existed. We saw this convergence happen with the SaaS boom over the past 15 years. But with AI, the CTO CPO CPTO role convergence question is playing out again in exec team meetings, board meetings, and across many sectors. It tends to generate strong opinions quickly, and those opinions are often shaped more by what worked at someone’s previous company than by what the current situation actually requires. What follows maps the real trade-offs, so the call you make is grounded in your context, not someone else’s.
At Hoola Hoop, we have watched this debate play out across our portfolio companies for the better part of a decade. For us, this is not a question AI invented. At our quarterly CTO and CPO leadership roundtables, we have had CPTOs speak directly to what the role demands, what the unique challenges are, and where it can break down. The patterns in what they describe, across different companies, team sizes, and sectors, are consistent enough to say that something meaningful is happening to these roles, not just to the individuals in them.
AI has changed the terms of the conversation, and speed is only part of it. The shift is more fundamental: the boundary between “what to build” and “how to build it” is dissolving. Product leaders are building functional prototypes using tools like Cursor and Claude Code and submitting pull requests directly to engineering repositories. Engineers are shaping UX decisions and product direction from day one, not after requirements land in a backlog. AI is not just making individuals faster, it is eliminating the handoff between roles, turning sequential process into continuous, shared problem-solving. We have written in more depth about how AI is reshaping the CTO and CPO role and what it means for how teams are structured. For the CTO CPO CPTO question, the implication is significant. The issue is not about optimizing the handoff between product and engineering, it is about whether the traditional separation still maps to how your work actually gets done.
How the CTO and CPO Roles Were Designed
The traditional separation between CTO and CPO made sense for a specific era of technology development. The CTO owned the technical foundation: the how, core architecture, infrastructure, engineering velocity, security, and the team capable of building and maintaining all of it. The CPO owned the user-facing strategy: the why, roadmap, prioritization, market fit, and the voice of the customer inside the organization.
Each role had a clean mandate. The CPO determined what mattered to users and, as a result, what the company should build. The CTO figured out how to build it. For a long time, those mandates were distinct enough to justify two separate leaders. Build cycles were long. The distance between an engineering decision and a customer outcome was wide enough that two people could stand on either side of it without stepping on each other’s toes.
That distance has collapsed. Product-led growth, platform business models, and full-stack engineering have been closing the gap for the better part of a decade. When the product itself becomes the primary acquisition and retention mechanism, every technical decision becomes a product decision. When engineers own the full-stack delivery, the leaders above them need to hold both lenses simultaneously. By the time most companies reach Series B or C, the CTO who cannot think in product outcomes and the CPO who cannot interrogate technical trade-offs are both becoming a liability.
How AI Is Accelerating the CTO CPO CPTO Role Convergence
AI has not created the underlying tension between product and technical leadership, it has removed the slack that allowed organizations to manage that tension through process. Three shifts stand out.
The collapse of the build cycle. Features that once required quarters to scope, design, build, and ship can now be prototyped in days and deployed in weeks or less. That compression means the hand-off between product thinking and technical execution can no longer afford to be a formal process with its own calendar, gate reviews, and dedicated meeting cadences. The thinking has to happen simultaneously, between leaders who are in genuine dialogue about both domains at once.
The disappearance of clean ownership. When a company deploys a large language model as a core product feature, who owns it? The CPO, because it faces the user? The CTO, because it sits on the technical stack? Neither answer is sufficient. Someone needs to own the intersection, and that person needs to understand model behavior, inference costs, data quality, user expectations, safety considerations, and product positioning all at once.
Emergent product capability from the technical layer. AI is now generating product capability that neither the CTO nor the CPO put on the roadmap. These capabilities are not coming from a user story or a product brief. They surface from the technical layer and land in the product layer. A leader who can only see one side of that process is going to miss the opportunity, or deploy it without fully understanding the implications for users.
Five Signs Your CTO CPO Structure Has a Problem
The CTO CPO CPTO role convergence debate often stays abstract until someone recognizes their own organization in it. These five patterns tend to appear before the structural role issue becomes a crisis:
The Common Thread
Each of these patterns is a symptom of the same underlying condition: the open wound between product and technical leadership is visible, and the organization is building scar tissue around it rather than closing it. The CTO CPO CPTO role convergence question gets harder to avoid the more of these patterns are present simultaneously. The cost of leaving that wound open is painful and increases with every product cycle.
What the CPTO Structure Does Well
When it works, a single CPTO removes the most common failure mode at growth-stage companies: the structural gap between what is technically possible and what actually gets built. That gap is rarely caused by bad people. It is usually caused by two leaders with different mental models, different incentive structures, and different stakeholder relationships. Those structural conditions produce friction by design. In a CPTO model, the tensions between technical rigor and product velocity live inside one person. They get resolved faster.
The CPTO structure works best when the company’s product and technical strategy are genuinely inseparable. For an AI-native company, a developer tools company, or a company building on a fast-moving technical platform, separating product and technical leadership can create exactly the kind of schism that slows the decisions that matter most. In these contexts, the CPTO is not a compromise. It is the natural shape of the role. Leading voices in the field argue that in the AI era, the CPTO becomes one of the most critical executive roles a company can define well.
The companies that benefit most from a CPTO role tend to share a common characteristic: their competitive advantage lives at the intersection of technical and product capability, not on either side. When that is true, having two leaders who must negotiate across that intersection adds latency that a single leader eliminates.
What the CPTO Structure Gets Wrong
The counter-argument deserves equal attention. The CTO and CPO are each a genuine full-time job that requires different areas of expertise. Asking one person to hold both is often asking them to half-execute two strategies rather than fully commit to one. At scale, the gaps become critical. Security incidents, architectural decisions, and platform reliability require sustained CTO attention that a leader splitting their focus cannot always provide. Roadmap clarity, user research integration, and commercial alignment require sustained CPO attention that the same leader, pulled toward technical firefighting, will deprioritize.
There is also a governance risk that organizations consistently underestimate. When the CTO and CPO are two people, they provide the organization, and each other, with a structural counterweight and checks-and-balances. The CTO’s pragmatism checks the CPO’s ambition. The CPO’s user focus checks the CTO’s tendency to over-engineer. Removing that check requires the CPTO to internalize both perspectives and actively argue against their own instincts. This is possible, but it requires the right context and a specific kind of discipline that most leaders develop only after making costly mistakes on both sides.
The right CPTO is also genuinely rare. The number of leaders with real depth in both technical architecture and product strategy, combined with the operational experience to run both domains simultaneously, is very small. Promoting someone who is 80% CTO into a CPTO role does not create a CPTO. It can create a “CPO” gap that no one owns. Companies that have tried to merge the roles and found their CPTO struggling are not failing because the concept is wrong, the failure of the role is most likely due to not having the right person for the full scope of the job.
There is a deeper leadership dimension worth naming here. Marc Maltz at Hoola Hoop writes about the authority-control paradox at the heart of senior leadership: as formal authority increases, actual control over outcomes often decreases. A CPTO sits in what Marc calls the Crisis Zone, where formal authority over product and technology is at its peak, but outcomes depend on two large teams, competing organizational dynamics, and market forces simultaneously. That gap does not close because the title does. It tends to widen. Add to this what Marc describes as inherited baggage: step into a combined role and you inherit not just a broader job description, but the historical friction between product and engineering, the cultural patterns each team built under the previous structure, and what psychoanalyst Christopher Bollas calls the “unthought known,” the unconscious patterns that everyone acts on but no one names. Courageous role-taking, in Marc’s framing, means entering a role with realistic expectations rather than the idealized version you were sold. That discipline is especially important for a CPTO, where the gap between the job description and the lived reality tends to be widest.
What Great Leaders Do Regardless of Title
The executives navigating the CTO CPO CPTO role convergence question best, regardless of their title, share a specific capability: they have invested in genuine fluency in the domain that is not their home ground. This is not about becoming a generalist. It is about building enough literacy in the adjacent domain that the conversation between product and technology happens at the right level of specificity.
The Underlying Principle
The leaders who develop genuine cross-domain fluency, regardless of whether they hold one title or two, consistently make better calls at the intersection of product and technology. This matters with or without AI in the picture. Building that literacy is not a response to a trend. It is a core leadership discipline for anyone running a technology organization.
The question is not whether to merge the roles. It is whether the leaders holding those roles are building the shared understanding that makes the seam between them invisible to the organization.
Questions to Sit With
If you are working through the CTO CPO CPTO role convergence question right now, these organizational questions are worth sitting with before you make a call. For anyone actually considering stepping into the CPTO role, Marc’s four questions for courageous role-taking are an equally valuable companion: do you have the tolerance and temperament for this risk zone, what inherited baggage will you encounter, and can you negotiate for the authority and boundaries you will actually need? Both sets of questions matter.
- When your CTO and CPO last disagreed on a significant, strategic decision, was it a productive tension or evidence of a structural gap?
- Is your roadmap genuinely shaped by both technical possibility and customer need, or does one side consistently dominate?
- If you had to hand a combined CPTO brief to one person on your current leadership team, who would it be? What does that answer tell you about where your biggest gap actually is?
- How is AI adoption showing up right now in the space between your technical strategy and your product strategy? Who owns that space?
- Are you designing your CTO and CPO roles for the jobs as they existed three years ago, or for what those roles require today and tomorrow?
A Final Thought
The CTO CPO CPTO role convergence debate will not be settled by an org chart. It gets resolved by the quality of the relationship between the leaders holding those roles, and by the individual investment each of them makes in understanding the domain that is not their primary one. AI has made that investment more urgent. The pace of change in the technical layer is now fast enough that a CPO who treats engineering as a black box is navigating with incomplete information. The pace of change in user expectations is fast enough that a CTO who treats product as someone else’s responsibility is building something that will need to be rebuilt.
Whether your company has two leaders, one combined leader, or is still working through the decision, the underlying work is the same: build genuine technical-product fluency at the senior leadership level. Create the conditions for fast, high-quality decisions at the intersection of both domains. And recognize that this intersection is where most of the highest-stakes choices in today’s technology company are being made.
This is exactly the kind of challenge that looks different from the inside than it does from the outside. The leaders who navigate it best are rarely the ones with the strongest view about how it should be structured. They are the ones who have built the kind of executive fluency that extends well beyond their primary domain. If you are doing that work in parallel on the relationship side of the house, the principles in Managing Up as a CTO or CPO are closely related. The same investment in understanding what the people across the table actually need from you applies in both directions, and the skills compound.
Ready to talk about CTO coaching with Leigh?
Book a 30-minute introductory call to explore whether coaching is right for you.
