Some Product Management Books
It struck me that I’ve never really read any books specifically about product management, but I get asked for recommendations pretty frequently. So I figured I’d rectify that, and picked a few books that show up commonly on lists of books for PMs: The Lean Startup by Eric Ries, Inspired by Marty Cagan, and Hooked by Nir Eyal. In particular, all 3 of these are on Ken Norton’s list of Books for Product Managers, which you know is excellent because (a) it’s from Ken (b) it’s very broad, covering a bit of PM methodology but also topics like thinking, writing, design, leadership, negotiation, etc. (c) it includes several all-time favorites of mine, like the mind-expanding Thinking, Fast and Slow.
In summary, all three are pretty good and I have few major issues with the messages they’re promoting. If they’re no longer mind-blowing, perhaps it’s because they’ve become part of the canon at this point. All three are also a bit on the sparse side and could be condensed significantly (like, down to one or a few HBR articles), but that’s typical of the business genre. Put on the audio versions at a fairly high speed — you won’t miss too much.
The Lean Startup by Eric Ries
★★★ A classic, mostly good advice, but feels a bit dated and narrowly focused to me
I’ve been aware of this book for a long time, but never read it until now. From what I understand, it’s been deeply influential on product development, including on me! So I may be giving it short shrift here. Maybe if I’d read it years ago I would have found it revolutionary. Now I feel it’s mostly correct, but really pretty straightforward, and there’s not much new I took away from it. Perhaps that’s a testament to how influential it’s been and how much it’s in the ether now?
The thesis here is that traditional product development is full of waste, and we can import a lot from lean methodology to get where we’re going faster. In my experience, it’s absolutely true that the best people are constantly asking the question, “which of our efforts are value-creating, and which are wasteful?” The way for a startup to move faster is essentially to front-load definition & testing of the key questions: the value hypothesis (does this solve the customer’s problem) and the growth hypothesis (can it grow into a business). Success in the early stages is not growth itself, least so on “vanity metrics” (aggregate metrics like number of customers), but rather obtaining the key learnings that validate or invalidate the hypotheses as quickly as possible. Really, the startup needs to get to product/market fit as quickly as possible, and everything else is essentially extraneous. So the way you do this is through MVPs (min viable products) and a rapid cycle of defining, learning, and experimenting.
So far, so good, I’m all in on this. To the extent it’s standard practice, great, but I also regularly see examples of product teams struggling where application of these principles is the heart of my prescription.
“There is surely nothing quite so useless as doing with great efficiency what should not be done at all.” -Peter Drucker
What resonates a bit less is the framing of the prescribed approach as a grand new science, a universally applicable methodology with definitive metrics that tell clean, objective stories. Product work just isn’t like that, and while all the principles and tactics here feel pretty solid, I think the scientific framing is misleading. In my experience, what separates the really great product people from the rest is not methodology, and it’s more art than science. It’s judgment, ownership, drive, influence, communication, vision, structured thinking, constantly driving issues to closure, and the ability to keep the big picture in mind while getting into the weeds. This stuff.
The failure of the ‘launch it and see what happens approach’ should now be evident: you will always succeed—in seeing what happens. Except in rare cases, the early results will be ambiguous, and you won’t know whether to pivot or persevere, whether to change direction or stay the course.
Two other quick notes: First, the book does feel very startup specific (truth in advertising here) and is probably most relevant for you if your challenge is going from 0 to 1. On established products (or especially platforms), I think the simplicity and clarity here can break down in places. Second, a lot of the examples struck me as odd. Again, maybe it’s just a failure on my part to remember what tech was like a decade ago, but Intuit and Groupon are not exactly my product north stars.
I would have liked to read the HBR article version of this book, with the structured framework laid out in 1/10 the space. I didn’t find the details or case studies super compelling. Recommended audible listening speed: 2.5x.
Inspired by Marty Cagan
★★★★ Probably as good a book as you’ll find for explaining to someone what a product manager is actually supposed to do
I thought this was quite a good book, and the best single overview of product management methodology I’ve seen. It’s well-structured, focused, easy to follow, and seems mostly correct to me. Being a methodology book, it still does seem to occupy a bit of an odd middle ground, neither getting into interesting business/product questions or cases nor actually showing you in any kind of practical detail how to do the stuff it says you should do. But maybe that’s impossible for a book tackling this subject at this level. Just be aware going in that it gives you that pure methodology slice of the world.
It doesn’t matter how good your engineering team is if they are not given something worthwhile to build.
The thesis of Inspired in a nutshell is that most product management is assembling a list of features handed down from on high into a roadmap, then driving delivery on that roadmap, and that no matter how agile the delivery piece is, this is essentially a waterfall method and it’s all backwards. Instead, product management is actually about figuring out the right product to build (product discovery), and that process itself should be agile, collaborative, and customer/business oriented. Get religion on your mission, get close to your customer, figure out what problem of theirs you’re trying to solve, and then tackle all the risks around your solution up front rather at the end. Run experiments, as quickly and cheaply as possible, using various kinds of prototypes, to assess value, usability, feasibility, and business viability. That is good advice.
Along the way, Inspired has a lot to say about who you need to be as a PM (an expert on the customer, on the data, on your business & stakeholders, on your market & industry), how to structure organizations, how to collaborate with your team, who to hire (intellectually curious, creative, persistent, passionate people), what visions and strategies need to do, how to set goals and measure progress (OKRs), and much more. I like the way customer interaction in particular was framed, and the amount of attention paid to target markets & personas, reference customers, customer interviews, and concierge tests—I haven’t seen it laid out with such clarity before. Overall, Inspired gets points for comprehensiveness and putting a clear framework on a huge range of topics.
I do think the depiction of product managers spending 80% of their time huddled with the designer doing product discovery work and essentially handing delivery off to a “delivery manager” seems out of whack. Maybe we’re just talking past each other here, but in my experience it’s far more balanced between discovery and delivery, and delivery can’t be punted to some “delivery manager” — it’s far less mechanical than the book makes it sound. It’s absolutely true that many teams don’t treat product discovery nearly seriously enough, and skip right to delivery of a feature list. On the other hand, if you’re doing it right, you still end up effectively spending most of your time in delivery (and there’s less of a bright line between them than is conveyed here). Some PMs just get more done more effectively than others, and that’s not even touched on here.
Related, Inspired repeatedly talks about delivering a product that will get a customer to “buy” or “switch.” But I’m not sure this framing applies to all of the product work being done. A huge amount of product development is trying to deliver more value to existing users with validated needs. Sometimes a technological leap allows for a product like Google Maps to be built — one that has obvious value but that wasn’t possible before. Sometimes you have conviction about a product like Apple Pay, but it requires multiple moves to get there (like putting NFC in every iPhone before payment was even possible). Platforms need to try to solve real customer problems, but a lot of their value derives from enabling unexpected use cases.
Cagan thinks roadmaps are tools of the devil, but I’m a little less hardline on this. Yes, feature lists handed down from management (or really, from anywhere) are bad, and focusing on feature output rather than business outcomes is a disease, and being committed to a plan going out into the future is not going to produce the results you want. But if you start from strategy and avoid the commitment pitfalls, I find roadmaps a useful way to make abstract strategy concrete. It’s like looking at a picture vs hearing the description of a design. And in practice, talking through your plan of attack with another experienced product manager can be a very useful way to get actual topical feedback about prioritization and where to get the most bang for your buck.
If we all read this, none of us would have their mind blown, but we’d all benefit from the shared language. Points off for repeated use of the term “ideation,” but a solid recommend nonetheless. Would make a great series of 3 HBR articles. Recommended audiobook listening speed: 1.75x.
Hooked by Nir Eyal
★★★ A good intro to behavioral psychology lite for product designers
Hooked brings a little behavioral psychology to product design, which is music to my ears. I’m a huge fan of books like Thinking, Fast & Slow, writers like Dan Ariely, and the whole behavioral psychology/economics space. Understanding how people actually think and behave, and how humans differ on these fronts from econs (the fully rational caricatures of humans imagined by standard economics), has huge implications for product managers.
When you get down to it, there’s not that much here. The “Hooked Model” is very simple: triggers (internal or external) lead to actions, which should be rewarded (slightly unpredictably for best effect), causing the user to invest in the product, which creates a loop.
That’s a useful framework for thinking about things. Of course, it’s also basically just operant conditioning (with the investment bit thrown in), so if you have any passing familiarity with behaviorism or have ever trained a dog (or raised a kid), you probably didn’t have your mind blown just now. And there are plenty of examples of successful tech products that don’t fit into the specific reinforcement model described here. Still, conditioning is extremely powerful. Looking at it in the context of products and thinking about the opportunity for and effect of different product behaviors on the user’s psychological state is a valuable framing, one more PMs should use. Same with thinking about people’s habits and how your product fits into their lives, amidst all their wants and needs, rather than trying to naively force your purported value in there.
I would encourage you to instead read some books that get into this area more deeply, as you’ll gain more insights applicable in a broader set of situations, and they’re just deeper and more interesting. Examples include Thinking, Fast and Slow, Predictably Irrational, and Influence. However, if you work on consumer products and want to dip your toes into behavioral psychology from the product side, this is a good place to start. It’d make a great HBR article. (But it’s also mercifully short!) Recommended audiobook listening speed: 1.5x.
