When it comes to product-led growth implementation at a product development level, the main factor is what to prioritise at any given point in time. Obviously, onboarding is the key focus for revenue generation, but for feature and product prioritisation any number of options are available.
So far we have covered topics like time to value (TTV), PLG metrics, Moscow analysis methodology and pirate metrics and I shouldn’t forget the HEART framework either. So why should we cover more options?
As those of us that have worked in SaaS know, it often takes a combination of metrics, frameworks and methodologies to get to the desired outcome. With this in mind, I can finally close out my methodologies run on our website content.
How to prioritise feature requests is one of the most frequently asked questions in SaaS product development. The product roadmap is often set way in advance and pivoting can feel precarious and in some cases, upset founders so much teams simply refuse to do anything other than what they are told.
Knowing a few more frameworks won’t solve your founders’ problem, but it may help you figure out which frameworks will provide you with the best balance for the upcoming feature or product release.
Rice is a framework adopted by the team at Intercom to rank internal product decisions. Once you’ve scored your features, multiply the Reach, Impact, and Confidence, then divide those up by the Effort, which will result in the features' RICE score. So how does it work?
Consider the number of people that will benefit from or be impacted by your product update or feature release. Ask yourself
Here your goal is to measure the quantifiable impact felt by your feature changes. To best measure impact, choose a rule by which to rank; be that a sliding scale, or grouping.
An example is 1-10 with 1 least likely and 10 most likely to benefit the user. A good methodology to use here is the HEART methodology mentioned above.
While it’s good to be bullish and confident about your next update or feature release, savvy product owners always rely on data. Being overconfident has been the ruin of many a good platform. By capitalising on the data gathered in the previous two areas, you should have a good level of understanding of the next steps.
Ask your team
Again, using some numerical scale is good for this or a percentage.
At this stage, we focus on the man-hours put in to achieve the desired effect of the new feature. You’ll gain an understanding of your team’s workflow and quantify how much each member is going to have to contribute. Then align this to your overarching deadline for the project.
Use this approach to govern your overall workflow around product updates and let your team integrate any of the other frameworks to focus on single elements, like the HEART framework for an updated UX.
Using this approach to product feature prioritisation requires your product manager to balance two things:
Potential Value:
And
Complexity and effort:
If you can rank these in a quadrant for effort and value to quickly determine if the value outweighs the complexity, then you have a great basis upon which to springboard into what features work and what do not.
|
High value/low effort |
High value/high effort |
|
Projects in this quadrant are your absolute winners. |
Galvanise your team around these features to ensure the high projected value can be hit. These are your big bets and large projects. |
|
Low value/low effort |
Low value/high effort: |
|
These feature requests are worth doing if larger projects have been completed, but can be left alone. |
Forget about it! |
Whilst a far more simple method of which to evaluate your product feature prioritisation, it is still a valid one.
I like these two simple frameworks, but I am also a big fan of combination frameworks and results. I’m hoping that the last few articles help you to decide which frameworks suit what part of your project, and of course, if you need any help, feel free to visit our product marketing services or our product led growth services.