Half of us were annoyed. The other half were pissed.
“We have to let users ‘undo’. Our product is useless without it," I argued (I was on the pissed off team in case you’re wondering).
“But nobody is going to NOT buy our product just because there’s no undo," came the response.
We argued far longer than we should have, debating the intricacies of an undo button and whether our engineering team should develop this one feature for our customers.
After multiple meetings, half a dozen arguments, and hurt feelings all around, a decision was finally made.
Sort of.
3 Things We Should Have Done Before Prioritizing
It turns out, we weren’t able to prioritize which features to work on because we didn’t have a handle on 3 things. To be clear, these are the three questions you should be asking yourself before you attempt to prioritize the features of your own product:
- What is the goal of your product? Alternatively, how does it fit your company mission?
- What markets and customers does your new product serve (and how does it serve them)?
- What is your products' target return on investment (ROI)?
Let’s look at each in detail.
1. Company Goals and Mission Fit
Yes, before considering anything else, you need to know your products goals and how those goals further your company mission. And I’m not talking about the mission statement that now sits on a poster in your lobby… or the one you wrote and threw in a drawer years ago.
I’m talking about your core purpose as a company… The reason your company exists in this world.
Not every product makes money, after all. Some products are meant to drive adoption. Others are built to increase brand recognition. Many aim to gather customer data.
Regardless of the goal, if you don’t know what your product is trying to accomplish it will be impossible to prioritize features.
And if your product goals aren't aligned to your company's mission, you'll be wasting time and money better spent focusing on goals that do.
If you’re not sure what your core company purpose is, read our article on effective strategic planning for small business. Skip to about halfway down where we describe how to create a purpose statement. It’s fundamental to building and growing any business.
2. Markets and Customers Served
With your product goals aligned with your company mission, you need to know which markets you serve. Too abstract for you? Focus on how your product helps your customers solve specific problems.
Only when you understand your customers' problems will you be able to prioritize features.
Without that understanding, you'll waste time working on cool ideas that don't help (and won't sell).
3. Target ROI
ROI, or return on investment is often (mistakenly) calculated after the fact. But this is a big no-no.
Why?
Because without comparing how much you will invest in your product vs. how much you expect to make in return, you are literally shooting for success in the dark.
Whether the goal of your product is to collect customer data, get social shares, or (in most cases) profit, you must know that single metric by which your product will be measured. This metric, when compared to your development cost, is your ROI.
Once you know your products estimated ROI you’ll finally be able to prioritize features since you’ll be able to compare how each feature contributes to that ROI overall.
Using These 3 Critical Values to Prioritize Features
So, are your product goals are clear? Do they fit your company mission? Do you know exactly what markets your product serves and what customer problems your product solves? Do you have a metric by which to measure your product against development costs?
If not, get a handle on that before reading on.
Made it to here? Awesome. We still need to prioritize product features, and to do that we'll need to quantify two important things on a feature-by-feature basis:
- Business Value
- Development Effort
Why we need to quantify these things will become clear. For now, just think of it as calculating an ROI for each and every feature under consideration.
Calculating Business Value
To calculate business value, you’ll need to refer back to your products goals and compare them across your target market. In other words, business value (in the context of product development) is a function of how many customers you can help times how each customer contributes to your products goals.
Business Value = # of Customers Helped x Value (Revenue or otherwise) per Customer
If you’re the anal retentive type who needs to quantify things (like me), here’s an example: If you can capture 10% of your target market of 100 customers with feature A, and each new customer is worth $1,000, the business value of feature A is:
100 (customers) * 0.1 (10%) * $1,000 = $10,000.
A faster way to calculate business value is to plot its relative value against other features you are considering. It’s less quantifiable but still effective. More on this method below...
Calculating Development Effort
As for development effort, you can do an exhaustive analysis of all the research, time, and other development costs required to develop each feature. But I’d recommend against that.
Instead, plot development effort for one feature relative to the development effort for other features.
I like to use the Fibonacci sequence to assign a development effort “value” to each feature… that is, would my development effort take 1, 2, 3, 5, 8, 13, 21 weeks or more to get done? It’s imprecise enough to capture development effort with your gut, but still has some value that you can use to compare against other features.
Pro Tip: If using ‘weeks’ with the Fibonacci sequence is too long or short, just change that unit to minutes, hours, days, months, etc.
The Prioritization Chart
Bringing it all together, let’s make a 4 quadrant chart with Business Value measured on the horizontal access and Development Effort measured on the vertical access. ProductPlan.com illustrates it well here:
Diagram courtesy of: 7 Strategies to Choose the Best Features for Your Product
From here, it’s easy to see which features to prioritize first. Throw out the low Business Value / high Development Effort features and focus on those features that are easy to implement and bring a lot of value.
But we’re not done yet.
Even in the chart above, there are a few features in the high-value/low-effort quadrant (quadrant 1) that could be debated for eternity. This is where you may want to assign a P-value, or development priority, to each of those features.
P1 | Highest Priority |
MUST be done during the next development cycle… the product will not be considered complete or upgraded unless it’s finished, tested, and ready to rock and roll.
P2 | Medium Priority |
SHOULD be completed during the next development cycle… the product can be considered complete without it, but will be severely lacking a highly desired and valuable feature.
P3 | Wishlist |
MAY be completed during the next development cycle if there’s time. If complete, will be icing on the cake. If not, no worries, it will be re-prioritized for the next development cycle.
How can you tell if a feature should be P1, P2, or P3? Ask yourself one simple question: What will be the cost of delay?
“If you only quantify one thing, quantify the cost of delay.”
A Quick Note on Tools
Part of prioritizing features comes down to the tools you use along with this recommended process. Here are some of my favorites:
- Trello | This is my current favorite. It’s like a digital whiteboard covered in sticky notes. Each sticky notes has a feature name with a description, and you can assign other values to them. Move them through the process, left to right, until they are ready for release! Awesome.
- Excel | Tried and true, Excel (or Numbers if you are all Mac’ed out) is a simple yet effective way to prioritize things. You can organize each feature into rows, and have columns for P-value, feature name, business value, development effort, notes, etc.
- Sticky Notes | No, not the Windows or Mac app… actual paper sticky notes on a whiteboard. This is not only incredibly effective at prioritizing features in a group setting, it gets people physically active which has a unifying effect on a team (read some of our articles on team building here >>).
Back to Undo
Remember that argument about the undo feature? As I said before… we finally decided what to do.
Sort of.
No undo feature was added because we couldn’t agree on what to do. It was decision through indecision... And of all the ways to prioritize product features, this was (and remains) the worst.
It was the last time I would let emotion drive a product decision. It was the last time I would walk into a prioritization meeting without data to drive us in the right direction. That decision was the beginning of the development of this process, and the last time we would operate without one.
I hope this helps. This was a process I’ve seen used and used myself to great effect over the course of developing nearly 20 products.
If you want to dive deeper on how to know whether your product will be successful in the market, read my post on 8 Questions Your New Product Idea Must Answer (Or Fail Miserably) >>
About the Author
Michael Mehlberg
CO-FOUNDER | TECHNOLOGY, PRODUCT DEVELOPMENT, MARKETING, AND SALES
Michael Mehlberg helps small businesses owners achieve their goals and live their passion. His approach to technology, corporate strategy, product development, marketing, and sales is both practical and highly effective, and has helped multiple small businesses grow into the company their owners envisioned. Reach out by emailing him at mike@moderndavinci.net or learn more on our About page.