Product Manager Only Rule — Do Nothing without known Priority
“If you don’t have Priorities in your life, you will not get anything done which is important for you. You will be overridden by anyone and everyone.”
Similarly, in product management too, if there is no priority or bad priorities put in place, the product will never go live or perform the way it is expected to.
“Do Nothing Without Priority”. If in product team, the product manager denies you to work on something and asks to do something else, You should
- talk about the priority.
- talk about the need.
Knowing the priority will help you plan well. Knowing the need will help you understand how it should be developed so that the need of customer is met.
The biggest value prioritization adds to your productivity is — Cut the Noise. You only define to work on what is the Only necessity for the moment or two.
Most of my career, I have seen companies setting the features priority as “High, Medium, Low”. Maybe good to start with, but for product managers, several prioritization frameworks available to use while prioritizing the backlog:
- MoSCoW
- RICE Scoring
- The Kano model
- The Lean method (Value vs Effort)
- Opportunity Scoring
- ICE Scoring
- Cost of Delay method
- Weighted Scoring (Benefit vs Cost)
- Story Mapping
- Product Tree method
- “My framework”—FMFM method
Explaining each of the above frameworks may probably end the world in this read. The motive here is not to make you know each of these methods, rather, make you know that priority is important. You as a Product Manager should never do anything without priority, and also enforce/transcend the same to all the cross-functional teams you work with.
Let’s me talk in brief the most popular frameworks which I too use mostly for my backlogs. I will detail each of these frameworks with examples in my upcoming book.
MoSCow method is most common one I see being used. Using this method, you will categorize your backlog items into one of these buckets.
This method best works for a new product. “The Must Have’s become your MVP”. The method is also best when you want to say your team what to include and what to exclude from the backlog.
The thing to note here is, I have often seen Product Managers put their 80% of backlog into Must Have’s. If so, then it is bloated. I believe (somewhere near) only 20% of your backlog items go to Must Have’s bucket. No customer needs your entire product even after a decade of PLC (Product Life Cycle). Each customer you can consider using somewhere 20–30% of your entire product features. Do not bloat your Must Have’s, and only focus on Must Have’s once you are done with prioritization.
Ok, what about once you have delivered Must Have’s? Pick Should Have’s and continue? Mostly yes, and Product teams do this as much I have seen things. No, that’s wrong.
“Prioritization is a continuous process and it doesn’t die/complete even if Product is in end of its life.”
You should be in prioritization process, even when Must Have’s getting developed. By the time you are done with Must Have’s and launch — the market has changed, the customer values have changed, your revenue cycle would have changed. “You have to redo the Prioritization and pick the next Must Have’s. Do not work on Should Have”. 😊
RICE framework was developed by PM team at Intercom. RICE stands for Reach, Impact, Confidence, and Effort. RICE framework uses objective scoring mechanism to rank your backlog items (features/stories).
Reach tells how many customers will be affected by this feature/story or how many transactions/any usage metrics it can generate for a given period (usually per quarter).
Impact tells how much impact this feature/story will have on an individual user. The impact is defined in a scale of 0.5 to 3 where, 0.5 — Low, 1 — Medium, 2 — High, and 3 — Massive Impact.
Confidence tells how much you are confident about the feature/story. Hence it is presented in form of percentage where 50% — Low, 80% — Medium, and 100% — High confidence. Take a feature, where you have done enough research and collected enough data (spoken to customers, studied competitor equivalents & positioning, demographic constraints & scaling factors, etc.). This feature will have your confidence level near or equivalent to 100%. Whereas, take a feature, where you didn’t collect much information and didn’t get any customer feedback. This feature will score low confidence below 50% as it is pure gut felt analysis.
Effort tells how much of time required by team to develop the feature. It is the resource estimate hence calculated in person-hours(months/days/etc). Take a feature where product team gives you effort estimate of a 4 person months (including planning, design, developing, testing). The Effort score is 4.
Then we do the math with the formulae above and get the RICE score of a feature/story. This is followed for each backlog item and a table listing RICE score of each story is created. The scores are sorted descending order and it gives you which stories to be work first in what order.
If you see the formulae, we divide R,I,C, with E. This is because effort is cost and other three are positives or benefits. It implies, you should first work on the features/stories which have high reach and low effort.
RICE model is best suited when you need priorities at each backlog item level which MoSCoW method doesn’t achieve. I usually apply this on my Must Have’s. My backlog with 1000 items out of which almost 80% doesn’t fall under Must Have’s, it doesn’t make sense to put efforts on prioritizing by RICE model on all 1000 items.
Kano model developed by Noriako Kano, is another popular framework which helps you to know the basic fundamental features/stories and differentiators in your product. This model helps you answer:
- What features/stories are basic need without which product cannot be delivered? i.e Product without basics is useless for Customer.
- What features/stories are performing which will help product gain more customers? i.e. Features that bring in efficiency in customer operations, or decrease direct costs to customer, etc.
- What features/stories are exciting to customers which will help differentiate product in market? i.e. features that make customer feel satisfied and happy for you going beyond to help them.
The above diagram explains it all. PM should bucket each backlog item in one of the four quadrants. Once done, you Product team should first work on backlog items that fall under right bottom quandrant (quandrant where all baisc needs of product is defined). Basically deliver features/stories in order:
- Basic Needs
- Performance Needs
- Delighters/Differentiators
The way you interpret the Kano model is,
- the backlog items falling in left quandrants — if delivered — customer needs won’t be fulfilled and customer might be dissatisfied (if the backlog item delivered is from lower left quandrant).
- the backlog items falling in right bottom quadrant — if delivered — customer needs are fulfilled.
- the backlog items falling in right top quandrant — if delivered — customer will be satisfied and happy for solving the problem(s) they are facing even though they didn’t expect it from your product.
I see, Kano model as powerful framework because it brackets the deliverables taking into account —‘Customer Feelings’. The greater the experience, the pleasurer the feeling. Hence, I often use it while product improvements or performance prioritization. The model helps very much to satisfy target customers. To make you understand more, let’s say developing a cooler for the zone where only 3 months climate is heat/summer and rest 9 months are cold/shivering. In this case, the customer is satisfied when product cools the room to needed temperature but customer is delighted when the same device does work as heater for rest 9 months. The consideration of, feeling of satisfaction or delightment makes Kano model powerful method to use it for improvising your product.
Other frameworks, I won’t be explaining them here to keep this writing short. It doesn’t mean they are not popular (but yes, not so often used atleast in my case) or less useful. It’s just that I want to keep this writing short.
And finally, let me talk about my framework. I usually use this much (doesn’t mean I only use this) to start with or decide something quickly (maybe because I designed it, hence, I can do it faster). The FMFM method. FMFM stands for Fast Money-Far Money.
The method is easy to understand with its name. It works this way:
- Create two buckets ‘Far Money’ and ‘Fast Money’.
- Go through every backlog items and put them in one of the two buckets.
- The features/stories which can generate revenue faster/now (considering — cost, time, effort, scope, complexity) are put in to Fast Money bucket.
- The features/stories which are slower in revenue generation are put into Far Money bucket.
- Far Money features/stories stay in backlog and are part of roadmap but not picked for working.
- Fast Money features/stories are further ranked and sorted based on — cost, time, effort, scope, complexity, estimated revenue for considered period (usually upcoming two quarters).
- By the end you know which ones to work first — start from first work item in Fast Money.
One might question, hey Praveen, your method doesn’t consider Customer Impact, Reach scale, etc. I understand it doesn’t depict above. But, when I consider revenue (direct or indirect) from a feature, all these factors get considered automatically. One cannot generate high revenue from a product if there are no high impact feature(s) in it. One cannot generate high revenue from a product, if it’s feature(s) are not of high reach. Considering revenue to prioritize also helps evade a feature if it won’t help generating revenue (directly or indirectly). This is so helpful that Product team only works on what produces results instantly. The greater advantage is, the revenue from addition/increment is upfront identified (estimated). This helps every cross-functional team strategize, plan and execute efficiently to meet the estimations.
Mostly I see the Product is developed based on customer feedback which doesn’t include whether customer is willing to pay for it or how much does he think he can invest in your product. This leads not to use FMFM method as it solely depends on the monetary benefits of the product.
To conclude,
- Do Nothing without known priority. Transcend this culture across all the cross-functional teams you work with.
- One need not learn all the frameworks, but definitely should know and practice multiple models/framework for prioritization.
- Apply one or more framework for priorization as none of them are complete and have their own pros, cons and usage contexts.
Signing off…
Thank you!
Do you like my writing? Does it add any value to your life or profession? If so, Follow me on medium and subscribe to get notification as soon as my new writing is published.
Your support is worth millions. You can support me by Buying a coffee
