The last five years have seen Danish tech companies posting an increasing number of Chief Product and Technology Officer (CPTO) positions. This role combines key CTO areas of responsibility, like maintaining a tech stack and running a service, with key CPO responsibilities such as defining target markets, specifying solutions, and executing a go-to-market strategy.
With these differences in mind, it is worth exploring why companies decide to combine the two roles and assessing whether it is a good idea or not. The assessment is based on best practices for team topology in innovative software companies. I outline two poor reasons for combining the roles and two situations where it might make sense.
Understanding the role of the CPO and the CTO
Let’s first separate the two roles and understand what each one is responsible for.
Chief Product Officer (CPO) | Chief Technology Officer (CTO) | |
|
Organisation |
Create an organisation that can translate market and customer understanding/data into value for the business and for customers. |
Create an organisation with strong technical skills and leadership that makes product development feasible. |
|
Strategic responsibility |
Responsible for connecting the business and financial strategy to strategic development initiatives through a product strategy and vision. |
Responsible for the architecture and tech roadmap that deliver the performance, reliability, and functionality required to get products to market. |
|
Operational responsibility |
Product managers (under the CPO) guide software development, taking responsibility for the backlog, data insights, and more. These development tasks are much easier to handle in product organisations capable of continuously defining key strategic opportunities and discovering solutions for them in parallel. |
The CTO should ensure the organisation can rapidly and repeatedly deliver quality software to customers. Architects and senior engineering staff should also participate actively in discovery work, where technical due diligence and risk mitigation are handled through analysis and prototyping. |
|
External responsibilities |
The CPO is responsible for the commercial outcomes of the strategic initiatives the company decides to invest in. This requires close outbound collaboration with the commercial organisation and customer support. |
The CTO is responsible for the company’s technology leadership position. This requires evangelism, active participation in university relations/recruitment programmes, as well as participating in developer conferences, open-source initiatives, and standardisation where required. |
In this setup, each exec can make the other stronger. In the area of architecture, it is obvious that the CTO benefits greatly from understanding the long-term product vision, target market, product principles, and key strategic opportunities when selecting and developing the right architecture for the business. It is, however, also obvious that these sets of activities require significantly different skills, experience, and educational backgrounds.
Two reasons that do not justify a CPTO
Saving money
Some companies look at their executive compensation structure and think: “Why pay two salaries when we can pay one?” This is fundamentally the wrong reason to create a CPTO role.
First, the skill sets required are vastly different. Finding someone who excels at both technical leadership and market-driven product strategy is exceptionally rare. You’re looking for a unicorn. Very few people with deep technical expertise can also navigate complex market dynamics, customer psychology, and commercial strategy. To create the right team topology you need both, plus a strong design organisation.
Second, even if you find this rare individual, you’re setting them up for failure. The workload doesn’t decrease just because one person holds both titles. The CPTO will inevitably gravitate toward their natural strengths, while the product or technology side suffers from neglect. The company may save one salary but will create a structural weakness that costs far more in missed opportunities, slower time-to-market, and technical debt.
Reducing Conflict
I’ve seen companies create CPTO roles because their CPO and CTO couldn’t work together effectively. The thinking goes: “If they keep fighting about priorities, let’s just make it one person’s decision.”
In more traditional waterfall development models, the CPO is often presented as the person responsible for “what” we are developing, while the CTO decides “how” we are developing it. This definition often leads to conflict because “what” and “how” are intertwined, both when exploring strategic opportunities and when exploring solutions.
The creative tension between product and technology is valuable in a product operating model. The CPO should be pushing for ambitious features and rapid market response. The CTO should advocate for technical excellence, scalability, and maintainability. These tensions, when managed well, lead to better outcomes for both customers and the business.
Creating a CPTO to eliminate this tension is like treating a fever by breaking the thermometer. The underlying issues, like unclear strategy, poor communication, and waterfall patterns, will simply manifest themselves in slow delivery, poor value creation, and low staff retention.
Two situations where the CPTO title might make sense
Small organisations (fewer than 15-20 people in product and R&D)
In early-stage companies where your entire product and engineering organisation is 10–15 people or fewer, a CPTO can make sense. Although most CPOs and CTOs are willing to take on the additional responsibility without the title change. At this scale, the role isn’t really combining two full executive positions. It’s creating one senior leader who can guide a small, integrated team.
In this context, the CPTO works closely with everyone, makes most decisions directly, and can maintain visibility across both product strategy and technical execution without the organisational complexity that would overwhelm a single person in a larger company.
However, this is a temporary solution. As you scale beyond 15–20 people, you should be planning to split the role. The organisation will need dedicated leadership in both domains, and trying to maintain a combined team topology beyond this point typically creates bottlenecks and burnout.
Highly technical organisations where customers are deeply technical
Some businesses serve markets where the customer is themselves highly technical: developer tools, infrastructure software, technical APIs, or specialised scientific software. In these contexts, the boundary between “product” and “technology” becomes genuinely blurred.
Your customers don’t just care about what problems you solve; they care deeply about how you solve them. Your technology choices, API design, performance characteristics, and architectural decisions are core product features. The typical CPO skill set, like market analysis, user research, and commercial strategy, is insufficient without deep technical credibility.
The CPTO trend is real, but rarely optimal
The increase in CPTO positions in Denmark reflects several market realities: cost pressure in a world of higher capital costs, difficulty hiring top talent, and too many organisations still using classic waterfall processes for software development.
For most software companies, especially those with 20+ people in product and engineering, separate CPO and CTO roles led by strong individuals who collaborate effectively will outperform a combined CPTO structure. The skills, temperaments, and focus areas required are simply too different.
If you’re a CEO considering creating a CPTO role, ask yourself honestly: Are you doing this because it’s genuinely the optimal structure for your business at this stage? Or are you trying to solve a talent problem, a conflict problem, or a budget problem through organisational design?
The answer to that question should guide your decision.
At Copenhagen Product Collective, I work with companies to assess their product and technology leadership structures and build capabilities across both domains. If you’re wrestling with questions about how to structure your senior leadership and team topology, let’s talk.
