The Value of Business Value

Business Value is often the holy grail of Product Management (and rightly so) especially when working in Agile.

Business value is genuinely very important; product managers are tasked with building products that offer some real value to somebody. Business values impact almost everything that we do with our product - its positioning, its go to market, its roadmap and its customer centric focus. These core elements of the art of product management are derived from and driven by the business values.

Classically we build things that people want to buy, advancing the business plan of our company. In other cases we may be trying to build infrastructure or experimenting with some novel ideas. However, in almost all cases we can define the objective with business value even if it is a stage or more removed from an actual sale to a customer. I plan to explore business value in these indirect cases in a future post.

So given that business value is one of, if not the primary objective of our professional lives it seems surprising how little attention many of us pay to the business value. Sure we read and write documents with some lip service to the business value. When we do a kick-off meeting we feel forced to generate a couple of statements on the subject and every so on a senior manager will feel the need to talk to even more senior people and have a mini crisis trying to generate a set of business values across all the products that they sponsor. It is possible that this is mainly a feature of big organisations; but my suspicion is that it is a common feature. It is more fun to build and design than to make bold declarations of future business value.

The crux of the issue is that it is really very important and on the critical path of everything that we do. If you are lucky enough to be constantly customer facing then you probably have a pitch maybe even several for different segments, but for the rest of us it is rarely on the agenda.

So here is an idea that I plan to put into action tomorrow - to have a slide deck or excel or some other file with every product that I manage together with its business value. So far, relatively easy, now for the hard part -  to try to keep it updated - say four times a quarter. At most reviews I think it will just be a critical read through and add the review date; but every so often things will change.

I think that this exercise will help in a few ways -

• We will really understand why we are building the product
• We will be able to remain true to the objective and not get inadvertently side-tracked in the natural drift of a dynamic product
• We will make any necessary changes actively after due thought 
• Of course finally we will always be able to provide answers to anybody who needs to know right now

Creating a Product Road Map

“Follow the yellow brick road” - this is the instruction that Dorothy got in order to get to Emerald City.

Product managers are responsible for building the product’s yellow brick road – the Product Road Map.

The road map generally should normally be planned for a 3 year period at a high level and for 18 months in a more detailed manner.

Probably the most important starting point for the road map process is the outcome of the strategic business process of the company. This is a critically important process performed periodically (often annually) by the senior management of the company together with the marketing team and actually drives the entire company. When we start to create or update the road map the last version of the strategic process is a major input.

Often this will be replaced or supplemented by a product strategic process where we systematically look at all aspects of the product and the market and set key business objectives within the overall corporate strategic framework.

The road map process starts with information collection which should include the following:

• Market trends
• Regulatory trends
• Technology directions
• Competitive analysis
• Customer requirements and suggestions

In the next step we need to analyze what is the likely impact of each item on the product and what we can or should be do in order to give the best response to the probable impact. The best way is to create a product requirements matrix with all the needed activities, new features, platform changes, etc. and then to prioritize this list.

Having done that, we need to figure out what is required in the development of each element in the matrix. We must get the rough effort estimation and / or the budget needed. Now we have the information needed in order to make decisions and to create a road map release plan, if possible for a 3 year period, but not less than 18 months.

Needless to mention that during all the process described here we need to drive internal collaboration and buy in by involving and getting the opinions of many other groups from within the organization for example marketing, R&D, sales, operations and so on.

This is a cyclic process, since we need to do it again at least once or twice a year and adjust the road map if needed.

The decision whether to let our customers be involved in the road map or more precisely to what extent they should be involved is not an easy one. See this article for some of our thoughts in this area. Generally we need to make the product ready for market, but at the same time, we need to be careful not to let the road map drift in the direction of one or two (big) customers, but, is not in line with the general market direction.

We should be very careful when externalize the road map document since it is has some legal status as a kind of contract and as such we need to enter all the needed legal and financial disclosures.

Hopefully this road map will lead us to Emerald City.

In subsequent blogs we will look at ways to share the roadmap internally and externally, getting internal buy in and some of the methods available to do competitive analysis and technology reviews.