Book Review: The Phenomenal Product Manager

I have no doubt that author Brian Lawley was a phenomenal Product Manager. I’m less convinced he is a phenomenal writer, and even less that he can teach you to be a phenomenal product manager.

For those not familiar with the software development cycle, a Product Manager is the person who “owns” a software product that is in development. The PM should understand what the customers need and also understand how long it will take to build that product.

The Phenomenal Product Manager is a short book, only 84 pages. There’s nothing that says a book has to be a certain length to be valuable, of course. But, this one suffers from two fatal flaws: too broad and a lethal dose of arrogance.

First, Lawley tries to cover too much ground. In those short 84 pages, here’s what he offers to teach you:

Chapter 1: Product Marketing versus Product Management…(4 pages)
Chapter 2: What is a Phenomenal Product Manager?………….(4 pages)
Chapter 3: Influencing Engineers
– Credibility……………………………………………………………………..(3 pages)
– Building Rapport with the Team………………………………………(2 pages)
– Assessing Your Team and Adjusting………………………………..(3 pages)
– Communication……………………………………………………………..(1 page)
– Influencing…………………………………………………………………….(4 pages)
Chapter 4: Leveraging Your Sales Team
– Motivation…………………………………………………………………….(1 page)
– WIIFM…………………………………………………………………………..(1 page)
– Identify the Target………………………………………………………….(1 page)
– Great Leads………………………………………………………………….(1 page)
– Messaging…………………………………………………………………….(1 page)
– Excellent Sales Tools……………………………………………………..(1 page)
– Upsell and Ongoing Revenues………………………………………..(1/2 page)
– Planning……………………………………………………………………….(1/2 page)
– Ground Rules………………………………………………………………..(2 pages)
Chapter 5: Getting Management on Your Side
– Five Critical Relationships………………………………………………(1 page)
– Data, Data, Data……………………………………………………………(1 page)
– Short and Sweet……………………………………………………………(3 pages)
– Communication Often and With authority…………………………(1 page)
– Carrots and Stick…………………………………………………………..(2 pages)
…

And on for another five chapters. Chapter 6 has three topics and 4 pages. Chapter 7 has 10 topics and 18 pages. Chapter 8 has a staggering 19 topics covered in an efficient 16 pages. Chapters 9 and 10 are each a single page.

But, the worst failing is the arrogance with which Lawley approaches his topic. He assumes that the Product Manager will be an expert on every aspect of the software development process. This means he has no problem telling the testers how and what to test. He has no problem telling the developers not only what features to include, but what programming structures to use in building the code. Not even every developer is an expert on the development process. As a Product Manager, you’ll lose your credibility pretty quickly if you start telling your development lead how to write code. He’s good at it, you probably aren’t or you would be a programmer.

The last technique in terms of influencing is what I call the “Three Reasons” technique. I use this all the time. . . when you are debating a point you state your point and indicate that it is correct for three reasons. . .ofttimes you don’t have three reasons thought through, but saying this and talking about the first one will give you time to come up with the second and third. Even if the other reasons are weak it is better than a one-point argument.. . .This may sound far-fetched, but you will be amazed at how well this can work.

I’m never comfortable with authors who tell me to lie. Of course it’s effective. Lying often is. However, it does little to build trust.

What I Liked
Lawley does a great job of capturing the breadth of the Product Manager’s job. The PM really needs to know about all aspects of her product. You will be the one held accountable if it goes badly and the one to get the lion’s share of credit if it goes well. Lawley nails the fact that you have to overprepare. You have to actively manage relationships with entire product team. And he does a great job of explaining that each group needs to be handled differently.

What I Didn’t
Too much sizzle and not enough steak. Don’t tell me that if I bring doughnuts to my engineer meetings and speak with authority I can get them to do what I want. It’s not true. (Although the doughnuts help.) Instead, I wanted Lawley to take some time and explain the dynamics of an engineering team and how each group, engineering, testing, product management, is both cooperating and at odds with each other. There’s a natural tension built into the product cycle. The better you understand it, and especially how it impacts various team members the better you will be at influencing the team. Lawley didn’t provide any of this.

What It Means To You
If you’re a new Product Manager, or if you are part of an engineering team and you want to understand the PM’s role better, this is a good primer. But, if you are experienced in the product cycle, this book is as likely to annoy you as to educate you.

2.5 stars out of 5.

Rodney M Bliss is an author, blogger and IT Consultant. He lives in Pleasant Grove, UT with his lovely wife and thirteen children.

Follow him on
Twitter (@rodneymbliss)
Facebook (www.facebook.com/rbliss)
LinkedIn (www.LinkedIn.com/in/rbliss)
or contact him at (rbliss at msn dot com)