The Best Ways to Prioritize Products and Features

By Janet M. Six

Published: December 23, 2013

Send your questions to Ask UXmatters and get answers from some of the top professionals in user experience.

In this edition of Ask UXmatters, our experts discuss the best ways of prioritizing a list of products and features.

In my monthly column Ask UXmatters, our panel of UX experts provides answers to our readers’ questions about a broad range of user experience matters. To get answers to your own questions about UX strategy, design, user research, or any other topic of interest to UX professionals in an upcoming edition of Ask UXmatters, please send your questions to: ask.uxmatters@uxmatters.com.

The following experts have contributed answers to this edition of Ask UXmatters:

  • Drew Davidson—Senior Experience Director at ÄKTA
  • David Kozatch—Principal at DIG
  • Shane McWhorter—Executive Director, User Experience Strategy & Design at Product Concept, Design, and Experience
  • Itamar Medeiros—Senior User Experience Designer at ROAMWORKS
  • Janet Six—Principal at Lone Star Interaction Design; UXmatters Managing Editor and columnist
  • Simon White—UX Manager at Voyages-sncf.com

Q: What are the best ways to prioritize a product and feature list?—from a UXmatters reader

“The best way depends on lots of different variables—such as how early in the product development lifecycle a product is, how mature a market is, or how well-known the targeted personas are.”—Itamar Medeiros

“There are lots of different ways of prioritizing features,” replies Itamar. “And just like any other type of method, the best way depends on lots of different variables—such as how early in the product development lifecycle a product is, how mature a market is, or how well-known the targeted personas are. I’ll discuss two methods that you can use in two different contexts:

  • Outcome-driven Innovation—“Anthony Ulwick created this framework for a strategy and innovation process, which he detailed in his book What Customers Want. Its basis is the premise that people buy products and services to get jobs done. (See Strategyn’s whitepaper ‘Jobs-To-Be-Done for further discussion of this framework.) Clayton Christensen credits Ulwick and Richard Pedi of Gage Foods with the approach to thinking about market structure that he described in his book The Innovator’s Solution, in the chapter ‘What Products Will Customers Want to Buy?’ as ‘jobs to be done’ or ‘outcomes that customers are seeking.’ From a product development perspective, I’ve found this method very productive of insights in the context of discussing business opportunities with product managers during a product development cycle. But I’ve found it hard to integrate this approach into the day-to-day prioritization discussions that I’ve had with development teams.” For further discussion, see Itamar’s blog post “Product Definition and Requirements Prioritization.”
  • UXI Matrix—“Jon Innes created the UXI Matrix, or Pugh Matrix, which is a decision matrix that helps you to evaluate and prioritize a list of use cases based on a set of predefined weighting criteria. This is different from Outcome-driven Innovation in that its focus is not necessarily on eliciting requirements. That said, this approach is easier to integrate into your day-to-day prioritization discussions with development teams—especially agile teams. Jon actually created this method to help Scrum teams integrate UX metrics into agile development cycles.” Itamar recommends Jon Innes’ SlideShare presentation “Integrating UX into Agile: How to Ensure Your Sprints Result in Usable Software.”

Balancing Business, Technical, and User Priorities

“Removing features that do not support any use case—even those already in a product—is the single most effective way of reducing development costs and time to revenue, while also improving the product’s user experience!”—Shane McWhorter

“What a great question that speaks to the heart of user experience!” exclaims Shane. “User experience brings a more customer-focused approach to product development that involves seeing a product as a whole experience whose goal is to help people to perform their tasks successfully rather than thinking of a product as providing a set of features without considering how people would use those features to get something done.

“A feature list’s only purpose should be to support the user in performing tasks. Those tasks differ in terms of their business priority, frequency of use, and importance to the product’s overall use. Some tasks account for 90% of the use of a product, while other tasks may represent only 1% of the use of a product. Some features are critical to performing that 90% use case, but others are less so. A stakeholder might even ask you to prioritize a feature that supports no use case at all! Removing features that do not support any use case—even those already in a product—is the single most effective way of reducing development costs and time to revenue, while also improving the product’s user experience! First, list your customers’ tasks by business priority, then by frequency and importance, and you’ll find prioritizing product features to enable those tasks a snap!”

“Don’t prioritize user needs over business needs. While user needs are incredibly important, they won’t matter if they don’t end up driving business.”—Drew Davidson

