Build the hierarchy from the reason a buyer would fund a change to the product detail that proves you can deliver it. Each lower layer should answer the question raised by the layer above. Discovery questions help an executive decide where to place you in the value pyramid.1 If you cannot state the business objective, do not lead with a feature. A feature earns its place after the buyer's problem has become a value statement and a use case. The hierarchy works when the buyer can explain the value upward in the organization and the proof downward into a demo.
The shape of the hierarchy
Treat the hierarchy as a route from customer need to usable product proof. Start broad, then narrow as the buyer gives you a reason to do so.
A product hierarchy starts with the fundamental needs customers seek to serve through a product or interaction with a company.2 It can be framed as a job to be done and run down to specific customer-facing items.3 The product need is the broadest category in the inverted pyramid.4
Use the broad layer to decide what the offer means to the market. Use the narrow layers to decide what to show, explain and connect to the buyer's situation. If a lower layer cannot support the one above it, stop and repair the connection before adding more product detail.
Build the business layer first
Begin with the reason the offer deserves attention in the market. This gives the rest of the hierarchy direction and keeps product language from taking over too early.
Start by naming what you offer, who you serve and your unique strengths.5 Then state the market need the offer fulfills and what separates it from other offerings.6 Your B2B value proposition should follow overall brand positioning and align with product or service messaging.7
Ask what the business is trying to accomplish, what changes if it succeeds and what would make the change worth funding. The executive expression usually describes what the business is trying to accomplish,8 so keep functionality lower in the hierarchy.
Write this layer in language the buyer can carry into an internal conversation. Improving a workflow may be too low if the buyer is trying to protect a business result. A statement about that result gives you a place to connect the offer without leading with its interface or feature list.
Cascade the value across stakeholders
A sale can contain several versions of the same value. Keep the central business objective stable, then show how it appears in each stakeholder's work.
Stakeholder-specific value propositions can cascade from an executive objective into the supporting results beneath it, in a structure similar to an OKR.9 Use discovery questions to find the result each person owns, the problem that blocks it and the change they would recognize as progress.
Ask which result the objective depends on, which problem makes that result harder to reach and what this person would need to explain internally. The answers tell you which layer to use in the next conversation. They also keep you from presenting the same feature to every person with the same wording.
When the buyer's answer stays at the business level, keep the conversation there. When the buyer names a concrete process or situation, move down to the use case. When the buyer asks how the change happens, bring in the feature that proves it.
Move from need to proof
The lower part of the hierarchy turns a business outcome into something the buyer can recognize in daily work. Keep each connection visible as you move down.
The product family and product class focus on the functional use case.10 Use that layer to state where the offer fits and what situation it serves. Ask which process, moment or workflow requires this outcome.
Connect the buyer's pain to a specific value proposition, then connect that value proposition to specific features.11 Select features because they explain how the agreed value becomes possible, not because they are easy to demo.
A group of features tied to a value proposition should already have a demo and a use case behind it.12 If you cannot say what the buyer would use the group for, it is still a product bundle, not proof of value.
Connect the pain point, feature, benefit and goal so the buyer can see the business case.13 Organize features by the problems they solve so the buyer can discuss them with their boss.14 This gives the buyer language for the internal conversation and gives you a route into the demo.
Use the hierarchy in the call
Use the structure to decide what to ask, what to say and when to show the product. Descend only when the buyer's answer gives you a reason.
Start with the business objective and the result behind it. Move to the functional use case when the buyer describes where the problem appears. State the value proposition in terms of the change the buyer wants, then select the feature that can make that change visible.
Give the value proposition enough detail to differentiate while keeping the presentation at a high level.15 The transition from feature selling to connecting the product with high level business initiatives is called value selling.16
When you demo, frame the feature around what the prospect can see or do in the product.17 Explain the action only after you have named the problem and the value it supports. Treat time savings and productivity gains as a sweetener around the main business result.18
In business sales, work as high in the value proposition hierarchy as the buyer can support.19 That may mean staying with the business objective through the call, or moving down to a use case and feature so the buyer can prove the objective is reachable. Let the buyer's answers set the level.
What not to do
These mistakes break the connection between the top of the hierarchy and the feature layer.
- Do not lead an executive conversation with functionality. Executive value is usually about what the business is trying to accomplish.8
- Do not jump from a pain point to a feature. A pain point should lead to a specific value proposition, then to specific features.11
- Do not present a feature group without a demo and use case behind it.12
- Group features by the problems they solve so the buyer can discuss them with their boss.14
- Keep time savings or productivity as a sweetener around the core business result, not the main value.18
- Differentiate while keeping the value proposition at a high level instead of turning it into a long product presentation.15
Before the call, write the business objective, the use case beneath it, the value statement that connects them and the feature that can prove it. During discovery, fill each layer only when the buyer gives you the information to support it, then move into the demo with that chain intact.