Beyond the Obvious
Phil McKinney
Hyperion, 2012
250 pages

Subtitled “Killer questions that spark game-changing innovation”, McKinney’s new book (released last week) is combination of personal experience in building new products as HP’s CTO and a framework for how he approaches the problem of trying to identify new business opportunities.

“Innovation” might be the one-word summary of 21st century business. That said, I hate the word. Governments are always dropping “innovation” into every announcement they make and CEOs all genuflect at the altar of “innovation.” Innovation is the panacea that will solve every problem – costs will go down, customers will throw themselves into your arms and the person that came up with the great breakthrough will be the next Steve Wozniak and Sergey Brin combined.

The trouble is that most people hate new ideas and actively work against them. Innovation is something most people like to have happened in the past. Real innovation is a process that’s not only messy, it’s painful. The outcome of real innovation in the short term is that people lose their jobs, that products people have spent their life building become obsolete and that individuals’ power is disrupted. In the long term, real innovation creates more value than it destroys and lets people move on to more important things. But people don’t always see it that way.

So what is McKinney’s approach to uncovering innovative new ideas? The first is dealing with what he calls “organizational antibodies” whose job it is to kill anything that threatens the status quo. The second is to ask what he calls “killer questions.”

I think McKinney has a solid approach – you should read the book and hear it from him yourself. This is definitely a practitioner’s book. It’s not an academic text like The Innovator’s Dilemmaby Clayton Christensen or Winning at New Products: Creating Value Through Innovation by Robert Cooper. McKinney references Cooper’s stage-gate process but doesn’t go into a lot of detail about exactly how to structure it beyond using an escalating system of commitment to allocate more resources to a project as it achieves development milestones.

Definitely read Cooper’s book if you want more detail on implementing stage-gate. My personal experience with it is that you have to be careful – if you take Cooper’s process too literally you’ll have a few dozen meetings before an idea gets anywhere near turning into a real product. But the fundamental principle is unarguable – start small. “MVP” as start-ups call it these days, the minimum viable product. This is McKinney’s approach as well.

How applicable is this book for the average product manager that’s tasked with keeping a single product on track? McKinney addresses this in the book. Innovation can and should come from anywhere. Even when the VP of Product Management or the CTO or the CEO has the formal responsibility for coming up with new ideas, anyone who sees an opportunity should work to make it happen. And don’t feel like the “organization antibodies” are out for you in particular – they’ll attack anyone, even the CEO. McKinney goes over the common arguments put forward by the antibodies like “You’ll never get approval” or “Not enough return on investment” and how to counter these arguments. Great stuff.

Now, to comment on the title for a second, I personally suggest not discounting the obvious. Sometimes doing the obvious thing is not very easy and people will even resist that. For example, it’s taken years for the mantra of “performance is a feature” to be widely accepted by developers because building systems for high performance isn’t easy. But at Google, where latency is practically a religion, they have lots of data showing that response time is the one feature that users value over nearly everything else. And it’s not like speed is a particularly insightful observation. It’s just a lot of hard work to make happen. So while innovators do need to look “beyond the obvious,” don’t overlook the obvious either.

For the “Killer Questions”, McKinney divides them into Who, What and How questions. Like “Who is passionate about my product?”, “What emotional or status benefits could people derive from using my product?” and “What is the process used by the customer to discover my product?” (a “How” question). Now some of these questions have a consumer products bias to them, which isn’t surprising that McKinney developed many of them working at HP’s consumer product division but many still have applicability to other industry segments like enterprise products. McKinney dives into examples of using each of these questions and what insights it generated.

One question that I think should be on every product manager’s mind these days, especially software product managers is “Can someone give my product away for free?” Twice in my career I’ve seen situations where a once-viable product category simply disappeared. JProbe, a great tool for Java performance analysis, ended up competing with free tools built into the developer tools that were given away by platform vendors. PowerRecon, a virtualization capacity planning tool, had great features but ultimately had to compete with a free tool from VMware that it was using as part of its pre-sales process. If you’re part of a big company with lots of products then having a limited product lifespan is fine as long as everything in the overall portfolio fits together. But when you’re a small company, having competitors priced at zero dollars will be tough to beat. Think about how you can take your product into a different market segment where the price competition is less intense, even if other competitive pressures are stronger. As a wise PM once told me, “If there’s no competitors it’s probably because there’s no market.”

