This insight is the next in a series which highlights the evolution of technology and product teams within an organisation and begins to look at the future structure of an organisation and the inevitable (and welcome) confluence of the technology function and the product function.
In previous insights, we have talked about the difference between a team that is effective and one that is efficient. Effective (building the right thing) was typically the responsibility of the Chief Product Officer (CPO) whilst efficient (building good software predictably) was normally seen as the remit of the Chief Technology Officer (CTO).
But the world has moved on. People realised that this ‘siloed’ approach wasn’t working for the customer, and organisations started a journey away from Projects towards Product.
The roles of CTO and CPO
The Chief Technology Officer (CTO) and Chief Product Officer (CPO) roles were born in isolation and only now are we beginning to evaluate whether we need both roles in their current form or whether it might work better to combine the roles.
The role of CTO
Startups are usually founded by either a technologist, a domain or subject matter expert, or both. When a domain expert starts a company, he or she usually realises within the first year that they need a founding partner to help lead ‘technology’ - relying on contract developers alone just doesn’t cut it past the MVP (Minimum Viable Product).
The person who joins the exec team at this stage is often called the CTO and their responsibilities are:
● Innovation
● Project management
● Assessing the technical feasibility of new opportunities
● Managing engineers and other ‘technical’ team members
Effectively, the CTO is responsible for the how of product development. Once your customer (often singular at this stage) decides what they want, the CTO leads the charge to find out how to build it and ensures that the product meets the customer’s needs.
As the company grows, the number of customers increases and suddenly the CTO is faced with a challenge - different customers want different things; their priorities and timelines differ.
The greatest product risk is then less about feasibility (can the engineers build what the customer wants) and becomes more about value (with our limited resources, what combinations of features gives us and customers the greatest return)?
To understand how to achieve the greatest value, the CTO needs to be continually out talking to customers and creating a product strategy, whilst continuing to ensure that her/his team deliver what has already been agreed - and checking that the platform scales effectively, is secure, and has low downtime.
It’s a tall order.
At this point, a lot of organisations bring in a CPO (Chief Product Officer).
The role of CPO
The rationale behind this decision is simple (albeit sub-optimal). The CPO will decide what to build and the CTO can work out how to build it. People talk about the “healthy tension” between product and engineering.
The CPO defines the strategy (represented in the roadmap) and the CTO takes this and, with their team, creates the release plan.
Somewhere in the middle, of what and how, they agree on the why which is where they discuss the risks of an idea:
● Value - can we make money from this?
● Usability - can we present this to customers in a way that they can understand and use?
● Feasibility - is it technically possible to build something that meets the customer’s needs?
● Business viability - are we the right people to be trying to solve this problem for customers?
It sounds like a simple and elegant solution, doesn’t it?
Unfortunately, an issue arises here because no one person is responsible for what the customer needs. Product OKRs are inconveniently split between ‘technical objectives’ and ‘customer objectives’, and the team needed to deliver the customer’s needs is split between two parts of the company. The why becomes both the CTO’s responsibility and the CPO’s responsibility and yet, somehow, doesn’t fully belong to anyone.
Improvise and adapt
This less than rosy picture ignores the fact that good CTOs are often well-versed in product management. They use this understanding to help craft both a roadmap and a release plan, then lead the team to deliver the product, to monitor customer success and the operational success of a release, and use customer metrics to check on success.
These CTOs are effectively operating as a CPTO although they don’t have the job title (yet).
As an organisation comes to understand that success should be measured by outcomes rather than features or outputs, it realises the need for a closer alignment between the strategy for the product and the ability to deliver that product. And so, the role of CPTO is born.
Sejal Amin at Forbes talks about the ‘product development culture’, and I think that term very nicely summarises the move by technical teams to better understand and deliver value to a customer, and the move away from the build trap which is epitomised by a continual push to deliver feature after feature in the hope that one of these will be ‘the one’ that achieves product-market fit and helps the company onto that hockey stick that they are all looking for.
So why doesn’t everyone have a CPTO?
Earlier I talked about the fact that good CTOs are often well-versed in product management, and that is true. The problem is that in the Venn diagram of technology and product, there are currently few people who can comfortably and competently occupy the space in the middle that we are beginning to term ‘CPTO’.
It isn’t that people don’t want the ‘person who can do it all’ but rather that it is very hard to find such a person.
Am I looking for a unicorn?
A unicorn (despite being the national animal of Scotland) is generally thought of as a mythical beast that has magical powers. Are CPTOs just mythical creatures that you aren’t likely to meet in the wild?
This is a growing domain and there are shining lights out there leading the way and others are bound to follow. Organisations such as LinkedIn, Ebay and Conde Nast have actively sought exec-level CPTOs.
There are those of us who have moved from CTO to a hybrid product/technology role and others are doing the same.
As the opportunities grow, CTOs will broaden their experience into areas we currently call ‘product management’ and CPOs will step sideways into the domain of the CTO. Organisations who embrace this new role, and ultimately their customers, will be the ones who benefit.
This Insight paper was originally published on the Blue Ocean Insight website. You can view the original article here.
If you want to discuss the role of CPTO with the Blue Ocean Insight's Team, you can email the team at info@blueoceaninsight.com.