A post in the Agile Management Yahoo! group has prompted me to make this second post with an example to elaborate on prioritizing and planning for market risk.

Steven Gordon wrote:

This approach seems oversimplified to me. In particular, I challenge the assumption that the low risk items should always be implemented first. For example:

1. A company might not even choose to bother with the market unless they can bank on a successful differentiator. In this case, shouldn't at least a slice or two of the intended differentiator be developed very early to obtain market research feedback on whether the idea really is a differentiator, whether it is really feasible to develop, and whether it might need tweaking or rejection.

2. A truly innovative differentiator can reshape the market and development vision of the whole product. Such a paradigm shift could totally change how the commodity features should be presented and developed.

I am more comfortable with the general notion that features should be delivered in order of immediate value than risk or risk of change. So, differentiators that have a large impact on how the whole product would be designed or on whether the project is even worth doing have large immediate value.

Here is my reply...

I believe a real world example would help. Let's imagine we are going to enter the cell phone market. Let's first define the table stakes commodity features. As entering the cell phone market has a huge setup cost, it will be necessary to offer a broad service attractive to many market segments. As I mentioned today's post really only deals with a single market segment.

I like to keep blog posts to under 1500 words and I will deal with market segmentation and product mix later. So let's try to define the general subset of features that represent table stakes for entering the cell phone market.

We will need...

A cell tower network
A deal with a long distance carrier to back haul our calls
A PSTN/SS7 telephony stack and associated infrastructure
Dial-tone
Ring-tone
Call setup across multiple networks
Call tear down across multiple networks
A Billing system with the ablity to bill individual calls and reconcile billing across networks to terminating or originating networks
An SMS Gateway
A Voicemail system
Handsets (one model might suffice but unlikely) with firmware to support voice calling and SMS messaging
Address Book feature on the handset
Inbox Feature on the handset
A support infrasture and call center
A market channel / delivery mechanism - such as a retail network

While we could argue the fine points of this set of features, the evidence from the market suggests that they are broadly correct. For example, if we study the MVNO market entrants in this century such as Virgin Mobile USA. Virgin rents its network from Sprint. At the time the deal was struck Sprint did not offer SMS messaging. It offered a rival service and technology from Qualcomm. Virgin thought it sufficiently important to include SMS that they deployed their own gateway to augment the Sprint network infrastructure.

While other features may be argued as "table stakes" the reality is that they are probably table stakes for specific market segments rather than the general market. This is a common problem with many firms. They do not perform good market segmentation and fail to truly understand which features of their product or service relate to specific segments. As a result they believe the table stakes are higher than they are. Smart market insurgents can exploit this situation by offering bear bones or white label products or services that offer just barely sufficient functionality to a market that needs unsophisticated features. A recent example of this would be the market entry of Google Docs which started life as a barely sufficient word processor that was only slightly more advanced than Notepad.

You suggest that differentiating features should be developed early in order to test them in the market and prove their value and market acceptance. I believe you are confusing research with production development. I believe these are parallel activities. Returning to our real example, let's imagine a differentiator is picture messaging. It would not be possible to demonstrate this feature on the production network without first delivering the table stakes. Though it is technically possible to skip the deployment of the SMS gateway, there is an issue with market acceptance if the SMS service is not offered.

However, the cell phone operator could test the market for picture messaging using research equipment. A COW (cell on wheels) could be deployed for market research. Typically COWs carry new network technology that is not deployed in production. COWs demonstrating full W-CDMA technology were available in 2001/2002 while most operators are yet to deploy W-CDMA for general use in 2008.

If you are able to deploy a differentiator prior to completion of the all the table stakes features then you simply haven't done your market segmentation and feature classification properly. The table stakes that remain to be completed are probably related to specific segments and not to the segment where you are testing the new functionality.

You state that value is more important than market risk or risk of change. Really? As recently as 3 years ago, I probably agreed with you but I've come to realize that I'm wrong. Why?

First, value is very difficult to define. Value is contextual and context is temporal. At best definitions of value are crystal ball gazing and are projecting value today based on market conditions today. Let's imagine that a new feature envisaged as a differentiator is planned. Let's say it is picture messaging and market research suggests that it is worth a $10 per month increment in MRC (monthly recurring charge). The lead time to develop it and deploy it is 18 months. 12 months in to the project a rival network launches picture messaging at $7 per month. What is picture messaging now worth? First it is no longer a differentiator. It is a spoiler. And it is probably not worth $7 per month but somewhat less. Either the price falls, or the size of the market falls because the insurgent stole some of our market share while we waited to bring the feature to market.

Let's now imagine that the competitor launches the feature early in our development cycle. Say month 2. The feature is a differentiator for a small market niche. Because we are following your strategy of prioritizing value first, we are building this differentiator first. We have started work. Have sunk cost in to it. When the competitor launches we redo our market forecasting and come to the conclusion that the feature is no longer viable. The cost outweighs the perceived gain in the market. So we cancel the feature and order another one. We just wasted valuable energy that could have been used developing a lower risk table stakes, cost saver or spoiler feature that is still awaiting engineering.

Hence, there are two reasons for not pursuing a value first strategy. The first is that value is hard to define and has a high variability to it. The second is market risk that puts the viability of the feature at risk. It's simply bad use of real option theory to prioritize something before we have enough information to be sure that we want the feature delivered. Technorati tag: Agile, Agile+Management, David+Anderson, Real+Option+Theory