So, you’ve got an idea for a digital product. It could be a website, a mobile app, an IoT platform or a recommendation system powered by machine learning. The potential of today’s technology means that an increasing number of ideas can now be turned into reality.
But what does the journey from idea to reality look like in a digital world? Well, there’s a multitude of things to consider, ranging from the tech stack your product will be built on to how it looks and feels in the hands of users.
Those tasked with overseeing this journey manage to avoid being overwhelmed by relying on a product backlog – a prioritised list of work that design and development teams are tasked with completing. It is the single authoritative source for things like features, functionality, bug fixes and infrastructure changes. If it’s not on the product backlog, it doesn’t get done.
I’ve managed projects for 30 years and have a lot of experience delivering products for other people. During that time, the biggest issue when starting a project or getting an idea off the ground is that it’s all in someone’s head. This makes it hard for the people who will actually end up working on the product to understand its size, scope, objectives, users and direction.
A product backlog is all about articulating what’s in your head to help you achieve your vision. It means you objectively assess what you need to do and when, splitting pieces of work up into chunks that your team on the ground can deliver.
But managing and mastering a product backlog is no mean feat. Here’s a few tips I’ve learnt along the way that should stand you in good stead…
1. Understand why you’re doing it
Your product backlog is more than just a laundry list of things to do; it’s a carefully curated list of priorities that answers the following questions:
- What problems am I trying to solve?
- What are the main objectives I’m trying to achieve?
- What are the benefits, or value this will provide my user with?
People often have great ideas for products, and believe that if they build it, customers will come. But success won’t come to fruition unless the problems of users have been given precedence. Everything else, such as new features or additional functionality, will come in time.
2. Understand your users
You’ll also need to figure out who your users are and the actions that they need to take in order to get the outcome they want. If your sole focus is the product or the technology behind it, you’re not solving the customer’s problem or meeting their needs.
Every story (an item in your backlog) should be framed by what the user is trying to achieve. It helps to look at the bigger picture, taking constraints like budget or timelines into account. Again, this will help you prioritise the items that need completing first.
3. Start small and go from there.
I’ve been in situations where we’ve gone round and round in circles when analysing the various journeys that a user can take. But within these journeys are discreet actions that can help solve very particular problems. It can be as basic as paying for something on a website using one specific payment method, logging into a mobile app, or even finding out about the product in the first place.
So it pays to start small and go from there. Most of the tech industry now adopts an agile approach towards product development, which makes it much easier to build incrementally compared to linear processes such as waterfall.
4. Try out ideas and test features
It’s no good simply hypothesising what you think your customers want without testing it out. Many people make the mistake of building out a roadmap for the next three years with tens or even hundreds of items. But when they start to go out to market, the end user doesn’t want or need particular functionality, which can have a knock-on effect for the rest of the roadmap.
Aim to get ideas and features out to your customers as quickly as possible. Even if they’re not fully functional or the finished product, most users love to test things out and provide feedback on how you can improve. Beta testing is something Microsoft has done for decades.
5. Build a framework around experimentation
As a consultancy that helps organisations solve problems using emerging tech, DiUS is always experimenting. However, it’s important to build a framework around experimentation to keep product teams on the right track.
For example, making sure that activities are being documented so progress can be explained to and understood by the wider team. Experimentation should also be timeboxed and have defined success metrics, as this provides a clearer path to create actions and complete tasks in the future.
6. Look at what needs to be done holistically and regularly
Every product development or software engineering project is a puzzle with several interconnected pieces. From databases and cloud platforms to authorisation systems and user interfaces, everything needs to speak to each other in order to work. So when refining and prioritising your product backlog, it can all seem a bit overwhelming.
That’s why it makes sense to take a holistic view of what needs to be done as a team on a regular basis. Not only does this help you break tasks down into more manageable chunks, it also means you can sequence tasks in the right order and ensure your focus does not drift away from the user.
7. Find a balance between different customers
Certain features of a product are designed for a specific set of users. And if you’ve tested and launched a feature that proves successful with these users, it’s easy to lose track of other users who require something different from your product. So finding a balance between different users is critical.
This is where user experience researchers and designers are crucial. By talking to and testing your product with a cross-section of users, they’ll know whether it is solving problems or satisfying needs. They will ensure usability and accessibility are considered in the design – not just an afterthought, leading to user criticism after you’ve gone live.
8. Always keep your backlog ticking
There are countless books and blogs out there that talk about how much time and resources should be spent on certain tasks, working on your tech stack vs. delivering more features etc.
But I think the most successful way I have seen is allocating a certain percentage of your capacity to work on tech debt stories. That way you’re consistently ticking off small pieces of refactoring work, and you will keep improving your product too.
If you need more help refining and prioritising your product backlog, or don’t have the people and resources to deliver it, get in touch with DiUS. We specialise in helping organisations of all sizes and industries with their product development requirements, from providing capability uplift to establishing best practice project management.