I was fortunate to catch Sean Johnson's talk at The Business of Web Conference in Cardiff this summer on the subject of value based pricing, it certainly provided me with a lot to think about.
For those who don't know Sean, he co-hosts "The Freelance Web" podcast, a show I enjoy immensely. Sean has been championing value based pricing for a while now and with further discussions on his podcast and an article in net magazine I wanted to add my voice to the discussion.
We should start with a brief description of value based pricing, Wikipedia sums it up pretty well;
Value-based pricing is a pricing strategy which sets prices primarily, but not exclusively, on the value, perceived or estimated, to the customer rather than on the cost of the product or historical prices.
In short, we are talking about the value our work has for our client.
Logical fallacies and other issues
The argument for value based pricing is often made by comparing it to time based pricing, when put this way it makes a lot of sense. You will restrict your business potential by charging by the hour/day, there is a limit at which point you will be viewed as too expensive no matter the skill and expertise you bring.
However, this comparison is a false dichotomy, it isn't a binary choice between the two and neither are their elements mutually exclusive.
Let us not forget it is a very competitive marketplace and we are often selling to clients who are not accustomed to buying design. I have become better at sales over the years but it is not my forte, that is not to say I ever get involved in a race to the bottom. I will openly state we are not the cheapest and have no interest in being so. But this problem would be greatly exacerbated having to justify charges which could be greatly higher than those I am competing against.
There is also the issue of a client's financial means, basic Companies House research can tell you a lot about a client's economic position but rarely tells the full story, be careful about quoting by assuming the funds available to finance a project.
The myth of the single build
I often dissuade clients out of functionality and features that can not be justified with the data currently available. I would rather launch a smaller site and build on it based on feedback, both qualitative and quantitative, I want to be my client's digital partner and maintain that relationship for years to come.
So how can I set a value based price when I am openly stating that the first build may not achieve all the goals and I can't accurately predict the amount of future work needed to reach the stated goals? In an ideal world I would have years of usage data from an existing website but start-ups don't have this and nor do a lot of established businesses!
For all the logic and benefits of value based pricing I opted not to integrate that into my business.
Fundamentally it feels dishonest to me. It doesn't sit well with me the idea that two different clients will potentially pay two different prices for the same volume of work. I will strive to meet all my client goals no matter the perceived value to said client.
I have been struggling for an appropriate analogy but I believe the following illustrates:
Let's imagine we are plumbers and wanted to buy a van for our business. We have settled on the make, the model, the features and even the colour - we now want to know how much it costs. Would we think it reasonable to be asked about how much our average sales are and how much value this van would add to our business and then have a price set accordingly? I'm not sure that would sit well with anyone.
I appreciate that we are not quoting against someone with an identical product but I don't believe we can value our services based on what we perceive the value to be for our client. If our hard work helps make the company more money (and that is often a stated or implied project goal), these additional funds may be funnelled back into further website development, or to expand and grow the business which too will present new opportunities for us.
Sean points out that we shouldn't be pricing against a list of functionality provided to us by our clients, I'm 100% in agreement. We should be sitting down and discussing goals (we ask a lot of questions) and how we can design a successful website, one that will add value to our client. They are hiring us to find solutions and I want to hear the problems so that the eventual framework we put in place begins to solve them.
From these discussions I can accurately quote a fixed price to deliver the best solution (within the usual budgetary constraints) which will then be refined and built upon as we monitor the usage and results.
I do price projects differently depending on the added value they give to my business, value based pricing of a sort. If it is an exciting project or in an industry where we want more exposure, then our prices are discounted. Costs can also fluctuate depending on how much assistance and help we will get from our client, the more they buy in to the process the easier it will be for us and that ease can be reflected in the price.
The biggest price variable is the budget I put aside for the discovery phase. More complicated projects will require more research, I'm not talking exclusively about complexity from a technical standpoint, but also in relation to the project goals. For larger companies my stakeholder interviews will be more involved, it is the complexity of the problems I am being hired to solve that is the biggest driver of cost.
I do believe that the ideas behind value based pricing can help companies and freelancers break out of the time based trap, I'm yet to be convinced it is the best way forward for me. My fixed prices are not based solely on time, there are a variety of variables that will have an affect and will help me both make a living today and keep some money in the account for the (mostly) predictable quiet periods.
My company ethos has always been to do a great job at a fair price, 9 years in and it is still working for me and one of the drivers of our success is retaining our clients.