It seems like only a few months ago I decided to make the switch to value pricing, yet - to my amazement / surprise / concern / shock / horror! - here we are nearly 3 years on…

The past 12 months have been quite an experience in my business journey. I was lucky enough to work on some great new projects, and continued my drive towards a more focussed, product-orientated business.

But I also found myself having moments of uncertainty with value pricing.

This post is a summary of what I feel went right and wrong, and how I plan to update my value pricing strategy in 2019.

Productising Services

This year I made a big effort to standardise my services, replacing where I could bespoke offers with products and packages. The goal of productising a service is to make the work - or at least the process - as repeatable as possible.

I think productising can work hand-in-hand with value pricing as transition your offer to be more about that value of the service and outcomes you deliver.

A productised service should be more easy to scale and increase its value to both parties. As time goes on, prices can be adjusted to better reflect value, and optimise the service to increase efficiency (and the value to you)

That being said, one conflict between Productised services and Value Pricing is that by publishing a price upfront, you are not charging for the true value. This, then, may not be truly value pricing (or perhaps it is not true productising), but it has certainly felt like a good stepping stone on the journey.

As Jonathan mentions in his article, I've ended up using productised services as a part of a product ladder, with fixed-price smaller engagements, and bespoke-priced larger engagements such as service plans and Rails application upgrades (see below).

Code Reviews

Code Reviews were perhaps my most frequent example of a productised service, as I found they became a pre-requisite to any higher-value service that I offered.

Code Reviews were easy to define and limit in their scope. They had clear outcomes, and an easy to convey value for customers. The report customers received as a result of the review gave them a snapshot of their current situation, and recommendations for the next best steps. Code Reviews acted as a great first engagement, with low risk for all parties.

For me, the Code Reviews were a great way to gain a deeper understanding of an application's code and infrastructure, and better appreciate what might be required to achieve the customer's goals.

I'll continue to offer stand-alone Code Reviews and incorporate them into other services.

Consultations

I recognised that sometimes a full-blown code review (which can take a few days to produce, depending on the complexity of the underlying code) may be too much at the very early stages of an enquiry.

For smaller engagements, such as those initial conversations that establish the value of a project, I offered a consultation service.

I've found the consultations haven't had much uptake though. Most incoming projects have progressed from a quick 15-minute phone call to the Code Review itself.

The Consultation offer is a little too generic at the moment, with little definition about who they are aimed at. I plan to change this in the coming weeks.

CodeShot: Ruby on Rails

I offered CodeShots as a "one-hit" piece of development work. Ideally a small, discrete piece of work that can be turned around quickly.

Whilst I have carried out a handful of these with some success, I've found it to be very difficult to isolate development projects to such a degree.

Based on what I've appreciated about value pricing this year, and recognising that such small jobs have little value beyond "needing to be done", I plan to retire (or at least redesign) the CodeShot offer.

Rails Upgrades

Rails Upgrades have been a staple product this year, and seem popular as Rails and applications built on it mature. That being said, some of those upgrades I've carried out have presented huge challenges.

This has been difficult to recognise (and admit to myself!), but where I thought I was value pricing upgrades as a service, looking back I can see that I was really pricing them as fixed-priced projects. I really had little understanding of the value that such upgrades deliver.

As Rails Upgrades can hide so many unknowns (although I've learned a few new red flags to look out for this year!), I plan to change how they are offered in the new year.

Sidenote: GitHub published a great article on how they upgraded from Rails 3.2 to 5, with some important lessons they learned during the process.

Service Plans

One of my earliest attempts at productisation was to introduce service plans. These are essentially retainer agreements that are limited by scope rather than time.

The scope of each service agreement is determined in conversation with the customer, based on their longer-term goals.

However, the service plans all feature some common benefits, such as ongoing upgrades and bug-fixes, monitoring, etc.

In the early days I made some major pricing mistakes with service plans. I've also learned it's fairly difficult to scope retainer agreements where there is a lot of ambiguity about the end project.

In line with the rest of the business, I've also spent the past year or so constraining service plans to Rails applications (rather than including mobile apps as was the case).

In 2018, a number of service plans came to their natural end. Whilst this may be beneficial from a long term business strategy perspective, there's no denying that losing that regular monthly income was difficult.

I still plan to offer service plans as a core part of the business, although will continue to revise what is offered, and spend more time assessing the value for each plan.

To that end, it may be that Service Plans have an annual review, or are offered as a foundation for other services. I also feel that more vertical specialisation may be required, knowing that this would affect the business as a whole.

Moments of Uncertainty

The previous 12 months have forced me to think about my approach to value pricing, as doubt has started to creep into my mind due to a number of value pricing mistakes I've made.

Rediscovering Value Pricing Benefits

Whenever I've had concerns or doubts about using value pricing, I usually read great articles for inspiration and listen to podcasts and find myself re-discovering its benefits.

I understand that the mistakes are mine and due to my misinterpreting or incorrectly applying value pricing principles. Whilst when I started this journey, I was fairly insistent on applying value pricing to everything.

I've had to accept there are situations where it is not always best-suited.

When In Doubt…

Agency-style work is one such example that I now avoid value pricing. This year I've worked on a couple of agency-style projects.

These projects have been genuinely interesting, and rewarding project. I get to work with great teams on much larger projects than I would normally.

However, it's clear that there is nothing like going back to filling in time sheets and concerning yourself with inputs over outcomes to remind you of the benefits of value pricing!

Onwards

I always intended this experiment to be a journey. Admittedly at the start, I hadn't wanted to accept that there might be areas where value pricing wasn't appropriate - especially as I felt so strongly that time-based billing is bad for everyone.

Three years on, though, I've come to accept that such circumstances can and do occur.

Rather than stubbornly trying to fit everything into a value pricing, I think it may be best to accept these, and instead concentrate on adjusting the business itself such that value pricing is the default.

In 2019, I plan to further tighten up the services that are offered, specialise more, concentrate on products (and productisation).

How was 2018 for your business? Did you try value pricing? Please comment below or get in touch .