When I was a product lead at Imperva, there was a feature that engineering kept telling me required a rewrite. Theoretically, they were right – the feature was written poorly. Its entire architecture was bad. We were monitoring our customers’ databases, and the architecture caused a severe performance impact on the databases themselves.

The poor state of the feature wasn’t engineering’s fault. It was an informed decision before my time there, that allowed us to release something very quickly. But you know how it is – temporary things tend to remain permanently, and engineering kept raising a flag that this feature needs more work. And I fully understood them.

The only problem was that nobody used that feature. I knew it not because I looked at our behavioral tracking (we couldn’t have one, as our systems were installed on-prem and disconnected from the internet). I knew it because the feature was so bad that if anyone wanted to use it I was sure I would have heard about it in the form of multiple support tickets. But there were none.

Following this analysis, engineering said that we should kill this feature. It makes sense – it’s never used, and it’s written badly, why keep it?

But there was a good reason to do so. While none of our customers wanted to use this feature, many of them wanted to have the option. And so, when we were answering RFIs and RFPs (long requirement documents that large enterprises request vendors to fully answer before they start testing their products) there was almost always a question asking whether or not we supported this capability. I wanted to be able to say yes. 

I decided to keep the feature without touching it and explained to engineering why. I also assured them (and was going to keep my promise) that if we see customers using it we will allocate the resources to write it properly. I never had the opportunity to keep that promise, and the feature kept living: poorly written and unused, but providing a positive answer to RFIs and RFPs until I left 3 years later.

This article is the last part of an article series about the value assessment framework:

• Part 1 discussed value layers
• Part 2 discussed value assessment
• Part 3 discusses addressing the value gaps

The example I shared above shows you that there are multiple ways to address gaps, and not all gaps need fixing.

Here is how you should look at the gaps you identified during the assessment phase.

Overall Status

Last week I recommended creating a value table, where you describe for each customer profile the value definition, the value delivery, and the value perception, and then assess each on a red/yellow/green scale. 

Before we dive into specific recommendations, take a look at the entire table and see if there are specific rows or columns that are in bad shape. This could indicate a larger root cause than just a specific problem. 

For example, if for most of your customer profiles there is a problem with value perception, it means that as a company you are not very good at communicating the value in a way that speaks to your customers. Alternatively, if for a specific profile none of the categories works well, it could mean that this profile isn’t fitting you or that you might be earlier in your product-market fit journey than you might have thought.

As explained in the example above, not all gaps need to be addressed, but there needs to be a good reason for that. You’ll notice that some of the gaps are expected (for example, if the value isn’t delivered it will rarely be perceived well), while other gaps might have been blindspots until the assessment.

Another thing to look at before we dive deeper into each type of gap is what surprised you most. Look at the table as a whole and think what is the main outcome from the assessment alone (understanding where you are at), before you start closing specific gaps.

Addressing Value Definition Gaps

Value definition gaps could result from any of the following reasons:

• You don’t understand which value you need to deliver
• You aren’t confident that what you understand is indeed true
• It doesn’t seem significant enough for them to buy your product

This is the only type of gap that you don’t want to leave untackled under any circumstance. If the value isn’t well defined you can’t make any decision that depends on it.

If you don’t understand the value, try first to get into your customer’s head and describe it from their point of view. Then ask yourself if it makes sense, and if it seems important enough. 

You don’t want it to stay in your head. Discuss it first with multiple stakeholders from the company – especially those who work with customers – and ask them if it seems right to them as well.

Then, go ahead and check it with customers directly. I’m a big believer in open communication. As a product manager or leader, you should always create your own customer advisory board, just less formally. Keep a good relationship with at least a few customers, to make sure you can approach them and ask them these questions openly when you need to.

Addressing Value Delivery Gaps

If you know which value you need to deliver and you see that you don’t, usually it’s very clear what to do. Close the gap.

But in some cases, this can be more complex.

It could be that there is a major technological gap that would take years to resolve before you can deliver the full value. It could be that there are strategic implications to going all in on the value, for example, if you are building medical devices and you want to remain with a specific FDA classification that is less regulated, but to deliver the full potential you need to be classified at a higher level. It could be that delivering the full value doesn’t depend on you, for example, if you need something to happen for the customer before they can fully benefit from what you have to offer. You might uncover that for the customer to enjoy your product another stakeholder (in B2B products) needs to also get value but you don’t currently address them.

When you look at these cases, there might be things that you can do within the value delivery itself. For example, you might find a creative way to deliver most of the value in a lighter way that wouldn’t take years or wouldn’t take you to a higher classification with the FDA. But eventually, many of these cases would take you back to the value definition.

If the value that you defined is not feasible, or not feasible given strategic choices or constraints that you don’t want to change, it means you need to redefine it, at least temporarily.

This could lead to a bigger problem: what if you can’t define a feasible value that is good enough? That’s why this assessment and the follow-up discussions are so important. If you have such a problem, you are far better off knowing that it exists and understanding what compromises you make than ignoring or not being aware of the problem. In some cases, this will lead you to understand that you can’t win here, and change the direction completely (for example, shift focus to another customer profile – business-wise, not analysis-wise).

Addressing Value Perception Gaps

Value perception gaps are trickier to identify and could be harder to close because they go deepest into your customers’ heads. But since a lot of closing them involves communicating the value properly, there could also be quick wins here that don’t involve a lot of engineering effort, which would allow you to move the needle in parallel to working on other things.

If you have a product marketing manager, this is a good opportunity to involve them.

Note that communicating the value can be done in multiple ways throughout the customer journey:

• The initial marketing materials and campaigns
• The sales meetings
• The product itself – by “talking” to the customer and highlighting the value, not just by the features delivering it
• Any interaction with customer success
• Regular checkup calls and emails
• Email campaigns addressing specific milestones that they have achieved with the product, or periodic summaries (your year in review)
• And more

Note that when you communicate the value, you should consider the multiple stakeholders involved. It could be that your users perceive the value, but their managers – the ones who approve the budget – aren’t aware of that or need more value for themselves before they can feel the product is valuable. You want to look at each stakeholder separately and see what they need.

This concludes the value assessment framework. As you can see it can open up many things for discussion, but that’s the beauty of uncovering your blindspots: now you can take care of them.