As product people, we constantly have to prioritize features and changes, which can have a major, sometimes even irreversible, impact on our product. It only makes sense that we try our best to understand the risks and benefits of each planned change, but when talking to colleagues within my product management bubble, many state that:
- They don’t spend nearly as much time as they’d like analyzing and understanding the effects of product changes.
- They’re hesitant to implement changes if they don’t have enough data supporting a positive outcome.
This puts many of us in a pickle: We want to make sure we don’t waste resources on changes with no or negative impact, but we oftentimes feel like we lack the data we need in order to make an informed decision. But there are good reasons to move forward with features we’re not entirely certain about:
There is no such thing as absolute certainty.
It may sound obvious, but I’ve seen very experienced product people seemingly forget it: No matter how sure you feel, no matter how much you’ve tested and analyzed, you can never be absolutely sure because you can’t predict the future. It’s one of the major reasons we build MVPs instead of fully-fledged products. The inability to accept this uncertainty can paralyze the product development process, which is significantly worse than a few under-performing changes.
Rigorous testing is a luxury.
I’m the last person to advocate against rigorous testing, but it’s not always feasible or economical. Small product teams oftentimes don’t have dedicated resources for qualitative testing and young products tend to not have the traffic necessary for quantitative testing. If an organization is new to testing in general, it might take them a while to get up to speed or hire someone with testing expertise.
Fear kills innovation.
Only implementing changes we’re certain about means only implementing tried and proven concepts. Depending on the product, this may even work for a while. But there’s no innovation without the possibility of failure. Exclusively basing your product changes on past successes may create a feeling of safety, but it gets the product stuck in a loop that quickly turns into a downward spiral.
So, assuming we’re striving for innovation and venturing into the unknown, how can we estimate feature impact and prioritize planned changes?
Talk to your users.
If you’re about to close this browser tab because I’m throwing obvious ‘advice’ your way: Good on you! Sadly this isn’t quite as obvious to many companies: A McKinsey design report from 2018 found that over 40% of companies don’t talk to their users during development.
It doesn’t matter whether you have dedicated testing or interview resources, developing a product without user input is an unnecessary gamble and even if you win every once in a while, you’ll lack a solid understanding of what makes your product successful.
Gathering feedback from your users, especially in early stages, doesn’t have to be a highly complicated process. Try to gather user input wherever possible without overly complicating the process. Just having a user walk you through how they would use your product (or feature) is a highly valuable learning experience that doesn’t require any complicated methods.
Make prioritizing ideas a collaborative activity.
Prioritizing ideas and hypotheses without supporting data can feel like guesswork, but there are ways to go about it without turning it into pseudoscience. In my experience it’s crucial that you have a participant from every profession that is either involved in the development process or in regular contact with the user.
For your average digital product, those professions would likely be development (and testing), design, customer service, sales, and product management.
Encourage discussions.
In order to properly prioritize ideas, the group needs to have a common understanding of what the ideas entail, as well as the goal behind each idea. But discussions aren’t just a necessity for prioritization, they have inherent value: In encouraging the team to challenge and ask questions, you will refine the existing ideas, as well as uncover new ones.
Use a relative prioritization method.
With this focus in mind and the knowledge that there is no such thing as certainty when it comes to innovative ideas, picking a relative prioritization method with little overhead is a good idea. Relative prioritization, as the name suggests, focuses on the relationship of the discussed topics (e.g. “A is more difficult than B”), rather than dealing in absolute values (“A will take 5 weeks, B will take 3 weeks”).
My personal go-to method for relative prioritization is the impact effort matrix shown above. Discussing each idea within the team and agreeing on its place in the matrix is a great way to gain a common understanding of the existing ideas, as well as discussing risks, benefits, and the required effort.
If you’re confronted with a collection of ideas in different stages of refinement (e.g. some ideas already having supporting data), you may want to have a look at Sean Ellis’ ICE Score approach, which takes confidence into consideration.
No matter which relative prioritization method you choose, if you assemble a representative of every profession involved, get them to work together, and encourage open discussions, you’re guaranteed to gain valuable insights that’ll help steer your product in the right direction.
How do you tackle prioritizing and estimating topics with a high level of uncertainty? Reach out for a chat over a (virtual) cup of coffee. 🙂
Do you like or dislike this post? Please give me feedback via the thumbs up or thumbs down button:
