Getting It Done by Roger Fisher and Alan Sharp
I picked this book up based on some positive reviews on Amazon and the fact that I recognized one of the authors from a popular sales/negotiation book that I was familiar with. The book covers a topic that is a common challenge for all types of Product Managers–how to lead through influence rather than hierarchy.
The Product Manager role can sit in a variety of places within an organization: Engineering, Marketing, a stand-alone Product Management department or even reporting directly to the CEO. But, no matter where it sits (even if it’s the Engineering side), the Product Manager has goals to accomplish and most of the time, they do not have direct control over the staff they need to accomplish those goals.
Even when a Product Manager does have direct control over some staff, there are still others on whom they rely that they do not have jurisdiction over and that makes a book like Getting It Done seem like a valuable tool. Unfortunately, while there are a few good tidbits that I found useful, on the whole I was let down.
Not much in the book seems to be geared toward leadership. It was more like project management, which shares some characteristics with leadership, but is not the same. The book is broken out into three parts:
- The Big Picture
- Basic Elements of Getting It Done
- Putting it All Together
which the authors use to layout their program. I found the format easy to follow, but not very engaging. Although the book was published in 1998, I felt like I was reading a book that was written in the 60’s. Perhaps that’s because not much of what is in the book is new. The authors acknowledge as much at the beginning,
“This book has taken shape over some seven years. We have been using the ideas in it for decades.”
Hmmm. Not so fresh, even back in 1998. In the introduction, the authors reference what they describe as an “old railroad story” to illustrate the importance of gaining cooperation. They present a story where there is a problem with a new locomotive engine, but no one seems to be able to fix it. They call in a specialist, who looks around, performs one minute task (in this case, a well-placed smack with a hammer) and everything is fixed. The specialist then provides a bill for an exorbitant amount of money (for this narrative, it’s $1000) and because it is so exorbitant, is asked to itemize it. The specialist itemizes the bill as follows:
- 1% for using the hammer
- 99% for knowing where to use the hammer
I have heard variations of this story for a number of different types of specialized roles–plumber, IT manager, chef. The problem with this example is that it’s not very original and even worse, does a poor job of actually illustrating the point it was supposed to be enforcing, namely the importance of cooperation (if you can see the point in there somewhere, please send me a note about it). Sadly, the book continues in this fashion most of the time. For the most part, I found the topics discussed to be either obvious, common sense or similar to other topics discussed earlier in the book. All is not lost, though, because as I mentioned there were a few gems that I found to be useful. GEM #1 The first is using quadrants to identify and then solve an issue. Breaking an issue down is not a new concept, nor is the use of quadrants, but the authors presented the information in a simple way that makes it easy for readers who are not familiar with the process to execute. They break the quadrants down like this:
- Data: What is the problem?
- Diagnosis: What are the possible causes?
- Direction: What strategy should be used?
- Do Next: What is the next step?
This is a basic framework that can be used to de-construct complex problems into more simple ones, with the benefit of not getting bogged down in conflicting issues. GEM #2 In a chapter about creating purpose, the authors discuss the idea of looking at purpose not as a singular event, but as one that can occur at multiple points in time. Frequently as Product Managers, we have to plan for what our product(s) will be in the future. When the end goal of the product is considerably larger than its current state, it may seem difficult to see how to get from point A to point B. The authors recommend setting your goals in three phases so that the journey from A to B is a path rather than a leap:
- An immediate objective
- A mid-distant goal
- An inspiring distant vision
I have used this process in phased feature roll outs. It’s a surprisingly effective tool for managing a large feature set or a software modification that is too big to fit into the standard release timeline. The tricky part about splitting the goals into phases is that you have to make sure that the early features are usable without the later ones and that you are not tipping your hand to competitors by giving them a view into your future product plans. GEM #3 Later in the book, the authors discuss point of view as it pertains to data collection and objectivity. They mention that it is very easy to get caught up in seeing (and valuing) only one’s own perspective. The metaphor that they use, a Russian proverb,
“Everyone looks at the world from the bell tower of their own village”
is an apt one and it reminds us that while Product Managers are the stewards of the product, we must expand our viewpoint beyond what we know or are comfortable with in order to best serve our customers. Like I said, there are a few gems in Getting It Done and for those readers who don’t have much experience in collaborative work environments, but for the moderately experienced Product Manager, they will have already learned or experienced most of what’s in the book.
Recommendation: only for beginners or those who struggle with building consensus
Popularity: 46% [?]
Entries (RSS)