Go backKnowing what to work on, and when to work on it, can be something of an inexact science.
As a Product Manager, you can be juggling requests and needs from various different teams - senior management may want you to work on a particular subset of features; your sales team may want to release a new tool that they say will triple sales; marketing believe that building a retargeting tool will encourage customers to come back and place orders in the future. Meanwhile, you have your own OKRs to deliver.
Fundamentally, I believe being a good Product Manager comes down to prioritising well. Ignoring the noise and delivering the stuff that is truly impactful will, I believe, result in the best outcomes in the future.
So how do you go about deciding what to work on, and how do you justify it to other stakeholders within your company?
Most blog posts you’ll read out there seem to suggest there’s not a magic wand for prioritisation - and unsurprisingly, there isn’t one. Instead, time spent developing your own is super important in my opinion. It gives you a basis to look at all future requests and in the future, decide what it is you want to work on. It enables you to justify your work not only to yourself, but the people you work with, and sets expectations about what’s important to your team and your users.
So in this article, I’ve outlined what I believe is a great framework for me, and how I like to approach problems, so any readers might take this away and be inspired to develop their own.
Customer desire
A great learning experience for me in my last PM role was my time spent working on a significant new service launch. It was a complicated build, with lots of developer effort, plenty of logistical and operations organisation, as well as a good amount of project management.
We believed it was a great new idea internally, and that customers would love it. In short: they didn’t.
Some of my own concerns started coming when I ran some focus groups discussing this new service with potential customers. Conceptually, they tried to compare it to other existing services from different companies, which was a problem as this wasn’t something the market currently offered. But crucially, the majority of them said they wouldn’t use something like this in it’s current form.
These focus groups were several months in to the build, and were intended to inform us about marketing this new service, and what messaging made sense to our consumers.
So, we pressed on and released the new service, promoting it fairly heavily. But it wasn’t the right idea and we shut it down several months later.
What’s the takeaway here? Speak to customers. It’s something I will always do going forwards in whatever way I can.
For nearly everything you work on, I believe validating it by speaking to customers is essential, and until something is validated, assume it’s not going to work out. As a Product Manager, it’s then your job to understand how to validate these ideas with your customers.
With this in mind, I then like to score features on a scale of 1-5, with 1 being low and 5 being high, based upon the following criteria:
- 1 - An internal idea
- 2 - A competitor has implemented this feature
- 3 - This originated from an insight provided by one or more customers
- 4 - This has been suggested by >5% of your customer base
- 5 - This has been suggested by >10% of your customer base
There are edge cases, such as insights generated by analysing data. But generally, I’d like to then try to validate this insight by speaking to customers.
On top of this, I’d probably sway the base customer percentages based upon the product I was working on - a B2B SaaS app is likely to have different customer expectations compared to a B2C social app, for example, so 5% and 10% may not make sense to all companies and products.
Business objectives
Another crucial angle to think about as a Product Manager is the overall bigger picture. How does a feature fit into what the company is trying to achieve, and your team’s objectives?
If customers request something, but it’s on a complete tangent to your overall strategy - there’s two potential conclusions:
- You may be wildly off the mark with your strategy
- This feature doesn’t fit into the overall business objectives
Generally, point 1 will be rare, and the takeaway will usually be 2. But if it turns out that a large percentage of your customer base like this feature, maybe it’s time for a re-think.
As a result, to feed into the matrix, I like to score a feature’s alignment with business objectives on a scale of 1-5, with 1 being completely unrelated and 5 being extremely relevant.
Judgement
While seeming contradictory at first, considering this is a model attempting to provide a defined formula to prioritise features, I do strongly think that judgement plays a big part in prioritisation.
As a Product Manager, you should understand the product better than your colleagues. You’ll likely be expected to understand the market and your customer base, while being involved in other elements such as understanding overall product strategy and objectives.
With this in mind, introducing judgement feels important, since you can use your intuition to decide whether a feature is worth prioritising.
However, it’s important not to place too much emphasis on judgement. Try to use metrics where possible, to support your judgement.
Another way of thinking about judgement is to compare it to the RICE models confidence metric. How confident are you, based upon your judgement, about how good an idea this new feature is?
So to feed into the matrix, I like to then use judgement as a percentage metric - scoring from 1 to 100, with 1 being your judgement tells you it’s a bad or low priority feature, and 100 being you think it’s a great feature.
Effort
Effort is at the core of everything, alongside customer requests, for me. If a new feature is expected to have a high impact, but will take your team months - it might be worth looking elsewhere first.
To feed into my matrix, I like to score effort by counting the number of days you expect it to take, and placing that on a scale of 1 to 10.
Bringing all of this together, you can visualise this prioritisation framework like so:
Converting this to a practical example, lets take two examples of features from my favourite company, Monzo, and score them based upon this framework:
- Ability to link different bank accounts to your Monzo account
- Virtual cards
For feature 1, lets assume the scoring is as following:
- Customers - 3 - Multiple customers have raised this as a feature they’d like
- Business objectives - 4 - This could be a paid for premium feature, fitting in with their overall business objectives
- Judgement - 0.4 - You think this is likely to have a positive impact, but you’re unsure on how many customers would use this as a feature
- Effort - 8 - Would require open banking integration, meaning a lengthy developer estimate
For feature 2 - virtual cards:
- Customers - 4 - This is a commonly requested feature by a good portion of Monzo’s user base. Competitors also offer it.
- Business objectives - 4 - Similar to feature 1, it could be a premium feature
- Judgement - 0.75 - You’re confident that this is something customers would use, and is a big new neobank feature
- Effort - 4 - Large assumption by me, but lets say that in principle it’s considerably more straightforward to build
Demonstrating this as a formula:
In this case, you can see that feature two, the virtual cards feature, scores significantly better and therefore you can assume that it’s worth prioritising over linking different bank accounts to Monzo.
If you’ve got to this point in this post, you might be thinking ‘Is this not just a repackaged RICE?’. My answer is, yes - it essentially is. I think the RICE framework is great, and makes a lot of sense. But the key issue for me is that it doesn’t factor in customer desire, or business objectives.
But, what’s important, and hopefully what I’ve emphasised in this article, is that building your own framework for prioritisation is key. Follow what you believe is important, be customer centric, and you won’t go far wrong.