Jotham shares the spreadsheet he uses to guide our clients in building out a product backlog
Head of Product for a company that don’t actually own any of their own products (yet) may sound like a funny old role. Whilst we don’t build much for ourselves, we are always working for multiple clients in multiple industries, with multiple agendas and ambitions. I might not be in charge of any one product, but I do have significant input into about 10 different client products.
I sketch out design flows, help our clients visualise their ideas and discuss their long term strategies with them. I’d like to write more about these areas in the future, but for now, let's focus on building the product backlog
The answer is different for every client, but the process of finding the answer is pretty universal and clients usually have an idea of this already.
For some of our clients the next goal is a financial one; increase revenue or make some cost savings.
For others, it's a security issue; our service needs to be bulletproof to protect our customer’s information.
Furthermore, it can be a client’s internal politics issue (hey, this is a real thing, and important to factor in!). Stakeholder X wants to focus on topic Y because it unlocks Feature Z for another team.
And there’ll be countless others too.
My job is both to work with the client to justify (or otherwise) that this ambition will be of genuine value to their organisation; and then to help inform the specific tasks that will help them achieve this goal.
Of course, it's never quite that simple. The available budget, timeline pressures and any issues with the existing codebase all need to be considered. The client may want to build one thing but the App Store reviews can make it very clear that the users want something else. It can be difficult to make progress towards the client’s vision, whilst also protecting and improving the core of the existing product.
Over time I’ve developed a rough formula to help prioritise the right piece of work.
Usually, this exists in spreadsheet form. It’s not foolproof, but it does serve as a great tool for conversation, and it makes something which can be very subjective, a little bit more objective. Here goes:
For each potential piece of work, I have 6 categories:
User Value (How important is it to the user)
Stakeholder Value (How important is it to the stakeholder)
Conversion Value (Positive impact to conversion)
Brand Value (Positive impact on brand perception)
Maintenance (Positive impact on our ability to maintain the product)
Crash Rating (Severity of bug/crash)
For each of category, I give a weighting value (1 = not very important right now, 5 = the most important thing right now). It’s basically a score multiplier. I want the most important category to give me a higher score. In my experience, this is usually the ‘value to the end user’ category.
I then rate the feature against each of those categories, out of 3.
It’s kinda hard to talk through, so here’s an example:
Conclusion - I should prioritise that small improvement to an existing feature over adding support for Dark Mode, it will have a much bigger and better impact to the customers and to the product in general.
This may seem like a complicated process, but once the spreadsheet is set up, its a really powerful tool for decision-makers. Its also easy to update it as goals and ambitions change within the client’s organisation.
The spreadsheet can grow and expand whenever someone mentions an idea, an area of the code to re-write or a new bug comes up in QA. It can serve you in whatever way is most helpful.
If you’re looking for further ways to justify the priority of a feature, User Testing is our favourite place to start.
Something may come up with a very high priority score, but the budget may not allow for it to be built this quarter. In that case, what’s the best use of the available budget so that the product can maintain some kind of momentum?
It doesn’t take too long to get a super rough ‘Tiny, Small, Medium, Large, Extra Large’ estimate from the development team. You can use any scale you like for this: actual effort days, story points etc. The end result will be similar.
Once you’ve got that, you can take the priority score and divide it by the estimate. The higher the resulting number, the more value for cost you’re likely to get out of that task.
This exercise doesn’t seem like the most creative of tasks, but once you’ve established that something is objectively important to build and focus on, you can assign much more effort in its creative solution because you’ll be much more confident that its the right thing to build next.
Search over 400 blog posts from our team
Subscribe to our monthly digest of blogs to stay in the loop and come with us on our journey to make things better!
We develop intelligent mobile apps for iPhone & Android that deliver for you.
Want to connect? You can find us on Instagram, Facebook, X (formerly Twitter) and LinkedIn.
Here’s our privacy policy.
Here’s our Accessibility statement.
Copyright © 2024 Brightec Limited. All rights reserved.
