B2B purchasing is complex. Not only do you have to navigate complex buying group dynamics, but often, those making the buying decisions aren't the same people using the solution.

So how do you develop a solution, prioritize features, and reconcile the different requirements and expectations?

Buyer vs. User: Understanding the Difference

A buyer is typically an organization represented by a purchasing officer, an executive, or a committee that makes buying decisions. Buyers are often decision-makers, influencers, champions, and gatekeepers who may not be using the solution.

Meanwhile, users work with a solution daily but are often not involved in the decision-making process. They typically don't have much input into the product selection conversation.

Users often look for details that can streamline their day-to-day workflow (e.g., ease of use, simple navigation.) Their priorities may or may not align with the buyers' criteria, such as business objectives, strategic outcomes, and costs.

Additionally, different buyers have different priorities. For example, someone from finance will want a solution that demonstrates economic benefits, while an executive will want to know how a product can benefit the company's high-level goals.

Misalignment often leads to conflicts in the product development and purchasing process. Project sponsors and buyers may make one set of decisions based on their beliefs and assumptions while the user research team pushes for a different direction.

How can you reconcile the different goals and expectations?

In our development process, we often use research-based story mapping to help buyers understand priorities from different users and gain an objective perspective to prioritize features in their solutions.

What Is Research-Based Story Mapping and How Does It Support Decision-Making?

Research-based story mapping is a technique used in agile software development to track and organize "stories" that describe a product's features. A story map creates a sequential view of a list of stories to help a development team understand them in context instead of viewing each requirement in isolation.

Here are the essential steps in developing a story map:

1. Write out the story one step or action at a time.
2. Arrange the steps sequentially into a narrative flow.
3. Explore alternative stories or scenarios.
4. Distill the map to create a backbone.
5. Identify the tasks or activities that comprise the essence of the system.

After creating a story for each feature, you'll conduct research to gather facts and generate insights that will help you prioritize decisions.

The focus on research and evidence reduces the dependency on gut feelings and personal opinions. The decision will also be less susceptible to the influence of management or buying team alone. Instead, it'll take into account the needs and preferences of the users.

Here's how to use research-based story mapping to support decision-making:

Set up a spreadsheet to track the evidence. Then, use these factors to determine each feature's value:

• Submitter: The person who submits the source, for example, the team member who conducted the user research.
• Source type: The data can come from users (e.g., surveys, interviews), business sponsors (e.g., workflow analysis), usability tests, or other information pools.
• Source reliability: This numerical score (from 1 to 5) indicates the level of confidence about the accuracy of the information. It's based on the context of the story in which a source is used.
• Business value: This score (on a scale of 1 to 5) indicates the business value of a task compared with other related actions on the map.
• Appeal: This score (from 1 to 5) indicates the appeal of the feature to users. It can include frequency of use, duration of the task, or effort required to complete the action.

Give each information source a score to quantify its weight in the decision-making process. Then, calculate and assign a priority score to each feature to reflect its prioritization value.

For instance, by adding the business value and appeal, then multiplying the sum by the source reliability score, you can scale the importance of the task (i.e., business value and appeal) by the source's reliability.

Next, you can create a heat map to list all the features from "hot" to "cold." By laying out the different requirements from buyers and users, you can understand their priorities in context. This objective view can guide the conversation and reconcile the various needs and expectations from users and buyers.

Finally, you can incorporate input from developers on the time and effort required for each story. The priority may change because it may be more beneficial to tackle simpler but lower priority tasks first so you can deliver immediate value before working on more complex but higher priority stories.