During our one-on-one a few weeks ago, Thibaud, OCUS’s CEO, told me, “Benoît, you are best when you’re assertive.”
His words resonated with me.
In my interpretation, Thibaud told me to make the tough decisions I consider to be right for our product and that he would support me. It’s a kind of carte blanche for a Chief Product Officer.
When you are used to running product organizations, however, you know the risks that come with that kind of trust and power.
Being right in product building is an illusion. One person can’t be right; systems sometimes can.
The CPO Dilemma
It led me to consider these questions:
1. What about empowering our teams to make their own choices, their own mistakes, and their own observations?
2. Do we have this luxury, this time, in such a high-paced and competitive environment?
As I thought about it, an idea started to materialize in my head: The CPO Dilemma.
The CPO Dilemma As the most-senior product people in an organization, should we as CPOs, VPs of Product, Heads of Product, and so on, push our knowledge, ideas, and decisions to go faster, or should we let our teams create their own experiences and learn?
In this scale-up world, this is an important trade-off that all product leaders will have to make.
Here’s my take: if you feel you have to intervene, always make the decision about whether or not to challenge your team based on what they will learn.
Give them the framework
Let them make the decision
Always push learnings
Three rules for the CPO dilemma
Here are three rules that have helped me challenge and train my team every step of the way.
Rule #1: Make the basics right
It might seem obvious, but a lot of product folks want to innovate, pushing the basics of their products to the side.
Think about this: if you have a feature-adoption problem, is it because you missed some features or because the overall experience feels clunky to users? If you put yourself in a user’s shoes, would you adopt a clunky, unstable product, even with some amazing features? I’d argue that stability and ease of use win over fancy functionalities.
I am a true believer that if the basics are not right, a product can’t succeed.
I am talking about excelling in these basics:
Simple and slick UX/UI
Your two to three core features
Quick bug fixes
When you excel in these basic areas, it opens the door for innovation that has the best chance for success.
💡 If you think the basics are not perfect in your product, challenge your team to balance prioritizing an ideal day-to-day experience for their users with the development of exciting features.
Shadow users performing basic functions on your product to help the team realize the user impact of clunky basics.
Rule #2: Evaluate for realistic impact
Something I’ve noticed over time is that Product Managers tend to put themselves in the perfect user situation when they evaluate the impact of a potential solution.
For many, the typical thinking process I’ve noticed is:
I have one million users
My daily stickiness is 60%
I want to push it to 70%
I will implement a push notification system to increase my stickiness
Sending one million push notifications per week will do the trick
It’s easy to forget that we live in a complex world. These one million users are using the product in a variety of situations, moods, and levels of urgency. We must consider these questions:
Out of your one million users, how many will opt-in to your push system?
Out of those who opt-in, how many will read your push notification?
Out of the readers, how many will engage?
Out of those who engaged, how many will use your feature, therefore helping with your ultimate goal of increasing your stickiness?
A simple calculation with a basic conversion ratio will produce something like this:
The graphic shows a large circle representing one million users. Inside of that, a smaller circle representing 300 thousand opt-ins, then an even smaller circle representing 100 thousand readers. The impact circle is the smallest of them all.
By performing these types of calculations, it’s easy to realize that for many new features, the impact will be low—and maybe the feature should not be a priority.
💡 Sit down with your team to do these rough impact calculation exercises. It’s very often an eye-opener for potentially zero to no impact features.
Rule #3: Go for simplicity (the “I don’t get it” rule)
This is, in my opinion, the most important rule of all for product leaders.
I believe in simplicity. If I don’t understand something, if I am lost when a Product Manager tries to explain something to me, or if we have to write documentation that is overly complicated to explain a feature, it’s a major red flag for me. It probably means that the feature is or will be poorly implemented.
Simplicity is hard, but you have to challenge your team on it. Complicated solutions are just too costly—in terms of time, money, and user buy-in. They create bugs, edge cases, and general dissatisfaction. Help your team realize when their solution is too complicated and explore with them how to simplify it.
💡 If you don't understand something during your product-building process, challenge your team. Play dumb, ask why repeatedly, and help them find the best approach.
Often, this type of discussion helps teams realize a solution's complexity. They'll come back with either an easier approach or a deeper understanding of why a solution needs to be complicated for now.
To summarize: make the basics right, evaluate for realistic impact, and go for simplicity.
When you apply these rules, your team will be more engaged. You will notice more intense discussions around those topics, velocity will increase, and you will find the balance between challenging your team, learning together, and moving fast.