This is a translation of Ben Horowitz's 2013 essay "Why Founders Fail: The Product CEO Paradox" from a16z, written for product-minded founders — along with my own commentary at the end. I had skimmed this article a few years ago, but reading it now it feels far more relevant. I touched on it in a recent Twitter thread as well.

(Translation begins)

Because I am a strong advocate of founders running their own companies, people often send me lots of email when a founder fails to scale or gets replaced by a professional CEO.

"Ben, what happened? I thought founders were better? Are you going to update 'Why We Prefer Founding CEOs'?"

Here is my response to these emails:

No, I am not going to rewrite that piece, but I am going to write this one. There are three fundamental reasons why founders fail to run their own companies:

  1. The founder doesn't really want to be CEO. Not every inventor wants to run a company and unless you really want to be a CEO, your odds of success are exceptionally low. The skillset required to be a great CEO is enormous and if you don't have the deep desire to learn those skills, you will fail. If you are a founder who doesn't want to be CEO, that's fine, but it's important to know that early to prevent a great deal of personal pain.
  2. The board panics. Even if a founder wants to be CEO, the board panics at their mistakes and replaces them too early. This is tragic and common.
  3. The third reason is the Product CEO Paradox.

The Product CEO Paradox

A friend of mine built his company from nothing to over $1B in revenue at a record pace by relentlessly pursuing his product vision. He did so by being deeply involved in the intricate details of the product's design and execution. This worked brilliantly through roughly 500 employees.

As the company grew larger, things went wrong. He went from being a visionary product founder who maintained consistency and context across a complex product line to making what appeared to be arbitrary decisions, to becoming a bottleneck for product.

This created employee frustration and slowed development. In order to solve the problem and scale the company, he stepped back and began deferring all major product decisions and directions to the team.

As a result, he ran into the Product CEO Paradox: The only thing that will wreck a company faster than having the Product CEO deeply involved in the product is having the Product CEO not involved in the product.

This is a common story. A founder comes up with a breakthrough idea and starts a company to make it real. Being the originator of the idea, she tirelessly drives the product, getting deeply involved in the details of the product to make sure the execution matches the vision.

The product succeeds and the company grows. Then, at some point, employees complain that the CEO is too involved in the product and paying too little attention to the rest of the company. The board and the CEO coach advise the founder to "trust the team and let go."

Then the product loses focus and becomes a camel (a horse designed by committee). By then, the CEO discovers that she can only make a difference in the world through the product, and realizes that she has effectively transformed herself from a world-class product CEO into a generic, mediocre CEO. It seems a new CEO is needed.

How do you avoid this? Most great product founders and CEOs that I know remain deeply involved in the product throughout their careers:

  • Bill Gates participated in product reviews at Microsoft until he retired.
  • Larry Ellison still runs product strategy at Oracle.
  • Steve Jobs weighed in on every important product direction at Apple.
  • At Facebook, Mark Zuckerberg determines product direction.

How do they do this without destroying the company?

Over the years, they've reduced their involvement in individual product decisions, while maintaining essential involvement. Essential involvement for a product-oriented CEO means, at a minimum, the following activities:

  1. Maintain and drive the product vision. The CEO doesn't have to create all the product vision, but the Product CEO must drive the vision she chooses. She's the only one who is in a position to both decide what it should be and to communicate it effectively.
  2. Maintain quality standards. What level of quality is good enough? This is an extremely difficult question, but it must be consistently part of the culture. When Steve Jobs ran Apple, it was easy to see why this was so important. Jobs drove "standards that generate incredible customer loyalty."
  3. Act as integrator. When Larry Page became CEO of Google, he spent enormous time forcing all product groups to develop common user profiles and a shared paradigm. Why? Because he had to. Nobody else would have done it if the CEO didn't. It wasn't anyone else's top priority.
  4. Consider the data they don't have. In today's world, product teams have access to unprecedented data on the products they build. Left to their own devices, product teams will optimize the product based on the data they have. But what about the data they don't have? What if you need to build a product or feature that customers can't imagine? Who will prioritize that? The CEO.

But how do you do only that when you've been deeply involved in the product all along? How do you back off in general while not backing off in specific areas?

At some point, you need to formally structure your involvement. You must transition from intense direct involvement to a process where you can contribute without undermining the team or disrupting them. The specific process will vary based on who you are, your strengths, your work style and your personality, but these activities usually help:

  • Write it, don't say it. If you have something you want the product to do, write it up fully. Not as a quick email, but as a formal document. This forces more clarity and limits your involvement to things you've thought through.
  • Formalize and attend product reviews. If the team knows to expect regular reviews where you'll check for consistency with the vision, quality of design, and progress against integration goals, they'll feel far less disempowered than if you change direction in the hallway.
  • Stop giving direction outside of formal mechanisms. It's fine and necessary to have ad-hoc conversations with individual engineers and product managers — you need to constantly update your understanding of what's happening. However, in those conversations, don't give direction. Save that for the formal communications above.

Backing off non-essential involvement while maintaining the essential is genuinely difficult. Many people fail at this. If you are in a position — as my friend was — where you can't let go of a little without letting go of everything, you might be headed for a CEO change. But don't do that. Learn how to do this instead.

(Translation ends)

My Commentary

The core message of this essay can be reduced to one line: don't weaken your influence on the product. But how that influence is exercised needs to change clearly over time, and how exactly it should change is left to each CEO to figure out — because the answer is inside you.

At 10X, I started handing off most of product management around September 2020 (as described in my earlier post). But I never thought of this as weakening my product influence. I thought of it as focusing on areas of even larger leverage — amplifying the value of the product in new ways.

For 10X's business, the things with greater product leverage than direct product development were: BizDev (deciding which partners to bring on, for what purpose, and how) and Employee Success (improving the experience for the team executing both product and BizDev). In hindsight, those transitions happened at roughly the right time.

Building out the BizDev team multiplied the opportunities 10X could access, and those opportunities now feed back into new business and long-term strategy as the most important source material.

Building out the ES team created the stability and conditions for each member to perform at their best — and a more stable foundation means a higher ceiling for how many people we can bring in.

In short: leaving formal product development has allowed me to focus on areas where my impact can be even larger.

That said, Horowitz's specific tips were genuinely inspiring. "Write it, don't say it" resonated immediately — anyone who knows me knows I'm faster with a pen than a word. But I also spotted a gap.

I hadn't embedded a formal product review mechanism into the company. Without a formal mechanism, there's no structured channel for giving feedback or issuing direction. The "CEO's prerogative" — the disruptive, transformative call that only the CEO can make — has nowhere to land if there's no formal mechanism to trigger it. And that absence creates a risk of missing discontinuous opportunities.

A few days after reading this essay, I moved quickly to build that mechanism.

What does your company's product feedback process look like? I'd genuinely like to know.