Demand Driven Development
Monday, February 13th 2006 | Ismael Ghalimi
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.
Entry filed under: BPM 2.0, Open Source
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ismael — it sounds like a good model for building a tool like Intalio, because it doesn’t directly impact on a firm’s competitiveness like the resulting system might. But if you are looking at packages (like ERP), then you should be more reluctant to share your bright ideas with potential (or actual) competitors — even with a six-month head start.
As I say — in your case it will build a better tool, which people like me will (hopefully) use in a multitude of ways to provide different functions to different firms.
Ric,
I agree with you, the model might easier to implement for tools and generic applications than ifor cutting-edge applications that would provide some advanced competitive differentiation. Nevertheless, we should also keep in mind that significant parts of SAP’s applications have been developed for specific customers initially, then integrated back into the main product line, to the benefit of competitors ultimately. Having someone else take care of your custom applications always pays off on the long run, and the way you deploy an application or a specific process within your organization is what really gives you that competitive edge, not the application itself, which should be considered as a commodity.
I’ve had this argument with people at work as well, and I still don’t see how commoditising the software function which supports a differentiated and advantageous business process works in your favour vis-a-vis a competitor using the same software. It’s true that the software in itself doesn’t provide the advantage (although I’m not even sure of that…), but virtually all non-trivial business processes require software support. While your suggestion is an improvement on the status quo (wait two years for the vendor to include your request in the standard package, and your competitors get it the same day you do), NOT making the process public via its supporting software function will give you the biggest headstart possible.
The whole BPEL/BPMS/ESB/SOA acronym soup is about making it easier to mix’n’match software functionality from various sources into a unique mix for yourself — that’s BPMS’ strongest selling point IMHO — I’m not sure you should be downplaying it!
Ric,
Anything that gives customers a clear competitive differentiation should indeed be kept private. The real question becomes where to draw the line, and it will be up to customers to decide where to draw it. That being said, I totally agree with your statement that a BPMS’ strongest selling point is in the ability it gives customers to innovate faster than their competitors. And if two companies have the same BPMS, deployed on top of the same ERP package, the one that deploys the smartest processes and makes them evolve the fastest will win in the end. It’s all about the process…
I don’t usually link to myself (it feels a bit masturbatory…), but I have a viewpoint and differentiation model that I described on an earlier post on my blog, if you’re interested.
I very much enjoyed training at Intalio last week. Our team was greatly impressed with the company, product, vision, and most of all people. Keep up the great work Intalio.
My comment is that I wish you would consider changing the name of your “On Demand Development” model. While I have no issues with the model itself, I have recently been spending time researching the language necessary to reach business people in the software-as-a-service market. To date there has been a proliferation of names that business people have not adopted. Some examples are: ASP, SaaS, xSP, etc.
Oracle, IBM and others have recently invested heavily in market-making language around the term “On Demand”, which I hope will stick and payoff for everyone in the market.
Business buyers today may imagine that “On Demand Development” is some kind of end-user-oriented forms+workflow development service - like Intuit’s QuickBase.
So again, may I suggest Intalio consider repositioning ODD under a different name. Maybe under By Demand Development or Demand Driven Development etc. Thanks.
Mark,
Thank you for the feedback. You’re making a very valid point. Let’s brainstorm and come up with something that might be less confusing. We’ve got until early March to settle on something we like.
I like the “Demand Driven Development” name. Makes for a nice acronym too (DDD, DCubed, 3D, …).
Hi Ismael, I really like your idea, but I see a couple of flaws in this model:
- What about your (the products) competitors? They will actively see what your customers are wishing for, and can then use that as leverage against your product. Why pay $2.5k (and wait 6 months) for feature X, when our product already has that built in.
- You have become a broker in the deal, instead of an innovator/leader. What is stopping them (the customers who now know each other) from dealing directly with Ukraine or another 3rd party software house and just doing it themselves without you.
- What is stopping ‘smart’ customer Y waiting for your other customers to pay for the feature, and just getting it in the next upgrade for cheaper than it would have cost them to join the inital payment.
- You also haven’t taken into account the actual demand from the customer, or willingness to pay for a component. Customer X might really want the feature, and is prepared to pay more for a better turnaround time, but Customer Y isn’t as enthused and although would still like it, isn’t prepared to pay as much as customer X would.
Ian,
Thank you so much for your objections. They will help us improve the model, which we’ve decided to call Demand Driven Development by the way. Here are some answers, following the same order as yours:
- Any smart competitor will always focus on our weak spots, and publishing our roadmap will make such weak spots known to the world. In that respect, we are helping our competitors. That being said, because the model allows us to implement new features faster than anybody else, at a lower cost, I like to believe that we can win on the long run. At any point in time, a competitor might beat us because of a couple features that our product does not have yet, but six months later, we will have ten more features than no competitor using a traditional product development model will be able to match.
- You’re right to describe our activity as brokering, but it’s not our business, in the sense that we do not make any money that way. As explained in the original post, we charge customers what we have to pay to our offshore development partner, without making any profit out of it. As a result, if a customer deals with our offshore partner directly, they will have to pay the same price as we do, or even higher, for we get a discount because of the volume of business we give to our partner. Demand Driven Development is not a business for us, it’s a way to fund our engineering effort, and as a result, we remain an innovating software vendor, using a broker model to manage our product and to fund its development.
- Customers pay for the development of custom features because they need it now. If they can wait, they have no incentive to pay for it and will do what is best for them — wait. Customers who need it now will pay for the feature, get it now, and in return we give them the feature three to six months before anybody else. What that means is that the value of getting feature foo at time t is a relative one: if foo costs c to develop, and if this value is x to customer X, and y to customer Y, as soon as you can find n customers of type X where n * x > c, you’ll be able to make the model work for you and your customers of type X. Customers of type Y will do what they do best — wait.
- Your last point is very much related to the previous one, and all I would add is that as with any participative model, some will get more than others, but it does not really matter, as long as everybody feels that they get more by simply being a participant rather than not being one. And if others get to benefit because of one’s active participation, more power to them!
Ian,
Regarding publishing the roadmap, I think it actually reverses the problem. There is no way a relatively small but innovative software company can protect itself against giants telling the whole world about features they supposedly provide and that such a small company does not. Whether it is true or not, whether the roadmap is published or not, the fact is that they just do it.
But if it’s published, then customers can get back to the bigger providers and start asking them: Why don’t you guys publish your roadmap? Why can’t I really have an influence on the features I judge to be important? And by the way, why can’t I even look at your source code? With the bigger players, only the most important customers can get that. The majority of customers have no power to influence the product they use whatsoever. The only thing they can do is switch to another big provider, for which they face the same problem again, unless they become a really big customer… Or they can work with a smaller and innovative company with which they can access the code, look at the roadmap, pay for the features they really want, when they really need it, etc.
But you might be right. Maybe this is hopeless and only the bigger players can provide broad software infrastructure. This is certainly better for them. Is it better for customers? They have the power to decide. This is especially true for the SMB market.
Excellent concept, and one that has evidence of success in other environments from my own experience, particularly the public sector. Additional benefits we experienced in this approach were a more rapid development of pragmatic standards that could be embraced by a wider group of users, with confidence as the original design and concepts were forged in the real world. As to the issue of competitive advantage, I think this is an over hyped issue, the context of use between one organisation and another make the risk of loss of advantage low, and actually drives behaviour towards excellence and rapid adoption vs resistance to change.
[…] Another interesting prospect would be the use of similar mechanisms to connect legacy versions of SAP R/3 — which will dominate the market for years to come — to older versions of Microsoft Office, such as Microsoft Office 2003 for example. Once customers will have indicated which features of Duet they like the most, it should not be too difficult for a BPM 2.0 vendor to re-implement similar features on top of SAP R/3, and make them work for the version of Microsoft Office that most customers will still be running in 2008 or 2009. To me, these other duos, be they powered by Office 2.0 or Office 2003, make for a pretty nice business opportunity, and they should really contribute to improve end-user productivity, especially for those that are not SAP power users. This is definitely something that Intalio should pursue with our Demand Driven Development program. […]
[…] In order to facilitate the integration of this technology within Intalio|BPMS, the entire engineering team that built it originally is in the process of joining Intalio. The roadmap is an aggressive yet pragmatic one. The goal is not to provide a tool that can support any notation — Microsoft Visio and IDS Scheer ARIS are good enough for that. Instead, the idea is to extend the scope to which extent Intalio|BPMS supports the Zero Code and One Click Deploy paradigms. As a first step, we will add support for UML Class Diagrams and offer the generation of EJB3 components and corresponding WSDL interfaces automatically, using Hibernate or Kodo as database persistence layer. Later on, we will add support for other UML diagrams, based on customer demand for them and following our now-popular Demand Driven Development program. Along the way, we will add support for the Eclipse Graphical Modeling Framework (GMF) for all supported diagrams. […]
[…] Even better, the upcoming 4.2 release scheduled for early July is adding support for magnetic grids and process-driven pageflows, while the 4.3 release that should become available in September or Ortober this year will add support for the graphical definition of complex event handlers. The later might even be part of a project we will manage through our Demand Driven Development program. […]
[…] We are proud to announced that we just signed a customer for our first Demand Driven Development (D3) project today. We are still under NDA with our sponsor, but we can share with you that the project is related to the integration of Intalio|BPMS with the Apache ServiceMix ESB. More D3 projects should be announced in the coming weeks. If you would like to sponsor a project, please log on to the bpms.intalio.com community website. […]
[…] Back in February, Intalio unveiled its Demand Driven Development (D3) program, as a way to essentially outsource major parts of our product management process. Since then, we have scoped over 60 projects, but we found it quite difficult to actually secure sponsors for them, irrespectively of the financial incentives we could offer. Today, I am pleased to announce that we signed our first customer for it. Here is what we learned along the way. […]
[…] 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. […]
Ismael,
While I see this working for user/customer facing functionality, how it does work for back-end or infrastructure related new development (e.g. upgrading the data access layer).
Vatman,
Good question. Take a look at the projects we completed. Many of them are definitely infrastructure related. Also, many back-end developments are actually required for addressing the needs of front-end features requested by customers. And when they are not, they fall into the category of core developments that should be funded by Intalio directly, but in such a case, getting the engineers to agree on them is actually pretty simple, hence the need for traditional Product Management is significantly reduced.
Best regards
-Ismael
Trackback this post | Subscribe to the comments via RSS Feed
Leave a Comment