In an earlier post I wrote about the difference between a project and a product. This distinction may seem obvious for some but considering the number of times I’ve found myself discussing its implications I’ve come to the conclusion that it may not be all that obvious.
Many traditional development process descriptions start with a requirements specification of some kind and then go on describing the creation of the rest of the development artifacts, all the way to a verified, validated and released product. In contrast to such one-off, linear processes, most system development organizations are almost completely occupied with continuously upgrading and correcting existing products based on a steady stream of internal ideas and new requirements and wants from customers, distributors and other external stakeholders. The upgrades are typically indicated by the version number of the product. (I’m for instance writing this on a computer running Ubuntu 12.04 which is an upgrade from Ubuntu 11.10 and so on.)
For such more or less continuous product development clearly something else is needed than a one-off development process to guide the engineering efforts. We need to plan several (upgrade) projects ahead to secure the necessary resources and for communicating with the market. We also need to continuously decide exactly what new features and corrections to add to the product at each upgrade.
Enter product management (and say hello to the product manager).
A product is according to Wikipedia “anything that can be offered to a market that might satisfy a want or need”. To maximize profits we want to make sure that a product matches the “wants or needs” as well as possible at the right price. Not only do we need to react to the feedback from existing customers and other stakeholders, we also need to pro-actively add innovative (and some not so innovative) new features so as to maximize profits, market share or whatever our goal might be for the moment.
To handle both the short-term requests from existing customers, sales etc and to actively manage the products features in the medium and long term is the purpose of product management and the ultimate responsibility of the product manager.
To plan and communicate the overall contents and timing of the major upgrades of the product, the product manager creates and maintains a product plan (aka product road-map) that in turn is based on both ad-hoc input from the market and thorough analyses of the targeted market segments, societal trends, the competition, available and future technology, partners etc (see e.g. ). All this makes the product manager one of the most important roles in the company, if not the most important role, and product management perhaps the most important process in the company.
Since we need to manage each product over its entire life-cycle, product management is not (and I’m sorry for keeping repeating myself) a one-shot project activity but a recurring line activity. The figure below gives a simplified view of how product management can be integrated into a project-oriented organization.
|Continuous product management.
Each new suggested feature, whether a new function requested by a customer or a feature suggested internally by the project manager, system architect or somebody else, is described in a change request.
New change requests are regularly evaluated by a change control board (CCB) with respect to cost / benefit and their consistency with the overall product plan. If the benefit exceeds the cost and the suggested new feature is in line with the product plan, then the change request is accepted for implementation and at some point scheduled into a project. Otherwise the change request is rejected.
The CCB is typically chaired by the product manager and has the major stakeholders of the change request such as the project managers of all ongoing projects and the line managers supplying the resources as members. The CCB is moderated and administered by a configuration manager.
While I can’t see any real alternatives to the above process and I have implemented it in several organizations, there are several challenges associated with doing so. I will return to these in future posts. A nice thing with the above process is that it plays very well with Scrum and other agile methods. This too may be the topic of future posts.
 Michael Porter. Competitive Strategy.