Risk-Impact Prioritization

It’s important to have a minimum viable design to test your hypotheses so that time is not wasted on a design that doesn’t have enough demand to be successful. But as a PM, you’ve got so many vested parties and stakeholders to deal with – higher management, board members, development teams, marketing, sales, not to mention higher-ups in the product-chain itself. Everyone has ideas for what the MVP should look like and what features it should consist of. But you only have finite resources and a narrow window of time to get that early version of the design out the door for a few select customers to try. How do you decide what features make it and what don’t, and how do you justify those decisions? It can prove to be very helpful to have a framework for this at your disposal.

One such framework is the Risk-Impact equation. It takes into account two crucial aspects that end up mattering most, per feature, on the journey towards your MVP. Read on to learn more.

Estimating Risk

It is important to understand, and maybe even quantify, how likely it is that this feature is going to be implemented in time. The important questions to be answered are:

Is it technically very challenging?

Let’s take the example of a new text editor, and the feature being considered is a cool new prediction system like Google Suggest, that will try to guess how you plan to complete your sentences. Showing off an MVP with this cool new predictor sounds very tempting indeed. But your engineer tells you it is not easy to build a deep learning system from scratch and get it to work on a given application. The system would need to be built correctly, would need to be trained to fit the needs of this application, and finally it would need to be tested for correctness and sanity. On the other hand, if the feature being considered was a new color coding scheme that helps make the editor’s user interface more intuitive to the user, that is something that might be relatively less risky.

Is it something that does not tap into the expertise of the current engineering staff?

Most times, engineers have their areas of expertise and interest. A back-end engineer is less likely to be happy coding up the user interface, and may not even be great at it, while a systems engineer may not be the best person to implement a machine learning model to predict outcomes (or in our case, the remainders of sentences.)

The risk associated with a feature is also dependent on the nature of the team. As a PM, it is important to understand well the strengths and weaknesses of the team, and the areas of expertise. If you want to release this MVP quickly, the focus can not be on hiring new engineers and it also can not be on training the existing engineers. It is important to figure out what features are out of the scope of what the current team can do, and categorize them as potential risks.

Is it just a lot of work?

Even if the engineering staff is capable of implementing the feature, the difficulty level and time constraints at hand need to be factored in. Smart and careful utilization of engineering resources at an early stage can prove to be very beneficial in the long run, and so from a PM perspective, you need to have clear prioritization of those limited resources. In this case, “risk” doesn’t just imply the risk associated with this feature not being built in time – it can also imply the risk of this feature blocking other features from making it.

It should come as no surprise that your biggest inputs to measure risk will come from the engineers. But it is important to ask the right questions, so that their answers can fit into this framework.

High risk features should be given lower priority, since spending time on them might not be the best way to spend time. If they don’t end up being implemented, it could have a negative impact, since crucial time was wasted in vain for a design that was meant to validate the demand for the basic idea.

Estimating Impact

How much will this feature matter to the audience? Higher impact features get priority over lower ones and sometimes this can even translate to fewer features in the product. Measurement of impact should be done considering all perspectives.

Overall impact on the product:

If the feature matters a lot to the overall product vision and contributes significantly to the core meaning of the product, then it should be rated as a high-impact feature. This is the type of feature you want your early users to get a look and feel for, since their feedback for this feature would be of high value in the bigger picture. Products that are run-of-the-mill and not that important shouldn’t score so high, since early feedback on them may not affect the overall product journey.

Impact relative to other features:

Early customers are going to have limited experience with the MVP. You want to give priority to the features that are going to stand out compared to the rest so that the users actually “get” what the product is all about. In a text editor application, you want the user to try the new features that you are bringing to the table (like that predictor system) rather than the usual features that one would generally associate with a text editor, like a font style or a layout.

Impact within the scope of the MVP exercise:

Again, early customers are going to have a limited experience with the MVP. Consider this thoroughly when designing for the MVP. A deep learning system that remembers the preferences of users over time is less valuable for a user that only gets to use this product for a few days, but could be extremely valuable for the actual product that a user will own or use for years, presumably. You probably don’t want to prioritize this feature over other features that could actually stand out in a limited span of time. Even if this feature is a “must-have” for the MVP, it could be valuable to spend some time deliberating over “how” to bring it out to the forefront so that it is clearly demonstrated to the early users, in order to get reliable feedback from them.

The Matrix

Once these parameters have been measured, build a “risk-impact matrix”. This is visually appealing and makes it easy to express all of those complex equations in a simple way. Divide the matrix into four quadrants: (clockwise from the top-left in the figure below) high-risk low-impact, high-risk high-impact, low-risk high-impact, and low-risk low-impact.

Features in the third quadrant should be prioritized over all others – these pose lowest risk and yet make the largest impact. Conversely, the features in the first quadrant pose highest risk and have the lowest impact. So it makes sense to give these the lowest priority, and maybe re-visit them at the end if there is room/time left. Among the remaining two quadrants, prioritization should take into account the company, product, and requirements. If the theme is to go conservative, the fourth quadrant wins. Sometimes you want to be aggressive if you have enough confidence in the rest of the product – that’s when you could consider prioritizing the second quadrant over the fourth.

So our theoretical prioritized list of features would be: D, A, B, C – I’m a conservative guy.

Finally, although this discussion was applied to building an MVP, the truth is, a framework like this would work in the same way even if it is a real product release. There will always be finite resources and a large number of features to pick from, and there will always be a need to prioritize. Holly Hester-Reilly provides her first-hand insights on this type of framework in her appearance on the podcast This Is Product Management – definitely worth a listen!

 

Leave a Reply