I attended the Silicon Valley Product Camp, last weekend, one of the yearly un-conferences for product managers in the US, Canada, and beyond.
During one of my sessions, a look into the role of product management in the innovation process, I posed some basic questions to the audience. What is innovation? As a group, we had lots of potential definitions. What is a product? This question elicited almost no answers.
That result wasn't a surprise. For years, we've been hearing about how difficult it is to define product management. Perhaps that has something to do with the difficulty of defining the thing that product managers manage.
We think we know products when we see them, in much the same fashion as Justice Potter Stewart famously defined obscenity, but we're a bit challenged to put into words exactly what they are.
We can easily define them in the negative, such as consulting offerings which aren't products, or IT projects that aren't products. We've all heard that products have lifecycles, which isn't nearly as Darwinian as one might expect. (Many ideas that don't deserve to become products, do. Many that deserve to die, don't.) But, if pressed, we're at a loss to define what products are.
That's worrisome, given the rising interest in "productisation." You might not worry about a great working definition for product, since we muddle through life without clear definitions of other things, such as cows or leprechauns. Unfortunately, we can't be sanguine about the definition of product, for the simple reason that we're trying to create them (a goal most of us don't have for cows or leprechauns).
Here are some interested parties who'd like to know whether or not what they're coding is a product, or should be treated as such:
- Customer-facing application developers who have discovered that, in truth, e-business and interactive marketing apps are hard to distinguish from what software as a service (SaaS) vendors provide.
- Manufacturers who are making software an increasingly common and important part of their products (cars, refrigerators, airplanes, DVRs, etc.).
IT departments who want to impose product-like discipline on the components in their portfolios.
- Services companies who want to productise their offerings, making them easier to develop, maintain, and sell.
- Software companies who are finding that, because of newer types of applications (mobile) and delivery (cloud), they have to re-examine their assumptions about what is or isn't a separate product.
In all these cases, app dev team members are trying to impose a discipline on themselves, under the banner of productisation. They know that they might need to re-define its work, in places as fundamental to their work as the task database, the issue tracking system, and the IDE. They also know that they might have to re-define some jobs, or create new ones. For the first time in the history of some organisations, this line of thinking leads to the first person hired as a product manager, where no such person existed before.
To help app dev professionals in that situation, I recently wrote a document that explains what product managers do, as distinguished from other roles that might look a little like product management, if you squint a bit. The document also identifies the chief reason behind this new-found interest in hiring product managers: creating better business outcomes through technology investments.
In many organisations, the product manager is the indisposable man or woman who understands both the technology and the business, and bears responsibility for the long-term success of both. (Even if you're a product management pro, you might want to take a look at the document, since it tries to look beyond the "product management as a matrix of tasks and responsibilities" model to identify the essence of this role.)
That document is just the first in a planned series about productisation, which began with this overview of the rising interest in product discipline. Stay tuned for more details about further research into this topic.
Posted by Tom Grant