How do I help prioritize the many competing requests for improvement for a product/service?

11 Mar 2013 - 4:50pm
3 years ago
6 replies
1638 reads

As a UX Manager, how do I help a business owner prioritize the many competing requests for improvement for a product/service? We are missing a Product Owner for this product and currently, the business owner is gathering all the feedback she's ever heard from internal sources and prioritizing the items of people who are screaming the loudest. She is looking to me to help her decide what we should work on next and I know that we should be using data to drive these decisions but I'm not really sure where to start. I have recently taken the role of UX Manager (but have been with the company for a while), so I am looking for any practical advice you have to offer. 


14 Mar 2013 - 1:08pm

I would most certainly start with the goals of the business. Are you using Agile Kanban methodology? Prioritization can be difficult. What usually happens is the disregard for an impact statement on how the workload affects other areas of the application. Take the time to size the efforts and definitley do not silo yourself from the rest of the dev group. As a manager, get everyone together in UX fashion and get some feedback. I am certain many of the stakeholders probably can make some great suggetions within your company.

Hope there is some advice you can use in there.


John C

16 Mar 2013 - 12:26am
Adam Korman

There's a great set of slides by Angel Anderson about "Design Triage" that's directly applicable to your situation: Just to highlight some of the points that I've found helpful when I've been in your shoes:


  1. A quick, broad-strokes assessment of where to focus your attention can be more valuable than a perfect diagnosis.
  2. Don't fall into the trap of spending all your time on "low-hanging fruit." It's easy to get sucked into just fixing the things that are easy to fix but either (a) don't really require your attention or (b) don't require your immediate attention.
  3. Don't waste your time working on things that are doomed to fail. This one can be hard, because you may recognize impending doom where it might be politically disadvantageous to say so aloud.
  4. Do focus your design efforts where they will have the greatest impact. This may not match how projects are prioritizied from a business perspective.
This last point is really important ... just because something is important overall doesn't mean that it would be a good use of the UX team (as a limited resource) to spend its time working on it.


16 Mar 2013 - 1:03pm
Tania Schlatter

As an outside consultant in this situation we try to get a sense of what users value most and compare that with ease/cost to implement. 

One place to start might be to take a critical look at the information and sources of the information the business owner has gathered, and try to qualify it to some degree. For example, can you sort out feedback by its source (customer, end user, internal, etc.) and then try to determine the general motivations behind the feedback? Are some nice to have requests? Are some internal and political? Do some keep users from getting value from the product? There may be other questions that apply, based on your situation.

If this type of analysis doesn't help prioritize, the solution I've found successful against conflicting internal priorities is to get feedback from representative users, usually in the form of sorting features on cards or reviewing paper prototypes. 

After reviewing the "Design Triage" preso, I'd say this is about defining an informed rationale that your business owner needs to say "no." 

Hope this helps,



16 Mar 2013 - 3:13pm
Stephen Perry

You need a prioritization matrix. Its a really simple and very powerful tool that collects all requests item-by-item, describes them, and weights them by the average score of 3 primary drivers: customer (or user) need, business need, and ease of implementation. It can be a simple spreadsheet with the average scores (ratings from 1-5, where 5 is the highest value of goodness for each row of requested items/features/issues) in 3 columns, or as complex as having 3 worksheets (one for each primary driver) with faceted ratings that add up, but eventually feed the main 3-column ranking. You simply sort by the completed average score and the cream immediately rises to the top.

The trick is getting everyone to agree on the ranking. If you involve key stakeholders in the ranking process, it all but eliminates the rather competitive quest for priority, and can also reveal differences in understanding of a requested item/feature. I'm always amazed at how well it works when applied properly. One of my biggest clients took it and ran, and now has integrated it into their agile methodology for prioritizing their back-catalog. Any stakeholder who does not participate in ranking exercises every 2 weeks basically forfeits their right to priority. It's become a behavior changing method for them.

Let me know if you want more details on the method.

- Steve


20 Mar 2013 - 5:20pm

Thanks to everyone for the helpful feedback!

21 Mar 2013 - 3:32am
Chad Jennings

I agree with Stephen. I've had great success with the prioritization matrix as he outlines. It forces the discussion to be about the success metrics and weighting of priorities. We tended to remove the "ease of implementation (Technical Complexity in agile-speak)" until after we'd prioritized from a business/customer side. Then have the feasibility discussion to reduce complexity of discussion initially.  

At Blurb this came down to really three categories: Drive Revenue (amount of new revenue can be estimated), Strategy (Future may not be revenue focussed), and Quality (includes quality of experience).  You then have 100 points to divide between these three categories - your weighting. Any feature that scores high in all three, many will not, tends to rise to the top of the stack. I.e. This "feature or product"  drives revenue, is inline with a long term strategic goal, and improves the quality of our user experience. That weighting is what the strategic discussion with execs is really about. If a favorite feature everyone believes in does not bubble to the top, then one needs to discuss the weighting framework as much as the pros and cons on the feature.   

I originally discovered this via the 280 Groups Product Management templates. Many of the other templates are less helpful imo, but this one is worth the price alone. The template has better explanation than mine.

- Chad

Syndicate content Get the feed