A daily newsletter on building software products for non-technical founders. Give me two minutes a day, and I’ll help you make technical decisions with confidence.
The order in which you build things matters less before you have any users. Assuming you have a clear idea of what will be valuable to your customers, you just need to build it as fast as possible, without sacrificing quality. After launch, you'll typically start getting feedback and feature requests from customers. You'll take the best (or loudest) suggestions and refine them into well-defined user stories. Then they go on the backlog. So, let's say you have three seemingly equally valuable features, which are independent of each other. Which one should you build first? And why is it hard to answer this?!
What do we do? We can turn to frameworks designed by product/project teams to help us. There are many, but let's look at RICE because it's relatively simple. It could be considered an oversimplification but, as a way of modeling this decision, I think it's a useful guide. Intercom, the customer service company, created the RICE prioritisation framework to help their Product Managers answer this question. RICE is an acronym for: Reach: How many users will benefit from this? Impact: How significantly will it improve their experience or solve their problem? Confidence: How certain are you about the benefits? Effort: How much time and resources are required? Essentially you assign a score to each vector, apply these to a formula and then you can compare the result between your tasks. There's a little bit to scoring but I'll try to summarise it here. Reach: How many people or customers will the feature impact in a specific time period? Impact: The size of the improvement on the user experience: Confidence: How sure are you about the estimates for reach and impact? Effort: How many person-weeks (or other effort units) are needed to complete the work? Once you've determined those, they go into this formula: Here's an example from Intercom themselves: Based on this framework, the higher the score, the higher the priority should be. Now you have a way of objectively ranking your tasks by priority. This is just a guide, and there will be exceptions. But if we're really unsure of how to prioritise the next tasks, this beats rolling a dice! |
A daily newsletter on building software products for non-technical founders. Give me two minutes a day, and I’ll help you make technical decisions with confidence.