Feature Priority: What Makes the Cut?
Inequality exists among feature priority — there’s no getting around it. Sometimes there are great ideas when it comes to adding features. But, let’s be honest, sometimes ideas are less than stellar, too. The question is, how do we know which ideas will ultimately increase a company’s profitability?
Unfortunately, we don’t — not at first, anyway. The good news is, there are lots of ways to vet and synthesize ideas and hypotheses into more usable plans. There’s pragmatic marketing, design thinking, various product management frameworks, UX research best practices, and more. In this post, though, I’d like to add some context as to how we determine feature priority.
A Spacey Illustration
I was once asked to prioritize planets by habitability. Naturally, Earth was my number one choice, then came Mars. After that, I was pretty stumped. All things considered, Mars is a pretty harsh place to live. I don’t know that I would exactly call it habitable, either. More like merely tolerable. It will most likely let us live there eventually, after some hard, hard work.
For the next slot on the Planet Habitability List, I choose…Jupiter? I guess? Mostly because it has a perpetually maniacal storm I’ve always found fascinating.
Where am I going with this? Product teams often place features on a priority list. Features often first go into the backlog where a development team eventually takes them in turn and refines them until they are ready to deploy. But this doesn’t necessarily make a whole lot of sense.
Such practices are the same as equating Earth to Jupiter in habitability when they aren’t really in the same ballpark. If an extraterrestrial came and saw my “Planet Habitability List,” they would see Jupiter as third on the list and likely conclude, “Jupiter got Bronze, not too shabby. Maybe I’ll go there.”
What’s the score?
The habitability example above is why we need to give our features (or outcomes, or however you manage your roadmap) a score (or something similar) to give them context. Considering my planet analogy, I would score them this way:
- Earth: 99
- Mars: 2
- Jupiter: .0000001
Now that we have some context, Jupiter doesn’t seem that hospitable. Sure, it’s third on the list, but in terms of score, it’s far from “bronze.” If we’re being realistic, we should probably remove it from the list entirely.
This is how we handle software features too. If it shouldn’t be on the backlog, we’re taking it off. Features that help customers build and enhance their order-to-cash strategy take priority every time. Features that don’t add value to the end-user are the ones that belong on the backlog.
Use the right tools
We use many tools to score roadmap-level features, but the real trick is to not compare features to each other as if they are all equal, unless there’s a clear reasoning for doing so.
Another important question to ask is, “are we using the right metrics to score these features?” If we use habitability as our metric, Jupiter clearly loses. But if we use size, well, Jupiter obviously wins.
We also want our customers and stakeholders to understand this philosophy, as well as the reasoning behind it. We won’t settle for, “It’s in the backlog, but we’ll probably never get to it.” If a feature scored poorly, it’s probably because it felt a little too much like a Jupiter. That doesn’t mean it’ll never happen, but it means we’ve determined that there are other features in the queue that would offer more value sooner.
Feature priority is all about efficiency
Knowing how to use the right framework to determine feature priority is a discussion for another time. For now, focus on simply scoring them at all. By investing a little bit of time in scoring feature sets, we can make sure we deliver value with every release.
Want to be involved in the improvement process for SalesPad Desktop? Starting in SalesPad Desktop version 5.1, you can leave us feedback! In the upper right corner of the application, there’s a “Submit Feedback” button. Clicking this will bring up a short form where you can offer your thoughts on what you like, what you don’t, and what would make the program better. We always appreciate your input!
This post was written by Software Product Manager Alex Schelhaas.