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

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).

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.

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!

- 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.

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.

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.

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…

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!

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.

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.