Overall “Beyond the Obvious” lives up to its name, delivering insights into how to structure a process around innovation. It’s inspirational for product managers through anecdotes of product development at HP while also being a practical guide on how to make innovation happen. Check out Phil’s tweets at @killerquestion and his blog at philmckinney.com.

Thanks to Jon Bernstein at Hyperion who sent me a copy of the book to review.

Related posts:

1. Book Review: Innovation Games
2. Book Review: The Product Manager’s Desk Reference
3. Book Review: The Lean Startup
4. Not a Book Review: Software Product Management

Tweet this: The Lean Startup by @EricRies : Book Review @PGopalan http://wp.me/pXBON-2Vg #lean #startup #innovation #prodmgmt

by Prabhakar Gopalan

The Lean Startup by Eric Ries hit the digital book stands a couple of weeks ago.  Eric Ries coined the term Lean Startup and is a recognized leader of the lean movement.  The book is an easy read and an excellent introduction to the concept of applying lean principles to startups.

The book illustrates with many examples, anecdotes and the author’s personal experience at IMVU, an internet company that makes and sells virtual goods (think avatars for IMs), on how lean startups work.  The book is organized into three parts – Vision, Steer and Accelerate.

The first part talks about how startups differ from established businesses and how to approach building a product through experiments.  The second part discusses how to measure and pivot or persevere and the third part discusses how to accelerate the processes in the three startup phases – Build – Measure and Learn.

The crux of the book is about startups experimenting and learning in an iterative fashion with the flexibility to change course based on the learning – the author calls validated learning.  To the author, the product is an experiment.  I couldn’t agree more on that very fundamental idea.  I think there is a lesson for most product managers right there.  To quote from the chapter Learn in the first section of the book:

In the Lean Startup model, we are rehabilitating learning with a concept I call validated learning. Validated learning is not after-the-fact rationalization or a good story designed to hide failure. It is a rigorous method for demonstrating progress when one is embedded in the soil of extreme uncertainty in which startups grow. Validated learning is the process of demonstrating empirically that a team has discovered valuable truths about a startup’s present and future business prospects. It is more concrete, more accurate, and faster than market forecasting or classical business planning. It is the principal antidote to the lethal problem of achieving failure: successfully executing a plan that leads nowhere.
Ries, Eric (2011-09-13). The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses (p. 38). Crown Business.

Some good content

The chapter on innovation accounting is highly instructive for the serious student in understanding lean and startup.   He clarifies the distinction between what he terms vanity metrics and actionable metrics.  Right after I had read the pages on vanity metrics, I was reviewing a presentation which among other things concluded that HTML5 jobs were more in number than any other information technology jobs based on the number of search results for HTML5 over other technologies (e.g. Java, .NET etc) at a leading job site.  It is shocking to see the innumeracy of managers and how data gets presented and interpreted incorrectly.  To those, Eric Ries’ offers a great lesson.

Another nice chapter in the book is on ‘pivot or persevere’.   Using the story of @2gov (now Votizen, a social media lobbying platform) he explains how pivoting is an important step in the startup journey.  This particular company had to pivot multiple times, each time in shorter duration than previous to learn and change course.  The story gives a sense of how flexible and real time learning has to be for a startup to finally get its business model right.

The chapter on batch size is yet another  good one.  Even for those unfamiliar with lean, this chapter would be an easy sell.  It starts with a simple example on processing envelopes, goes on to explain how Toyota out competed American manufacturers and his own story at IMVU.  If we stretch the concept behind this a little bit, we can start questioning the whole notion of economies of scale and their practical use and limitation.  This can turn many years of conventional Western thinking upside down.

But not everything is great

Some disappointments in the book: The book starts with a lot of promise about how lean can be applied to organizations of all kinds small and big, for profit and non-profit and software and non-software companies.  However, as you progress along, you get the impression that most of the stories discussed are about the author’s own experience at IMVU.  That by itself may be instructional, but not sufficient.  If you are at a big company, how do you apply lean startup principles (maybe a topic for the next book?).

In fact, in one section he spends a short paragraph on Organizational Superpowers – how one young employee gets the lean startup principles but is unable to convince the VPs and senior managers at his organization.  And abruptly shifts gears to another topic leaving you to wonder what you should do about it.

The author also has something against white boarding.  He criticizes “white board strategizing” as many as 10 times in the book (it’s a good thing you can count occurrences of words in your Kindle!)  For people that are visual, the white board is more than a strategy tool.  It is a way to express and exchange ideas, a blessing.

