Demand Driven Development
By Ismael Ghalimi
February 13th, 2006
Until now, if the customer of an enterprise software product needed a new feature to be developed, three main options would have been available: wait for the vendor to add the feature into a future release of the product, pay for the development of a custom feature and hope that it would make its way back into the product, or hire a third-party to develop a propriatery extension that would have to be maintained separately. The first option might lead to nothing, the second is expensive initially, and the third is expensive both upfront and down the line. Open Source development solved part of the issue by allowing customers to develop the feature themselves and contribute it back to the open source project, hoping that the community would pick it up at some point. It’s better than the first three options, but could still be improved upon. Here comes Intalio’s Demand Driven Development, which will be unveiled next month and to which I am glad to give you a preview today.
The main idea behind Demand Driven Development is to syndicate the development of custom features among a group of customers who need the same features and are willing to pay for it. Here is how it works: customers get access to a detailed product roadmap and can suggest the addition of new features to it. Upon review by the vendor, features that make sense get added to the roadmap, but no delivery dates are committed for them. Instead, customers can bid for the development of specific features, indicating how much they are willing to pay for which feature, assuming that the feature could be delivered within a certain timeframe. Multiple customers can bid for the same feature, and once enough bids have been collected to fund its development, the vendor develops the feature and delivers it to the group of sponsors, three to six months before anybody else gets it.
Similar models have been developed in the past, but Intalio’s Demand Driven Development goes a step further in two main ways: First, development is done in Ukraine and billed at cost. Let’s say that a given feature would require two man months of work for its specification, development, testing, and documentation, and a man month costs the vendor $5,000 offshore, fully loaded. In that case, the vendor will charge $10,000, on top of which 50% will be added to fund the integration of the feature into the main product and it’s ongoing maintenance. Second, 50% of what sponsors pay for the development of a custom feature is automatically converted into credit for future software upgrades for the vendor’s commercial software products. So let’s do the math, and assume that three customers team-up to fund the development of the aforementioned feature: each would pay a third of $15,000 ($10,000 + 50%), which is $5,000, but each of them would also receive a $2,500 credit toward future software upgrades, reducing their net cost to $2,500 each. What this means is that a customer would have to pay only 25% of the feature’s total development cost, while getting it before anybody else, having the guarantee that the feature will be integrated into the main product from the get-go, and receiving the assurance that the feature will be maintained by the vendor moving forward. How is that for a deal?
While benefits for customers are pretty obvious, benefits for the vendor are worth mentioning too. First, customers rather than investors end up funding most engineering development costs, which is good from a pure equity standpoint. Second, because customers tend to be better than entrepreneurs or investors at deciding which features are more important than others, the process leads to the development of features that will help sell the product, and because multiple customers have to team-up for the cost-effective development of a specific feature, the process also ensures that only features that are relevant to multiple customers will be developed, avoiding the common trap of custom development. Third, because a credit is given to customers toward future upgrades, customers that might not have considered the vendor’s commercial product now get an incentive to do so. To make a long story short, everybody wins, multiple times.
Demand Driven Development is Intalio’s further attempt at changing the economics of BPM, but it is applicable to virtually any kind of enterprise software product, not just a BPMS. We will release a first version of our Demand Driven Development service next month, and open it up to other software vendors that might want to try the model out. We are currently working with our offshoring partner for building the underlying infrastructure and have already started a couple of projects with early adopters. If you are one of our early adopters, or would really like us to consider a couple of features that would make a difference for your BPM project, let us know, and we’ll make sure to put you in touch with other customers who might have similar needs.
Author’s note: Following Mark Hamm’s excellent advice, we renamed the original ‘On Demand Development’ to a more explicit ‘Demand Driven Development’. Thank you Mark for your advice, it should help a lot of people get a better idea for what we’re doing.
demand driven development