“Whenever I’m prioritizing products and features for a certain project,” answers Drew, “I use the following exercise to determine their priority: I list the business needs, the user needs, and the technology requirements. Then, I consider where the needs from each of these categories intersect—for example, which business need aligns with which user need and which technology requirements align with the needs of the business and the user. Don’t prioritize user needs over business needs. While user needs are incredibly important, they won’t matter if they don’t end up driving business. Once I’ve determined the right priorities, I break down what’s possible within the specified timeframe. This exercise helps me to determine the priority of each product or feature.

“One note: some features are bigger and more time consuming to create than others. A product’s internal architecture is something that often gets overlooked when scoping out the technology and requirements for a given release. When you’re considering making changes to a Web site or application’s architecture—or creating a new architecture—be sure to establish a realistic timeline that accommodates a mixture of both large and small features. The small features are easy, but the big changes are what will make your project stand out.”

“If we fail to relate our design work to the business’s bottom line, that’s a problem.”—Janet Six

I whole-heartedly second Drew’s recommendation not to prioritize user needs over business needs. As UX designers, we empathize with users and want to give them the best possible experience—while showing off our spectacular design skills, of course. However, if we fail to relate our design work to the business’s bottom line, that’s a problem. Many companies truly care for their customers, but they must do that while ensuring that they are making enough profit to stay in business. Fortunately, this is not a binary choice. You can often both support business needs and make your users ecstatically happy. Just put business concerns first, so the company can be successful and keep distributing your awesome products to customers.

Sort by Potential Revenue

“The ideal basis for prioritization is potential revenue…. Separate the nice-to-have features from the real revenue drivers.”—Simon White

“The ideal basis for prioritization is potential revenue, of course,” responds Simon. “On a coarse prioritization pass, you need to separate the nice-to-have features from the real revenue drivers. Sadly, the fine details of a user experience are often nice-to-haves. Maybe you can fight for an earmark for customer satisfaction as a source of soft return on investment (ROI) or pick one feature from a list of UX priorities each cycle, or Sprint.”

Use a Bucket Sort

“Features that stakeholders have rated as essential, that are unique, and that have high expected-usage scores will be your winners once you design, then market the product.”—David Kozatch

“If you have many features to rank, I recommend using three buckets or piles,” recommends David. “Have stakeholders or respondents identify each feature as one of the following:

  1. Essential
  2. Nice to have
  3. Not needed

Then, run through the feature list and ask them to indicate whether each feature is unique in comparison to those of competitors—as far as they know. Run through the list again and ask them whether they would personally use a unique feature starting on Day 1 of trying your product. Features that stakeholders have rated as essential, that are unique, and that have high expected-usage scores will be your winners once you design, then market the product.”

References

Christensen, Clayton. The Innovator’s Solution: Creating and Sustaining Successful Growth. Boston: Harvard Business School Publishing, 2003.

Ulwick, Anthony. What Customers Want: Using Outcome-Driven Innovation to Create Breakthrough Products and Services. New York: McGraw-Hill, 2005.

4 Comments

Great insights.

I think once you have your priorities listed, you might want to go the next mile and consider how easily and efficiently each product or function can be packaged and distributed. That might change your priorities.

Unique features are essential in grabbing user attention and filling a void, but you must also consider timing and distribution. Unique features could be expensive and slow to build.

Unfortunately, it’s not always the best products that succeed. In our business food chain, it’s often who was there first, what is cheapest, who has the most money.

Good luck.

Great discussion, Sam!

However, if we fail to relate our design work to the business’s bottom line, that’s a problem.

No, it isn’t.

Coming up with the best ideas often requires the ability to ask what Don Norman calls “the stupid questions.” That usually means not having business acumen and not having an MBA or the ability to bandy about terms like ARPU or OIBA. That’s exactly why you will have been hired, because there are plenty of people in any business who will be able to think about those things better and faster than you.

Your job is to design the best experience for the customer. If that doesn’t “align with business needs,” then the ball’s in their court to argue why an inferior user experience is good for business.

Designers who wag their fingers about “balancing business needs with user requirements” can all get jobs at Microsoft, the home of usage-free design.

Hello, has anyone come across any software that might speed up the evaluation process?

Join the Discussion

Asterisks (*) indicate required information.