Lastly, the author, while espousing the case for scientific method and management throughout, is ambiguous on his position vis-a-vis Taylorism in the book’s epilogue section.   Taylorism is the anti-thesis of experimentation and learning.  It is revisionist history to explain how Taylor has been misunderstood over time.  Reality is, it was a reductionist time-motion study that has significantly contributed to how Western management has fallen trap to linear thinking models.  (For more on how Taylorism driven strategy is dangerous, please check out my presentation on the need for experimentation as strategy at ProductCamp Austin).

I’d recommend this book as a must on your bookshelf.  It is a primer for understanding the lean process in startup settings.

- Prabhakar

Tweet this: The Lean Startup by @EricRies : Book Review @PGopalan http://wp.me/pXBON-2Vg #lean #startup #innovation #prodmgmt

Related posts:

1. Book Review: Beyond the Obvious
2. Book Review: Innovation Games
3. Book Review: Expert Product Management
4. Not a Book Review: Software Product Management

It’s been a while since I reviewed a book on this blog.

BTW, if anyone wants to review books for this blog, contact me.

OK, enough with the housekeeping, on with the review.

Title: Take Charge Product Management – Time-tested Tips, Tactics, and Tools for the New or Improved Product Manager

Author: Greg Geracie

Published by: Actuation Press, 2010

ISBN: 978-0-615-37927-2

Website: http://www.actuationconsultingllc.com

Take Charge Product Management by Greg Geracie, subtitled “Time-tested tips, tactics and tools for the NEW or improved product manager“, is clearly aimed at people with little or no Product Management background.

The book consists of 9 chapters and a Epilogue. Yes, an Epilogue. I’ll get to that later.

The chapters are:

1. Your Mission, should you choose to accept it
2. The role of the Product Manager
3. Key activities to help you succeed
4. Establish firm footing
5. Formulate a winning approach to the market
6. Moving from vision to execution
7. Product development
8. Never take your eye off the market
9. Documenting results

Structure and Style
What’s interesting about this book is that each chapter starts with a short anecdote about people in the fictitious company: Alpha Technology Ventures. There’s CEO Sinclair Jones, VP HR Linda Welsh, Chairman Kevin Knowles, VP Sales Robert Lamp, head of Engineering Alex Wong, and a few other minor characters. But the main character is Sean Knight, a former Sales Consultant who transitions into being the company’s first Product Manager in Chapter 1.

After a short anecdote about the exploits of “newly minted” PM Sean Knight, each chapter continues with additional information to help the reader understand the issues facing Sean and tools and technique to move forward.

For example, Chapter 4 begins with a conversation between Sinclair and Sean. Sinclair gives Sean some advice on how to build a solid foundation in his new role and how to work effectively given the conflicting tensions he’ll have to deal with amongst the different groups in the company. Sinclair leaves Sean with the following advice: Good generals make sure to secure their base of  operations before expanding outward.

The chapter continues with advice on where to find information within a company that can be used both to get a good understanding of the market, customers, products, buyers etc. The list of suggestions includes analyst reports, customers lists, existing presentations, win/loss data, competitive information, defect reports etc.

Each chapter ends with “Tips for Taking Charge”. These summarize and reiterate some of the key points of each chapter.

The Epilogue summarizes the progress Sean has made in his first year as a PM. Sean’s achievements may be slightly optimistic, but they do represent a target to aim for, for anyone in Sean’s place.

First the negatives
While I have absolutely nothing against self-published books, a lot of them suffer from poor typography and graphics. This book is no different. The entire book is set in what looks like 12 or 14 pt. Times New Roman. It looks like a Word document was simply reformatted to fit the smaller page size of a book.

The lack of variety in the font makes it harder to differentiate various sections of text and scan efficiently over the pages. At minimum, the Sean Knight anecdotes should have been typeset differently than the main body in each chapter. Maybe this is a minor point to some, but readability is something that every book publisher should address. Formal publishing houses definitely do.

Some of the diagrams in the book are very hard to read, usually due to the fact that a large diagram has been reduced significantly to fit on a single page.

For example in Chapter 6, there is a diagram entitled Alpha Technology Venture’s Completed Product Lifecycle Management Framework.

This diagram condenses an entire Product Lifecycle (from Strategy to Retirement) across the top, and is broken out (along the side) by  Activities, Owners, Collaborators, Description and Deliverables. There are 12 different columns in the diagram.

