3 Common Mistakes When Starting Product Prioritization
Whilst it can be great to have 100’s of ideas a day it can be overwhelming when you realize it’s simply not possible to accomplish them all simultaneously.
The same can be said for handling product backlog, feature requests and anything else you need to put together a great product.
So what do you end up with? A huge list of things that need to be done, with no clear indicators of importance. Get them in the wrong order and you’ll cause a domino effect that derails your entire project. Not ideal, let’s look at how to solve that.
3 mistakes that can get in the way of efficient product prioritization
While there’s almost an endless list of things that can derail a project, there are some mistakes that pop up more than others.
You forgot to run discovery
The discovery phase essentially sets the scene for what your team chooses to build. The aim? To know what you’re doing, why you’re doing it and importantly, who you are doing it for.
Once you have the answers to these questions, you can start to build a product with true value to the user. What you may not realize is that these answers also hold the key to better product prioritization as well!
Which problems solve user pain points faster? Which features help deliver the most value?
If you can answer those questions, then you can quickly identify and start to prioritize your tasks. Once you have run discover, you’ll have a better idea of the following:
- What are you working on and why?
- Is it worth pursuing and will it actually bring value to the customer?
- How will you measure success?
In order to make sense of the items on your backlog, it can be useful to group items together that similarly address a particular problem to solve. This is where your roadmap comes in. A roadmap takes items in your backlog and provides strategic information as to the opportunity these ideas can provide.
Once you have this alignment, intention and direction you can begin to provide everyone with this information. That way everyone knows what, why and for whom you’re building things for.
Your development team isn’t aligned with the product vision and/or strategy (even after discovery has been run)
Running product discovery is a great way to align development with the product vision, but simply running discovery doesn’t mean that the team will stay aligned. Especially when working as a self-organized team.
Having a self-organized team is fantastic for product managers. They can go away and focus on the big picture while the development team gets to work on making the product. It’s something every product manager hopes to have, but that’s not to say self-organized teams are without drawbacks.
Left to their own devices, the team can start to drift away from the product vision, which doesn’t bode well for the final product. A well defined product vision is the cornerstone for a successful product. That means keeping it in mind during every decision the development team makes.
The last thing a product manager should do is stifle creativity, but there’s a point where creativity can get in the way of the bigger picture. While it can be uncomfortable, product managers shouldn’t be afraid to step in and make changes if the development team’s decisions are getting in the way of the overall product vision.
You thought deciding on a prioritization framework was enough
So, you’ve chosen a framework, but are you actually using it? This is a shockingly common mistake that usually stems from a management level when they don’t fully understand the framework.
That being said, the opposite can have equally damaging consequences when it comes to prioritization. Simply committing to a framework and assuming it will fix everything isn’t the answer.
While picking a framework offers a way to standardize the prioritization process, it doesn’t mean it will fix all of your problems. Prioritization frameworks tend to exclude anything that isn’t specifically part of that framework. This includes things such as dependencies, the dynamics of the competitive landscape and budget cuts or limitations, to list just a few examples.
If something comes up that goes against the prioritization framework you’ve chosen, don’t be afraid to break the framework. It may seem counterproductive, but it can be the difference between a smooth development process and a nightmare.
Want to become an expert on prioritization? airfocus will get you there.
Our Mastering Prioritization eBook is packed full of tips and tricks to help you make prioritization decisions easier and faster. Grab your free eBook today and learn how to source insight, choose the right prioritization framework and much more.
This is a guest post written by Malte Sholtz, CEO & CPO at airfocus, and was originally published on the PMF blog.
