Being a CEO of a product wasn’t what I thought it would be

I was excited to manage my first product. It was over a decade ago. At the time, we didn’t have all of these product management resources and best practices that spelt out what a product manager did. All I knew was that I was going to be the CEO of a product. 

I was excited about the opportunity. As a CEO, I was going to lead the team to success. As a product manager, I would understand my customer’s needs and get my team to deliver solutions for them.

I tried my best to implement the things I thought a CEO product leader should do:

However, I learned that being a CEO of a product is so much more than just following the rules that I read in books and trying to emulate great leaders. While the best practices of product management are tremendously useful, they must be applied correctly. Here are some differences between learning and doing that I discovered on my first product. 

(Art by DALL-E)

When I took over the product, the first thing I saw was the Big Hairy Audacious Goal (BHAG) set by my predecessor. We were building a transformational online experience that was going to blow our customers away. The product would manage everything from low-level operational activities all the way up to C-suite reporting. There was even going to be a personalized news feed, so executives didn’t need any other apps during the day. 

Why did we do this? We got the idea from the CEO bible, Jim Collins’s Built to Last. Collins told us that by giving the team a BHAG to attack, we’d rally the troops to build something awesome. 

In Reality: After a few months, I realized that the BHAG was a side project. It was attached to a far simpler goal which was to upgrade our outdated technology stack. I learned that the team was mixing these two projects, the technology upgrade and the BHAG, together. This greatly increased our Work in Progress and slowed our velocity to the point where it would take 2 decades to finish the project. We were trying to drive a racecar down the track while upgrading the engine, but we didn’t have to. By separating them into two different projects, we could fix the scope for the technology upgrade and massively reduce the project's costs. The BHAG was then split up into incremental improvements on the new platform which could be more easily prioritized.

(Art by DALL-E)

Coming into the project, I started prioritizing things the way my predecessor had. He was very hands-on, working hard to make sure that every dollar was spent effectively. So I would ask all the regions what they wanted to do and have them cost it out. Then I would then rank the features and determine what the development team worked on. By personally prioritizing all of this work, I could ensure we were working on the right things.

In reality: After a few months, I started seeing issues with this process. My stakeholders were complaining that they were putting all this time and effort into gathering requests and sizing them, but they only have their projects deprioritized. 

There had to be a better way. I looked at the relative size of each of my stakeholders based on revenue. Then, I divided my capacity based on that revenue and assigned this capacity to the stakeholders. Finally, they would create a prioritized backlog and determine what work could be done in that increment based on their capacity. 

This transformed the way the stakeholders thought. Previously, they fought with me, arguing that their incremental need was more important than other teams. By giving them 100% ownership of their own work, they could make the trade-offs internally on what they wanted to deliver.

Over the years, I’ve re-learned this lesson many times. By giving people ownership of a specific piece of work with well-defined boundaries, they will give me far better work than if I keep sticking my nose in.

(Art by DALL-E)

At the beginning of each increment, I sent a detailed list to each stakeholder with the plan for the increment. It would have planning, requirements submission, refinement, development, unit testing, and UAT. This was before we’d moved to agile and we were still using a waterfall release cycle. The stakeholders had everything they needed to get me what I needed on time. 

In reality: I noticed the same pattern each increment—the requirements submission from many stakeholders was late. This would mess up our entire development cycle. Why would this happen when I’d given them all of the information they needed far in advance?

I learned that you can have too much transparency. Transparency doesn’t mean showing the stakeholders everything that I am doing. It means showing them what they need to know. As I looked at the list of things I needed from them, I realized that I needed to be clearer about the things I really needed from the stakeholders.

I decided to focus on the need for timely requirements. I no longer sent out a timeline of the development process, but a note devoted to the requirements submission. It had a number of key dates: when requirements were due, when the stakeholders would be reminded, and when the requirements would no longer be accepted. I also included a helpful RAG (Red/Amber/Green) chart to let people know where they stood on timing. After the final date, they would forfeit their capacity for this release. By changing the process, all of the stakeholders were able to get their requirements in on time, increment after increment.

(Art by DALL-E)

My boss was a big fan of Steve Jobs. He liked Steve Jobs' quote, “It’s really hard to design products by focus groups. A lot of times, people don’t know what they want until you show it to them.” 

Though he’d come from a sales background, he was adamant that we not talk to customers about their problems. He said, “We can’t ask clients about what they want. If we ask them what they want, they expect us to deliver these things.”

In reality: Instead of including customers in the formal roadmap process—I knew my boss wouldn’t go for that, I asked the sales teams for customers that wanted to talk with me. I learned that we had customers who just wanted to share their thoughts. Plus, I didn’t just find out what they wanted in my product but also what they liked and didn’t like in our competitors’ products. Previously, all we’d known about our competitors was what they’d put in their press releases.

I also learned that I could get customers to do work for me. At the time, we were looking for a way to manage user permissions in the system. One of our customers was very frustrated with the current system. She’d even built her workaround and created a spreadsheet of what she needed. Then, she gave me the spreadsheet, which I was able to use when designing the new system. Thank you, helpful customer!

Being a CEO is harder than it looks. When I look at a great CEO, I think of my current CEO, Jamie Dimon. When I was young, I thought it would be great to be Jamie, because he gets to tell everyone what to do. Now I realize that he doesn’t just have 300,000 employees that he tells what to do. He has 300,000 employees he’s responsible for and needs to listen to. Not just that but he has to keep our 80 million customers happy not to mention the Board of Directors and all the company’s shareholders. 

I learned that being CEO of a product isn’t just about reading books and applying best practices. It’s the nuance of actually getting things done. While prioritization is critically important, that doesn’t mean I should do it all myself. When Steve Jobs says that customers don’t know what they want, that doesn’t mean that he doesn’t listen to customers.

Finally, I learned that leadership isn’t as much fun as I thought. With all this power, I thought I’d get to focus on the fun stuff. But leaders need to drive results and make things happen. Yes that’s fun, but it takes a lot of time. One of my friends, a former Army Captain, told me, “Once you become a leader, you don’t get to do anything anymore. You have other people for that.” 

Now, when I lead products, I’ve become the CEO of my product. Not the CEO that I read about, but a CEO that gets results by bringing my customers and stakeholders along for the journey.

Note on the artwork: These images were created with AI which clearly has room for improvement—especially when it comes to spelling.

Explore more great product management content by exploring our Content A-Z