Thread by @patio11

. @eladgil wrote the High Growth Handbook, regarding the challenges startups weather after product-market fit. Spoiler: great problems to have are still problems and can still kill you.

We excerpted a chapter on product management: stripe.com/atlas/guides/b…

Thoughts:

In the early days one of the founders, likely the CEO, is going to own the product *thoroughly*, inclusive of roadmap but down to obsessive detailed decisions. Eventually, even with continuing interest in owning product strategy, you'll need people to expand scope of the role.

Truly great PMs can have a wonderful conversation in their own head, with the product team, with customers, with "the business", and with external non-customer stakeholders, at appropriate level of detail, while keeping the narrative fabric straight.

Like many skills, once you've seen someone who is really, really good at this, you are very glad to have them doing it 100% of the time rather than doing a half-hindquartered version of it yourself for 80 minutes a week in between all the other hats.

In really good working relationships between a PM and EM that I've seen, there is a division of labor something akin to "Where are we going?" and "How do we get there?"

I'm not of the opinion that you necessarily need an engineering background to be a PM but sufficient facility with your company's environment to be a SQL maven, work your email tools, and speak deeply with engineers around objectives/prioritization is really, really useful.

Partly it's about earning mutual trust over time. Partly it's about being able to hear opinions regarding e.g. "We need X amount of time to refactor or we bite a Y% productivity hit until we do" and balance against recent cadence, near objectives, etc.

Partly it's being an advocate for your team internally because there will *always* be someone saying "Duct tape it and move faster!" and, in those times where that someone is not you, you should be able to zealously advocate for giving team the space needed to produce great work.

Elad mentions that most high-performing software companies don't need *project* managers. I would caveat this with "Does your company have something it does which is operationally intensive?" In which case it probably will have project managers, too, sometimes supporting ProdMs.

"Operationally intensive" is a term of art for humans-touching-atoms which underpins a lot of the great software companies coming up right now, which are no less software companies for the fact that they do do material work, at scale, on messy interactions with nature.

There's an entire rest of the book where that came from. You can find it on Amazon: amazon.com/High-Growth-Ha…

I don't normally enjoy business books, because they're typically business blog posts with 300 pages of filler. This one isn't that, happily.

I'd encourage you to read the interviews in the book.

Picasso once said something about how art critics talk about majestic trends and soaring emotions while artists talk about where to find cheap turpentine.

My review: "This book smells of turpentine."

(Incidentally, if you're an author of a turpentine-y persuasion, my colleague @zebriez would love to make your acquaintance. She's busy trying to build a publishing house within our software company, and is brilliant to work with.)