To be honest, this is a good diagram and an entire book could be written detailing the individual elements, but each element is so tiny that the diagram simply becomes an eye chart.

Also in Chapter 6, another diagram - the Alpha Technology Ventures Product Decision Matrix Framework – suffers from the same problem.

It’s a table consisting of about 15 columns and 6-7 rows. To fit the table onto the page (remember it’s 15 columns wide!), it is laid out in landscape orientation, using what looks like a 5pt font. The text is incredibly tiny and barely legible.

And now the positives
This book is clearly aimed at the neophyte Product Manager. The exploits of Sean, Sinclair and others at the beginning of each chapter provide context for the reader as they work through the meatier content in the middle of each chapter.

There are a lot of tips and explanations of basic concepts throughout the book. A sidebar in chapter 3 explains Return on Investment (ROI). Another sidebar in chapter 5 explains FTE (Full-time equivalents).

The author touches on many of the common issues and challenges that new product managers — particularly at small companies — face, such as transitioning into the role from another department, the political realities they must face, the daunting scope of the role, the challenge to initially define it, working to be proactive vs. reactive etc.

Each chapter works it’s way through basic concepts fairly well and lays out some concrete actions that a PM can consider.

It’s clear that Greg has lived through much (if not all) of Sean’s experiences himself during his career and is now imparting the  wisdom gained to the next generation of new Product Managers.

In summary
Typography and diagrams aside, I’d say that Take Charge Product Management is a good resource for the new or soon to be new startup Product Manager.

I include the word “startup” because Product Management in larger companies — i.e. with an established Product Management team — would have defined roles and responsibilities, and some level of process (I would hope).

The book is easy to read with a nice casual style to the writing.  And while there is little that is new or truly innovative in the book, there is enough substance that the reader won’t feel they’ve wasted their time.  It’s not going to make you an expert or turn you into a rock-star PM, but if you want to learn the basic concepts before digging into more detailed reading or taking some classes, this is a good place to begin.

Saeed

Related posts:

1. Book Review: Expert Product Management
2. Not a Book Review: Software Product Management
3. Book Review: The Product Manager’s Desk Reference
4. Book Review: Innovation Games

There aren’t a lot of really good books available for Product Managers. That may be simply because only a few people  truly understand what Product Management is, AND have it in them to write good books about it.

There are quite a few books that try to cover specific parts of the Product Management function, such as up front analysis, pricing, product launch etc., but very few try to look at the breadth of tasks involved in Product Management and describe them at a thorough level of detail.

The Product Manager’s Desk Reference, (PMDR for short) by Steven Haines, tries to take on that daunting task.  At over 700 pages, this tome contains a broad array of information.

The book is divided into 6 modules each containing several chapters. The Modules are:

1. Foundational Elements of Product Management
2. Making the Market Your Primary Focus
3. The Start of the Product’s Journey and the New Product Development Process
4. Continuing the Journey: Post Launch Product Management
5. Professionalizing Product Management
6. The Product Manager’s Tool Box

As mentioned each of these Modules is composed of several chapters. There are 23 chapters in the book. Some of these chapters are:

• Chapter 1 – What is Product Management?
• Chapter 3 – Leadership: Creating Influence
• Chapter 6 – Finance for the Product Manager: Keeping Score
• Chapter 14 – Justifying Product Investments: The Business Case
• Chapter 20 – Lifecycle Product Portfolio Management
• Chapter 23 – Organizing for Product Management

There is also a good glossary and a healthy index. Both are signs of attention to detail by the author.

In Chapter 1, the author delves into defining Product Management in detail. He asks: “What is a Product Manager?”

He provides 3 bullets to answer this question.

• The product manager is the a person appointed to be a proactive product or product line “mini-CEO” or general manager
• The product manager leads a cross-functional product team.
• The product team’s responsibility is to optimize the product’s market position and financial returns, consistent with corporate, business unit, or division strategies.

Emphasis on the word optimize is mine. I like that word a lot because Product Management truly is an optimization function. i.e. define how to invest limited resources in an optimal manner to deliver product to market, ideally with a high level of quality that is inline with market needs and expectations and that achieves business goals. Yeah, real easy.

He later defines Product Management as follows:

Product Management is business management at the product, product line or product portfolio level.

Again, emphasis on the word business is mine. Note that there is no reference to technology, development, engineering or anything similar.

