April 2, 2019

Real-world nitty gritty

Sent by Jonathan Stark on April 3rd, 2019

Reader Balint Erdi wrote in with a really juicy question related to a value pricing sales conversation he had recently. It’s kind of long and a little confusing, but that’s exactly why I want to tackle it for you here.

Value pricing in the real-world is more art than science and I hope that by getting into the nitty gritty of actual situations, you’ll start to get a better feel for the reality of it.

Here’s Balint’s entire message:

Hey Jonathan, (Feel free to use the following in your newsletter, if you think it’d make good material.) I’m an Ember.js consultant and I just had a call with a company that has a performance problem with one of their pages. My idea was that within software consulting, performance optimization is one of the areas that lends itself to value-based pricing. I started our discussion with the CTO by proposing that I work with a fixed fee and only get paid if I manage to move the needle in a non-trivial way. I said this much when he asked if I usually work that way, to which I replied that when I’m not doing “classic” feature development work, I strive to do it that way, yes (I couldn’t say I do work that way because I haven’t had any success when I tried this, value-based pricing, in the past). He explained that it wouldn’t possibly be the best fit for this project because he doesn’t want this to be a “one off, hand it over” type of job, but he’d prefer that I work with the team so that they also learn how to do that. He suggested a daily rate. He also mentioned that solely focusing on improving the performance is not a perfect criterion since one could employ methods that achieve this but would result in hard to read & maintain code. I agreed and actually wanted to mention this and have this as a condition in my proposal. We agreed that I’d get access to the code and then I’d make a proposal and go from there. I’m curious to hear what you think about this. (The company is based in Belgium, just to give you some information whether that can be a cultural thing.) Does the gig seem a good fit for value-based pricing? Should I have done something differently? Thank you, Balint

Phew! Okay, got all that? There’s a LOT going on there, right?

Here are the key bits called out with my thoughts inline:

I’m an Ember.js consultant and I just had a call with a company that has a performance problem with one of their pages.

If I was on the call with this prospect, I would find out exactly what business problem the slow page was causing. Knowing that it takes, say 10 seconds for the page to load is not enough info.

So what if it takes 10 seconds to load? Why not just put up it? It is frustrating to their customers? Or to their customer service team? Or to their dev teams?

The value (and perhaps the architecture) of the solution depends on the nature of the specific business problem.

My idea was that within software consulting, performance optimization is one of the areas that lends itself to value-based pricing.

Sure, web performance consulting could certainly be value priced. Just ask Steve Souders ;-)

I started our discussion with the CTO by proposing that I work with a fixed fee and only get paid if I manage to move the needle in a non-trivial way.

This is called contingency pricing, which I’ve never done personally but am comfortable with philosophically as long as you agree to the price up-front. Not agreeing to the price up-front and instead saying something like, “Let’s see how much I can improve the speed and then I’ll tell you how much you owe me,” is not a comfortable situation for a buyer. Like hourly billing, this would force the buyer to make a purchasing decision without knowing the final price. Buyers don’t like this.

I said this much when he asked if I usually work that way, to which I replied that when I’m not doing “classic” feature development work, I strive to do it that way, yes (I couldn’t say I do work that way because I haven’t had any success when I tried this, value-based pricing, in the past).

I applaud Balint’s truthful response, but I suspect it transmitted uncertainty to the buyer. What do you mean “you strive to do it?”

Maybe the next time, go fully transparent and say, “No, this would be the first time,” and have a conversation from there.

The client would probably ask a follow-up question like, “Well… why are you changing from the old way?” at which point you could say, “When I have done work like this in the past on a time and materials basis, I find that it leads to scope creep and blown budgets. I’d rather give you a fixed price and stand behind it. Will that be acceptable?”

He explained that it wouldn’t possibly be the best fit for this project because he doesn’t want this to be a ”one off, hand it over” type of job, but he’d prefer that I work with the team so that they also learn how to do that.

This is very interesting and I would have drilled into it quite a bit. My sense is that this desire to have Balint “work with the team” would be a good way to add a couple options to the proposal.

For example, there could be opportunities for video documentation, group training, ongoing project oversight, periodic code review, developer coaching, etc. To find out, I would have asked questions like:

He also mentioned that solely focusing on improving the performance is not a perfect criterion since one could employ methods that achieve this but would result in hard to read & maintain code. I agreed and actually wanted to mention this and have this as a condition in my proposal.

And here we get to the heart of the matter as to why the buyer is leaning toward a time and material model (i.e., he suggested a daily rate) and away from a fixed price.

Here’s what’s going on…

One of the issues with fixed prices is that they can create a fear of “corner cutting” in the prospect’s mind. The client worries that the provider might focusing on reaching the stated goal through any means possible, regardless of the negative overall impact.

A service provider could cut corners on the way to acheiving a stated goal in all sorts of ways. Here are three:

For example, if you locked your keys in the car and called a locksmith, you would not be happy if he got you back into your car by smashing the windshield with a hammer. That would be an unacceptable shortcut.

This is why guarantees are important when giving fixed prices. Balint’s contact appears to be reacting to this “corner cutting” fear in a very specific way. Namely, he is afraid that Balint might be incentivized to reach the performance goal by cranking out a bunch of brittle, poorly tested, throwaway code. Balint could have offered a few different types of guarantees that would have addressed his buyer’s concern, enhanced the perceived value, and projected confidence.

We agreed that I’d get access to the code and then I’d make a proposal and go from there.

It’s a good sign that the client trusts Balint enough to share their code with him without an agreement in place, but personally I wouldn’t accept the responsibility until they were officially a client. There’s no good reason to get access to (or even view) someone’s code before they are a client.

Does the gig seem a good fit for value-based pricing? Should I have done something differently?

This project might be a good fit for value pricing but I don’t have enough information to form a credible opinion. I would need to know:

That’s enough for today I think. Sorry for the long email! Hopefully it was worth your time to read. Thanks again to Balint for sharing!

Yours,

—J

BackRandomNext