Customer Login

Value-Price, or Value-Anchor?


Value-based pricing is all the rage. “Ditch hourly!” and “Sell on value!” are stock responses on just about any Q&A thread on freelancer pricing — and these are themes I’ve written about here for the last 3 years.

But longtime students of mine are quick to point out that I don’t personally always value-price my consulting. In my pricing course, I encourage many freelancers not to practice value-based pricing.

What’s the deal, Brennan?

The other day, there was a thread in the Double Your Freelancing Clients community that centered around this confusion. I briefly commented in the thread with my position, but promised that I’d write a lengthier response here on DoubleYourFreelancing. Well, this article is that.

Why should you figure out the value of your projects?

At the root of any advice on value-based pricing is the idea that a project has value that goes beyond the technical.

Let’s say I hypothetically resurrected the very first website I ever built: a hobbyist Nintendo blog I hosted on Geocities back when the web was young and link exchanges were still a thing. By all accounts, that was a perfectly fine (though aesthetically dated) website. It had pages (which were HTML documents), and these pages were styled.

My current website is a bit more advanced, and leagues more valuable. DoubleYourFreelancing.com accounts for tens of thousands of dollars a month in revenue for me — which is tens of thousands of more a month in revenue than my Nintendo site ever paid.

Both websites play a different role in my life and my business. One is more valuable than the other.

Unfortunately, the bulk of us still charge based on the market worth of whatever the “thing” is we happen to do. We ignore the value (that is, the effect a project has on a business) when determining a price.

And it’s no secret that those of us who are charging five figures or more for a week of work aren’t in the business of selling websites (or applications, or blog posts, or whatever else). We’re in the business of making companies better off by delivering results that increase the value of a business.

Now, the simple truth of the matter is that even the worst freelancer is tangentially aware of this fact. Clients aren’t typically out there to spend lots of money on commissioning code, designs, and words that serve no purpose. But our pitches and proposals don’t often reflect why the client needs us, and what that will ultimately do for them. We end up focusing on the technical deliverables, and pricing them against whatever “the market” thinks they’re worth (which is typically loosely tied to employment salaries and such).

So now that we’ve defined in a nutshell why you should try to understand the value behind a project, let’s switch gears and see how that can be used when selling:

The difference between value-pricing and value-anchoring

When most people talk about value-based pricing, what they’re saying is that the price you quote a client should reflect the value of a project.

That is, your cost should be somewhere between $1 and $VALUE_OF_PROJECT, preferably somewhere toward the higher extreme.

What this does is it makes the decision to buy a lot easier for the client. After all, who wouldn’t want to spend $50 to get $100? When you’re arbitrarily choosing a price or quoting some number of hours multiplied by your hourly rate, you’re leaving it up to the client to determine whether you’re at or under the payoff of the project.

And, like many freelancers, the client doesn’t always know what this payoff is, or whether a payoff is even achievable in the first place. They often just have some fuzzy feeling that “a new website” might end up doing something good for their business. (It’s up to you as a freelance consultant to help them determine actually what this good is and what it means.)

Value-based pricing is a strategy that allows you to make selling easier by presenting yourself as a multiplier in the business of your clients, rather than an expense.

Done properly, it also has the added benefit of helping you focus on doing the right work for your clients — that is, work that directly affects the degree of the value being delivered, rather than requirements that are “cool” or the result of your client waking up that morning with a grand idea. Focusing on value helps you focus on the right set of deliverables.

But my biggest issue with value-based pricing is that, at the end of the day, it’s still fixed-fee pricing. You’re charging a flat rate for some deliverable.

And while this works great for many projects (as I’ll highlight in a second), it’s not always the best way to work — no matter your profit margins. Many of us, especially those who work on highly custom engagements like websites or web applications, know firsthand the problems that can come with all-you-can-eat pricing.

A practice that I’m fond of, and the style I personally use when pricing my non-productized consulting engagements, is to anchor my weekly rate against the value of a project. I call this value-based anchoring.

When anchoring, you’re still psychologically achieving the same end as traditional value-based pricing (by presenting yourself as an investment), but you’re not committing yourself to a fixed fee. You’ll still present your time and material rate (e.g., “I anticipate this option taking 4 weeks, which at my weekly rate of $20,000 would cost $80,000”), but by the time they see that $80,000 price point they’ve already learned about how you plan on making them hundreds of thousands of dollars. (Obviously, your pricing and project values will depend on what it is you do and for whom.)

proposal_excerpt

(an excerpt from a recent proposal of mine)

There are some instances where having a fixed price / fixed scope engagement aren’t always best for your clients. Many projects aren’t well defined at their onset, and are liable to change direction. Rather than going through the amendment song-and-dance whenever that needs to happen, it’s often advantageous for your clients to pay you for your time.

In the rest of this article, I’ll do my best to help you understand when you should value-price, and when you should value-anchor.

When to use value-based pricing

  1. You’re selling a productized service, which by definition is a fixed engagement.
  2. The scope of the project is limited and small. The likelihood that the client will “go out of bounds” is sufficiently small, and your margins (especially now that you’re pricing on value) make it unlikely that the project won’t be profitable.
  3. You’re solving a problem that you’re very familiar with. One advantage to niching is that you can gain a lot of experience in solving one specific problem for a certain type of client, which will help you be much more confident when estimating.
  4. You’ve already sold a roadmapping session. The roadmapping session, which I describe in detail in Double Your Freelancing Rate, is a paid product designed to help you learn as much as you can about a project and what it’s about. The more details you have about a project, the better your estimate. But when you’re not charging for your estimates, you’re probably not putting a ton of time into them, which increases the likelihood that your client and you aren’t on the same wavelength.