Product Management truly is a business function, and this is something that is clearly not understood or acknowledged by many in the high-tech community. Unfortunately, many within the high-tech community view Product Management as an adjunct to Development or Marketing.

For software and technology companies, one aspect of Product Management is related to technology, and gathering requirements and seeing them through the development process. But it is far from the only thing Product Management should do.

Given the book is 700 pages in length, there is a lot more that I could write about it.  Chapter 23 — Organizing for Product Management — is an interesting chapter. The author focuses a message towards “managers of Product Management and those who are responsible for evolving the Product Management organization”. i.e. management and Sr. Management in a business.

He covers cross-functional teams, Product Management objectives, how to transform an organization that doesn’t have Product Management well defined, coach Product Managers and a case study on Airline Recruiting Corporation (ARC) and their ARC Compass division.

How to best organize, structure and implement Product Management in companies is not a well understood topic. It usually just happens organically at some early stage in the company lifecycle. While far from perfect, this chapter is one of the few, if not only, texts I’ve seen trying to put some structure around this subject. There is a lot more to discuss and write on this topic, particularly as Product Management evolves, but this is a good starting point.

I only have one complaint about the book:

Module 6 — The Product Manager’s Toolbox — is simply 50 pages of templates of various documents printed in book form. While this does bulk up the book, the reader would have been better served by having actual templates downloadable from the author’s website, or some other place on the Web. I’m not a big fan of templates in general, but for the new Product Manager, they can provide some structure that may not be present otherwise. And I find it surprising that other vendors  and consultants actually charge for these kinds of tools.

Overall, it’s not light reading, but certainly much more accessible than the other commonly cited tome on the subject — The PDMA Handbook on New Product Development — which is rather academic in style and consists of a series of chapters written by at least 20 different authors.

The Product Manager’s Desk Reference delivers on it’s promise. It’s not a book that you will read cover to cover, nor is it a book that lays out a strict how-to or recipe for Product Management. It’s a comprehensive reference book that describes a broad business function that is ill-defined and ill-understood in many companies, and attempts to put some rigour and structure around it.

Will you use it every day? Not likely. But then like any other “desk reference”, you wouldn’t expect to. But when you need to better understand some aspect of Product Management, it’s likely that this book is a good first place to look.

Saeed

Related posts:

1. Not a Book Review: Software Product Management
2. Book Review: Expert Product Management
3. Book Review: Take Charge Product Management
4. Book Review: Innovation Games

Just a quick shout out about a new book on software product management, aptly titled: Software Product Management, Issues and Perspectives. The book is a collection of articles by various authors, published by Icfai University Press in India.

The book consists of 22 chapters divided into three main sections:

1. Development and Engineering
2. The Team
3. Sales, Marketing and Intellectual Property

The contributors consist of a mix of Indian, European and North American writers. I’ve never heard of many of them, but a few are familiar:

• Michael Ray Hopkin of Lead on Purpose blog
• Martin Cagan of Silicon Valley Products Group
• Gabriel Steinhardt of Blackblot Product Management
• Jim Geisman of SoftwarePricing.com
• John Mansour of ZIGZAG Marketing
• Robert G. Cooper, Professor, creator of the Stage-Gate process, from the Product Development Institute
• Saeed Khan, of On Product Management blog

Yup, that last guy is me.  I feel like I’m in pretty esteemed company.  And to top it off, my article entitled Product Management Axioms (originally printed in ProductMarketing.com magazine), is Chapter 1 of the book!

More info on the book can be found on the publisher’s site here.

Saeed

Related posts:

1. Book Review: The Product Manager’s Desk Reference
2. Book Review: Expert Product Management
3. Book Review: Take Charge Product Management
4. Book Review: Innovation Games

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:

1. Determine the level of detail and time to spend
2. Competitive, market and technology trends
3. Gather and Prioritize Requirements
4. Decide on timeframe
5. Choose organizing strategy
6. Build Internal roadmap
7. Fine tune and get buy-in
8. 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:

1. Setting Goals
2. Writing the plan and getting sign off
3. Deciding who will manage the program
4. Determining the length of the program
5. Recruiting participants
6. Selecting candidates
7. Defining factors in response rates
8. Estimating participation levels
9. Obtaining agreements
10. Determining incentives
11. Starting the program
12. Maintaining ongoing communication
13. Responding to participants
14. Communicating internally
15. Administering exit surveys
16. 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:

