What do we build next and why, is one of the most critical elements of delivering a successful roadmap. Everyone comes to the table with their own views, desires or wants. Whether it’s the engineers wanting to implement a new technology, the designers wanting to see a new feature implemented or the product sponsors who believes that the next item on the agenda should be what they feel is the most important. But how do we set about prioritising tasks?

In this post, I cover why prioritisation matters, how to avoid prioritising for the wrong reasons and more importantly what methodologies can provide robust and proven direction in setting the right priorities.  

In an ideal world, no one would argue with what needs to be built when. In the real world only a truly objective and collaborative method will bring all stakeholders onboard on what’s important and help to align the roadmap. Having a clear, logical and explainable reason as to why one feature needs to be done today and another can wait until the next iteration is crucial.

Why prioritisation matters

Time and resources are always limited. So if we are going to succeed we need to make sure we get the most important things done first. Waste time implementing a feature at an inappropriate time and the opportunity cost of not building the right feature could kill the project. 

Eric Reis, the author of the Lean Startup method, points out that most startups fail because they run out of money before they find a viable business model. A robust roadmap should be prioritised so this doesn’t happen. If we never get the chance to do what’s important because we worked on something else instead, we’re easily heading for failure. 

What does a new feature cost

Every feature we build into a product carries cost. It’s not just the cost of writing the code, or updating the user interface but far beyond that. When considering a feature cost we should take into account all the other factors including, the documents needed for the feature, training material needed, QA and testing, how support would handle requests from customers, how the organisation factors the feature into the pricing, how to demo and sell the feature and how to position and market the feature and all the training that goes around the channel teams. 

It’s tremendously hard work for any product team to deliver it’s core feature sets to a core target market, let alone continue to expand the features based on a need of a small number of customers particularly if they are in a nonstrategic customer segment. The overheads of of adding new features can slow things down to the point that the real focus of what must be done gives away to what could be done. 

Prioritising on a wing and a prayer

As a product leader, my role is to connect with all touchpoints of the product, this means talking with customers, prospects, engineers, designers, investors, researchers, executives across a business, salespeople, analysts and subject matter experts. Everyone will have their own priorities, whereas I can’t prioritise everyone’s desires, I need to understand how each stakeholders’ needs translate into a sequence of implementations that delivers the most values. 

Earlier in my career, I really didn’t fully appreciate how important setting the right priorities can be. In products I’ve developed and those I’ve seen or consulted in developing I’ve seen a variety of ways that priorities go awry, here are a few example sources. 

The guys upstairs feel it’s important

The product sponsor has a gut feeling a particular feature needs to be added next. Whilst it’s difficult to say no to a man or woman at the top, without serious analysis on why it’s important to implement something the team can lose morale, productivity drops and eventually the opportunity cost becomes too great for the product to bare. It’s important to communicate a thoroughly reasoned explanation of why something must not be done next and why other features are a higher priority. 

The customer feels it’s important

Letting the customer define the product strategy can be a costly mistake. As Henry Ford said, “If I had asked people what they wanted, they would have said faster horses.” Customer insight and priorities are very important but they’re not everything. A lot of times customers will just ask for what they already know. A roadmap made entirely of customer requests can result in a product with little focus and poor usability. Think of a swiss army knife. It has everything from a knife to saw to scissors to magnifying glass and many other things besides. But how many times have you used a swiss army knife this year? Unless you do a lot of camping, it’s not the best tool to get specific jobs done. I’ve seen so many products that try and be the swiss army knife and woefully fail at being able to do anything specifically. 

Sales feels it’s important

Don’t get me wrong, listening to the sales team is very important, these are the guys who are at the front line of understanding why particular prospects are rejecting the product. They have insight into what’s important to buyers and how to get their attention. However, prioritising on specific customer needs in order to close a sale can seriously detract from being focused on how to best serve the market. And whilst satisfying the relationship between the consumer and the producer is the cornerstone of any successful business, allowing a few individual customers to set the priorities of what needs to be built next can be a costly mistake in the long run. 

Support feels it’s important

Usability matters. If support teams are spending countless hours supporting customers through problems that could be solved through new features then it’s a good idea to pay attention to them. But these priorities need to be examined in the context of all the goals that need to be achieved. There’s little point to prioritise usability if key features are stopping prospective customers to choose the product. On the other hand, a product with poor usability can fail as the cost to the customer in navigating and getting what they need to get done outweighs its benefits. 

Our Competitors are doing it – we should too

The quickest way to bottom is to blindly copy the competition without a well thought-through strategy. Once the product starts to compete on feature list alone usually the product with the largest feature list and the lowest price wins. It’s far better to differentiate on the features offered that perfectly match the specific customers’ needs which competitors can’t or won’t be able to match. Being the leader in a niche and pricing on value is usually a more astute strategy than trying to continuously catch up with the competition. Better still building partnership with specialist technology partners, whether through integrating APIs or through shared offerings can leverage the power of the product far beyond what anyone competitor could offer. 

Prioritising methodologies for successful products

I am a firm believer in a methodological approach to solving problems. Setting priorities is one of the most important problems a product leader deals with and thankfully there are a number of frameworks that offer objective ways to analyse and decide on what needs to be built first, next and later. Here I outline five methods I use in setting product priorities, each has pros and cons and often using more than one method delivers the best results. 

Critical Path Analysis

Some fifteen years ago I became a Prince2 qualified PM. Prince2 is an acronym for PRojects IN Controlled Environments and for a long time was the de facto process-based method for effective project management. One of the pillars of Prince2 is a critical path analysis. A critical path is determined by identifying the longest stretch of dependent activities and measured in time required to start and finish. 

