Antipattern #5: The CTO and CPO have different agendas
If these two roles don’t have a trusted relationship built on mutual respect and collaboration, the transformation will fail.
Note: this is the fifth article in the series on anti-patterns when moving to the product model. Here’s the first anti-pattern: "Giving too much autonomy, too soon".
As a coach, my colleagues and I are typically brought in when there is a significant problem to solve that calls for a move to the product model.
At the top of the agenda, the company wants to innovate, increase its products’ competitive advantages, and attract talent.
When having early discussions with leaders, these aspects are brought up at the surface level. What typically goes on beneath the surface could be completely different. When you peel the proverbial onion, you discover where the – real – problem lies.
Here are a few examples:
There is a conflict between the product and tech organizations.
The business and the CEO feel that the throughput is too low.
There is a history of failed product launches.
There’s high attrition.
All of these examples connect, in some shape or form, to the CTO and CPO. They need to be the main drivers of solving these problems. However, they can’t do it alone. Support is needed from their leadership peers and, if necessary, external coaches. But if these two roles don’t have a trusted relationship built on mutual respect and collaboration, the transformation will fail. I have seen transformations become great successes because of a healthy relationship between the CTO and CPO, and I have also experienced the opposite.
An old colleague of mine once told me an Eastern European proverb: “A fish rots from the head.”
This anti-pattern is dedicated to surfacing situations where the relationship between the CTO and CPO is put to the test.
Example #1: There is a conflict between the product and tech organizations
I have always been a strong advocate of diversity of thought and healthy friction in product development. For example, an engineer looks at a problem very differently than a product designer or product manager, and vice versa. By combining different perspectives and having debate, you discover and deliver well-rounded, valuable products. There’s magic that happens when you wrangle and build on each other’s ideas.
That’s what good looks like in my book.
Unfortunately, in many product organizations, there are massive silos between product and tech. There are trust issues.
If you walk into a product manager meeting, you might hear thoughts such as:
“The engineers just accept our requirements and give us no feedback on progress. They don’t ask any questions. Often they cut corners and don’t deliver according to my PRD (product requirements document).”
“Tech just talks about ‘legacy’ all the time. When will development speed up?”
And, on the other side, when you walk into an engineering meeting, what might you overhear?
“Product doesn’t involve us at all. They just hand us bull**** requirements for stuff no one needs.”
“There is always a ‘sense of urgency’ to get stuff done. They micromanage us. When will we have time to work on the platform?”
When you pick up on these signals, an alarm bell should go off. The relationship between product and tech is broken and needs to be healed.
Example #2: The business and the CEO feel that the throughput is too low
This is a classic example. Leaders at the top absolutely love when new features come out. Nothing makes a leader within the business happier than when a new sellable feature is launched. Leaders within the business are often “output”-driven. They have been conditioned throughout their careers to be action-oriented, to have a “sense of urgency,” and to get stuff done. It’s what has gotten them promoted, but it’s also something they need to unlearn. Modern product leaders still get things done, but they’re savvier, reducing the risks of building the wrong products.
Too often, I’ve seen clashes between the business and the product and tech organizations. A narrative about the “speed” of product development starts to take root, often from small conversations. A stakeholder from the business has a water-cooler chat with a colleague about their feature not being on the roadmap. The other colleague nods in agreement. That conversation leads to another similar conversation, which leads to another, and so on. The story has started to spread like wildfire. And who starts to have a target on their backs as a result? The CPO and the CTO. The narrative subtly moves up the chain of command and reaches senior forums within the organization.
“I’m hearing from my teams that they have a perception that product development is slow. What’s going on here?”
The CTO and the CPO look at each other. In an instant, they both become defensive.
“What do you mean? I haven’t heard that. Maybe it refers to the replatforming work we are doing at the moment. It’s affecting our capacity,” the CTO retorts.
“Yeah, I can see where they are coming from. There is a lot of pressure on the dev teams at the moment,” the CPO chimes in.
A question: who did the CPO subtly point the finger toward? The CTO. In other situations, the opposite could be the case. If you perk up your ears, you’ll notice these subtle signals that show there are fundamental trust issues between the two, and they surface when there is increasing pressure.
Example #3: There is a history of failed product launches
Here’s a scenario I've seen a few times.
The company, let’s call them BigCo, has over recent years placed its bets on a new product strategy. Instead of having a portfolio of 50+ products, the concept has been to harmonize and focus on a few key products. The benefits are easy to grasp. Instead of having to sell, market, and service 50+ products, you now have a handful. Executives within the business are thrilled by how this will streamline their operations. Additionally, product and tech finally feel like they have focus. As a result, they update their team topology to align teams to the “bets.”
This sounds all well and good.
Now, with the new product strategy, it meant a replatforming exercise, a blank slate. BigCo would build their new products from the ground up, without legacy code and without all of the “unnecessary features.”
The product teams assigned to a particular product knew what features were used the most to inform what to build first. They started creating the first MVP. Fast forward six months, and they were ready to launch to a first set of customers.
And what happened?
You know the answer. Customers weren’t happy.
“Is this it? This won’t solve all my problems, just a few of them,” one said.
Fast-forward another six months: the team has now added even more features. Still, customers weren’t happy and they were not ready to migrate to the new platform.
The problem: when writing the shiny new product strategy, they missed a crucial piece of the puzzle: customers really love their “darling features.” Over the course of many years of being sales-led, BigCo’s customer base had grown, but so had the amount of functionality. For every new customer, requirements had sneaked into the sales agreements, forcing product to build the customers' darling features. As a consequence, the product suite grew.
Now, at this juncture, the CTO could point the blame at the CPO for making such a choice – or – they could join hands to fix this conundrum. Which path will they take?
Example #4: There is high attrition
People are quitting. They are fed up. The business had been growing for years. The charismatic founders have had a successful track record. From the outside, the company was on the trajectory of becoming a unicorn. From the inside, there was a big difference. The company had been operating for 10 years. For the first few years, they had been searching for product-market fit, which had been a frustrating experience, and then, finally, they struck gold. They found a niche, an unaddressed problem to solve – jackpot. The numbers quickly went up. VC money flowed. The hiring plans grew bigger and bigger. The roadmap was filled with new markets to launch and new exciting features to build. The only problem? People were quitting left and right.
The founder CPO had the “ideas” and the CTO was a diligent “burning the midnight oil” type of engineer – a doer.
“We shipped so much faster when there were only a few people in the same room. We pushed new features out every week. Now, we’re so slow. We need a sense of urgency. We need people to be held accountable.”
To address these challenges, the CPO’s modus operandi was to add more pressure to the teams and dial up assertiveness. And, what do you think happened? Yes, people started to quit.
In a choose-your-own-adventure setting, which path will the CTO and CPO take moving forward to solve the problem?
Option 1: Continue adding pressure to teams, and hire people who can handle the pressure, who are doers and less like “snowflakes,” perhaps outsourcing development.
Option 2: Take a step back, collaborate more as a duo, define the strategic context for teams, and coach and empower people to learn the ins and outs of the business.
How to avoid this anti-pattern
We have now explored examples of triggers for a transformation to the product model and some examples of the underlying root causes. What’s brought to light is that the alliance between the CPO and CTO is pivotal to the success of the transformation. Their relationship will be tested as pressure mounts both internally and externally. Both of them need to stand together. However, bear in mind that it doesn’t need to be a 50/50, yin and yang, give and take, power dynamics type of relationship. But, if the imbalance is too big, there will be dire consequences, just like what was pointed out in the last example.
Fundamentally, these two people need to candidly talk about their motivations behind the transformation and what they and their organization want to get out of it. This could start over dinner or a facilitated conversation.
Is it to improve retention of talent? Is it to set the company up for scale?
In connection to the outcomes, they also need to be open and honest with each other about the problems, and that they are part of the problem. The relationship doesn’t need to be perfect. They don’t need to be best friends, but they need to have a common goal.
Key takeaways
The relationship between the CPO and CTO is pivotal to the success of the transformation to the product model. These two leaders are the main drivers, and if they have different agendas, misalignment will quickly take root. It’s essential that both surface their true motivations for change—not just on a surface level, but by diving into deeper causes. By connecting to these motivations, they, together with the CEO, need to align on the outcomes they want to achieve with the transformation. How will success be measured? How will you gauge whether the transformation is working? Stay tuned, as there’s much more to come on this topic in future articles.
What’s next
Next up, we’ll explore a critical trap: losing momentum could put your transformation at risk.