post

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Guest Post

How to build a companion product and win user trust

mission statement

Deep dive: Crafting your product vision and mission

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

Join us at #mtpcon London in 2025 – mark your calendars

How Google makes AI work at Enterprise scale – Miku Jha (Director, AI/ML and Generative AI, Google Cloud)

5 ways to invent and simplify as an AI/ML product manager

Why teams often struggle with OKRs: A conversation with Jeff Gothelf

Building your own user experience and software stack: This week’s product news

Martin Eriksson has 25+ years experience building world-class online products in both corporate and start-up environments for global brands such as Monster, Financial Times, Huddle, and Covestor. He is the Founder of ProductTank, the Co-Founder and Curator of Mind the Product, and a Product Partner at leading venture capital fund EQT Ventures. He is also the author of the best-seller Product Leadership, How Top Product Leaders Launch Great Products and Build Successful Teams (O'Reilly, 2017).

Martin Eriksson

<a href="http://mindtheproduct.com/wp-content/uploads/2012/05/changed_priorities.jpg"><img loading="lazy" decoding="async" class="alignright size-medium wp-image-1904" title="changed_priorities" src="http://mindtheproduct.com/wp-content/uploads/2012/05/changed_priorities-300x225.jpg" alt="" width="300" height="225" srcset="https://www.mindtheproduct.com/wp-content/uploads/2012/05/changed_priorities-300x225.jpg 300w, https://www.mindtheproduct.com/wp-content/uploads/2012/05/changed_priorities.jpg 800w" sizes="(max-width: 300px) 100vw, 300px" /></a>One of the core responsibilities of a product manager is to prioritise everything that needs to get done into a roadmap. There are different views on how that roadmap should look but first, what about the prioritisation process itself?
<h2>Prioritise for scale</h2>
Whatever process you follow it&#8217;s important that it&#8217;s appropriate to your business and the size of your team.
Early stage 
In the early stages of a product or a business you really don&#8217;t want to focus too much on process, and with a small team you can probably only tackle one thing at a time so what you need is to know the most important thing to work on. This is where methodologies like Lean Startup shine and you can focus on acting on user feedback and iterating quickly.
Big company, big product 
In a really big company with a really big product the investment decisions are much larger and you simply have to do more analysis before you commit resources to a project. The classic approach would be to do a full cost benefit analysis of each proposed project, expressing the benefits and costs in their net present value and using that to prioritise each project. I&#8217;ve worked in organisations where this method has been followed, but never in one where it has been appropriate. This is really only for huge, complex and capital intensive programs like high speed trains, because doing it iteratively would be a disaster (oh the tunnel didn&#8217;t work there? ok, we&#8217;ll move it 5 feet over to the right).
Just right 
So what about everything in between? Compared to an early stage business, a mid-sized business has the additional challenges of multiple stakeholders, a larger dev team and a larger more complex product. If you stick to early stage methods you&#8217;d get into more arguments about priorities, never get around to refactoring, build up technical debt and forget about stability in favour of new features. If, on the other hand, you chose big company methods you&#8217;d probably spend days or weeks nailing down the exact cost and the exact benefit of each enhancement, but really, who wants to go back to Econ 101? More importantly, in today&#8217;s rapidly changing world, who has the time? What you need is a prioritisation method that makes the process scientific enough to make the process objective (making it clear that everyone&#8217;s pet project is being judged equally) while keeping it lightweight enough to focus on building and learning over process.
<h2>Just Right Prioritisation</h2>
So how do you build a prioritisation process that balances objectivity and agility? Here&#8217;s how I do it.
Pick your levers 
Before you sit down to prioritise anything you have to know what&#8217;s important for your business. If you&#8217;re an app platform it&#8217;s probably the number of apps and app downloads you have. If you&#8217;re an e-commerce site it&#8217;s likely the conversion rate and sales revenue. The point is &#8211; every business is different and if you don&#8217;t define and agree your priorities up front you risk optimising for the wrong thing, or nothing at all. Pick the 3-5 levers that you can affect and that will have an impact on your business, and then pick measures of these levers that are trackable, actionable and distinct. Measuring page views is silly because how do you know if that TechCrunch article or your shiny new feature delivered the improved KPI?
Score your projects 
I set up a scoring matrix that lists each of the KPIs along the vertical axis, and a score from 1 to 5 on the horizontal axis.
Why a score of 1 to 5? The trick to speeding up your prioritisation is to simplify the calculations required to score individual projects. It&#8217;s not really important to know if project A will achieve £10k or £15k new revenue, but it is important to know if it achieves more than project B. So I set up scores based on bands &#8211; score 1 for 1% to 10% improvement, score 2 for 11% to 20% improvement etc.
Weight your scores 
It&#8217;s important to realise that all KPIs are not created equal. A 10% bump in revenue may be vastly more important than a 10% bump in unique visitors, or vice versa depending on where the value lies in your product. The beauty of using a score of 1 to 5 is that we can weight our levers &#8211; 10% improvement may equate to a score of 5 in revenue but just a 1 in visitors.
I colour the bars in so you can see the scoring at a glance, this is especially useful if you post these up on a wall as part of the epic card.
<iframe loading="lazy" src="https://docs.google.com/spreadsheet/pub?key=0ArvPP2CNhc8odGx6a24xcU9JdE9QUVBRQmFDVkRsNUE&amp;single=true&amp;gid=0&amp;output=html&amp;widget=true" width="630" height="220" frameborder="0"></iframe>
Sweden, Neuf points 
Now that you have a score you can compare each project, list them in priority order and voila, you have your ingredients for a roadmap. But you can also get more creative and add in more layers. For example you may want to account for legal requirements by giving trump scores to projects that may land you in jail if they&#8217;re not done (or not, your call really). You can also account for effort by dividing the final score by a similarly weighted effort score.
<iframe loading="lazy" src="https://docs.google.com/spreadsheet/pub?key=0ArvPP2CNhc8odGx6a24xcU9JdE9QUVBRQmFDVkRsNUE&amp;single=true&amp;gid=1&amp;output=html&amp;widget=true" width="630" height="360" frameborder="0"></iframe>
Of course the beauty is that the weighting of the scores is up to you &#8211; and what&#8217;s important for your business. And you can compare all your projects in one list, sorting by the score.
<iframe loading="lazy" src="https://docs.google.com/spreadsheet/pub?key=0ArvPP2CNhc8odGx6a24xcU9JdE9QUVBRQmFDVkRsNUE&amp;single=true&amp;gid=2&amp;output=html&amp;widget=true" width="630" height="210" frameborder="0"></iframe>
From analysis to scoring 
So instead of spending weeks or months doing detailed analysis of each cost and benefit &#8211; and getting the cost/benefit right to the nearest dollar &#8211; you can now score projects or epics quickly and efficiently. This focuses the process on what&#8217;s important to your business and on relative priorities rather than absolute priorities. Basically you get to focus on execution instead of dithering on the detailed analysis of a cost or benefit. And that has to be a good thing right?
<h2>David vs Goliath</h2>
<figure id="attachment_1881" aria-describedby="caption-attachment-1881" style="width: 300px" class="wp-caption alignright"><a href="http://mindtheproduct.com/wp-content/uploads/2012/05/sumo_david_vs_goliath.jpg"><img loading="lazy" decoding="async" class="size-medium wp-image-1881" title="David vs Goliath" src="http://mindtheproduct.com/wp-content/uploads/2012/05/sumo_david_vs_goliath-300x179.jpg" alt="David vs Goliath" width="300" height="179" srcset="https://www.mindtheproduct.com/wp-content/uploads/2012/05/sumo_david_vs_goliath-300x179.jpg 300w, https://www.mindtheproduct.com/wp-content/uploads/2012/05/sumo_david_vs_goliath.jpg 1024w" sizes="(max-width: 300px) 100vw, 300px" /></a><figcaption id="caption-attachment-1881" class="wp-caption-text">David vs Goliath by <a href="http://www.flickr.com/photos/gregfoster/2834857578">Greg Foster</a></figcaption></figure>
One final challenge is how to weigh small changes and tweaks against major new features or products. How can you prioritise changing some copy or fixing a little bug against a major rewrite or a whole new product line? The former might take minutes, while the latter might take 6 months. Seems impossible right?
Score everything equally 
The correct way would of course be to score each project/task and estimate the relative value to the business. But even with a lightweight scoring process you&#8217;ve probably spent more time doing the analysis than the small tasks would have taken in the first place! And nothing annoys me more than spending time on definition and analysis for a 10-minute change.
Split Roadmaps 
The more sensible option is to have two roadmaps or backlogs &#8211; one focused on big projects like new features or product lines, and another focused on small ongoing tasks like bugs, enhancements and tweaks to existing features. The former requires detailed analysis and prioritisation and the latter can be much more fluid, with much simpler prioritisation criteria. This not just simplifies your prioritisation but gives you the agility and flexibility to respond to market and customer needs quickly in the small tasks roadmap without derailing bigger strategic projects.
Time boxing / Resource boxing 
Great, now you have two roadmaps but you still haven&#8217;t actually prioritised between them. Your team can&#8217;t all focus on one or the other, you need to get the balance between them right, and this is where time or resource boxing comes in. Depending on the size of your team and the relative importance of focusing on small vs large projects you have a few different options for tackling the small tasks roadmap:
If your team is smaller you may want to time box it by assigning a day per week, a day every other week or x points per sprint.
If your team is larger I would suggest splitting it into small semi-autonomous teams that focus on different projects. In this structure the small tasks roadmap is a rotating responsbility that one team focuses on full time while the other teams are working on the large projects.
At Huddle our team was split into several teams of 5 &#8211; 1 lead dev, 2 back-end devs, 1 front-end dev and 1 QA. The teams then took turns executing the ongoing roadmap work while the other teams worked on major projects.
Priorities 
The beauty of splitting the roadmap and then time-boxing or resource-boxing is that the prioritisation between large and small becomes just as measurable &#8211; after all you control how much time or resource is spent on either roadmap &#8211; but while you do spend time analysing and scoring your major roadmap you don&#8217;t have to get into too much fine grained detail on the ongoing roadmap.
<h2>Communicate</h2>
Whichever process you follow it&#8217;s incredibly important to communicate internally as often and as openly as possible about the roadmap process. It&#8217;s not just about disseminating the final priorities but being very open about the KPIs being tracked and targeted and the process by which the roadmap was developed. This ensures that everyone in the company is aiming for the same target and helps unleash their creativity in coming up with new ideas or better ways to execute existing ideas to reach those goals.
<h2>So what have we learned?</h2>
There are plenty of books out there on the early-stage <a title="Eric Ries' The Lean Startup" href="http://astore.amazon.co.uk/mindthe-21/detail/0670921602">lean start-up</a> <a title="Brant Cooper's Entrepreneur's Guide to Customer Development" href="http://astore.amazon.co.uk/mindthe-21/detail/0982743602">processes</a> and many more on the corporate <a title="Cost-Benefit Analysis (Richard Layard, Stephen Glaister)" href="http://astore.amazon.co.uk/mindthe-21/detail/0521466741">cost benefit analysis</a> end but these are some tricks I&#8217;ve learned that seem to fit everything in between, tricks which help you maximise output while minimising the time sunk on process.
<ul>
<li>Match your process to your scale</li>
<li>Know what your KPIs are before prioritising</li>
<li>Use quick simple scoring where possible to focus on relative priorities over absolute priorities</li>
<li>Split your bugs and small tweaks priorities from the main roadmap</li>
<li>Communicate not just the roadmap but the process behind it</li>
</ul>
I hope they&#8217;re useful to you too, whether you&#8217;re new to product management or an old hand like me. Please feel free to ask questions or suggest your own tips in the comments.

Product Prioritisation 101

Martin Eriksson

Read more

Comments