Your Second Boss

If you work in product and you don't report directly to the CEO, you have two bosses. One is your manager in the org chart. The other is the CEO. You can extend the idea to almost any role in a company and get something from it, but in product management there is no question. The CEO is your second boss, and maybe your real one.

Most product people nod at the idea and change nothing, because the org chart pays your manager to think about you and pays the CEO to be far away. The distance is the opportunity: almost nobody crosses it.

When one of the texts turns into a phone call, I ask one question before anything about the meeting itself: do you know the challenges of this business today? What is keeping your CEO up at night? What is the CEO saying over and over to the functional leaders without ever feeling they got a clear answer?

There is always something. Every company has existential crises. Every public company has a bear thesis, written up by Morningstar or someone like it, and it does not matter who you are: Nvidia has one, Apple has one. In all the years of taking these calls, sitting in a parking lot at my kid's soccer practice catching up with someone I managed seven years ago, I have never once heard a product person answer the question crisply.

What I hear instead is about their team. How do I get more resources. How do I own more of the product. How do I get promoted, grow my area, hit my numbers. That posture has a name, kingdom building, and when I ran product organizations it was one of the first things I looked for and worked to eliminate, because it's worse than either species from Chapter 1. A kingdom-building org isn't sales-driven or product-driven; it's team-and-career-driven, and nothing about it reaches the customer or the shareholder. It's friction in the system. It dissipates into heat.

So the questions become: are you waiting for the CEO to tell you the problems, or are you listening for them? Are you waiting to be handed license and resources, or are you walking in with solutions? And when you bring a solution, is it visibly colored by kingdom building, or is it articulated with mastery of all the available options?

Imagine being the CEO of a company with a few thousand people in it. Someone with product in their title, someone you might not even recognize, catches you for ninety seconds and says: you know the three big areas of challenge you laid out at company meeting? And the question you took from that analyst on the last earnings call? I think that one is interesting. There are a few ways we could attack it as a business. I see three. The first two are the obvious ones, and they cost what they cost. My team has an idea about the third, because we can reuse something that already exists in our code base and be clever about it. The details don't matter right now. We're taking a shot at it, the early numbers look like this, and it ties to the top-line number this way.

Ninety seconds. No deck, no meeting request, no ask. Nothing in it for the speaker's kingdom. A CEO who hears that pitch remembers the person who made it for years, because almost nobody at the company talks to them this way: prepared, connected, and calm about the parts they don't know yet.

My boss for years was Brian Halligan, and one of his habits was walking the engineering floor with his dog and a cup of coffee, stopping people at random, cheerfully: "Who are you? What are you working on?" He is a charming, curious, magnanimous person, as respected an operator as his generation produced and a student of the craft at the same time, so people lit up when he did it. More than once he caught my eye mid-conversation, and I watched the body language of the pair of them from across the floor.

I came to call what I was watching for the two-sip answer: the whole story, connected, in the time it takes the CEO to drink two sips of coffee. He stops a co-op a few months into their first stint. That thing you said at company meeting about this kind of customer? We all read the NPS threads in Slack, so everyone on my team knows it's a sore spot. My team owns that part of the product, I work on this piece of it, and the thing I'm shipping today makes it work the way those customers keep asking for. Two sips. The CEO is smiling, the co-op knows exactly who they're talking to, and the story runs unbroken from company meeting to code going out that afternoon.

Brian and I reached the same conclusion about this, nearly independently: it was how the chief product officer should be evaluated. How do you know whether your CPO is doing a good job? Stop anyone on the floor. If the answers connect, the culture is doing what the CPO exists to make it do. If a co-op has never heard of the CEO and can't say why their ticket matters, no roadmap deck compensates. That was my performance review for years, and it was a fair one.

Over my career I managed many hundreds of product managers. Most of them, when they wanted time with the boss, wanted to talk about their careers, and career meant title and compensation. That is a fair thing to want and a fine conversation to have. There was another group, small, that never asked for clarity on the career ladder, and that group was the one being promoted multiple times in a single year and handed equity grants that came to be worth seven figures.

What that group focused on instead was firing their teams up with primary-source information about the customer and the business. The move looks like this in a room. A product manager stands up in front of the team and says: remember the third point the CEO made at company meeting? Let me break it down for you. The team leans forward. Laptops tip down. The PM keeps going, connecting the point to these customers, these calls, this part of the product, and laptops close. Keep going and the laptops end up on the floor, because everyone is at the whiteboard solving the problem. That PM gets promoted. I saw it over and over.

That PM is also the one the CEO grabs me about in private: she's unbelievable, shouldn't she be the GM of the new business we want to start? And I'd have to say: there are four levels between her and that job, and she is five years out of undergrad. The GM roles on my team were deeply senior jobs. Lou held one, and Lou's next job was running product at Toast; I would work for Lou in a heartbeat. Yet here was a frontline product manager being discussed in the light of that seniority, for one reason: she was already behaving like it. Mastery of the company's existential problems, told through the voice of the customer, connected to what the CEO said at company meeting. People who talk that way get treated as whatever level the talk implies.

You can't produce that talk from a standing start; the raw material has to be in your hands before the hallway moment arrives. The build in this chapter's video stands up a keeping-the-CEO-up-at-night brief that refreshes itself from your company's own record, in Day.ai and in plain Claude Code. The exercise comes first, though, and it needs nothing but a blank page.

1. Close the laptop and write the three existential challenges of your company, the ones your CEO would name to the board. Use only what you remember. Where you're unsure, guess; the prompt will show you which guesses missed.
2. Take your team's current top initiative and draft its two-sip answer: two or three sentences that run from one of those challenges, through something a specific customer said, to what your team is shipping now.
3. Say it out loud with a timer running. Mark the spot where it runs past two sips of coffee or turns to your team's headcount.

Paste this into whatever AI you work in, ideally one connected to your company's material: Claude Code in a company-brain folder, Cowork, Codex, or similar. Run it once your list and draft are on paper.

APM through director: this is the career chapter, and the exercise is the cheapest career move in the course. If you already report to the CEO, Chapter 5 is yours; read this one for what to look for in the people you promote.