If you are involved in deciding what goes onto your Product roadmap, you will find this useful, even if you're not a 'Product Professional'.
Follow me on Twitter @AConsidineTong for more insights.
Deciding what to put on your roadmap and when to build it is HARD. It's hard because unless you are blessed with a massive engineering bench, zero external competition, minimal technical and contract debt* and a completely aligned go to market team, it's going to involve balancing many different priorities and deciding what not to do as much as what you are going to do.
(*Contract debt = when you have already sold something that you have not yet built).
If you have read any of my articles you will know that I subscribe to the idea that Product Leaders can't, and shouldn't, make these decisions on their own. Instead, the raison d'etre of a good Product function is to lead everyone to consensus about what should be built when, and why. So, in that spirit, this article is for everyone because all functions within your business, from engineering to sales, data science to delivery, should play a part in defining your roadmap.
1. Have a process for ingesting new ideas/suggestions
If the Product function is going to be one of enablement (which I strongly believe it should be), then you need a way to canvass - both proactively and passively - other parts of the business for ideas about what to put on the roadmap. In other words, you need a process for getting ideas out of sales/marketing/delivery/engineering and into the Product team where they can be triaged and analysed.
You could do this in a number of ways:
Shared Inbox; where people can send you free-form suggestions on email about what they'd like to see in the product
Google/Sharepoint/etc forms: where people can fill in a short form detailing their suggestion
Word Document: provide a template for people to complete and email/submit to a central repository
Jira/YouTrack/Salesforce integration: give people the ability to raise their suggestions as tickets on an existing platform.
There are advantages and disadvantages to each of these approaches which you can read about here , but you need to figure out which one works best for you.
2. Build a Scorecard
Once you have gathered your suggestions, ideas and demands (!) you need some way of assessing them against once another. Ideally, you will have selected a process of canvassing ideas that gives you as much information as possible, but if not, you will need to assess, as a minimum, the following metrics in order to score and rank your options:
a) Associated Pipeline opportunity
b) Impact on Target Addressable Market (TAM)
c) Time to deliver
d) Cost to deliver
e) Risk if not pursued
It’s likely that you might not have the raw data on these metrics, you may need to create a relative score. For example, early on, you might not have done the work to fully understand the time to deliver but a good CTO/Director of Engineering should be able to give you a relative t-shirt size (XL-L-M-S-XS) to which you can assign a numerical value.
3. Identify your potential business 'levers'
Unfortunately for you, even if you have all of the data above, once you’ve converted it into a scorecard, it’s likely that there still won’t be a clear-cut answer. This is where ‘levers’ come in. Levers are a way of weighting your scores to ensure what gets built matches the company’s stated current strategy.
For example, this year’s strategy might be profitability, or expansion into new markets, or simply top line growth. The reality is that you need to develop different features and products depending on which strategy you are pursuing and so you need some method for building this into your scorecard via categorisation and weighting.
This can be complex, get in touch if you need help.
4. Be data-informed, even if you can't be data-driven
If you’ve worked in business for longer than 5 minutes you will be familiar with the following scenario:
You go to a meeting and a team presents their work to senior stakeholders for them to make a decision. The team have gathered data, analysed the outcomes and have come with a suggestion that makes a lot of sense. And the stakeholders say no, the answer is wrong. Maybe it is, maybe it isn’t. Maybe the stakeholders have passion projects to protect, or maybe they have access to information or insight that the original team does not.
And guess what? That’s fine! It’s fine to make a decision that doesn’t align with the data, as long as you are honest about that fact. It is perfectly legitimate to say ‘the data says x but because of this other factor, we are going to do y, and if that fails we will revert to x/look at this again’. This is called being data-informed and it ensures that decisions are made honestly, with the facts in mind, even if the facts are not followed. It also gives you a clear back up plan and the ability to pivot quickly if needed.
5. Make decisions on a regular cadence and with appropriate governance
One thing that isn’t negotiable in all this is the cadence and governance around your process. It is imperative that this process happens regularly and feeds into your release cycle in a way that can drive certainty for both technical (what to build) and commercial (what to sell) teams.
You need to evaluate new ideas on at least a monthly basis and have an on-going cycle of product development that shapes and decides on these new ideas. You need to have dedicated people working on this – it can’t be somebody’s hobby. You need input from technical teams early on so that you know what is and isn’t possible and you need a proper Product Management toolkit (LINK) so that everyone is aligned and working co-operatively.
Depending on the size of your organisation you may need more than one layer of governance when it comes to decision making. You may need a working group, a stakeholder forum and a decision-making board. More on this below. If the answer isn’t clear to you, get in touch and we can help you figure it out.
6. Seek input from everyone, but have a quorum for decision making
As well as having regular cadence and strong governance, it is imperative that early on you figure out which people are going to have the final say and who will make the tricky decisions about what is prioritised and what is not. It might be your CPO and your CEO, members of the leadership team, or your Board, but you need to decide and you need to write it down.
Whilst it is important to involve as many people as possible in the data-gathering stages of prioritisation, decisions by committee are notoriously tough. Instead, create a quorum of people who must meet to ratify the final decisions. This should be no more than 5-6 people and if they cannot attend they must either send a deputy or contribute in advance.
Setting this up from the beginning with drive accountability and clarity and help you to avoid any impasses in the future.
So, go forth and prioritise! And if you’re struggling, contact us: we can help.
- ACT