Complexity Bites – Why There Are So Few Good Product Management Tools

I’ve been thinking lately about the characteristics of product management as compared to some other business processes. Some of this is driven by the fact that we have such a lack of tools to help us do our job, while our colleagues have a surfeit of tools – the people running the business have SAP, the sales people have Salesforce.com, the marketers have Marketo or Exact Target, and the developers have a ton of tools for editing, building, tracking bugs, etc. But we PMs are not well served by tools, and in fact live most of our lives in either Excel and Word, or in Jira, or in a combination of those. And none of us are happy with this situation.

Why are so few PM tools available? And why have none of those that exist caught the imagination of product managers to the degree that we have put our credibility on the line and pushed for their installation at our companies?

There are a few reasons, one of which I want to focus on now:

• PMs don’t have a tool budget. Unlike developers, or the backoffice, there’s no budget for PM tools. But of course, those other disciplines didn’t have a tool budget until there were tools to buy, so that’s a little bit of a post hoc, ergo propter hoc argument (putting the cart before the horse).
• Maybe product managers are happy with “making-do” with MS Office and wikis and Jira. Well, we’re not that happy, but we manage to live with it. We’re very adaptable! But this again is not an explanation – those tools are difficult to work with for our jobs, and they have lots of downsides that we can all recite.
• Well, perhaps product management is qualitatively different from the disciplines that have been automated. In particular, it is complex, rather than simply complicated.

Obviously, I am going to riff on the last point – product management is complex. I am using the term complex in a technical way to differentiate it from complicated. Complicated, in this usage, means that there are a lot of moving parts, but they interact in predictable ways. The back office (automated by SAP) is complicated – there is a right answer for how much inventory you have, and you can get to it by following a set of steps. Complexity is a step beyond that – there are a lot of moving parts, but the interdependencies between them, as well as the outside world, result in emergent behavior that can’t be predicted.

Product management is qualitatively different from the disciplines that have been automated

This aligns with my (our?) experience as product managers that we often don’t know what we want until we see it, that no matter how well we conceptualize or prototype a feature or capability, we don’t really start to understand until we see it working, and even then, when we show it to a customer we learn more. And that this happens regardless of what methodology we use to discover, elaborate, document, prototype, design, implement, and test that feature. It’s always possible to have a worse methodology, but it’s never possible to have a methodology that “gets it right the first time.”

These are all characteristics of complex knowledge domains. It’s one reason the Lean Startup approach is so appealing to software product managers – it explicitly says that at the outset you don’t know anything. No matter how good your insights, you have to test them to validate them, and then you’re likely to need to make a pivot as you learn new information.

What does this mean for tools? We’ll cover that in the next post, and I’ll start bringing together some of the threads I’ve been discussing for the past few weeks on creativity, blocks, and the general angst of product management.

In the meantime, what do you think about the proposition that product management is qualitatively different from the disciplines that have been successfully automated, and what do you think are the implications for tools for product management?

For further reading, to whet your appetite and make your head hurt, I suggest looking into Cynefin, a framework for understanding knowledge developed by Dave Snowden. A series of seven blog posts on the origins of Cynefin is collected into this PDF – interesting although slightly difficult reading. (Hat tip to Jean Baraka of Rally Software who turned me on to Cynefin at Agile 2011.)