A few days ago, I got an email from a new student of the January Masterclass. He’s been talking with a prospective client and after applying a lot of what we covered in some private coaching sessions, he was able to figure out that this client stands to make at least $100k a year after this project goes live.

So, understandably, he was trying to figure out what he could charge the client. However, I think my answer might have surprised him, and might even surprise you.

I don’t think that value-based pricing means figuring out the potential financial upside for the client and working backwards from there. Determining the upside isn’t about setting the project budget as much as it is justifying it.

Allow me to explain:

It’s easy to think that if you want to price according to value you need to come up with the amount of value you’re delivering for a client, subtract a few dollars, and — voila! — you have a project budget.

You might reason: “This client will probably make $50k if I do X, Y and Z for them. Ergo, I’ll charge them $40k.” But this lends itself to putting a price tag of $40k on X, Y and Z… which I’m generally not a fan of this unless X, Y and Z are very well defined and there’s little risk that other requirements might creep in.

If you’re like me, you tend to work on big projects with variable scope, and getting to a solution will likely evolve over time… So you can’t lock both the price and the scope of the project. But you still want to price based on the value you’ll produce, because the alternative is a race-to-the-bottom commodity rate.

So rather than having your client’s potential financial upside set your budget and set the scope, instead you’ll use this info to justify your rate, which should be measurably north of whatever “market rate” is standard for your occupation.

You’ve probably heard of Patrick McKenzie before — and if you joined the Recurring Revenue for Consultants Bootcamp, you’ve met him. As a consultant, his rates were upward of $30,000 a week. Technically, he did a little SEO, copywriting and Ruby work for his clients — but $750 an hour is a bit more than the average SEO, copywriter, or Ruby developer, right?

Patrick used the value he routinely produced to justify his rate. He isn’t some whiz-bang Ruby core contributor or “rockstar”, but he’s extremely savvy when it comes to figuring out the amount of value he brings to his clients businesses, and puts that — and not lines of code or “best practices” or whatever else — at the forefront of his proposals.

Here’s the system we dive into in my class, which I’ll cover ever-so-briefly here:

• Figure out the key performance indicators, or KPIs, that matter most to your clients. Often this relate to revenue. Examples include e-commerce conversion rates, lead form submissions, or trial signups.
• Come up with some realistic KPI projections based on a successful completion of the project on the table. If you can put together a smart marketing and goal tracking strategy that could provide a lift in website conversions, what might that be worth to the client?
• Propose an engagement, and anchor the estimated time multiplied by your hourly/daily/weekly rate by that potential upside. This makes you less likely to be reduced to a commodity — “Why should I pay you $200 an hour when this other developer only wants $20 an hour?”

I know quite a few people who have successfully made the jump from providing just code, design, or copy to focusing on making businesses better off, and many of them brought in over six-figures in additional revenue last year.