Nearly every company I’ve worked with since becoming a web professional six years ago has lacked an efficient way to decide which things to do first. Put 10 people into a room for an hour, and they’ll surely come up with a wish list a mile long.
A few years ago I was VP of Web development for an online retailer. When the business manager team gave me a list of 250 separate features that they wanted to have by launch, setting priorities became a top concern — we had only 2 developers on staff and 90 days to launch. A consultant I was working with at the time gave me a TQM-style process for prioritizing initiatives. I’ve refined and simplified it over the years, and have ended up with a tidy little process that’s easy to use. Here’s how it goes:
Step 1: Make a “Big List of Things To Do.”
This is a list of all the initiatives coming down the pipeline. By “initiative” I mean anything that will take time and effort and isn’t part of business as usual. The Big List should include features you want to add, changes to make, new sections, and so on. Do this collaboratively — the idea is to have a complete list of wishes and expectations from everyone who has them. Get your coworkers and managers together in the conference room and brainstorm for an hour. If that’s not possible, drop by people’s desks for a few minutes and get the information that way — whatever works. Don’t worry about whether you have time to build the things or if they’re good ideas. Just make The List.
Step 2: Organize your list according to Dependencies and Baseline items.
Once you have the Big List, spend time organizing the initiatives. The first group should put together dependencies — “You can’t launch X until you have Y.” Let’s say you’re working on a website for home renovation, and you want to launch a kitchen layout widget. The new widget is only useful if the visitor can save results, so you can’t launch it until you have a registration system. That’s a dependency.
The next consideration is “Baseline” — what’s the handful of things that you absolutely, positively must have in order to launch the project. This should be a fairly small number of things — when you define a set of things as baseline, you’re saying, “we cannot launch without this.” Remember that Baseline needs to include any Dependencies.
Step 3: Have the appropriate coworkers score each item.
If your Big List is really big, start by scoring only the baseline and dependency items, then do a second round to identify the extras that you can add on if there is time. In this step, certain coworkers provide scores (on a scale of 1-5) for each initiative in each of the following categories:
- Technical Feasibility: Is it easy or hard to do? How long will it take to implement? Do you have the technical staff or budget to pull it off? For this, a score of 1 is low feasibility (meaning, it’s hard or expensive, or would take a lot of time). Have a technical manager, developer or engineer to provide this set of scores.
- Creative Feasibility: Do you have the content? Can you make it? Do you have creative staff or budget? Again, 1 is low feasibility (hard) and 5 is high (easy). Ask the content manager or other appropriate creative lead to provide this score.
- Importance to the User: For this one, ask whoever has the best understanding of the practical needs of your users. That could be a customer service manager (who hears all of their requests and complaints), the head of your research department, or in some cases a marketing manager. This should be someone who is in contact with actual users or user testing results, rather than simply marketing data. Again 1 is the low score (not important).
- Importance to the Business: Have a business or marketing manager provide this score. Here they’re assessing which features will support the company’s business objectives — increasing revenue, expanding service to a certain customer segment, and so on. As before, 1 is the low score.
Gather all of the scores together into a spreadsheet. Add the feasibility scores together for each initiative. Then add the importance scores for each item. (You can see all of this in the sample file prioritization.xls, found at the end of this article.)
Step 4: Graph the overall scores.
This is the neat part. Once you have scores, you can create a simple graph, like this:
Each quadrant tells you something different. Area 1 is filled with important things that are easy to do. Do those first. Area 4 is filled with things that are neither important nor feasible — scratch those off the list right away. Area 3 shows initiatives that are easy to do, but not all that important. You can slip those in if you have a spare moment, but why bother? Besides, you also run the risk of cluttering your interface with easy-to-build features nobody wants.
Area 2 is the challenging one. It’s filled with important things that are hard to do. Think about each one carefully. This is where most of your conversation, debate, and resource allocation work will come in. Keep track of these over time; new technologies might make these a lot easier to build in the future.
That’s it. Easy. The trick to making this work is having the right people providing input on the right aspect of each item on your list. This simple process provides a quantitative, de-personalized way to arrive at rational, actionable, and — above all — realistic launch priorities.
Janice Fraser is the CEO and a founding partner at Adaptive Path. She is a highly regarded speaker, educator, and design strategy consultant.
Download the document discussed in this essay:
[
Prioritization Worksheet] (Microsoft Excel - 27k)
Source: Janice Fraser
License: Creative Commons