One of the fundamental issues in a negotiation, or in any buyer-supplier relationship is whether a supplier can actually do what we need them to do. We spend lots of time trying to get a read on this, and will even be willing to pay higher prices if we are sufficiently convinced that one supplier is more likely to do what we need them to do than another.
Outcome-based price models make sense in many cases, but not all cases. The Thomas Eggar blog has a good post on this topic here. The best example I can think of is in the world of IT. Software is a complex area, and there are many ways in which its development can go wrong. Determining whether or not the company that is proposing to build the software has the capability, capacity and project management skills to drive the project to completion is a difficult thing to asses pre-build.
Paying time and materials for this can lead to sloppy code-writing and missed deadlines. So why not specify outcomes? To answer my own question, it involves trust on both sides, and it requires the development of fair and relevant metrics along with an agreed method of measurement. (Please note that I was tempted to use the word “robust” but then likely would not have been able to finish the post after hitting myself with a hammer.)
On the positive side, specifying outcomes aligns incentives. In the IT example, just banging out lots of code without considering the bugs that it is causing won’t work.
Outcome-based pricing won’t work in all cases, but can if we can get the metrics right. Metrics to avoid would include things like share price, sales/revenue, and other things that are a product of many other variables. Good metrics would be things like up-time, number of mission critical bugs, and potentially even some measure of usage or end-user satisfaction.