Communicating Customer and Business Value with a Value Matrix

December 15, 2008

So, you’ve wrapped up your customer research, completed your personas, and have even written a few scenarios that show how users would want to interact with your brand new product. What’s next? What happens to the personas and scenarios once you’re ready to start requirements definition and design. Are you sure you’ve adequately communicated the type of system your users need to the Business Analyst and Interaction Designer on your team?

If you’re like me, you’ve always felt something was missing once you finished creating your personas and scenarios. They communicate the heart and goals of the user, but miss out on a lot of details. And while it’s the intent of both documents to do just that, neither personas nor scenarios succinctly communicates to your business what features a product or service should have and why it should have them.

Champion Advertisement
Continue Reading…

I’ve tried—and seen other people try—a variety of solutions to this problem. In the worst case, a manager simply denied the problem existed, insisting that the research team’s responsibility was to understand the customer, not propose new functionality. I completely disagree with that assertion. Over the years and with the help of several colleagues, I have refined a deliverable that I think fills this gap: a Value Matrix.

I’m glad to report that each time my team or I have used the Value Matrix, the outcome was a very happy stakeholder or client.

What Is a Value Matrix?

A Value Matrix maps the value of your recommendations for features and services across business needs and defines the criteria by which you would judge each recommendation successful.

The Value Matrix communicates with product stakeholders and business owners in a language they understand. I’ve encountered many business people who have difficulty understanding how personas and scenarios apply to the product development process. While they understand there is value in creating the personas, using them is challenging for them.

In considering this problem, I’ve come to the conclusion that personas and scenarios represent only half of the equation that defines who our customers are. It’s possible to use this half of the equation in a variety of contexts throughout an entire business, but when the time comes to apply this deep understanding of your customer—far deeper than broad-stroke market research—to a particular product or service, there’s something missing.

The process of creating the Value Matrix can fill that gap. The Value Matrix succinctly communicates to all stakeholders the reason—not just the business objective, but also the specific customer need—for each feature or process. In essence, the Value Matrix provides a means of summarizing and applying your customer research.

The Value Matrix is not a magic bullet. It provides a summary of a variety of documents and assumptions already in existence. And it takes quite a bit of collaboration to create one.

The Value Matrix Template

Let’s look at the makeup of the Value Matrix template shown in Figure 1. You can download this template for a Value Matrix.

Figure 1—Value Matrix template
Value Matrix template

As you can see, the Value Matrix template comprises a simple table, consisting of five columns:

  1. Customer Need
  2. Business Objective
  3. Proposed Functionality
  4. Success Metric
  5. Priority

Let’s take one column at a time.

Customer Need

If you’ve just completed a round of customer research such as a contextual inquiry, interviews, or exploratory usability testing, you know a lot about your customers and their frustrations. You’ve probably turned all the information you’ve gleaned into high-level goals and even crafted a few scenarios around how users want to interact with the product or service. Great! Now, let’s dig a little deeper.

In the Customer Need column, list all the nuggets of information about what a user is trying to accomplish in relation to the product you’re building. There’s no need to explain why they want to accomplish each goal. (You’ll do that in your personas and scenarios.) Just explain what they need. If possible, use actual quotations or describe users’ actions and point to videos of user observations. If you have multiple data points that support a particular need, include them. Though, I’ve found three are enough to show there is a significant need, without overwhelming the business audience.

Business Objectives

The second column is for Business Objectives. Determining business objectives requires assistance from your Product Manager or Business Analyst. The intent is to map each of the customer needs to one or more specific business objectives. Likely, most customer needs will meet one or two business objectives. If a customer need addresses more than two business objectives, consider narrowing that customer need.

Sometimes you won’t be able to map a particular customer need to a business objective, perhaps because either

  • that customer need is not relevant to the business—which happens quite often, because great products focus on solving specific problems
  • there’s a business opportunity that your company has previously overlooked—which is also quite common

The latter case could indicate there’s an opportunity for a new product or an enhancement to the current product.

Proposed Features

Now, this is where your powers of insight and intuition really come into play: What features would be useful in meeting customer needs and furthering the identified business objectives? What features did customers like when you were testing competitor sites?

The best way to answer these questions is to do some creativity exercises. Invite people with complementary strengths and skill sets to participate, but keep the group small. This is a brainstorming exercise, but you’re already armed with a lot of insights into your customers. When adding Proposed Functionality, use those insights.

Multiple features can meet each customer need, and one feature can meet multiple customer needs. That said, associate a particular feature with a customer need only if it directly addresses that customer need and business objective. That can be a tough call sometimes. On the other hand, listing only one feature in every row likely makes the whole document meaningless, because it probably means you’ve defined the feature too broadly.

One other tip: Be prescriptive rather than descriptive. Describing how a product or service will work is for the design and business teams to flesh out later.

Success Metric

The Success Metric is my latest addition to the Value Matrix. It describes how to measure a feature’s success. In some ways, this could be redundant to the Business Objective column—assuming, of course, that business objectives define specific targets—but you can also include a number of expected uses, repeat uses, and other things that might fall out of the scope of—or expand on—the business objectives.

In filling out this column, work with your Business Analyst and Web Analytics teams. (The Web Analytics team will love you for including them so early in the process.)


While Priority is the first column in the document, it’s the last one you’ll complete. Prioritize each customer need as it relates to business objectives. You can judge the most important customer needs only in the context of the business objectives. So, you must consider both when defining priority. Note that no technological requirements factor in this prioritization. That comes later. But brace yourself—not everything you’ve defined here will make it into the first release.

Negotiate with your Business Analyst or other stakeholders to determine priority. If you’ve been working closely with them all along, this shouldn’t be a tough negotiation—or, if it is, at least you’ll know the sticking points before the negotiations begin.

Once your prioritization is complete, you’ll notice something: This looks suspiciously like a roadmap. Or, if it’s not quite thorough enough to serve as your company’s or team’s official roadmap, it can at least inform the creation of the official roadmap.

Adapting the Value Matrix to Your Needs

I’m certain the Value Matrix I’ve defined isn’t perfect for everyone’s needs. In fact, I’d venture a guess that no document format would satisfy the needs of every situation. This document need not replace any existing documentation your team creates, but it could provide a summary of various documents and a bridge between them. Here are some potential improvements to the Value Matrix I have considered that you might find useful:

  • References—A column for references to other documentation for business objectives, customer needs, and so on. This would let people see the source material you used in creating the Value Matrix.
  • Market Research—A column for information gleaned from market research. Market research tends to be broader, but has a much higher sample size than customer research and usually offers insights of its own. However, when market research is available, I prefer to list it in the Customer Need column.

The main benefit of the Value Matrix derives from the process of its creation. To create a Value Matrix, different team members must work together and, through their collective insights, you’ll make your product or service stronger. 

CEO at Bluespark

Co-founder of Ruzuku

Peoria, Illinois, USA

Richard F. CecilRick has nearly a decade of experience envisioning and designing innovative solutions for a variety of companies, including startups, non-profits, universities, and Fortune 100 companies. During his tenure at Motricity, he worked with Cingular, BET, Ask, Alltel, and other clients and was the Design Lead for their core product offering. Rick was a co-founder of both the Interaction Design Group—now the Interaction Design Association (IxDA)—and the Triangle Usability Professionals’ Association (UPA). Active in the UPA, he also serves on the organizing committee for World Usability Day. Rick is also the UXnet Local Ambassador for Research Triangle Park.  Read More

Other Articles on Business of UX

New on UXmatters