Product Management is one of the most critical functions for any enterprise software company. As a product gets used by more and more customers, requests for new features start to pile in, and the job of a Product Manager is to prioritize them in order to meet customers’ needs, while avoiding feature creep. During Intalio’s early years as a company, we found it very difficult to manage this process. Too many resources where allocated to the development of features that very few customers actually needed, while features that could have made a significant difference on the market did not get developed, for lack of available resources. We only managed to solve this problem when we decided to outsource it, and selected an unlikely outsourcing partner for it: our customers.

The way we managed to outsource our Product Management function was through a process we called Demand Driven Development (a.k.a. D3), and launched a year ago. D3 is based on a two-phase process that empowers our customers to tell us what they need, they pay for it. In the first phase (Identification), we identify which features should be developed. In the second phase (Implementation), we implement them. The entire process is managed in the open from our community website.

You can think of the Identification Phase as Digg for Product Management. We publish a candidate list of features on the community website, and we let customers and partners suggest additional ones [Status: Submitted]. We then let the community discuss about them, and rate the features they like the most [Status: In Discussion]. We facilitate this process by providing additional input that we gathered from the field, then promote the most popular candidate features [Status: Estimating].

Once a feature has reached the Estimating Status, we enter the Implementation Phase, and we start involving our engineering team to develop a basic set of specifications for it, and scope the necessary development effort, quantified in man-months and calendar-months. We then multiply the number of required man-months by an average monthly cost (usually fairly low, for we do a lot of development offshore), to which we add a 50% overhead aimed at covering the maintenance of the feature for at least three years. Armed with these numbers, we come back to our community, and ask customers to bid for the development of the feature [Status: Out for Subscription]. As soon as we get enough customers to pay for it, we close the bidding process, and start the actual implementation [Status: Project]. When some features appear to be very specific to the needs of a particular customer, we ask for at least two customers to bid for it before we commit to its development. This measure helps us ensure that we reduce the risk of feature creep.

Once a feature is impemented, three options are available to us: One, we can give it to the customers who paid for it 3 to 6 months before anybody else gets it, thereby creating an incentive for customers to contribute to its funding. Two, we can incorporate it into the Enterprise Edition of our product, thereby increasing the value of a subscription. Three, we can donate it back to our open-source community, thereby getting help from the community for its downstream maintenance. In most cases, we do all of the above, in a staged manner, killing three birds with one stone.

In order to make it even more attractive for customers to participate in the funding of some features, we also give customers credits toward future subscriptions to our Enterprise Edition, equivalent to 50% of the amount of funding they contributed. As a result, if two customers end up paying for the joint development of a given feature, all they have to pay is a quarter of the overall development costs. We like to believe it’s a pretty good deal, and our customers tend to agree.

When we launched this program a year ago, it was initially received with a fair amount of skepticism. We knew that it would take time for the concept to sink in, and we decided that we would give it some time to mature. We signed our first project after six months, at which point the program started to generate more and more interest. We rapidly built a list of 60 candidate features, and in the six months that ensued, we signed another 11 projects, and doubled the number of candidate features. As of today, here are the projects that have received funding from customers:

A year into it, we can call this initiative a success, far beyond anything we could have expected in fact. More than 20% of our current engineering budget is currently funded through D3 projects, and we expect this contribution to increase beyond 50% before the end of the year. Along the way, we stumbled upon some side benefits that make it even more attractive from a Product Management standpoint.

First, such a process gives you a very effective way of dealing with what we call “checkbox features”, which are features that customers request as part of their evaluation process, but do not really need. Whenever we get asked for such a feature that we do not support yet, we point customers to our D3 website, and immediately get rid of 9 out of 10 checkbox features, without much further discussions. For the remaining one, we usually find a project worth considering, and get someone to pay for it immediately, which is nice.

Second, by opening up our Product Management process in such a way to our customers, we really turn them into development partners, and share with them the responsibility of developing the product they need, while asking them to vote with their checkbooks. This is a very powerful self-fulfilling prophecy.

Granted, not all parts of the product can be developed in such a way. In particular, the core components, such as the BPMN modeler in Intalio|Designer, or the BPEL execution engine in Intalio|Server, could not receive sufficient funding for them to be developed through a D3 process. Nevertheless, these are also the parts of the product that require the least amount of Product Management work, and can be managed almost entirely by the engineering team itself. These are also the components that we donated to large open-source communities (Eclipse and Apache respectively), thereby outsourcing Product Management to them.

If you would like some more advice about this process, feel free to drop me a line.