Part 1 of Our Unique Guide to Setting Effective Value-Based Prices

Why You Should Ship Early and in Chunks

Takes 10 minutes to read. Too busy right now? Save it and read it later!

By delivering work in shippable chunks, using value-based prices becomes easier and you also create more value for clients by reducing risk.

To many, setting a value-based price seems daunting, even impossible. This three-part guide is intended to demystify the art of determining value-based prices and presenting them. Part one: Why you should price your work in chunks.

The basic idea of value-based pricing is that clients pay for the value, not the production cost, of what they receive. We’ve covered value-pricing from multiple angles already on this blog (scroll to the end of this article for a list). But we haven’t really dug into the issue of how you set a value-based price. That’s what this guide intends to answer.

This is the first post in a series about setting value-based prices. In this first article, I’ll discuss why you should break down large projects into installments and price them individually. We’ll also look at ways of doing that.

The next posts in this series will cover ways to price these installments based on what your client considers valuable. I’ll also discuss the factors that influence your buyer’s sense of value.

Finally, we’ll wrap it up by showing ways to present these prices to the client in a way reduces buying friction.

The Challenge of Setting Value-Based Prices: They Don’t Depend on Quantifiable Information

I decided to write this series since the challenge of setting a value-based price seems to be what holds many back from adopting value-based pricing in earnest. Especially those who have so far used hourly billing and its one winning feature: the ease of calculating a price.

This ease of counting hours is for many seen as a form of fairness. Hours are conveniently quantifiable. Not only that, but everyone can also agree on what an hour is, ergo everyone has the same idea of its value. The conclusion that many draw is that hourly billing is somehow inherently fair.

Problem is, it’s not true, which I’ve demonstrated in previous articles on this blog, such as this one on ways to implement value-based pricing.

Unlike hourly billing, value-based pricing is usually not easily quantifiable. There’s often no way to measure the “amount of value” and put a value-based price tag on it when it comes to professional services.

Value Points and Point Pricing as a Form of Value-Based Prices

Agencies that use "point pricing" offer clients a menu of services with value-based prices in points.
Agencies that use “point pricing” offer clients a menu of services with value-based prices in points.

But there are exceptions. Some agencies have in fact tried quantifying value by replacing hours by (value) “points.” Using this model, they offer clients a menu with items with value-based prices in points. It’s become known as “point pricing.” In a digital marketing context, it could be something like “short blog post: 7 points, interview: 9 points, Twitter update: 1 point” and so on.

The idea being that the value-based price should reflect the value provided, not the effort spent (hours). The neat thing about it is that the agency can price each point differently for different clients. In value-based pricing, this is called “pricing the client.” Agencies can also customize the menu for each client, further tweaking it to the client’s willingness to pay. It seems to have worked for some agencies.

For a large scalable business (such as a major content marketing agency) that delivers similar services to all of its clients, point pricing is an attractive option. It offers a nice degree of consistency. Point prices can be set by senior account managers and it’s easy to train even junior team members in applying the menu. They don’t need to understand or care about the intricacies of pricing to give a client a value-based price.

But agency and freelancer services are usually more bespoke. They’re not small standardized deliverables, but more often larger projects that can take months to complete. Value-based pricing for projects is far harder to quantify than assigning points to a services menu “à la carte.”

That’s why I argue that value points aren’t always an alternative to the billable hour.

A Case for Chunks and Fixed Value-Based Prices

For customized and unique projects, the best way to set a value-based price is to deliver work in chunks.
For customized and unique projects, the best way to set a value-based price is to deliver work in chunks.

One of the main issues with a point-priced services menu is that it works for well-defined items, such as deliverables as part of a digital marketing strategy, but not really for multiple-stage projects.

Imagine sitting down with the client and debating the point price of each sprint. Each feature built having a value in points assigned. I believe it can be done. I have entertained the idea of using points to price agile sprints. But I think it makes it more complicated than it has to be. It also requires that everyone who interacts with clients at your agency and does this kind of planning understands pricing.

There’s an easier way.

Break down large projects into manageable chunks which are then priced based on value. Each chunk is shippable and can stand on its own and deliver value.

