Lessons learned from being a CTPO
I recently completed my first role as a Chief Product and Technology Officer (CPTO). As the position becomes increasingly common, I wanted to share my experience, including why I accepted the role, what I learned, and its key aspects.
Why?
Why did I accept this position? My background is in engineering, having led numerous teams at SoundCloud, Issuu, and other companies. Despite software development requiring collaboration between design, product, engineering, product and engineering leaders are often managed separately by a CEO who may lack the necessary skills (and certainly the time) to address conflicts that arise.
I oppose this separation because it can result in product/design dictating decisions while engineering merely implements them. Instead, I favor giving each discipline an equal say. Becoming the CPTO allows me to unite these disciplines as a single team with ideas evaluated based on merit rather than source.
Initial Plans
My initial plans focused on easing any existing tension between these groups. Firstly, I introduced a unified name for my organization — the “Builders” — which symbolises our collective aim of creating products together. This seemingly small change already had positive effects; As an example, we began holding joint Builders All Hands meetings instead of discipline-specific ones.
Though renaming was a step forward, multidisciplinary leadership and restructured teams were also needed. Unfortunately, this meant replacing a few employees with more insular mindsets to ensure cross-disciplinary collaboration.
Lastly, the crucial aspect: As a CTPO with an engineering background, you must avoid adopting a mindset like “Now I can finally tell the product managers what to do.” Instead, you need to become a “discipline-neutral” leader, focusing on bringing out the best in your team by ensuring equal representation for each discipline.
This approach has led to some unanticipated challenges and learnings. On the positive side, emphasizing cross-disciplinary work and viewing builders as a unified team proved effective. Employee satisfaction increased, attrition decreased significantly, and productivity improved. This allowed for streamlined decision-making — creating a joint roadmap and a common approach to product development became much simpler.
Difficulties
However, no solution is perfect, and some difficulties arose:
1. The role of a CTPO can be overwhelming, as there are numerous considerations and building a great organization is just one aspect of the job (an enabling task necessary for business success). Ultimately, what you’ll be measured by is making the product and business flourish. I felt overwhelmed at times, particularly before my full leadership team was assembled.
2. Being “discipline-neutral” proved challenging due to my uneven knowledge distribution; my engineering background provided me with stronger expertise in that area. I had to accept my dependence on others in unfamiliar areas like Design (the most apparent example).
3. Initially, I was the only management team member (out of nine) representing about 60% of the employees while also representing Product in a product-led organization — most other disciplines depended at least partially on the product’s progress. This sometimes left me feeling alone during management meetings.
Would I do it again?
Absolutely! I still think there are a lot of advantages to one person leading the product development process. It is not the solution for every company out there. Finding the right set of people is a puzzle and the puzzle piece “CTPO” does not fit every time. My next blog post in this series will discuss building this puzzle — meaning if you should hire a CTPO or go for separate leaders of the disciplines.
