All software platforms must evolve to thrive and survive by adjusting to users’ needs and, when justified, expanding core functionality. The challenge for leadership and product teams is to select the features that provide the greatest ROI with acceptable risk. Too often, feature development is driven more by gut instincts than by a more methodical evaluation of options. In this article, we’ll walk through a very approachable method for identifying and validating your winners in the backlog.

When determining your software’s next set of features, consider feedback from various sources, including customers, user experience, and key stakeholders. This list of features can be displayed in a visual representation or roadmap of where your software is headed and used to explain your vision. A product roadmap is not just a development schedule but a communication tool for the internal team, customers, and key stakeholders. Some features may need to be broken down into smaller features to be accurately scored.

After receiving feedback from users, customers, and key stakeholders, it is time to prioritize features on your product roadmap. Where do you start? Like prioritizing tasks within a to-do list, begin by comparing the value associated with each feature and the resources needed to complete it. One strategy to do this is by comparing Value vs. Risk.

Value is, of course, a key aspect of any product development. This is what drives not only your business goals but also user or customer success. Often, understanding the value of certain features can come easier than identifying risks. When we can work and build relationships with our customers and/or users, hearing what brings value can come naturally. However, Risk is often overlooked and critical in determining how to manage your product successfully.

Identifying Risk

Before we determine what to build, let’s identify the risks of each feature. Risk in this context can have a few different meanings. Before diving into each one, obtain feedback from various individuals within a cross-functional team. If you do not have a team that you work with already, find individuals who provide subject matter expertise. Key individuals to include in these conversations can be those with a background in product development, intellectual property, customer/user success, or business strategy, to name a few. When diving into these conversations, consider the below questions:

• Cost –How much will development or planning cost? Do we need to identify resources that we don’t already have? This can be both time and materials. It can also be related to other costly risks, such as regulatory or security obstacles. Will this feature introduce security or regulatory risk?
• Time – Similar to cost, this is how long the features are expected to take. But, it is not just about programming work. Also, consider this in terms of the steps needed to build the feature. Do you need to wait on a partner for API integration? Do you need a certain amount of data to create an algorithm? How urgent is this? Will you lose customers if this isn’t done on time?
• Effort – Will you need your technical lead or the most experienced developer? Are there gaps in your team’s skillset that you need to build before starting the project? Is this part of the software’s main innovation that needs to be flushed out? Is it even possible to build it?

Each of the above categories may be unique to your project. With your team, determine which is the most important.

Identifying Value

Now we need to identify value. Value in this context can also have a few meanings.

• Strategic vision – Will building this feature help paint the picture for investors? For potential customers? Is this a core feature needed to validate product-market fit? Is it scalable? Does it need to be scalable?
• Milestones/KPI – Does this feature move the needle for revenue or daily/monthly active users? How will it affect product performance (e.g. usability, software speed, loading, etc.)? Will this feature help you reach milestones for a strategic partnership?
• User and customer success – Is this a feature that would make a user or customer more likely to adopt your platform? Is this feature something that will make the product more valuable overall? With this feature, are you able to offer variable or tiered pricing?

Scoring Value and Risk

We just defined Risk and Value in this context, so now we can score or grade each feature. There are several ways to do this. For example, you can make up your scoring system and think broadly and relatively to the features on the list, such as “Low, Medium, High.” You can also score features on a 1-5 numeric or Likert scale. However, I recommend starting simply until you become more familiar with the process.

Create a table like the one below with at least four columns. The column on the left will be the list of features. “Source” can be where those features came from. For example, was this feedback from a customer? This information then ties back to your Product Requirements. The two columns will be where you will score your Value and Risk. Lastly, the “Roadmap” column is where you will indicate when on the roadmap you expect to work on the feature.

Example of Value vs. Risk Table

UX: user experience, BV: business value, CS: customer success

Let’s work through this example. 

The first feature we will score on is: “integration with social media.”

• Value: Users mentioned they would like to see this in the software, but it doesn’t make or break their overall experience. In other words, we wouldn’t directly lose revenue opportunities from not having this feature. We will consider this a “Low” value.
• Risk: Integration with social media is more complex than we thought. We need to add a few new pages/screens. We will consider this a “High” risk because it will take longer compared to the other features, and we need to bring on a UI/UX designer to help with the workflow and screens.
• Risk vs. Value: Compared to the other two features, this feature has low and high risks. That said, this is the lowest priority.

Let’s do one more. The next feature we will score is: “Single-Sign-On.” Users asked for this feature, and from a business value perspective, it will increase the likelihood of a person making an account.

• Value: Users mentioned they would like to see this in the software, and it directly impacts the ability of a user to sign in. This moves the needle from the user acquisition and revenue perspective. We will consider this feature a “High” value.
• Risk: Our team has built similar sign-in processes before, which is a relatively easy feature to incorporate into our software. We will consider this a “Low” risk.
• Risk vs. Value: Compared to the other two features, this feature has high value and low risk. That said, we will make building this feature a high priority.

Back to the Product Roadmap

Once we have prioritized features, we can develop or add them to our product roadmap. The far-right column in the graphic above leaves a space to add when you plan to develop that feature. There are many types of roadmaps, but for the sake of simplicity, we can place our features on a timeline. Using a timeline helps you determine when it is realistic to work on a feature. Consider roadblocks such as the availability of your resources, big marketing events coming up, or customer meetings. It is particularly important to consider High Risk, High Value items that may take a longer time to execute but are important to accomplish. In this case, it may make sense to break these into smaller features before adding them to the roadmap.

Once you can compare features on a timeline, you start to see patterns in when you’ve decided to work on each feature. However, a timeline isn’t always necessary. Especially for ideas coming off the ground, it is often simpler to decide your next goals for the days or months ahead versus an entire year. Check out this blog post for more detail on developing a strategic plan and product roadmap.

Now that you have a list of prioritized features and your roadmap, you can share it with your team and key stakeholders. This exercise will help you consider the value and risks of what you are building before having critical conversations and getting feedback. 

In order to evaluate and prioritize the Risk vs. Value of feature development, it is important to consider the various meanings of Risk and Value in the context of your project. This includes factors such as cost, time, effort, strategic vision, milestones and KPIs, and user and customer success. By comparing these factors, it is possible to make informed decisions about which features to prioritize on your product roadmap. This will help you achieve your business goals and deliver value to your users and customers.

If the concepts in this article peak your interest, let us know. The REEA Global User Experience Research team can deliver studies that inform the next iteration of your product with nuanced user feedback and then engage an in-house team of 140+ engineers to bring it to life. To learn more about how to compare Risk vs Value, please contact us today.

Explore REEA Global’s recent articles featuring:

• Beyond BigCommerce: Unboxing Full-Stack Solutions for E-commerce Success
• Scaling Beyond Plug-and-Play: Why Engineering Expertise is Key to Next-Level E-Commerce Solutions
• Navigating the Drupal 7 Sunset: A Strategic Guide for Enterprises
• Unlock Your Business Potential with Custom Software Development: A Personalized Approach to Overcoming Growth Barriers
• Navigating Leadership Transitions with Technology Partners: A Path to Rapid Momentum in Software Development