Subject: Practice: Pay-Per-Use - msg#00000

Next Message by Date:

Re: Practice: Pay-Per-Use

Recently our team was asked "If we could measure one thing and one thing only and report it back to the company what would it be?" Currently I am on an ECommerce team providing internal systems for managing and processing orders. Many ideas were submitted. Mine got no attention in our meeting were we went over the suggestions. The other suggestions went like this: Hours the servers have been up without a problem. Number of new features delivered on time. Number of orders successfully processed. ... and a few more on similar lines... My suggestion was measure how much money or systems earned or saved. I suggested that this would not be an easy thing to measure (but it was fair because they don't ask me to write easy code) but would give a number that is meaningful to people where decisions are made concerning staffing, equipment, budgets, etc. Many of our systems save money because we have replaced services that were outsourced to "large" companies which charged plenty of money. Many of our systems are a piece of earning money in that we give marketing special flexibility in the ability to make product offerings. I don't know why my suggestion didn't make it to the meeting for discussion. My paranoid side says, "no one liked it". I don't know the real reason. I should ask. Geoff --- In xpbookdiscussiongroup-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx, "Kent Beck" <kentb@xxxx> wrote: > With pay-per-use systems, you charge for every time the system is used. > Money is the ultimate feedback. Not only is it concrete, you can also spend > it. Connecting money flow directly to software development provides > accurate, timely information with which to drive improvement. > Lots of software is already pay-per-use. Telephone switches, electronic > stock exchanges, and airline reservation systems all charge you a fee per > transaction. While pay-per-use has business advantages and disadvantages, > the information it generates can help improve software development. > The ultimate form of pay-per-use I've seen was in a messaging product. > Users were charged per message. Each story in development was deliberately > selected to encourage more messages. Support for a new handset, for > instance, came with both a cost estimate and a revenue estimate. The team > analyzed the usage of the system to provide feedback for the accuracy of the > revenue estimates. The team used this information to optimize both cost and > profitability. > Today's typical arrangement requires the customer to pay for each release > of the software. Pay-per-release opposes the supplier's interests and the > customer's interests. The supplier is selfishly motivated to have lots of > releases, each containing the least possible functionality necessary to get > the customers to pay. The customer wants fewer releases (because of the pain > of upgrading), each containing lots of features. The tension between the two > sets of interests reduces communication and feedback. > Even if you can't implement pay-per-use, you might be able to go to a > subscription model, in which software is purchased monthly or quarterly. > With the subscription model, the team at least has the retention rates (the > number of customers that continue to subscribe) as a source of information > about how the team is doing. An even smaller change of business model is to > weight contracts more toward support fees and less toward up-front revenue. > One objection to pay-per-use is that customers want predictable costs. If > the price advantage of pay-per-use is large enough, customers may not mind. > A team using the information provided by pay-per-use should be able to do a > much better job than a team relying for feedback only on license revenues.

Next Message by Thread:

Re: Practice: Pay-Per-Use

Recently our team was asked "If we could measure one thing and one thing only and report it back to the company what would it be?" Currently I am on an ECommerce team providing internal systems for managing and processing orders. Many ideas were submitted. Mine got no attention in our meeting were we went over the suggestions. The other suggestions went like this: Hours the servers have been up without a problem. Number of new features delivered on time. Number of orders successfully processed. ... and a few more on similar lines... My suggestion was measure how much money or systems earned or saved. I suggested that this would not be an easy thing to measure (but it was fair because they don't ask me to write easy code) but would give a number that is meaningful to people where decisions are made concerning staffing, equipment, budgets, etc. Many of our systems save money because we have replaced services that were outsourced to "large" companies which charged plenty of money. Many of our systems are a piece of earning money in that we give marketing special flexibility in the ability to make product offerings. I don't know why my suggestion didn't make it to the meeting for discussion. My paranoid side says, "no one liked it". I don't know the real reason. I should ask. Geoff --- In xpbookdiscussiongroup-hHKSG33TihhbjbujkaE4pw@xxxxxxxxxxxxxxxx, "Kent Beck" <kentb@xxxx> wrote: > With pay-per-use systems, you charge for every time the system is used. > Money is the ultimate feedback. Not only is it concrete, you can also spend > it. Connecting money flow directly to software development provides > accurate, timely information with which to drive improvement. > Lots of software is already pay-per-use. Telephone switches, electronic > stock exchanges, and airline reservation systems all charge you a fee per > transaction. While pay-per-use has business advantages and disadvantages, > the information it generates can help improve software development. > The ultimate form of pay-per-use I've seen was in a messaging product. > Users were charged per message. Each story in development was deliberately > selected to encourage more messages. Support for a new handset, for > instance, came with both a cost estimate and a revenue estimate. The team > analyzed the usage of the system to provide feedback for the accuracy of the > revenue estimates. The team used this information to optimize both cost and > profitability. > Today's typical arrangement requires the customer to pay for each release > of the software. Pay-per-release opposes the supplier's interests and the > customer's interests. The supplier is selfishly motivated to have lots of > releases, each containing the least possible functionality necessary to get > the customers to pay. The customer wants fewer releases (because of the pain > of upgrading), each containing lots of features. The tension between the two > sets of interests reduces communication and feedback. > Even if you can't implement pay-per-use, you might be able to go to a > subscription model, in which software is purchased monthly or quarterly. > With the subscription model, the team at least has the retention rates (the > number of customers that continue to subscribe) as a source of information > about how the team is doing. An even smaller change of business model is to > weight contracts more toward support fees and less toward up-front revenue. > One objection to pay-per-use is that customers want predictable costs. If > the price advantage of pay-per-use is large enough, customers may not mind. > A team using the information provided by pay-per-use should be able to do a > much better job than a team relying for feedback only on license revenues.