3 steps to prioritise your product roadmap

So your product has successfully launched. The flow of new customers is building up. Congratulations! But the product isn’t perfect. Of course it isn’t. It’s human nature to always want to push further (and we do love to grumble). There are multiple competing pressures on how to prioritise all the outstanding features in your product roadmap.

Houston, we have a problem

Fairly soon you can hit a situation where nobody seems to be happy about your product roadmap:

• Established customers want shortcuts to do things faster, and some new features
• Onboarding customers want very simple ways to do things so they can set up quickly, plus new features
• Sales claim you will only get more customers by adding new features (which may or may not be the same ones existing customers want)
• Support say you will lose customers unless you fix problems – and add new features
• Ops want to amend the architecture so it scales better at lower cost as your user numbers grow
• And Development just want to shred the whole thing and refactor the code into a much better version, with the latest technologies and no technical debt

And then there’s Marketing, who are looking around for new opportunities and want to repurpose the product for a new geography or a new vertical or a different size of company. But that will mean new features or rebranding or different user admin…

So how do you choose where to spend a limited budget? And how do you keep everyone happy?

Step one – stop trying to keep everyone happy

There’s a freedom in recognising that you will never make everyone happy. If you feel guilty about that, you will make decisions based on emotional needs, which is not in the best interests of the business. Running a business is not a magic lamp, or even a democracy. In fact, if everyone is happy, you are almost certainly not ambitious enough. And if you can get to the bottom of your list, you are spending too much on development.

However, it is important to keep people informed so they understand your choices. Share your product roadmap on a regular basis, and in multiple ways. Being transparent shows people that you are not ignoring their pet ideas, but you have other plans which are even more important.

Step two – create the wishlist

Gather the ideas in one place

Before you can choose the best ideas, you need to get all options on the table. Requests will come from multiple places – user forums, competitor and market analysis, sales conversations, account meetings, support tickets, team meetings etc etc. Most of them will be a single line without much detail.

Find a way to record all ideas centrally. There is specialist product management software for this (eg Aha! or Asana). Or you can adapt project management or document sharing software, or even use a humble spreadsheet if you’ve only got a small team.

Decide visibility

As part of this, decide who should be able to see the roadmap wishlist. I’m a fan of portals that let customers see each others’ ideas, and potentially add comments or votes. Or you may prefer to limit who can add to the list. But letting the support and sales teams at least view the list helps them to keep customers and prospects up to date.

Probe for understanding

Don’t accept single line suggestions at face value. If you are requested “Why can’t I change the font?”, learn more by asking questions like:

• “How will it help you to change the font?” (What’s the real benefit this would give?)
• “What makes the font a problem at the moment?” (What underlying business issue will it solve?)
• “How big is the impact?” (Do you just fancy matching your corporate branding, or does the current font make it impossible to use on a mobile device?)
• “How do you get round the problem at the moment?” (Is there more than one way to achieve the same goal?)

These answers should help build the story so you understand the need. With a bit of adaptation, this also works for technical wish lists and starts to allow comparison with feature requests and bug fixes, eg:

• “How will it help to refactor the code?” (Will it make future development quicker? Will it improve stability or speed? Or will it just satisfy an urge for tidiness?)

From the answers you can start to assess how many other users are likely to want this or be affected by it, and the depth of impact it is likely to have.

Step three – decide your criteria

This step is a whole workshop in itself, but you need to decide the rules by which you will judge requests and prioritise your product roadmap.

Define your priorities

Start from your company strategy. Is your primary driver to increase customer satisfaction and retention? To grow customer numbers and revenue? To become more efficient and increase profit margins? Or to establish yourself in a new market?

It’s probably more than one of these, so pick out the top 3-5 priorities and turn them into questions you can use to rate each request:

• Will this get us new customers?
• Will it stop current customers leaving?
• Can doing this reduce our costs?

Score each item

Now you can score each wish list item on a scale of 0-5 against each question. You can even add a weighting to the more important questions. Then you can use the totals to choose what gets onto the roadmap.

Getting buy-in from other teams at this stage is really important. If they accept your scoring methods and can see the link to the company strategy, it’s much harder to complain when their pet item doesn’t reach the top.

It helps to also involve internal experts at the scoring stage. For instance, I will sit with the Head of Sales to agree the impact of each request on new sales, and with a Support expert to agree about retention impact. Their pet items may still not come top overall, but they are more likely to support your choices because they have influenced them.

Breaking the mould

I tend to add one final item to the criteria list called “JFDI”, with a fixed score of 50. Occasionally something will come along that does not score highly against our normal criteria, but for political or other reasons, just has to jump the queue. If you’re resorting to this on a regular basis, you need to rethink your criteria (or your strategy), but it’s important to keep some flexibility for emergencies.

That sounds like a lot of work!

Is it all worth it? For a small product with a simple set of requirements – no. You can probably pick the next priority through informal discussions.

But if you’ve read this far, you’ve probably got a complex product with a lot of unhappy stakeholders and a stupidly long wish list. If your requests are widely scattered and poorly understood, there may be an overhead at first. But once in place, it does not take much effort to maintain.

And to get agreement on your priorities from key people, you need a transparent process. You can explain the rationale behind your choices, and it helps bring the temperature down in the debate. You won’t make everyone happy, but you can make them a lot less unhappy.

I can help

If development decisions are made politically and it is causing issues, you can break the behaviour patterns by using an external facilitator to help set up a new approach.

I run workshops where your key stakeholders can discuss and agree the decision criteria and scoring formula that will best support your business strategy. I can also advise on ways to document and communicate what you are doing, to give a lasting impact.

Set up a call to explore with no obligation and get in control of your product roadmap.