When to use value-based anchoring

  1. You’re selling something that’s likely to change once your client gets their hands on it, like a website or application.
  2. It’s best for your client to not fix their scope. Many projects should change midway through. It’s healthy to change course as business needs shift, and these needs can start to shift pretty dramatically once you and your clients are thinking daily about their projects. Since my job is to ultimately protect the client, I want to get them to their end goal the best way possible — this might mean faster or via shortcuts, and it could mean spending more time than anticipated on a particular problem.
  3. Results are more dubious. Sometimes, you can’t really assess the true value of a project for a client. In my mind, value-based pricing lends itself to “pay $X, get $Y.” In some cases, $Y is an unknown. In these instances, I think it’s best to still charge for your time (again, by the week), but to price anchor using a range or best guess when laying out your offer in the early stages of your proposal.

Charging for your time still presents budget risks for your client. There is always the chance that my 4 week project at $20,000 a week will actually take 5 weeks, which would incur a 25% budget increase for the client!

But as freelance consultants, our job is to first and foremost protect our clients. This includes protecting them from going over budget. While that risk is always present, it’s my job to not allow that to needlessly happen (there are plenty of instances where spending 25% more is worth it to the client).

 

I hope this helped clear up any confusion you had about value-based pricing, and gave you a little more insight into why I personally don’t value-price my typical consulting engagements (though I do value-price my productized offerings). If you have any comments or questions, I’d be happy to respond in the comments below.

  • hgdybecker

    You mention anchoring with a weekly rate. What about anchoring with a monthly rate? I do conversion optimisation and a week is usually not enough additional time to get real results (depending on the amount traffic and conversions and whatnot), but a month usually is.

  • Ted Johnson

    Why is charging a weekly or monthly rate superior to a basic hourly rate? Isn’t a weekly rate just a figure calculated by X hours per week = Y weekly rate? Won’t a smart customer ask “Ok your weekly rate is $1000, how many hours are you going to work?”.

    Do you have a blog post or podcast someplace that addresses why hourly is something to be avoided?

  • Excellent post and explained thoroughly. I’ve been caught in scope creep many times on an fixed project and then we have to go back and explain why the fixed price needs adjusting. Many times when proposing a solution to a new client , I want to get the order and I find adding additional fees creates additional hurdles to the decision.
    I leave out the chance of an overage, but end up with a fight later if it does.

    Would you add in upfront and lose the chance of getting a new client or get the client and then communicate clearly when something is beyond scope?

    • Yes, I’ve found that a lot of people just want the sale, and end up with a pissed off client at the 11th hour who hasn’t received what they thought they’d receive because… the sales and onboarding process was sloppy. The freelancer just wanted to get them to sign and pay. It’s important to set the right expectations, and to host ongoing budget/scope meetings throughout the engagement. Don’t leave anything up for assumption.

      • Woah my comment didn’t come across right, clients still get what they were quoted. Not talking empty promises to get an order. Genuine scope creep.
        I agree budget/scope meetings can be improved. Thanks for your info, looking forward to your lead gen course when open

        • Ah, gotcha. Sorry about the confusion… and DYFC opened and closed over a month ago – next won’t be until 2016 🙁

          Scope creep is usually the result of one of two things:

          1. The “right” project is legitimately larger in scope than initially estimated. It’s in the best interest of the client to add more. Rather than just gladly accepting new requirements, it’s important to remind them that this new feature WILL take more budget, which means budget earmarked for other features won’t be there. (FWIW, this is why I built Planscope – to make this a non-issue)
          2. Client wants to add for the sake of “great ideas” or whatever. Here I try to jump in and make sure any new scope passes the “will this get us closer to our goal of doing X”, where X is whatever business problem they’re out to solve. If true, the point above kicks in and the client needs to figure out what to cut / how to expand their budget. If false, then I really try to push back. My job is to be a good steward of my client’s budget.

          • Thanks Brennan. Pity about the course. I think I could really learn something…
            Keep up the good work!

  • Thanks Brennan, spot on as always! The book The Agile Samurai talks about the Furious Four, Time, Budget, Quality, and Scope. The first three are almost always fixed so I spend a tremendous amount of time with a potential customer helping them understand how much is yet unknown about their app and how flexibility on scope is a benefit to them and us. Usually once we start delivering versions of the app and they start interacting with it and sharing it with customers fixed scope docs loose their luster and become guidelines. Real usage and learning trump plans. Something else that typically happens is that budget figures are forgotten as the value of the product comes into focus for the client, they no longer worry about arbitrary budget numbers set up before anyone really knew what the project would become. The challenge for us is that we never know when the project will end so it’s hard to have something lined up and ready to roll when the project is finally complete.

  • ledestin

    Excellent writeup. Now I know how to argue that rate is better than fixed price! Also, going to read about weekly rate.

  • Great points, Brennan.

  • Mauro Chojrin

    It’s a very interesting point. I also had that confusion when I finished reading your email course. So far, the clients I’ve been dealing with will always prefer to know in advance how much the project will cost. I never had the chance to explain the alternatives yet but I kind of read their faces when we discussed fees. I believe it’s easier for the buyer’s mind to know what they’re getting into before diving in (Even if it’s more expensive looking backwards)

X
- Enter Your Location -
- or -