Over the past several weeks, we’ve used our website to share with you several different feature prioritization frameworks. Some, like Kano Models, are more useful very early in product development. Others, like WSJF, go hand-in-hand with agile frameworks and scale-up incredibly well for larger organizations. Still, our review of feature prioritization models would be incomplete without acknowledging the simplest one. After all, in software development, we frequently discuss minimum viable products. So, too, should we consider the simplest method of feature prioritization I’ve seen used successfully through the years.
Oftentimes, feature prioritization need be no more complicated than asking the stakeholders, “If you could only have one thing, what would it be?” This introduction of a forced constraint forces dialogue among the product team and, assuming there’s relative agreement within the group, gets you rowing in the same direction.
Consider the key reasons for utilizing any type of feature prioritization framework:
- Features are seldom force-ranked by business value, so teams spend too much time on functionality that produces little return on investment.
- Too much time goes by between the spec being written and the stakeholders seeing working, shippable software. By the time they provide feedback, it’s too late to make substantial changes.
- There isn’t enough interaction between business visionaries and the development team to keep them informed about changing priorities along the way.
When asking stakeholders for their “one thing,” we can see how it goes a long way to overcoming key challenges of prioritization. First up, this technique ensures that everyone knows the top-ranked feature. Moreover, by being the top-ranked feature, it will be worked on soonest, meaning stakeholders will be able to view progress sooner. And of course, progress is key for interaction and communication between teams. And that’s why choosing “one thing” is the simplest method for feature prioritization.
If you’re seeking something with a bit more complexity than “one thing,” a slightly more intricate approach is the MoSCoW model, which breaks the nice to have features into should and could haves. In general, you’ll likely find that the longer your backlog is, the handier the use of an intricate prioritization becomes.
However you segment your potential features, if you’re moving beyond “one thing,” you’ll need need to rank each feature based on business value. Assuming your team is closely aligned and has a solid understanding of your business goals, this ranking could be rather simple. At the same time, if your feature list is gargantuan or if your team isn’t aligned, some of the methods we’ve shared to measure either the reach or the impact of a given feature could be useful.
Those who’ve followed the various prioritization frameworks we’ve addressed might be noting that as of yet, none of this advice has taken into account the effort required to develop a given feature. To be clear, story pointing – the process of understanding the effort to execute a given feature – has an entire section within my book The Epic Guide to Agile, but it appears several pages later, after business value has already been established.
When I wrote The Epic Guide to Agile, it was critical to me that user business value was discussed prior to estimating effort. As you’d expect, the features that deliver the most value frequently require more effort, but it’s vital that estimations inform – but not cloud – our acknowledgment of the potential user business value.
