Did you ever pick up a book, read it and then think, where’s the rest of the book? If not, then you haven’t read Expert Product Management by Brian Lawley.
Subtitled Advanced Techniques, Tips and Strategies for Product Management and Product Marketing, the book covers 4 specific topics in what is less than a hundred pages in total.
These 4 topics are: Product Roadmaps, Beta Programs, Product Launches and Review Programs.
Product Roadmaps
The Product Roadmaps chapter starts by discussing why have a roadmap and what a Product Roadmap is. It then describes various types of roadmaps such as Market and Strategy Roadmap, Visionary Roadmap, Technology Roadmap, Technology Across Product Roadmap, Platform Roadmap and finally, Product Roadmap.
The distinctions between these various types of roadmaps become somewhat pedantic as, in the end, each roadmap presented is simply a high-level list of items presented in a chart representing roughly 3 calendar years.
Following this list of roadmap types is an 8 step process that is used to create a roadmap. These steps are:
- Determine the level of detail and time to spend
- Competitive, market and technology trends
- Gather and Prioritize Requirements
- Decide on timeframe
- Choose organizing strategy
- Build Internal roadmap
- Fine tune and get buy-in
- Create External Roadmap
These 8 steps form the bulk of the chapter, and while each step is described in some detail, there is nothing in these steps that is new or innovative, or that most any product manager with a few years of experience wouldn’t know. As an example, one of the Best Practices at the end of the chapter reads:
Always use code names for products on your roadmaps. You never know where a roadmap is going to end up and it’s much better to have a code name so you haven’t committed to a formal name in the market place, and so that your competitors will have a more difficult time determining exactly what your roadmap is trying to convey.
OK, is it just me, or does this not make any sense? If anyone with a small amount of understanding (e.g. a competitor) sees a roadmap slide, whether it has actual product names or code names, they are going to know what it’s describing, unless everything else on the slide, including all roadmap items are also written in some kind of code.
Beta Programs
The next chapter covers beta programs. Beta programs are near and dear to my heart, as in my opinion, running a successful beta program is one of the toughest tasks for many product managers. For more on my thoughts about betas, read my article Building a Better Beta.
Back to the book. This chapter is a scant 15 pages. The section on how to run a Beta Program, lists the following factors to consider:
- Setting Goals
- Writing the plan and getting sign off
- Deciding who will manage the program
- Determining the length of the program
- Recruiting participants
- Selecting candidates
- Defining factors in response rates
- Estimating participation levels
- Obtaining agreements
- Determining incentives
- Starting the program
- Maintaining ongoing communication
- Responding to participants
- Communicating internally
- Administering exit surveys
- Writing a final report
Now, this is actually a very good list to consider and follow when enacting a beta program. It’s actually similar to a list I define in my own article. The problem here is that for this book, many of these 16 topics are covered with scant information. For example, under “Starting the Program” (actually the heading in the book is “Kicking off the Program”), it says:
When you are ready to start the beta program, make sure that you do everything possible to avoid a false start. Double-check the installer and software download sites. Make sure the interface and documentation are ready for customers to use in a meaningful way. And build a [sic] FAQ that you can include to help customers from hitting bumps on the road.
Again, nothing wrong with any of this, but it’s pretty basic advice. How about some details or examples? Basically it says, when you’re ready to start the beta, make sure you’re actually ready to start the beta.
Product Launches
Chapter 4 covers Product Launches. Launching products can be quite complicated and involved, and there are even a number of books specifically dedicated to this topic. I don’t fault the author for not providing as much detail as those books, but for such a meaty topic, this is yet another razor thin chapter.
He spends a few pages talking about messaging, positioning, features and benefits (all of which really should be done well before the launch phase), and also covers a few financial considerations related to launch, but in the end, it too high level and simplistic to be applicable for most people.
Review Programs
This chapter discusses 3rd party product reviews, and how to create a reviewer’s guide. The section entitled Why Reviews Are Critical reads as follows:
Reviews establish credibility and are much more believable than your own marketing. Third-party opinions always carry much more weight than what a company says about it’s own products. Multiple good reviews have the ability to influence the market, create sales momentum and drive your product’s brand. And of course, good reviews also lead to winning awards for your products which give you further visibility.
This paragraph reads as if it was written in 1980 or for someone who had no idea what a product review was intended for.
The rest of the chapter covers 10 recommendations to make it more likely to get a good review from a reviewer. These items are:
- Put a dedicated Sr. Product Manager on the job
- Start early, work from a timeline and hold team meetings
- Get your materials and references together
- Do the killer demo: practice, practice, practice
- Make it “Dummy Proof” with custom preset accounts
- Set the competitive argument
- Phase rollout, track equipment, check in routinely
- Provide immediate responses
- Include screenshots & photos with captions
- Write the review for them
#10 is interesting. It is a sad but true fact, that many reviews have been written, and probably still are written by the vendors themselves, either directly, or indirectly by providing a reviewer’s guide with their product. As the author states:
…make sure you provide Adobe Acrobat PDF and Microsoft Word versions of the reviewer’s guide. You want the reviewers to plagiarize as much as possible. Put words in their mouth if you possibly can.
While I have to give the author some points for providing an honest description of how some reviewers work, it’s unfortunate that the chapter basically ends on such a negative note. There is some discussion about other uses for a reviewer’s guide, but the topic could have been covered in a more positive and thorough way.
Summary
I can’t honestly recommend this book to other people in the field. The title — Expert Product Management — is misleading. There is very little in this book that rises above what I would consider basic or possibly intermediate level information.
For the topics covered, the content is rather sparse and at times superficial. For a book targeted at “experts”, there is no coverage of topics such as defining or crafting strategy, competitive analysis, business objectives, pricing, dealing with market maturity, organizational issues etc.
This book might be useful to new product managers or product marketers, or for people who have little experience in any of the four topics covered. But, if the person is that inexperienced, most of this information can be found for free on the web, or the person should pick up some other books that provide a more thorough background on product management and more specifics on the topics covered in this book.
Saeed