Prioritizing for Anything

You can have anything you want, but not everything.

Photo by Dan Gold on Unsplash

I have found almost universal applicability of priortization techniques usually used in product management. This has helped me with my personal finance, my life, and my work, whether I was trying to provide direction to a small team or the entire organization. This is a run down of the techniques, and how I have found them to be useful.

Critical Path

This is the simplest of all techniques. I have used it with heterogenous groups and with teams with intermediate or junior engineers. I also use this technique for personal financial planning, and juggling family priorities. It is easy to explain and easy to understand when done wrong. When the group starts having too many things in the critical path of their goal, I tell them to rethink the approach because when (nearly) everything is critical, nothing is critical. It also works better when the team has a good idea of the nature of the work that needs to be put in.

When trying to prioritize with the critical path, you only need to ask your team critical pain points of customers, or consult with your spouse on critical life goals (that need financial planning). As you identify the most critical item on the list, identify the next critical thing, and so on.

One mistake I have seen teams make with this technique is to chain the items in the critical path. This leads to over prioritizing one epic or or one goal, and you land up with too many ‘critical’ items. In order to avoid this, try and identify the critical items to achieve all your epics or life goals. For example, instead of saving first for your child’s education and then your retirement, its better to prioritize two investments, one for your child’s education, and one for your retirement. These first investments may not be sufficient, but that’s alright because the trick is to keep iterating, and build the investment corpus over time.

Kano

This is the next one on the simplicity scale. I had a lot of fun using this to help a leadership team reimagine their All Hands meetings, and more recently draw parallels to team engagement. It is most useful to dissuade a team from the ‘shiny object syndrome’, and prioritize things that potential customers need in order to just consider using the product. For example, the leadership team I was talking about was debating whether fresh fruits would encourage more participation in the All Hands, but it turned out that the biggest impediment was lack of office space.

The Kano model classifies customer needs into three categories: expected, normal and exciting. If the expected needs are not met, then the customer is going to be dissatisfied. Normal needs are those that when met, they lead to satisfaction. Exciting needs when met, lead a customer to be delighted. Teams can use this classification to prioritize the expected features and then consider a mix of normal and exciting features.

The model heavily depends on the value of features based on the customer’s perception. It requires you to know your customers really well. You don’t want to spend a ton of a money releasing what you consider an exciting feature only to find out later that the customers didn’t really care about it.

Desirability, Feasibility, Viability

This is a somewhat sophisticated technique that tries to balance between demand, effort and profitability. This is a good technique when features of a product need to be prioritized without the fiat of an Executive in the product team.

‘Desirability’ is from the customer’s point of view. Do customers want this feature?

‘Feasibility’ is if we can build this feature. If something clearly requires more time or money, then it has low feasibility. More commonly, feasibility is based on alignment of other features in the solution. For example, it is more feasible to add a feature to save customer credit card information to a payment solution than to an identity management solution.

‘Viability’ is often a measure of the revenue or profit, but it could be any metric of value.

Once all features on the table have been scored on each of the attributes, each feature can be given a composite score. The features with the highest composite score are then prioritized in the product roadmap.

ROI

I have used a simple ROI method called a ‘2x2 matrix’ or ‘Eisenhower matrix’ for many years now to prioritize my work. I am pulled and pushed into multiple things in my line of work. I am expected to manage my time.

The 2x2 Matrix has two axis: Effort, and Value.

The ‘value’ axis represents the value that you provide to the organization, and not the value of the task. For example, my company may not value my hobbyist programming, but it may value me mentoring others; so if a potentially programming task comes along, I provide more value by delegating to a programmer than doing that task myself.

The 2x2 grid creates four zones:

• Low Effort/Low Value — find a way to delegate these tasks especially to someone for whom this may be a high value task.
• Low Effort/High Value — do these as soon as possible. Treat them as quick wins.
• High Effort/Low Value — avoid these! These will take a lot of time and provide very little value or none at all.
• High Effort/High Value — plan for these. Treat them as a project with milestones, collaborators, and a deadline.

Scorecard Approach

There is another more complicated ROI method that builds on the Desirability, Feasibility and Viability technique.

Theoretically, it is beneficial when the composite scores are very close, and there isn’t enough budget to include everything. In order to calculate the return on investment, it considers a formula that takes into account the effort to build the features, and a confidence factor based on risk. It weighs the value in terms of customer need and business objective.

Practically, it is better to bring in UX professionals once there is general agreement on the top features. They can conduct customer interviews, and use the research for further refinement and prioritization.

MoSCoW

I have typically used this more as a method for communication than prioritization. This is useful when the acceptance criteria for a story needs to be communicated to developers.

• Must have are the aspects of the story in the critical path. If any of these aspects can not be met due to deadline pressure, the entire story needs to be dropped. For example, an unambiguous error message on incorrect login credentials is a must have aspect of a login story.
• Should have are the satisfiers. They are not critical, but are painful to leave out. For example, the error message should be in a font and color that usually signifies an error condition in the application.
• Could have are the aspects that should be dropped first if there’s deadline pressure. These are typically the delightful aspects. For example, suggesting alternate methods of login.
• Wont have are aspects out of scope. These are useful for creating a bounding box on a story.

Prioritization Paralysis

Sometimes, I have too much on my plate and I can’t decide what to begin with. This usually happens when I am late on multiple assignments. If none of the above techniques work to prioritize things, the only thing that is of priority is progress. This is not progress that is measured with KPIs or metrics but just enough progress to get out of a rut.

When stuck on priortitization, progress on anything is a good win.