When we have a product, and the product has it’s users, and users are engaged — they usually give feedback in form of bug reports and feature requests. There may be other forms of feedback, like comparisons, overviews, discussions etc, but as (if) they don’t add new tasks to your backlog we can ignore them for now.
With bug reports things are quite simple:
- check if it’s really a bug and can be reproduced
- assess it’s severity in terms of broken users scenarios
- assess it’s priority in terms of how many users are affected and how important are these users for you
- check if the fix won’t make things universally worse (some minor bugs are better left untouched, when there is no evidently good way to fix them without big changes in all product)
There you are, include the bug into your backlog easily comparable with other bugs. There is no need to argue that bugs are to be fixed, right?
With new features it’s not that easy. If we look at the popular RICE framework, for example, we use Reach, Effort, Impact, Confidence assessments as the base for comparison.
The formula looks like this: (Reach x Impact x Confidendce) / Effort = RICE score.
This framework usually need adjustment to use in real work environment, for instance, it does not include the dependability factor (when your low-RICE feature blocks some other high-priority feature or product part), scheduling (when postponing the feature makes it completely useless, like Christmas specials or such), available workforce (you may not have enough engineers at hand just at the moment) and more. So RICE is just a helping tool, but not a plan-composer.
I would suggest also adding into such frameworks’ formulas an additional factor of ‘source weight’. The feature request may come from:
- a prospect with huge contract (noticeable potential revenue but low reach and impact for the majority of other users) an ‘influencer’ able to open some new market niche for the product paying audience (not that big part of the overall user base but ready to pay for the new feature)
- investor/stakeholder/manager whose benevolence is important for the future of the team and product itself
These are not as easy to measure in money or people or some other quantifiable unit, so we can adopt the same scale as with ‘Impact’ from RICE formula: Massive = 3x, High = 2x, Medium = 1x, Low = 0.5x, Minimal = 0.25x.
The ‘Source weight’, or we can also name it ‘Opportunity’, coefficient should be applied to the RICE score and will help to balance external feature requests with your own product plans, giving some more weight to incoming ideas. Your own ideas will have Medium source weight, so if you are (like me) inclined to prioritize your own view over infrequent external opinions (after all, who’s the product manager, responsible for strategy and familiar with every detail of product status and plans?), the new coefficient might help to think twice and not miss something useful.
But again, all these scoring techniques only help to compare what’s comparable. Final decisions are always yours.
Top comments (0)