In Service to Engineering

I love product managers, and I remind product managers of this constantly: we in product management can all go home, and the company might be totally fine, maybe for a long time. If the salespeople go home, you have a huge problem immediately. If the engineers go home, you have a huge problem almost as fast. Lose either of those groups and you lose the company. Lose product management and you might not.

So what is the function for? The company needs its engineers connected to the business: making decisions that account for revenue growth, revenue retention, market strategy, expansion. Product management is how that happens, and it only happens one way. We are in service to the engineering org. Not the other way around.

Which is why the mini-CEO framing has to go. A product manager who comes to work with the mindset that they are the CEO of their part of the product, who uses language like "I'm over this part of the product," is working from a broken map. It is absolute bullshit. And nobody who thinks of the job as a mini CEO is thinking about being a CEO in the right way anyway; the real version of that seat, as Chapter 11 will show, runs on empathy and service too.

There is some giving up of ego in this. The good news is that it feels really good, and it makes the work more sustainable and more rewarding. Ask anyone on our team about the best moment of their week and the answer is some version of a customer high-fiving the thing they built. The heart emoji from a customer in a shared Slack channel beats anything the org chart can issue.

We provide engineers the lens through which they do their work. A prioritized backlog is a lens. There are other lenses, which later chapters build, that make a prioritized backlog unnecessary, and there are remixes of the same backlog that engineers find dramatically more digestible and more inspiring than the ranked list. A large share of the job, done well, is the internal marketing of the same work.

That phrase makes some product people flinch, because marketing sounds like spin. It is the opposite of spin. Engineers care about impact. When we illustrate impact better, we motivate better, and motivated engineers do more work. This is where the productivity of a product-driven company comes from: more PRs, faster bug fixes, more urgency and focus, and none of it from longer hours.

The raw material for the good lenses is customer and revenue evidence, and Parts II and III of this course are about where to get it. The principle comes first: same work, better story, told with the customer in the frame. When I want a team to build something, the spec matters less than whether the tech lead can feel the person on the other end of it.

Engineers are not trying to impress anybody outside of engineering. They are trying to impress each other. They want to be around people they admire, and they want to earn admiration inside that group. They do not even want to be the best at the company; they want to be eightieth percentile at the company. It is like being in a band. You do not want to be the best player in a rock band; that is a problem. You want to be about the third-best player in the band, thinking these cats sound incredible and I am honored to be here, and then you want to play something that makes them look over and go, okay, damn.

Product management can design the environment where that moment is likely. The cool factor and the credit that accrue from one engineer's work reflecting out to their peers move through small channels: the emoji in Slack, the high-five in the hallway, the invitation to the dive bar on Friday. Subtle stuff, and we can influence every pathway it moves through. We can build the scoreboards. We can write the messaging that makes impact legible. We can make sure the customer's reaction, in the customer's words, lands on the builder's screen the same day, where the whole team can see it.

Kiran's win looked spontaneous but it was built on the environment we've worked hard to cultivate. Take away any part of it and Kiran or any other engineer might not see a reason to take initiative like this. When everyone cares deeply about the customer, it feels amazing and it's impossible to compete against.

There is a tender moment in every company's life: things are going well, and you are about to add a lot of people. Whatever culture you have set by then is the culture that scales. A thoughtful CEO at that moment might say, let's be sure to harden into product-driven.

The hardening happens in small precedents. The first time an engineer ships a partner integration without asking, does leadership celebrate it or schedule a process review? The first time a customer complaint reaches a builder directly, does the team treat it as a gift or as a breach of protocol? Each answer becomes a story people tell, and the stories become the defaults that scale.

We started close to home with Product's relationship with engineering. In the rest of the course, we'll turn to how product interacts with other parts of the organization. Before we get there, though, we need to turn inward.

1. From memory, list the last five things your team shipped. Next to each, write who got the credit and whether a customer's reaction ever reached the engineer who built it.
2. For each one, name the dunk nobody took: the customer who could have heard the same day, the partner who could have been looped in, the thank-you that never reached the builder's screen.
3. Run the prompt and pick one way to put customer reactions in front of the builders. Use it on the next thing your team ships, and afterward write down what the engineer did with it.

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. Bring your list; the AI checks it against the record.

Product managers and product leaders: the mini-CEO habit is the industry's default career advice, and unlearning it is this chapter's whole ask. Engineers will feel seen, and are encouraged to forward the chapter to their PM without comment.