Menu

The First PM's Playbook: Don't Gut the House, Amplify Its Soul

The first PM's job isn't to install rigid process. It's to channel a startup's chaotic energy into a force multiplier. Here's the playbook.

The First PM's Playbook: Don't Gut the House, Amplify Its Soul

They hire you to fix their house, but it’s not your house. It’s their home. Your job isn’t to gut it; it’s to find its soul and amplify it.

The Discovery

You walk in on day one as the first Product Manager. The energy is electric. It’s a beautiful, chaotic mess of passion, late nights, and Slack messages that fly by like tracer rounds. The product is the founder’s baby, and they’ve raised it on instinct and adrenaline. It’s gotten them this far. It’s their secret sauce.

But the sauce is starting to burn. The founder has become the bottleneck. Every decision, every clarification, every prioritization call flows through them. The very thing that made the company successful—their vision and drive—is now capping its growth. They’ve brought you in to fix it. To “add process.” To “bring structure.” To “clean up the house.”1

And this is where most first PMs get it wrong. They arrive with a toolkit of frameworks and a mandate for order. They see the chaos and want to tame it. They see the passion and want to contain it. They start building gates, installing processes, and turning vibrant, creative conversations into Jira tickets.

My realization, standing in the middle of that beautiful chaos, was different. My job wasn't to control the energy. It was to channel it. It wasn't to build a cage. It was to build a conduit.

The Strategy: From Bottleneck to Force Multiplier

A startup’s energy is its most precious, non-renewable resource. It’s the raw, fissile material of innovation. If you try to suppress it with rigid process, you’ll kill the company’s soul. You’ll create a feature factory where passionate builders become resentful ticket-takers.

The alternative? Become a force multiplier.

A force multiplier doesn’t just manage the work; they amplify the energy of everyone doing the work. They don’t just translate requirements; they transmit intent. My strategy wasn’t to implement SCRUM or SAFe by the book. It was to design systems of communication and empathy that would make the entire organization smarter, faster, and more connected. The goal is to create empowered teams, not compliant ones.2

This meant my primary role was to be a translator. I had to paint a vivid picture for engineers in China of the problems faced by a VP of R&D in America. I had to articulate to the go-to-market team in London why a technical trade-off was not just necessary, but strategic. It’s about building clean, clear lines of communication that flow effortlessly across departments and continents.

Execution: Systems of Empathy

Talk is cheap. You have to build the forums for these conversations to happen. Here are two rituals that became the backbone of my teams.

The Customer Dive. We had brilliant engineers in Shanghai building a product for research scientists they would never meet. A feature request was just a line of text. So, we started bringing the customer into the room. Not just their words, but their world. We’d share recorded interviews, user session videos, and detailed stories of their day-to-day frustrations. We’d show the engineer not just what to build, but who they were building it for and why it mattered. The shift was immediate. They went from asking “What’s the acceptance criteria?” to “What if we solved the root problem this way?” They became problem-solvers, not just coders.
The Product AMA (Ask Me Anything). Our sales team was a pack of wolves—and I say that with the utmost respect. They were hungry, smart, and relentlessly focused on the customer. They had questions. They had ideas. They had frustrations. Instead of letting that fester in backchannels, we created a forum for radical transparency. Once a sprint, the product team would stand in front of the entire GTM organization and take any question. No topic was off-limits. It was terrifying. It was raw. And it was the single greatest trust-building exercise I’ve ever been a part of. It gave us priceless market intelligence, but more importantly, it showed we were accountable. We were in it together.

The Payoff

What happens when you stop controlling and start channeling? The founder is no longer a bottleneck; they’re a partner you can challenge and collaborate with. I was blessed with this in Stuart Hearn at Clear Review, a founder with a great product vision who had the confidence to be challenged.

The sales team stops selling features and starts selling the story, because they understand the ‘why’ behind the roadmap. The engineering team starts proactively solving problems, because they have empathy for the user. The friction between departments doesn’t disappear—that would be boring—but it becomes productive. It’s the lively, challenging collaboration that fueled our rapid success.

You move from a collection of high-performing individuals to a high-performing system. That’s the job. That’s what a great product manager does.3

The First PM's Playbook

  1. Diagnose, Don't Prescribe. Spend your first 30 days listening. Understand the existing flows of communication and energy. Map the relationships. Don't show up with a solution before you understand the problem.
  2. Build Conduits, Not Gates. Your job is to make information flow, not to control its release. Design rituals like Customer Dives and Product AMAs that connect people directly to the 'why'.
  3. Translate Intent, Not Just Requirements. A Jira ticket is a sterile contract. Your job is to be the storyteller, the context-setter, the painter of pictures. Give your team the full color version of the customer's problem.
  4. Embrace Productive Friction. A great sales leader or founder who challenges your roadmap isn't your enemy; they're your sparring partner. That tension is where the best ideas are forged. If everyone agrees with you, you're probably not being ambitious enough.
  5. Make Yourself Radically Accountable. Stand in front of the company and take the tough questions. When you own the failures as much as the wins, you earn the trust required to lead.

Conclusion

Your legacy as the first PM isn't the roadmap you shipped or the processes you installed. It's the connections you forged. It's the empathy you built into the system. You weren't hired to be a cleaner or a decorator. You were hired to be an architect of communication. To take a house with great bones and a fiery soul, and wire it so the music could be heard in every single room.

  1. The best tactical breakdown I've seen on the unique tightrope walk that is being the first PM is this piece from Reforge. It validates so much of what you often have to learn through trial by fire. ↩
  2. Marty Cagan is the godfather of modern product management. This piece on empowered teams is the 'why' behind my entire philosophy of channeling, not controlling. It's the antidote to the feature factory. ↩
  3. Ben Horowitz's essay, "Good Product Manager/Bad Product Manager," is the canonical text. Period. I re-read it once a year. It's a timeless reminder that a great PM takes responsibility for the outcome, good or bad. The 'CEO of the product' title is debated, but the accountability isn't. ↩