The Product CEO Paradox
Using Ben Horowitz’s 2013 blog post in practice
In a 2013 Post, Ben Horowitz wrote that product oriented founders sometimes fail as a result of being caught in the Product CEO Paradox. This paradox, he says, is a result of getting caught between the desire to be close to the product and the need to scale as CEO. It’s a problem that nearly every product oriented CEO must face as their company scales. Below is his summary of the paradox in action.
This happens all the time. A founder develops a breakthrough idea and starts a company to build it. As originator of the idea, she works tirelessly to bring it to life by involving herself in every detail of the product to ensure that the execution meets the vision. The product succeeds and the company grows. Then somewhere along the line, employees start complaining that the CEO is paying too much attention to what the employees can do better without her and not enough attention to the rest of the company. The board or CEO Coach then advises the founder to “trust her people and delegate”. And then the product loses focus and starts to look like a camel (a horse built by committee). In the meanwhile, it turns out that the CEO was only world-class at the product, so she effectively transformed herself from an excellent, product-oriented CEO into a crappy, general purpose CEO. Looks like we need a new CEO.
Ben Horowitz
As a product oriented founder and CEO, I definitely understand this paradox. From the moment I started my company, I have been involved in every detail, every design, every bug and every direction setting meeting the company has every had. In fact, when people ask me what my management style is I often say it’s Totalitarian Curious.
When my company started scaling in 2012, I found myself smack dab square in the middle of the Product CEO Paradox.
I was constantly battling the feeling that delegation felt a whole lot like abdication.
My board of directors, just like Ben described, urged me to hire world class management and trust them, delegate to them. As a rising star at the time, we had no trouble attracting world-class talent, but then the paradox began to take hold. We were building a camel, not a horse and I was miserable. I felt like I was losing control and I’m pretty sure the employees thought I was turning into a world class pain in the ass.
But then something happened that broke the paradox. We face planted in the market and then pivoted.
The pivot is a story for another time. But long story short, we pivoted and we pivoted hard enough that I functionally descaled the company back to the starting line. In other words, I had the very rare do-over.
The comeback is also a story for another time. But long story short, I found myself now ready to scale again. We got to product market fit, we got to revenue, and we needed to scale to meet market demand. That’s when I remembered Ben’s article. After readying about 25 times, I decided that this time I was going to listen to his advice and put in place some principles and practices that help me avoid the very paradox I found myself trapped in the last time I scaled.
Here’s what I’m doing this time.
Formal writing. In startups everyone is working hard. But I find the real question is “are they working hard on the right thing.” One of the worst things any team can do is to move a light speed in the wrong direction. Changing the direction after a Herculean effort in the wrong direction can be demoralizing and create absurd situations. I have had situations like this where even thought the team understood they had moved in the wrong direction, they still fought doubling back. It’s human nature to not want to throw your hard work in the trash. So be careful to never let your team go in the wrong direction in the first place.
Whenever I want to ensure the team is working hard on the right things, I try to set North in writing. I keep it formal enough to set direction, but light enough that I can do it quickly. We now have a formal document format in Google Docs with our logo, special formatting, and visually obvious structure. When I write something using this format it is sent by my Chief of Staff and we make it clear that policy or direction is being set.
Casual Conversations. Every founder wants to connected to their team and to feel like a regular contributor. The problem is your not. Everything you say can be interpreted differently than you intend. I had situations where I was casually talking to an engineer and an offhanded comment I made was interpreted as a executive order to pivot. Conversely I’ve had situations where I did want to make a big change and people thought I was just making an offhanded comment.
But does this mean I need to give up casual conversations. The very thing that keeps me emotionally connected to my team?
No. What I do know is if I have a casual conversation I immediately Slack the group I was chatting with to clarify exactly what we decided paying special attention to clear up any chances of miscommunication. Then if anyone was confused we have a Slack trail to go back to.
Formal Touchbases. We now have a formal part of our process where there is a check-in required from me to continue. It’s super light weight, rarely lasts more than 5 minutes, but keeps everyone in touch with my definition of North. This goes for every group involved in creating the product including engineering, design, product and even sales. What I’ve found is that if you have a formal, but light weight, writing to begin a sprint, then a light weight touchpoint in the middle then you can make sure North is where you are going without annoying, or worse micro-managing, your team.
Delegate, but never abdicate. Once I was able to utilize the tools above then, and only then, was I able to delegate. But even then, delegation is not something that’s fire and forget, it’s a garden you must constantly tend. Whenever I consider delegating anything I ask myself “am I delegating, or am I abdicating.”
One of my most common mistakes is that I would hire a “senior” person to take on a major responsibility and then I’d hand them the farm — assuming they would do a better job than me. The problem is that when you are going from 0 to 1 in any given area, of the founder doesn’t set the foundation of North for that area, then the new “senior” person will see that North hasn’t been defined and begin defining it for their team. If you do this what happens is that inevitably your new senior manager will have a slightly different perspective than you. In the beginning the directional change is small, but a 2 degree change over time can reek disaster.
The key is to get in their early and set North with the new person. Make sure North is clear and check-in time to time with one on one conversations to make sure you are on the same page.
Visibility. Related to the Product CEO Paradox is the Kanban Paradox. In other words Kanban sticky boards are great with 5 people, but it does’t let you scale to 20 or 40 or 200 people. That would be ridiculous.
But at the same time, stickies are great. They are a physical form stating priority. Kanbans with stickies are the water coolers of the startup world. It’s the gathering point where people get together to talk about what they are doing, their struggles, and the priorities of the company. They are the ultimate place to project the visibility of North and the North is in fact the thing everyone is working on.
Jira and other electronic mechanisms for tracking stories, tasks, and epics are great for scalability, but they are horrible for visibility. No one, and I mean no one, view Jira as a water cooler. No one says “ hey let’s all open up Jira and have a casual conversation about what we’re doing.” The very word Jira instills fear because it connotes the very last thing an engineer wants to do.
A meeting.
So what we do now is we’ve maintained all of our Kanban boards, but we’ve changed stickies from meaning tasks to meaning stories where the color of the story denotes the epic it belongs to. Then our PM matches the stickies inside Jira and we track subtasks of stories electronically. This way engineers still gather around the water cooler of the Kanban board to make decisions and discuss the the day to day. But the PM works to make sure we scale operations by tracking the details in Jira where we can measure velocity and scope creep.
It’s the best of both worlds.
The WalkAbout. A big area where I biff’d last time was scrum. With ten different scrum meetings happening a day it’s impossible to attend them all. If you try to attend them all, you look like a chicken with your head cut off. Attend none, and you risk loosing the pulse of your product. The common response is hold a scrum of scrums meeting. However, the implementation of a “scrum of scrums” ended up becoming the Hell of hells. It was a mega meeting that nobody wanted to be in — a real snoozer.
So what we did was we did away with scrum and replaced it with what we call a WalkAbout. The idea is that I and my PM walk to each Kanban board (we have six main boards right now) and discuss the tickets. We basically do a diff from the day before (she actually takes photo and looks for the diff!), we discuss the progress, and we discuss any decisions we need to make. 90% of the time we can do the walkabout without need to destroy the flow of any engineer or designers — brilliant. When we do need to engage an engineer or designer, we do so individually and we limit the interaction to a short a time as possible.
The reason we meet individually with a team member is simple. In a public scrum, saying that your blocked is often tantamount to saying your screwing up on your job — and many engineers simply claim they are never blocked. While others, usually the people who enjoy grandstanding so they can put the “no” in North, claim they are always blocked in order to steal the public forum they are given. However, when we notice an engineer is blocked we talk with them one on one. The result is that they are more honest and they can tell we are there to help.
WalkAbout only takes me about 30 minutes once a day. It’s something I can do at any open 30 minute slot and after doing it for a couple of weeks, I know the Kanbans by heart, I know we are all working on North, and I do it all while only rarely interrupting the flow of the team. The other beauty is now the team knows that when I’m on WalkAbout I am definitely making decisions, but when I’m casually talking to them, it is the exception that I’m making a decision and if it is a decision, I’ll confirm in writing.
After implementing these new processes, we have deleted almost all of the old “agile” meetings. Everyone is happier and I’m able scale while still keeping my finger on the pulse of the team and the product.
As far as flow is concerned. I typically use the 90% Rule. That is, my team should be in flow 90% of every day and on 10% of the day is process, meetings, or management. Before implementing these new processes, my team was lucky to be in flow 50% under a more strict Agile process. But when I loosened up, invented some new process, we now easily hit 90% every day.
