The Market Prioritization Framework (Part 3: Calculating Market Value)
Mike Lattiak, Senior Product Manager
With your product values established and your pipeline all set up, now it is time to figure out what to do with all these requests coming in. In this part, we will begin examining each item in your current backlog along with all new requests being sent through your pipeline. For each item, you’ll be working through a formula designed to help you determine an accurate and easy-to-update market value. At the end of this exercise, you’ll know exactly how much your market prioritizes each and every feature request.
So what is this formula?
Market Value = (Frequency * Product Impact) + Urgency
It is rather simple, but each component of this formula has its own rules we’ll need to go over in detail. But don’t feel locked in! Think of this as the ‘baseline’ formula to use. As you continue to read the article, imagine what other factors might need to be added to your own personal calculation.
Determining Frequency
Frequency is the amount of unique requests that align with a problem you are aiming to solve. This is a critical measurement to understanding the urgency of a pain point across the entire market. Issues that affect a single customer vs a widespread issue need to be properly identified when prioritizing.
Out of everything covered in this guide, being able to judge frequency can be the trickiest. It is easy to succumb to hive minding - where an idea presented by a single person can quickly snowball and give you an unfair representation of how many individuals actually need it. A simple example of this would be to get in front of a group of users and ask “who would like this feature?”. You will get a lot of raised hands! Users typically don’t understand the concept of priority and how it relates to limited development resources. So of course, they will throw their support towards anything that might sound remotely useful.
Instead, we want to narrow down frequency to individuals or groups that are suffering from a pain point identified in your value proposition canvas. This moves the conversation away from polling for specific features and instead records how many users are suffering from a problem that has a multitude of solutions. This will allow us to avoid duplicate data and make sure that all voices are equal. So how do we do this?
Internal Requests
Did it come from the minds of a product manager, designer, or executive? These might be born from discussions or internal testing of the product itself.
Treat all internal requests as a single source of information. Even if both an executive and designer have requested the same feature, it is still wise to record the request. However, since this request has not come from a user in your market you should not increase the frequency. Instead, add a tag of ‘Internal’ to the item. Communicate back to the requester that once data from the market is found that supports the request coming in, you’ll be able to update the frequency accordingly. That way, you can continue tracking the item in your backlog but you are not recording an inaccurate frequency.
User Requests
This is the heart and soul of the frequency tally. Each individual request that comes in needs to be examined to understand where it came from. Based on your product and how frequently you gather feedback, you might end up running into duplicate requests. Unfortunately, there isn’t really a “magic bullet” approach that works for all organizations. Instead, consult with your product team before proceeding. Below are some recommendations to help kickstart the conversation:
B2B Products / SaaS: For tracking business requests, are you polling individual users at the business, or are you just talking to managers / stakeholders?
If a single pain impacts an entire department, consider only tracking it once for that business. If multiple businesses have the same pain point, then it can be counted as different frequencies.
If the businesses you are working with are too large or complex, consider utilizing user personas to help differentiate unique requests. This is particularly helpful if your product is divided among different user types. This does allow for the same request to be counted multiple times at a business, as long as different user personas are bumping into the same problem.
B2C Products: Each individual request represents a unique frequency count. Be mindful of how you are gathering this feedback, a large user base can easily be persuaded to pile onto a single request.
Internal Products: If you are building a product for internal use, treat each individual in the organization like a user and give them their own frequency count.
It is also crucial that nowhere in this process do you make assumptions about your users. Don’t include them as part of the frequency unless you have direct data that shows they need this enhancement. Make sure with each increase to the frequency that you have documentation linking the user to the request. This will also allow you to properly reach out and communicate to users when the feature requires feedback or is about to be released.
Determining Product Impact
A scale of 1 through 5, product impact helps measure the direct result a request would have on the market. Utilizing your product values, you will need to analyze each feature request and assign it a number. This number can change over time, particularly as your product continues to mature.
We recommend defining the values as follows:
5 - Losing Market Value
4 - Aligned to an Aspirational Product Value
3 - Aligned to a Current Product Value
2 - Nice to Have
1 - Not in Market / We Don’t Sell
Impact Rating | Details | Examples |
5 - Losing Market Value | Without this functionality, you are losing customers. The pain point is so great that users won’t use your product without it being solved. These occasionally align with your aspirational product values. These requests should be relatively rare as your product matures. In most cases, they appear shortly after an MVP is launched and will already be identified as a high priority business value. | No iOS or Android support. Not allowing the user to perform a fundamental part of their job in the application, like reporting or communicating. These are large scale modules that introduce solutions to pain points not previously solved by the product. |
4 - Aligned to an Aspirational Product Value | A request that directly aligns to at least one aspirational product value. Request directly impacts the core purpose of the product. You can prove through quantitative means that this request improves user success / happiness. If you don’t have any more aspirational product values, then features that revolve around multiple product values tend to settle here. These increases are so drastic that you could easily write a case study about it. | The feature can substantially save a user time and money. This can be a new report that showcases inefficiencies at a company and allows the user to fix them. |
3 - Aligned to Current Product Value | A request that directly aligns to at least one product value. The vast majority of requests should fall into this category. | Standard feature development. Adding in a dashboard to promote accountability, creating a chat bot to encourage communication, adding a user forum to deepen community, etc. |
2 - Nice to Have | Requests that are not direct needs of the marketplace, but still improve the product. These features might slightly align with a product value, but fall more under the bucket of ‘usability improvements.’ | Basic improvements to the UI/UX (quality of life), small modifications to existing functionality, etc. |
1 - Not In Market | The request represents a market that your product does not participate in. These are features you would normally dismiss or archive. | Expansion into new markets, like if you were a home rental product and someone requested expanding into car rentals. |
Determining Urgency
Urgency is a metric that is used to determine how users weigh the priority of a request. It is useful in identifying more passionate requests made by users. Are users angry that the feature does not exist? Or are they just casually noting it? Do they consider it a defect? Do they call up every few months to complain?
It is recommended that you work with your customer support or customer success team when defining these values. You’ll want to use a rating from 1 to 3:
1: The default urgency. Just by submitting the feature, the number is set at one. These are wants / nice to haves from their perspective.
2: The user is indicating a stronger desire for the feature. They need it to be successful. They are typically passionate about the need, wanting to know more information about its release / timeline. Users who frequently come back to request the same feature again and again typically fall into this category.
3: The user has passionately stated their disapproval of not having this feature. Typically the user is angry / upset and has reached out to you.
When assessing impact from multiple users, you’ll want to assess urgency based on an average of the data. If the majority of your users are not communicating a sense of urgency, we strongly suggest that you stay within the 1-2 range. The purpose of this metric is to modify the end prioritization ranking by just enough to separate high urgency items from the pack.
Backlog Impact
Once you’ve gone through your backlog and added this new value, take a step back and examine the outcome. Depending on the age of your product and the amount of requests that have come in, you should begin to see items that clearly stand out above the rest. In fact, most backlogs that have this value properly applied begin to look like the following:
This is a backlog that consists of about 50 requests, sorted by market value. From a visual standpoint, the line looks like a ‘reverse hockey stick’, with the top of the backlog having a significantly higher market value than the bottom. This is reflected by the blue line, which shows the cut-off point in your prioritization. Everything to the left of this line exponentially increases as you continue to identify pain points and update frequency/impact.
The other interesting feature of this prioritization is what we refer to as “backlog purgatory”. Data will quickly flatten and about 60-80% of your backlog ends up consisting of low impact requests submitted by a single user. These items will likely stay in this purgatory until an additional request comes in, increasing the frequency and shooting up the ranking.
Conclusion
Always remember that market value is just a component of your overall prioritization. Despite the complexity of this process and how it might initially impact your backlog, there are still a lot of missing elements behind prioritization not covered here. For example, development complexity, business value (ROI), risk, or even design size. These factors can be vital to consider as well, particularly when it comes to understanding your current product vision or yearly goals.
So instead, remember to think of Market Value as a single but vital data point in your decision making process. This data will allow you to bring clear communication from your market to your product team, empowering you to make impactful decisions