Fog Creek Software
Discussion Board

Selling value, not time

You've said that it's better to sell a product versus a service due to the fact that you have limited time. 

Weiss et al, advocate selling 'value' as a consultant.  That way you're not limited by time constraints.  That way, you can say... sell a new process for 50K that saves the company 500K, even if you only spent a week developing the process. 

I'm having a hard time mapping that to the programming world.  It seems that customers of bespoke software don't want anything to do with it.  I have a feeling it's because software is more of a commodity than management consulting.  Or it might just be me.

Did you try this approach when you were consulting? 

Thursday, March 25, 2004

The idea of selling "value" or "value-based pricing" as a consultant is increasingly trendy for this reason, especially among the fucked company style of companies:

It sounds great but it always sounds great to vote yourself a raise -- the real question is if the boss (or customer) will go for it.

Joel Spolsky
Fog Creek Software
Thursday, March 25, 2004

I just realized I didn't answer the question.

No we did not try it.

Joel Spolsky
Fog Creek Software
Thursday, March 25, 2004

Thank goodness Goodyear doesn't use this model, otherwise I'd be paying a $50 per-day tire rental fee for the privilege of getting to work on time. If it wasn't for those tires, I wouldn't be able to keep my job.

Or am I missing something to this argument?

Thursday, March 25, 2004

You might think of it as "value minus value of next best alternative" rather than straight "value." In the example of tires, you've got other tire companies that won't charge a fee, so Goodyear can't get away with gouging you. But in a monopoly situation there is no "next best alternative" so it's straight "value," which is a fine pricing strategy.

So "value-based pricing" is only practical with little or no competitition.

Dan Maas
Friday, March 26, 2004

Doesn't this amount to fixed price versus billable hours?

Fixed price means the customer is assigning a value to an agreed upon end result.  From that point, if you can deliver that value in a week or 30 minutes before the end of the six month deadline, the customer pays the same price because he's getting the same value either way.

Just make sure you're scheduling skills are up to snuff :).

(And make darn sure a lawyer has bullet proofed the definition of what you're required to deliver.)

Jim Rankin
Friday, March 26, 2004

"Value" is a good concept, particularly if risk is included with cost and benefit.

However, value is a slippery thing. How do you measure it objectively? To be enforceable, any contract must be definitive: a court should be able to objectively determine if each party has met their obligation under the contract. So, its best to have a product to deliver, with specifications that define that product. Then you can verify delivery as satisfaction of obligation. Unlike value, the product specification doesn't change without revising the agreement.

Talk about value if it gets them to sign the contract, but don't put it into the contract. Same with "service" without a deliverable or a specific duration.

In any reasonable contract between two parties, there must be "value" for both; a win-win situation, otherwise no contract will get signed. I work for the Department of Health, so our concept of "value" will be different from a private health-care provider's. We provide free vaccines for children; we get value from that because of fewer epidemics and warm-and-fuzzy feelings when the Legislature is handing out tax dollars. It also provides value to the constituents.

Unfortunately, most business people have figured out that most programmers have a wildly different idea of "value" based on technology. So you have to make sure that you present any "value" suggestions in terms of what "business value" they will recieve, not a technology silver bullet. "IT business alignment" is a much bigger buzz-phrase than "value" is.

Also, values change. For example, they thought the program you're writing would solve their problems. They were wrong, and realize that when they start using the program. The value of the program is now zero. Same thing can happen because of changes in the business.

Another useful concept is what economists call "opportunity cost." Since you have limited resources available, one course of action prevents you from taking other courses of action. If you have $5 in your pocket, buyinga donut for breakfast means you have to give up something on the lunch menu. The cost of the donut is what you give up at lunch, not the amount of money changing hands. (However, if the donut costs $6, you don't have a choice.)

Turning this around, an investment is something you give up today, so you can have something tomorrow. You need a positive ROI (or whatever metric you want to measure). But you also need the liquidity and resources to support the investment and operations until you reach the break-even point, otherwise you're losing money. So value is definitely not enough.

David Lathrop
Saturday, March 27, 2004

> And make darn sure a lawyer has bullet proofed the definition of what you're required to deliver.

Actually, you want to make sure a *developer* has bullet proofed the definition.

Sunday, March 28, 2004

*  Recent Topics

*  Fog Creek Home