The Product CEO Paradox

Originally published at Andreesen Horowitz.

A friend of mine led his company from nothing to over $1 billion in revenue in record time by relentlessly pursuing his product vision. He did so by intimately involving himself in the intricate details of his company’s product planning and execution. This worked brilliantly up to about 500 employees. Then, as the company continued to scale, things started to degenerate. He went from being the visionary product founder who kept cohesion and context across and increasingly complex product line to the seemingly arbitrary decision maker and product bottleneck. This frustrated employees and slowed development. In reaction to that problem and to help the company scale, he backed off and started delegating all the major product decisions and direction to the team. And then he ran smack into the Product CEO Paradox: The only thing that will wreck a company faster than the product CEO being highly engaged in the product is the product CEO disengaging from the product.

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.

How can we prevent that? It turns out that almost all the great product-oriented founder/CEOs stay involved in the product throughout their careers. Bill Gates sat in every product review at Microsoft until he retired. Larry Ellison still runs the product strategy at Oracle. Steve Jobs famously weighed in on every important product direction at Apple. Mark Zuckerberg drives the product direction at Facebook. How do they do it without blowing their companies to bits?

Over the years, each one of them reduced their level of involvement in any individual set of product decisions, but maintained their essential involvement. The product-oriented CEO’s essential involvement consists of at least the following activities:

• Keep and drive the product vision – The CEO does not have to create the entire product vision, but the product-oriented CEO must drive the vision that she chooses. She is the one person who is both in position to see what must be done and to resource it correctly.
• Maintain the quality standard – How good must a product be to be good enough? This is an incredibly tough question to answer and it must be consistent and part of the culture. It was easy to see the power of doing this right when Steve Jobs ran Apple as he drove a standard that created incredible customer loyalty.
• Be the integrator – When Larry Page took over as CEO of Google, he spent a huge amount of his time forcing every product group to get to a common user profile and sharing paradigm. Why? Because he had to. It would never have happened without the CEO making it happen. It was nobody else’s top priority.
• Make people consider the data they don’t have – In today’s world, product teams have access to an unprecedented set of data on the products that they’ve built. Left to themselves, they will optimize the product around the data they have. But what of the data they don’t have? What about the products and features that need to be built that the customers can’t imagine? Who will make that a priority? The CEO.

But how do you do that and only that if you have been involved in the product at a much deeper level the whole way? How do you back off gracefully in general without backing off at all in some areas? At some point, you must formally structure your product involvement. You must transition from your intimately involved motion to a process that enables you to make your contribution without disempowering your team or driving them bananas. The exact process depends on you, your strengths, your work style and your personality, but will usually benefit from these elements:

• Write it; don’t say it. If there is something that you want in the products, then write it out completely. Not as a quick email, but as a formal document. This will maximize clarity while serving to limit your involvement to those things that you have thought all the way through.
• Formalize and attend product reviews. If teams know that they should expect a regular review where you will check the consistency with the vision, the quality of the design, the progress against their integration goals, etc., it will feel much less disempowering than if you change their direction in the hallway.
• Don’t communicate direction outside of your formal mechanisms. It’s fine and necessary to continue to talk to individual engineers and product managers in an ad hoc fashion, because you need to continually update your understanding of what’s going on. But resist the attempt to jump in and give direction in these scenarios. Only give direction via a formal communication channel like the ones described above.

Note that it is really difficult to back off of any non-essential involvement yet remain engaged where you are needed. This is where most people blow themselves up: either by not letting go or by letting go. If you find yourself where my friend found himself—you cannot let go a little without letting go entirely—then you probably should consider a CEO change. But don’t do that. Learn how to do this.

Where Should Product Management Report?

A group of executives for a client recently asked me a fun question.

“We're hoping you can settle this debate for us. Where should product management sit on the org chart? Who should it report to?”

Aah, the old org structure question. This is an easy one to answer: Product management should report to a product management executive.

Sure, it’s a flippant answer, but it makes an important point.

Would you have salespeople report to your CTO? Would you have developers report to your CSO? Would you have accountants report to your VP of human resources? No. Then why would you have a product manager report to anyone but a product management executive?

Companies thrive or fail based on product performance, and products are the lifeblood of an organization. No matter how good your marketing, sales, channel or brand, if you don’t have good products, you’re sunk. (As David Oglivy said, “Great marketing only makes a bad product fail faster.”) Product strategy and execution is too crucial to company success and growth to be subsumed under another function.

Most companies have a marketing executive and a technology executive, and there are executives in sales, operations, legal and human resources—so why not a product executive? Appointing a product management executive sends a signal to the organization that product is just as important as the other functions. Will this automatically make your products great? Of course not. But when product management reports to another group (e.g. marketing, technology), it may be more difficult to produce good products.

Placing product management under the technology or engineering function often transforms the role into that of a feature order taker vs. a strategic business leader. One of two things often happens to strong, business-focused product managers working inside the technology organization.

1. They are slowly transformed into technical product managers (due to the strong technology orientation that comes from that group) instead of what the business really needs—someone to take responsibility for the commercial success of the product.
2. They get frustrated by the focus on technology over business and market and end up leaving for greener pastures where they can practice “true” product management and where their full range of skills are more appreciated.

Placing product management under marketing can hinder the working relationship between product management and the technology or engineering function, due to engineering’s perceptions (accurate or not) of marketing. Plus, the marketing organization has so many other responsibilities—demand generation, sales enablement, product marketing, field marketing, brand, PR, analyst relations—that product management can get lost in the shuffle.

In a large percentage of leading organizations, we see the product management executive as a peer to the CMO and technology leader (usually a CIO, CTO or VP of engineering), as well as other functions like sales and finance. The title of chief product officer, while still rare, is becoming more common. Leading product organizations include not only the product management function, but also related functions like pricing, user experience and product operations. These shifts represent an acknowledgement of product management as a strategic driver for the company’s growth.

Software Revenue Acceleration

Some years ago, a client of ours was, not surprisingly, debating how to accelerate software revenue. Their product and target market segment both set up nicely for a classic reseller channel - yet their efforts over several years had met with very limited success.

Our client's conclusion was equally unsurprising: the resellers simply lacked the necessary product knowledge, and their ability to grasp the finer points of the software was lacking. Sounds familiar?

It is a relatively common complaint at many software companies: the customers / resellers / partners / salespeople (circle the appropriate group(s), please) just aren't smart enough/skilled enough for our software to sell effectively. And very often it is noted that the group of people in question just don't have "domain expertise in our software."

That observation is almost always correct when seen from the development department of the software vendor: the supporters know less than the developers, the salespeople less than the supporters, the channel partners less again, and finally we find the hapless customer who is near zero in domain expertise in the vendor's product.

But if we flip around the point of departure, what the customer does have is domain expertise in the problem or process the vendor's software is intended to help solve. And the vendor's channel partner will have a relatively good grasp of the customer's process, but still less than the customer's own personnel. Backtracking all the way back to the software vendor's development department, it is there we find the least amount of domain expertise in the customer's situation.

So it's almost a law of nature that these most/least combinations fall along a relatively orderly spectrum. As one domain expertise falls, the other one rises. They work nicely together to make sure that the most important items at each locale get addressed properly.

It is the task of a software vendor to make sure that each link in the chain from its own development all the way to the end user gets just the right dose of software domain expertise. Then, assuming that the software product indeed solves the target market segment's problem, software revenue acceleration will follow.

Let Vicendia Partners help you map your software domain expertise against your customer's challenges and processes so you can accelerate your software revenue. Call us today at (630) 217-5948.