Starting with a user journey map and identifying each step of the customer’s journey can help to identify the critical pain points that the product can provide the solution for. This set of stories translated into a list of features and individual goals and tasks can then be logically broken down into the different activities that need to be completed. Some can happen in parallel, many could be sequential. 

In a large team, there are usually multiple engineers, designers, researchers and other executives who need to complete each goal before moving to the next one. There is the frontend, the backend, API integration and much more besides. Whilst product management is not project management, there are many similarities between the roles, in particular in prioritising tasks and building a sequencing diagram that brings all these tasks together and identifies the critical path to delivering the product. 

Whether I’m prioritising features for a new product or extending an existing one, it’s important for me to have oversight on the evolving nature of user behaviours, needs and preferences, whilst balancing these with technical capabilities, dependencies and the time and effort required to implement features. Bringing all these together in a visual critical path diagram using classic project management tools supports both planning and communicating what and when something needs to be done and why.    

Return on Investment Analysis

Okay, I should come clean. Driving ROI and business value-driven prioritisation is one of my top go-to methodologies. When faced with many good ideas, a straightforward ROI scoring system can help to identify and delineate finer differences in priority. 

Since we can’t do everything at once, we must do the things first that has the most value with the least amount of effort. Mathematically speaking then : 

Priority = Value/Effort

Value is ultimately a measure of the benefit the consumer and the organisation gets from implementing the feature or change. Whilst Effort is the sum total of what it takes for the company to deliver the said feature. In this formula whatever provides the most benefit for the least effort should be prioritised. 

Value needs to be aligned with strategy. As a product leader it’s important to not only strive to provide value to the customer by identifying and solving their needs, but also to understand the benefits the company will get from adding, changing or enhancing some aspect of the product. Building a better product then relies on balancing the need to drive business results whilst also focusing on organisational goals. 

Effort is the sum of all the resources that the organisation needs to spend in order to meet the customers’ needs and achieve the desired features. The higher the effort, the higher the value needs to be in order to justify prioritising it over other potential candidates. Whilst estimating efforts, it’s important for the product manager to take the lead in the initial estimations. I believe what sets a great product manager apart from others in the field is having a deep understanding of what it takes to implement something. This will only come through experience and working collaboratively with engineers and designers to continuously monitor, report, evaluate and update the implementation of tasks and required efforts. 

Overtime a great product leader working with a great team can accurately estimate the effort, although as with life, things sometimes take longer than we want. It’s important to be aware of this factor when carrying through risk analysis and to build in safeguards to ensure activities don’t run wild without clear processes of how to manage them. Equally, it’s important to have an organisation-wide view of the effort needed, taking into account the efforts on all other business functions of the organisation. 

By creating a sorted list of features taking into account the value against the effort we can quickly and effectively communicate and prioritise what needs to be built next. 

RICE model

The RICE model extends the Return on Investment approach for prioritisation by specifically taking into account Reach, Impact, Confidence as well as Effort for a given feature. The purpose is to score not just on Impact (i.e Value from ROI) and Effort – but to incorporate Reach and factor in Confidence too. The formula for a RICE score is

(Reach × Impact × Confidence) / Effort = RICE score

Since I’ve already outlined Effort and Impact above in the ROI model, I’ll briefly cover Reach and Confidence.

Reach can mean different things, from number of customer transactions to trial-signups, to how many existing users and customers try the new feature. It’s an estimate and it needs to be within a given timeframe, a month, a quarter or a year.

Confidence is a percentage value of how much trust we have in estimating the reach and impact of the given feature. A 100% score means we are very confident about the Reach and Impact estimates. Generally, anything less than 50% is often considered a high-risk estimate.

Kano Model

The Kano model provides three broad categories for customer expectation, these are: expected needs, normal needs, and exciting needs. Kano is most useful for prioritising features based on the customers’ perception. It requires an intimate understanding of the customer and their environment. 

The customers’ expected needs are roughly equivalent to the critical path. These are the needs that must be satisfied if the customer is to buy the product. If expected needs are met, we can move to the normal needs, these are not strictly critical but will add to customer satisfaction. Once these are met the exciting needs can be prioritised, these bring delight and the wow factor and provide features that go beyond the customers’ expectations. 

Of course expectations rise over time, what might be considered exciting today will be tomorrow’s expected need. It’s important to understand this, especially while building technology-focused products. The world moves at a very fast pace and by having a finger on the pulse of trends and new expectations a great product team can continue to navigate the marketplace to stay ahead of the curve. 

MoSCoW Method

Whatever framework is used to prioritise, it’s important to clearly communicate them to the whole team. The MoSCoW method provides a method for categorising the priorities list of requirements into unambiguous buckets, making it clear what the right criteria are. MoSCoW stands for Must have, Should have, Could have, Won’t have. 

Must-haves are all the requirements and functionalities that have to be there for the product launch. Sometimes called ‘minimum-to-ship’ features, without these the product can not be sold. Like a chicken sandwich without chicken! The bread on its own isn’t a sandwich. In product terms, this means fulfilling the minimum number of features the customer is willing to pay for. 

Should-haves are not critical, but very important. These features should be the last item to cut in order to meet budgets or deadline pressures. 

Could-haves are features that are not as important as the first two but may either be easy to implement or provide added benefits or solve a non-critical pain point for the customer. 

Won’t-haves are features that are out of scope for a particular release. Won’t have should not contain critical path items. Of course they could be brought in later but it’s important to communicate these upfront to avoid confusion about scope. 

Whilst MoSCoW is not a prioritisation method, it’s a great way to communicate scope priorities to the team. 

Summary 

Setting the right priorities for the right reasons and holding fast and steady when needed can be the make or break of a product. A reasoned and objective approach based on tried and tested frameworks is one of the best ways to work through all the good ideas, and once those are in place, it’s just as important to communicate them clearly to all stakeholders.