How the Hell Do You Formulate Value Properly

If you can’t be bothered to read, too many words, then here’s a short cheat sheet right away

Today we had another traction meeting and once again we talked about the eternal topic: how to formulate value instead of pretending to. I’ve discussed this so many times that I decided to write an article so I could just link to it. Here it is.

I’ll start with two examples. For one and the same company. One lousy, the second quite workable.

The first: “Our system automates processes and cuts costs. A single window for all operations, a convenient interface, all the reports in one place.”

The second: “Forty percent of your goods spoil in transit. The drivers can’t monitor the temperature in the refrigerated trucks — the sensors run on different protocols, the data doesn’t match up. We’ll build a single monitoring system. Spoilage will drop to five percent, saving two million a month.”

Feel the difference? In the first case we’re talking about our wonderful product. In the second — about what specifically hurts for the client and how we take that pain away.

Usually it looks like the first example. A person comes in and says: “Our profit is low.” Or: “Our costs are high.” That’s the same as saying “the weather is bad.” What specifically? “The trucks sit idle for four hours at loading” — now that’s a problem.

Next you have to find out why things are still bad. Have they not tried to make them good? What’s getting in the way? What’s the constraint? Not just “the system is bad.” But a specific technical dead end that makes it impossible to remove the barrier. For example, the data is stored in three different systems and they aren’t compatible with each other. Each one is written in its own programming language. One is as ancient as a mammoth. The second is homegrown and its author quit long ago. The third is in Excel, period.

After that you can talk about a solution. Not just “we’ll implement a new system” — that’s like telling a sick person “be well.” But specifically: how exactly we remove the constraint, take away the barrier, solve the problem.

There was a case in our old office:

Our labour productivity dropped (that’s the problem). Why? Because the coffee ran out. It froze in the cups (that’s the barrier). Why did it freeze? Because the housing office in whose building we sat had embezzled the budget and hadn’t paid for heating, so the heat was cut off (that’s the technical reason the barrier exists), so we packed our things and urgently moved to a new office (and that’s already the solution). The coffee got hot again and work got back on track.

All right, let me give a non-anecdotal example.

There’s a trucking company. Problem — the trucks sit idle. Barrier — the dispatchers and the warehouse staff work off different documents. Technical constraint — the accounting systems are incompatible. Solution — a single routing system. And the value — less downtime, more deliveries.

Or here’s another one, an online store. Problem — people abandon their carts. Barrier — placing an order takes seventeen clicks. Technical constraint — the code is so tangled that if you touch it, everything collapses. Solution — an external cart service, with an SLA on the abandonment rate. Value — more orders actually paid for.

And now, let’s go through it again, how to do this

• Step 1. The problem. We answer the question: what’s bad in the business? What specific thing is our budget owner spending all his time on, because damn, it’s a disaster! And don’t give me “low profit” here. Specifically — what’s happening? Trucks standing still? Goods spoiling? Customers leaving?
• Step 2. The barrier. Why hasn’t this crap been cleared away yet? I mean, why does the problem still exist? Do they like it when things hurt? Or did they never even try? Then is it really a problem? If they did try — what got in the way? Not “there’s no system” — but what specifically stops people from doing their job properly?
• Step 3. The constraint. Right, and now the most interesting part — why can’t they remove the barrier? What exactly in the systems, the processes, the technology prevents it? What specifically is broken? Which screw won’t turn?
• Step 4. The solution. We look at the constraint and think — how do we remove it? What specifically do we change in the system? And most importantly — why was it impossible to do this before and possible now?
• Step 5. The value. And now the main thing — what does the business get? And again — no “improved efficiency.” How much money exactly will we save? How much faster will it work? How many customers will we not lose?

A couple of examples

The first:

• Problem: “>40% of the goods spoil in transit because of an incorrect temperature regime”
• Barrier: “The drivers can’t track the temperature in the refrigerated trucks while under way”
• Technical constraint: “The temperature sensors and the monitoring system run on different protocols, the data doesn’t sync”

The second:

• Problem: “Every third customer leaves after the first purchase”
• Barrier: “The managers don’t know when and why a customer is unhappy”
• Technical constraint: “The interaction history is stored in three different systems, and it can only be assembled by hand”

Five typical mistakes when analysing problems

Now let’s take apart how people usually screw this scheme up.

• Mistake one: They describe the barrier as the absence of a solution. For instance, instead of saying “the client has a problem — there’s no task management system,” it’s worth figuring out: “What specifically is happening?” It turns out people don’t understand each other, tasks get lost, deadlines burn. That’s the barrier. And “there’s no system” isn’t a barrier at all, it just means you have a task tracker you want to flog.
• Mistake two: In the constraint they tell the medical history instead of the diagnosis. There’s no need to explain how you ended up with three incompatible systems. Explain why right now you can’t just take them and make them get along.
• Mistake three: They confuse the barrier with the constraint. Look:

Barrier: “Lack of coordination between departments”

Constraint: “The departments don’t sync their processes.” That’s the same thing! Whereas here’s the real constraint: “Each department sits on its own accounting system, and those systems don’t get along with each other”

• Mistake four: In the solution they don’t explain why it will work precisely now. “We’re implementing a new system” — okay, and what stopped you before? Did new technologies appear? Can the old systems finally be replaced? Explain what changed.
• Mistake five: They describe the value as “an increase in efficiency.” Let’s be more specific: Units of trucks. Percentages of spoilage. Roubles. What exactly will improve? Will we save money, free up the time of the critically important nodes of the system? How much faster will shipping become, by how much will sales grow? No, at the hypothesis stage you’ll of course get the values of the variables wrong. The numbers will turn out nothing like the real ones. But we’ll refine their values later, and for now we’ll just sharpen the wording so that it’s absolutely clear whether we delivered the value or not.

In other words: a well-formulated value tells you how people’s behaviour will change, and it contains a criterion of refutation. That is, there’s no doubt whether it was delivered or not.

What this can look like

I was just about to publish the article, but decided to show it to Tyoma Kharitonov. And he says:

“Nice framework. But you’ve missed an important thing. Value often grows not out of a rational constraint. Here are three cases from practice. The first — income-loss insurance for people with mortgages. Try selling it through a calculation of the real risks? Doesn’t work. A person fundamentally doesn’t want to think about the fact that he might lose his job. The second — lead generation with pre-qualification in real estate. The marketer wants his ass covered by numbers. And the head of sales refuses even with extra pay — because the system will make his work transparent. The third — teaching children. Nothing rational works there at all. Nothing.”

Tyoma is right, of course. People have emotions. Even in B2B. Especially in B2B. People make decisions not because it’s profitable for the business. Well okay, not only because of that. But because they want to feel calmer. More confident. More successful. They want control over the situation. Growth. And this motivation may have nothing whatsoever to do with the objective indicators of the business.

This means that a constraint can be not only technical but psychological.

But you still have to formulate it just as precisely. Not “the customers are afraid,” but “the offer triggers in the customer a fear of losing his job.” Not “the head of sales is resisting,” but “implementing the system will make the department’s quality of work transparent, which threatens the manager’s position.”

So here’s one more example, with a psychological barrier, from Tyoma:

What’s interesting about this case: the subscription really was a good deal, but people weren’t buying. The constraint turned out to be not technical — not in the services or the interface — but psychological: in the fear of overpaying for something they didn’t need.

They started forming segments by emotional needs. Each one got its own simple set of services with a story you could understand:

• “I’m insanely busy and have no time for anything” → a taxi so you can work from the car, plus a scooter
• “I’m really good at counting and you won’t fool me with your subscriptions” → free delivery from the megamarket, the subscription pays for itself in two months
• “I want to put on good Soviet cartoons and songs for my grandchildren” → Soyuzmultfilm on Okko and Young Pioneer songs on Zvuk

Later it turned out that “busy” actually meant “lazy,” and that instead of Soviet cartoons the grandmothers put on Smeshariki for their grandchildren. But that doesn’t matter anymore — what matters is that the person assigned himself to a segment and bought the subscription. Because the constraint wasn’t in the services, but in how the person sees himself, and therefore the solution lay in the realm of psychology too.

P.S.

In reality everything is more complicated. Everyone in the company has their own pain. The CEO looks at the numbers and sees “low profitability of the vehicle fleet.” The head of logistics sees “delays in shipments because of incorrect routing.” The operations clerk sees “confusion in the paperwork.” And each of them is right, because each sees his own part of the elephant.

If you don’t work out whose pain matters more for making the decision, you’ll solve a particular problem instead of the main one. Which means that a) you’ll be paid less and b) they’ll pay reluctantly.

But that doesn’t mean you have to choose. Just run the problem of each decision-maker through our framework. Often you’ll discover a funny thing: the problems look different, but the barriers are similar. And even more often — different barriers have one and the same constraint.

Old man Goldratt used to say that in every system there’s one bottleneck that all the trouble comes from. Find it, remove it — and all the problems come tumbling down at once like dominoes. Because that constraint is the root of the evil; the barriers grow out of it, and the problems grow out of the barriers. Solve it precisely and you get an avalanche of improvements.

To find it you need one more tool — the Theory of Constraints. But that’s a whole other story.