I know this might sound impossible for some projects. And yes, it probably is for rare monolithic projects that require months of initial work. My counterargument to that is that agencies and freelancers shouldn’t do that kind of critical marathon work. At least not on a project basis.

If you must do that kind of work, I strongly recommend you try to partner with your client. A value-based partnership is certainly possible but falls outside the scope of this article. If this is something you’d like to hear more about, please write a comment below.

Breaking down large projects into shippable chunks doesn’t only make value-based pricing possible, it also brings a plethora of other benefits.

The Winding Road: Knowing What You Don’t Know and Accepting It

In software development, the horizon is close. In other words, we can’t see very far down the proverbial road before we have to start guessing. We can usually predict issues that might arise in the next few days. Beyond that, it’s challenging to predict and difficult to even speculate.

To illustrate, I made this animation. It shows how a major monolithic project that seems optimistically manageable at first turns out not to be that at all.

Software projects rarely go according to plan, as illustrated by this animation.

Complications are revealed as the team makes progress along the project’s meandering and winding road. The “fog of uncertainty” lifts gradually. The project progresses from the Optimist’s Horizon to the Self-Delusional Horizon onto the Eat-My-Hat Horizon to the final and terminal Here-Be-Dragons Horizon.

Does this seem familiar to you?

I know this problem well. Years ago I traveled to conferences across the world to talk about estimating web development projects. The spreadsheet-based method I proposed helps agencies and freelancers estimate the time it takes to build a website or an app. It’s accurate enough to be useful for planning provided the agency has some experience and knows the platform they use.

Side note: I stand by much of what I said almost a decade ago, except when it comes to pricing. I wrote an article about my reflections over the years since.

The Cone of Uncertainty Shows Why Estimation Is So Insanely Hard

What is clear to anyone who’s tried estimating large projects early is that the errors increase by multiples the earlier you attempt to make an estimate.

In software estimation and project management, we talk about “the cone of uncertainty.” The cone illustrates the fact that the further your from actually building the software, the higher the risk your estimate is dead wrong. Reversely, the closer you are to finishing the project, the narrower the cone becomes, and the more accurate your estimates are.

Here is an example based on data from thousands of software projects. This graph is based on an example in the book Agile Estimating and Planning (paid link) by Mike Cohn:

The cone of uncertainty illustrates the fact that the further your from actually building the software, the higher the risk your estimate is dead wrong.
The cone of uncertainty illustrates the fact that the further your from actually building the software, the higher the risk your estimate is dead wrong.

Lesson: To reduce estimation error, avoid making guesses about the remote future. Instead, focus on the here and now and work with what you, for a fact, know.

Loose Coupling Reduces Risky Dependencies and Enables Shipping of Chunks

Monolithic software presents many risks by virtue of being monoliths. That’s why software engineers strive for something called “loose coupling.” It roughly means making components as independent of each as possible. Loose coupling makes it possible to separate components and use and test them on their own.

Smart Businesses Actively Avoid Big Risky Bets

Big bets can be entertaining if you can afford to lose them.
Big bets can be entertaining if you can afford to lose them.

Beyond technical risks, big bets are dangerous in themselves. Businesses try to avoid big bets whenever possible. A big bet brings big risk and very few bets promise the return to make that risk worth it. Companies abhor risky bets, why you can insure almost anything today. It’s clear why: avoiding big bets just makes complete sense from a business perspective.

By Breaking Work Down into Shippable Chunks, You Help Your Client Think Like a Startup

It’s not just big companies that want to avoid risk, small vulnerable startups do too. Instead of hedging all their savings and raised capital on a moonshot idea and go for “build it and they will come,” startups use MVPs. So-called “minimum viable products” allow a business to test an assumption with as little risk exposure as possible. The assumption is usually that a certain group of people are willing to pay for a product to solve a problem for them.

The same thinking applies to your clients. As a consultant, part of your job is helping your clients avoid risk. If a project seems like a big bet, suggest alternative and less risky ways to achieve the same result.

Clients appreciate agencies and consultants that point out such problems. They will want to hear your feedback on their strategy. You know things they do not. There might be technologies, products or methods that they are not aware of. Using these, you might be able to build something cheap and simple that reduces a big bet to a small bet.