1. Put a dedicated Sr. Product Manager on the job
2. Start early, work from a timeline and hold team meetings
3. Get your materials and references together
4. Do the killer demo: practice, practice, practice
5. Make it “Dummy Proof” with custom preset accounts
6. Set the competitive argument
7. Phase rollout, track equipment, check in routinely
8. Provide immediate responses
9. Include screenshots & photos with captions
10. 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

Related posts:

1. Book Review: Take Charge Product Management
2. Book Review: The Product Manager’s Desk Reference
3. Not a Book Review: Software Product Management
4. Book Review: Innovation Games

One of the most fundamental tasks in product management is requirements gathering. Product managers need to speak with target audiences, get a good understanding of their needs, wants and desires and then translate those into the language of requirements that product development teams can interpret and understand.

On one level, requirements gathering can be a rather mundane part of the job. Visit or call customers, prospects and partners, and talk to them about certain topics. Spend time with various people at a customer site and have them show you what they do and how they use your product. Have them tell you what they like and dislike about your product. Copiously take notes and then repeat the process again and again until enough data is collected that patterns can be seen and requirements created. Mundane and repetitive? Yes. Does it have to be this way? No.

Innovation Games, by Luke Hohmann, provides a set of clever tools and engaging activities that Product Managers can use to elicit feedback from users and prospects. The book’s tagline “Creating breakthrough products through collaborative play” nicely sums up the goal.

There are 12 games listed in the book. They are:

1. Prune the Product Tree
2. Remember the Future
3. Spider Web
4. Product Box
5. Buy a Feature
6. Start your Day
7. Show and Tell
8. Me and My Shadow
9. Give them a Hot Tub
10. The Apprentice
11. 20/20 Vision
12. Speed Boat

Each game is described under the following sections:

• The Game
• Why it Works
• Preparing for the Game
  • Materials
• Playing the Game
• Processing the Results
• How can I use <the particular game>

Not all games are applicable in all situations, and they are not intended to be. Me and My Shadow and The Apprentice require you (the Product Manager) to follow the user around or actually do their job in order to gain insights. Not always possible.

Others, such as Prune the Product Tree, Buy a Feature, Speed Boat and Spider Web are best done in group settings with a number of different users. I particularly like the games Remember the Future and Product Box.

Remember the Future asks users to think ahead into the future and answer the question “What will the product have done [at some sufficiently forward time in the future] to make me successful?” One of the arts of requirements gathering is asking the right questions. Remember the Future provides a very simple way of phrasing the question in the context of a necessary solution, versus simply a functionality request, such as “What do you want the product to do?”. The difference is subtle but significant.

Product Box is very different. It asks users to imagine they are selling your product, and they are in charge of creating the product box. They are given blank cardboard boxes, markers and other creative tools and let loose. They can put anything on the box they want, including marketing messages, images, features, pricing, you name it, to make the product as appealing to other users. While this may sound like a bit “out of the box” [sorry couldn't resist ] when compared to more typical requirements gathering techniques, it’s strength lies in the fact that it is driven by the user and their imagination, and not by the Product Manager and their biases or constraints.

Both Remember the Future and Product Box would be great tools to use if you are in the process of trying to define a new product. Instead of the typical pattern of PowerPoint presentation followed by Q&A; a follow up of one of these two activities can really get minds moving.

While not all people may be up to creating a Product Box, or may like being Shadowed, there is enough breadth in the games that appropriate situations can be found for many of them. Overall, what I most like about Innovation Games is that it is a low-risk and engaging way of turning what could be a mundane and repetitive task (for both the Product Manager and the customers) into something different and truly interactive.

If you want to know more about Innovation Games, check out the web site: http://www.innovationgames.com

Also, Luke Hohmann has a blog at http://www.lukehohmann.com

Saeed

[Full Disclosure] While I know Luke personally — I met him about a year ago in California and keep in semi-regular contact with him — that in no way influenced my opinion of the book or the games. Even before meeting Luke or learning of his book, I had successfully used some of these techniques — activities similar to Buy a Feature and 20/20 Vision — with customers. Innovation Games simply helps formalize some of the things we know and do instinctively as Product Managers, and provides a few new tools to help us do our jobs better.

Related posts:

1. Book Review: The Product Manager’s Desk Reference
2. Book Review: Take Charge Product Management
3. Not a Book Review: Software Product Management
4. Book Review: Beyond the Obvious