Read my book

I wrote books about Webpack and React. Check them out!

Tuesday, October 15, 2013

Sell Value, Not Features

If you haven't been following #NoEstimates discussion, go ahead and read Pawel Brodzinski's post on it. You should also check out Neil Killick's writings on the topic. We had a nice discussion about the topic at Jyväskylä Lean Coffee. The core of the issue is simple - does estimation provide any value? If not, why do it at all?

When to Estimate?

If you are starting a project from scratch and have no previous experience about the domain to base your estimates upon, I believe time spent estimating is more or less waste. Instead you might be better off by getting your hands dirty and prototyping. The more you understand, the better you can estimate.

Generally estimation is used when trying to figure out the size and cost of a project. Unfortunately due to many possible biases, and the fact you might still be missing a lot from your estimate, the cost may not reflect reality. In the worst case you are stuck with a death march that has a fixed cost and have to finish the project no matter what. That is something you definitely want to avoid.

There are a couple of contractual ways. You can for instance state that in case the scope of the project changes too much, you will renegotiate. But even still it feels like there must be a better way. How do you know the features included in the offer are relevant in the first place?

Value, Not Features

What if it was possible to build contracts based on value, not features, delivered? It is true value can be harder to quantify. But even with feature lists the whole purpose is to produce value. The features just enable that. Wouldn't it hence make sense to move focus to value itself then?

In practice this would require a different way to construct a contract. Rather than specifying beforehand that you will deliver this and that feature, you would state that you would focus on providing this and that value. For instance in case of a web development project you could state this in terms of actual usage and user activation. It is possible to measure these things after all.

Mutual Success, Strong Relationships

This focus on metrics gives the project success a concrete definition. And best of all the definition is something that benefits the customer and helps to build trust between the parties rather than alienate them. Of course selling based on value is more difficult.

You will actually have to understand how the business of your client operates and what he values. But it also means that once you get to this stage, the bond between the parties will be much stronger as a result as it's not only about the money anymore. Money is just a side benefit from value created.


I believe estimation still has its time and place. Putting too much emphasis on it in the sales phase may be a big mistake. There are ways to build more meaningful relationships with your clients than relying on feature lists. A happy client is a paying client.