Chunks Make Apples

As a seller of services, the last thing you want is being grouped together with every other agency or freelancer that provides a service similar to yours. That’s exactly what happens when you sell hours. They’re commodities and create the illusion of being comparable. The only differentiating quality they do have is price, which results in a race to the bottom. That’s not in your interest.

What you do want is being hard to compare. By selling services in chunks, comparing you with another company becomes very difficult. To make a comparison, the buyer has to get a similar quote from another agency or freelancer and then compare them word-by-word. This means you’re in control of the message and can play on your strengths.

Suddenly, it’s clear to the buyer that one company sells apples and the other pears.

Discussing Results Early Positions You As Someone With Strategic Insights

Helping your clients work on strategy is a great way to be perceived as someone with rare and valuable insights.
Helping your clients work on strategy is a great way to be perceived as someone with rare and valuable insights.

Starting conversations about risks, bets and return will shape how the client views you. This is a form of early value creation and it positions you as a person or company with valuable advice. That makes your client less price-sensitive and you’ll be able to command higher value-based prices over time.

Not only do these conversations show skills the client may not have expected, but they also demonstrate a not so common attitude. Specifically, the drive to achieve results early. As long as you’re not skipping ahead and taking unnecessary risks to get there, result-focus is almost universally desired by clients.

The Challenge of Using Value-Based Prices for Year-Long Projects

You may object that this won’t work. Perhaps you’re saying that clients will want to know the total price of the project. That is often the case in an RFP (request for proposal) process. I’m not too keen on RFPs generally speaking and the advice I’ve given earlier about RFPs applies here as well.

I’ll let you in on a secret: Clients never could, and they never can get a true total price estimate no matter who does the estimation.

Even if you spent weeks using software estimation applications (yes they do exist) and compiled reams of data on team velocities and risk analyses, your answer would be a guess. A very well-founded guess, but still a guess. Estimation is a modern crystal ball and just as limited. You cannot predict the future. I think it’s better to accept that fact than to pretend you can and paint yourself into a corner.

If the client pressures you for an answer, there’s a way to handle that. It involves understanding the value of the project and I’ll return to it in later posts in this series. In the meantime, I recommend checking out the article about how to handle RFPs.

It’s Simply Agile

If none of this seems particularly controversial it’s because it isn’t. Much of this is an already established practice and goes under the title “agile.” My real contribution is the suggestion to take the ideas of agile software development and combine them with value-based pricing to create better and fairer software projects.

Using Value-Based Prices for the Foreseeable and Controllable Future

Trying to guess the future isn't a great way to approach value-based pricing, that is unless you have a time machine like Marty McFly. Instead, value-price what you do know – what's right in front of you.
Trying to guess the future isn’t a great way to approach value-based pricing, that is unless you have a time machine like Marty McFly. Instead, value-price what you do know – what’s right in front of you.

As we can see, delivering work in fixed value-based price installments or chunks reduces many of the challenges of pricing software projects. You can offer a fixed value-based price for the next installment since you know and can control many of the variables. Costs can also be estimated with decent accuracy since they’re happening now or soon, not in the remote future.

Conclusion: By Delivering Shippable and Workable Things Earlier You Can More Easily Set a Value-Based Price

By breaking down projects into shippable chunks which are only specified in detail until it’s absolutely necessary, risk can be radically reduced. That in itself is valuable.

Since chunks will be completed soon, rather than in the distant future, chunks can also be accurately estimated in terms of production cost. Value-based fixed prices can be set with confidence. Once a chunk is shipped, the next one can be similarly scoped and priced. Meanwhile, the customer sees immediate return which further motivates your value-based prices.

Read the Next Part


Want to Learn More About Value-Based Prices and Pricing?

These are some of our previous articles about value-based pricing:


Author: Jakob Persson

Jakob is the founder and CEO of Zingsight, the company behind Bondsai. He's been involved with the web for over twenty years and has previously co-founded and grown a web agency from 4 to 70 people. Jakob holds degrees in media technology and cognitive science. He consults in product design and management, and business development. Jakob is an experienced skier and a learning scuba diver.