Book review: Inspired by Marty Cagan

Book reviews are not my normal type of content but I just finished reading a great book on product management and thought that I'd share some of the highlights.  The book is called "Inspired" by Marty Cagan; I'll list some actual highlights below but the main reason that you should read this is that Mr. C actually has opinions and expresses them clearly, no pussyfooting around with if, buts and maybes. He does this in a fairly concise way, the entire book is only ~200 pages but it covers a huge amount of content. You could easily knock this one out in a coast-to-coast flight or even during the delay before boarding depending on your choice of airline.

If you are cheap, short of time and manage enterprise software then pop into B&N, grab a cappafructousino and read just chapters 38, 40 and 41 before sheepishly returning the book to the shelf...or maybe buying it.

The focus of the book is definitely on the up-font planning processes rather than the actual delivery. He does cover the move into general availability but with less detailed chapters, still relevant but not as packed with good advice as the planning section is.  This seems fair given that it matches the balance you should have in the product lifecycle.

Key messages:

• Try not to be put off the real goal of the product by one-off customer requirements or shiny things. As he quotes..."the main thing is to keep the main thing the main thing".
• Keep innovating, before you finish up the current release start planning the next release and include innovation before the backlog fills up with bug fixes, refactoring and customer-specific requirements.
• You need all of these but as Bill Gates said to FOCUS magazine in 1995 "We don't do a new version to fix bugs. We don't. Not enough people would buy it. ... You won't get a single person to say they'd buy a new version because of bugs. We'd never be able to sell a release on that basis."
• User design is key to success
• He doesn't say it explicitly but this didn't used to be the case for enterprise software where we got away with some appalling looking but functionally brilliant solutions...at least I did anyway).
• Personally, I'm not sure where to go with this in my new mainframe home where most people still think that the VT220 was a major step forwards in UI design because it added green or amber text to the previous white-only choice of the VT100 (yes I am old enough to remember this).
• In the spirit of user design you should identify distinct fictional characters and build the solution to suit their specific needs.
  • Learn from my mistake, choosing Dr. Sheldon Cooper, Martha Stewart and the Dali Lama was probably over ambitious. Go for people representative of those with a budget and a business need instead.
  • Seriously though this is good advice, base them on real target customers and then validate your modeling.
• The #1 trait to look for in your product managers is passion...this is not a segue to a 50 shades of grey book review but an indictment of the role of a product manager as the CEO of the company (Chief Evangelizing Officer)
• Interestingly he does not advocate the need for product managers to initially be experts in the technology that they delivered products for. He feels that passion, intelligence, integrity, etc. are more vital.
• Having just moved into a role working with alien technology I can see both sides of this. There's a huge learning curve when transitioning but your mind is completely unfettered by nasty things like facts or history!

Specifics

• Marty's a big proponent of not spending huge swaths of time writing detail documents  (that nobody reads). He likes the agile approach, prototyping and early engagement with real customers.
• Don't confuse the following roles although to be fair I've worked with some product managers who add a lot to these adjacent disciplines.
  • Product management and product marketing. 
  • Product management and project management. 
  • Product management and user experience design
  • Product management and engineering
• One great idea in the book is to have product management give engineering a 20% "budget" every release cycle to spend as they see fit. This gives them control over what refactoring etc. that they want to include and managed well will stop the situation when an entire release cycle is given over to nothing it refactoring (customers hate that btw). It's a nice idea but you have to trust that engineering won't over allocate.
• Marty seems to advocate the use of NPS to measure product success. I like the NPS system but would caution that the company's NPS is greatly affected by many factors outside of the direct control of the product management role: tech support, field facing staff, etc.

The only areas where I'd like to see Marty expand is around use of data and facts, not opinions. This is absolutely the best advice but is very hard to do especially as you plan for innovative products heading into unchartered territory.

He also advocates allowing key people to spend 20% of their time thinking about innovation if you work in a large organization where innovating is more difficult. I'm not sure that I entirely agree with the premise behind this. I've worked in some huge organizations and none of them have been anti-innovation. In smaller companies everyone is innovating for sure but they are typically so stressed out innovating on their "one big thing" that they don't have the luxury to spend time on other innovation.

Bottom line is that the book is definitely worth reading and probably even using as a reference on an ongoing basis.