Rob Rivera wrote, in a comment on a previous post:

If we think that having a better or easier tool will make us more effective product managers, we may be fooling ourselves… We should be spending 80% of our time understanding, measuring and tracking how our solutions impact our customers’ bottom-line. For that we need very few “tools.”

He goes on to recommend a tool called LeveragePoint that focuses on measuring customer value. Definitely an interesting perspective, and I can’t argue with the idea that we need to focus on customer value.

But I’m not completely on the same page as Rob. I think it’s true that tools don’t solve problems. On the other hand, it’s clear that better quality tools, and especially tool innovations, often lead to better quality or totally new solutions. For example (from a different domain) I have a cheap table saw at home. I could use it to build some kitchen cabinets. But my cabinets would be kind of crooked. I’m not an expert cabinet maker, but even if I were an expert, my cheap table saw would make it really hard to build non-crooked cabinets, compared to having a good quality table saw.

For a great perspective on this, I suggest reading Doug Engelbart’s riff on the pencil as a tool (in his great 1962 paper), compared to ways the pencil might have evolved:

We fastened a pencil to a brick and experimented. … With the brick pencil, we are slower and less precise. If we want to hurry the writing, we have to make it larger. Also, writing the passage twice with the brick-pencil tires the untrained hand and arm.

How would our civilization have matured if this had been the only manual means for us to use in graphical manipulation of symbols? For one thing, the record keeping that enables the organization of commerce and government would probably have taken a form so different from what we know that our social structure would undoubtedly have evolved differently. Also, the effort in doing calculations and writing down extensive and carefully reasoned argument would dampen individual experimentation with sophisticated new concepts, to lower the rate of learning and the rate of useful output, and perhaps to discourage a good many people from even working at extending understanding.

I’m saying that the current PM toolkit is pretty much like a pencil fastened to a brick.

Image attribution

Pencil and brick. (CC 2.0 license, Attribution, Some rights reserved by danxoneil)

About the author

Your host and author, Nils Davis, is a long-time product manager, consultant, trainer, and coach. He is the author of The Secret Product Manager Handbook, many blog posts, a series of video trainings on product management, and the occasional grilled pizza.

You might also like

  • It's great that people are thinking about tools to assist the job of Product Management. I think there are some areas, like pricing, where tools can help. But one has to understand that Product Management is as much art as science. This is why it's difficult to create comprehensive tools–there are too many variations in the role. A good table saw will help you create beautiful kitchen cabinets, but it won't help you design them.

    • Yeah, so that’s what I'm trying to address – I think there are some things we all do that are admittedly more complex but that could be automated. I've listed a few of them in other posts. But they are things that occur in normal product management day-to-day work that transcend the ability of a list-based solution to address. For example, when you have to decompose a requirement into "the part that got delivered in the last release" and "the part that didn't get delivered." (And even if that doesn't happen to all product managers, I know it happens to a lot of us!)

      • Nils, I imagine three broad categories in tooling up for this job.

        The first is the routine stuff. We hate the administrivia and clerking and unproductive meetings that go with the job. That’s our burning pain. So the toolmakers first tackled prodmgmt daily efficiency. These apps are the ones that try to automate our workflows, CRUD our spreadsheets, bring paper online, turn reports into charts, that CYA and give us powerpoint-ready blurbage.

        And there’s this other stuff. The reasons we became product leaders. The pursuit of product clarity. The joy of bringing people and teams together. The elusive harmony of “final” choices with minimal dischord. The satisfaction of discovering what users really need and what customers will pay for. Better decisions, collaboration, insight. There are tools for these, mostly soft disciplines and skills. This is about coming back to our core purpose: turning needs into vision into valuable products.

        The last category is about reacting to SNAFUs. There’s almost no literature on what PMs face in terms of breakage, catastrophe, attack. Or how PMs respond. And very few tools that help us manage variability, risk, loss.

        These correspond, roughly, to three faces of product managers. The product process administrator, the product champion, and the troubleshooting manager.

        • Great analysis Phil! I’m most concerned about the lack of tools for the “product champion”, but your point about the troubleshooting manager is right on.

          • Do we have to finish wading through the problems of the product process admin before we have the underlying resources needed to serve champions?

          • Well, if history is a guide, then yes. But I am hoping we can break out of the current loop. For example, in my podcast about the “Product Manager System of Record” I describe a capability for capturing and working with customer interviews. This is a capability that’s fully within our technical grasp, but just hasn’t really been implemented very widely. The exception is Hubert Palan at ProductBoard who is actually building out some of this vision.

  • {"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}