I'm nearing the end of Eric Sink's Business of Software. Don't worry, a review will be on its way shortly, but I wanted to share some of my thoughts and personal struggle about pricing. Eric goes into the basis for choosing a price, but doesn't address why so many geeks have trouble choosing one... it all comes down to Costs vs Value.

First, let's get into a bit of Econ 101:

Costs - what it takes to make something happen.

This can be further divided into Actual Costs and Opportunity Costs. Actual Costs are the real dollars that come out of your pocket while the Opportunity Costs are simply what those resources could have been doing elsewhere. For example, in terms of software development, this is simple. Your Actual Costs are your developer tools, books, internet access, computers, Mountain Dew, and electricity. These are all numbers have a direct - and usually noticable - impact on your bank account. Your Opportunity Costs are more complex and include the what you could have received if you had played video games all day or worked at the local Starbucks. These are numbers which have to be estimated and are incredibly difficult to measure.

Value - a measure of utility*.
* There's probably a more formal definition out there somewhere, but all of them that I have found include the word "value" in them. Out of respect for my numerous English teachers throughout the years, I will refrain from defining the word by using it.

To put it simply, Value is simply how useful/needed something is to a person. For example, in the Washington DC Metro (the subway), when it rains there are regularly people selling umbrellas outside each Metro stop. They could sell these year round but I have yet to see one on a sunny summer day. The reason for this is simple. When the sun is shining, it's simply another thing to carry. When it's raining and you have three blocks to walk, it's a whole other story and many people are willing to pay $5 or $10 quite happily.

Alright, now back on point... why do geeks have such a difficult time setting a price?

When you develop v1.0 of your product, you take the costs of development, divide it by a number of units you think (or blindly hope) you can sell, you come up with a dollar value, and then you ask yourself... "Should I round down to 19.95 or up to 29.95?" You know that there are certain psychological aspects that go along with *9.95 and you aren't sure what they are, but you know you want to use them. This process completely ignores one part:

You are thinking only in terms of Costs and not in terms of Value.

All those geeks out there are saying "But if the production costs of that Nth CD are zero, how can I charge $X?" In a non-physical product market such as ours, production costs should be additive, not necessary the basis for determining price. What if the product saves your customer $100k/year? What if your product allows someone to work 5x more efficiently? A spreadsheet program falls into this category. How much time and effort does it save to tweak a percentage and have all your spreadsheets update accordingly? How often does the spellchecker on your email save you from making stupid mistakes? You must consider these factors when you choose a price.

Here are the aspects which I consider vital when setting a price. It can apply equally well for an mISV or custom development. In my own ranking from highest to lowest importance:

• Customer Pain - How important is the need this product solves? How much effort does it take for them to switch to my product?
• Actual Costs - How much time/money did it take to build, install, configure, or train? What is our average hourly rate?
• Opportunity Costs - Was this rushed and/or did other important things get set aside?
• Ongoing Costs - How much additional time/money will this require in the next 30, 90, or 180 days?
• Competitors - How much are similar products (better or worse) in the same space? What are the benefits of my product compared to those?
• Complements - How much are the required supporting components and/or other components which work well with my product?
• Future Costs - What is it going to take to get to v2 of this product? Does this product have a v2 or should effort be directed elsewhere?

Depending on who in your company is asking and answering these questions, you'll come up with wildly different responses. I'd suggest bouncing around a few numbers for a while and giving each a try over a period of time.

A few people have attempted to ding me on the pricing of the Domino Bridge. They simply don't believe that it's worth $3000 to have dotProject and SugarCRM synchronized. They could be entirely right, but I don't believe so. By using the Bridge, I was able to completely streamline our process of evaluating opportunities and remove the tedium and error-prone double entry previously required to make sure each system had the latest information. With minimal effort, as soon as we get a potential customer, their contact information has rippled through all of our systems and is always up to date. Scheduled calls and meetings show up in each of the systems and ensures that my calendar is always up to date. Most importantly, since all Sugar Opportunities and dotProject Projects are tied together, tracking the cost of a sale versus the revenue is amazingly simple.