In CustDev, there is a thing called the "feature-value gap".

This is when we seem to be talking about value, but in reality, we slide into a list of feature wishes.

And then the team builds another 7 buttons. But the money doesn't increase.

For example,

During an interview, the client says:
"We need integration with X"

And you record that as value.

Although the value could be completely different. Say,

"...so that data doesn't have to be moved manually between systems, because we often make mistakes and lose money because of it."


Your product is just one of the possible ways to deliver value.

(sometimes not the best)

The feature-value gap can arise for several reasons:

1. Clients generally think in terms of features

Because it's easier to say.

For value, you need to recall cases, calculate time/risks, admit the problem.

But naming a feature is easy: "It would be cool if I could do this."


2. We provoke it ourselves with our questions

"What features do you need?"
"What is missing in the product?"

Such phrasing almost guarantees a backlog of wishes, not value.


3. Clients confuse "convenient" with "important"

Someone might genuinely want a beautiful dashboard. Because it's pleasant.

But they will pay for something that reduces risk, adds money, saves time, helps with compliance, etc.


4. We don't consider different roles

A user will say "I want a button."

But their manager will pay for "control, risk, speed, economics."

If you only interview users, you can easily get stuck on functionality.


I think some of this will definitely appear in your interviews.

And if so...

A few rules from experience on how to avoid this more often:

Rule 1: Start not with the product, but with the real situation

Instead of "what do you need?", ask "when was the last time something happened?"

What was the most unpleasant/expensive part of that situation? How did it end? How much money (time, nerves) was spent?


Your goal is to extract context + consequences.

Rule 2: Always translate "I want a feature" into "why?"

The good old "ladder of why"...

You need integration? Great! Why?

What would be different if it existed? And if it doesn't, what breaks? Who suffers?


After 3-4 "whys", the real value usually emerges.

Rule 3: Record value in the format of "result", not "solution"

Bad insight formulation: needs PDF export

Good: needs to compile a report for the client in X minutes without manual editing, otherwise we miss deadlines and get fined.


The feature could be PDF.
Or it could be a link, API, template, auto-send.

The result matters.

Rule 4: Check the significance of value through the cost of error

If this isn't solved in the next 3 months, what will happen?

And the worst-case scenario? And how much does it cost (approximately)?


If you hear "unpleasant but we'll survive", it's probably not value, but convenience.

And one last thing...

Remember that after the 100th interview, things will become a little clearer

Great insights to you!

#value_search