This month we decided to dig into the management side of product management, and dug into Andy Grove’s seminal book, High Output Management.
I don’t want to spoil the podcast ending, but Sandi gave this a solid 5 out of 5 on the pony scale (🐴🐴🐴🐴🐴).
We don’t hand out our ponies lightly, this is a great read for product managers at every stage.
I’m not a manager, are you sure this book is for me?
Absolutely! I’m not a manager either—not of people, anyway—but this was still one of the most helpful books I’ve read about the craft of getting things in front of customers!
Andy Grove wrote this book for two audiences:
- People managers—those who supervise other humans.
- Know-how managers—those who shape the work of others without direct authority.
I can’t think of a better direct example of a know-how manager than a product manager. While about 100% of the book applies to people managers, close to 90% applies to us know-how managers.
Highlights from the show
Output based v. Activity based
How do you know if you’re a good product manager? I ask myself this question at least once a month (and not in a “well done, you’re so introspective” kind of way… more like a “oh god, I hope I don’t ruin anything today” kind of way).
Grove offers some valuable guidance for anyone looking to measure their effectiveness: don’t judge your activities—judge your output.
That’s basically the premise (and title!) of the whole book. You’re judged for the work that your team does. What’s the output? That’s all that matters.
As a PM it can feel so satisfying to do that bit of data investigation, dig in on that user research, triage those bugs, write that spec.
All these activities are often needed to get to output, but they have no value on their own.
You can be the world’s best spec writer, churning out spec after immaculate spec every day, but if your teams aren’t getting features in front of customers, you’re a shitty PM.
The “out of industry” trap
Grove talks about how hands-on (or hands-off) to be as a manager. His main advice: tailor your approach to how experienced your report is. The more experienced, the less involved you should be in their day-to-day.
Totally sensible. But he adds a little twist—it doesn’t matter how generically experienced that person is, what you should measure is the Task-Relevant Maturity (TRM) of the person you’re managing for the role they're currently in.
This one comes up in product management all the time!
It’s very rare to hire a product manager right out of college. Only the largest organizations (Facebook, Microsoft, Google, etc) hire and train new grads, and they each only take about 20 a year. Most people who start working in product management come from some other role (engineering, testing, marketing, etc) or from out of industry altogether.
If you’re managing a PM who’s got 5 years of work experience, you may expect them to be a reasonably autonomous employee. But if all their experience comes from other roles, or out of industry, they are going to have really low TRM in product management and need a lot more direction than you might expect.
I’ve seen this happen more than once, and even been that fledgeling PM myself. There’s a surprising number of things your new PM won’t know, no matter how many years they worked in tech marketing, finance, or consulting.
Don’t give your new PMs enough rope to hang themselves. Make sure you allot plenty of time to training a fresh PM, even if they have years of other work experience.
We'd love to hear your thoughts on the episode. Feel free to tweet at us @ClearlyProduct. Also, let us know if you've got a book in mind that would make a great episode!
Happy listening :)