The Battle for the Roadmap

Ah — the eternal battle between sales & marketing teams, customer success, product visionaries and development teams to mould the roadmap.

The sales team have a list of features that their prospects urgently need. Apparently these are preventing deals being signed, and competitors who have those features are cleaning up — but do they lead the product down a blind alley? Product visionaries have their own list of features that need to be implemented for the product to build or maintain it’s lead, relevance and cool in the market — but do they solve a problem customers will pay for today? Customer success teams have a list of features that users of the product are crying out for that will prevent them from churning, or will reduce the number of support calls — but current workarounds kind of do the trick, messily. Development teams have a set of features that need to implemented that will allow the product to scale, be more secure and more manageable — but are they needed today, or is this just over-engineering?

So who is right? How do you know which features should be prioritised? In many fast-moving companies, there isn’t a repeatable way of approaching the problem. Instead, the process tends to come down to

• Who shouts loudest (usually product visionaries and sales leaders)
• Passive-aggressive ignoring of certain unloved requests (usually overworked product managers)
• Using arcane process and over-estimation of effort (usually development teams)
• Slavishly following the highest-paying customer requests
• Control of the purse strings (the CFO)

All of these examples represent an underlying objective that is intrinsically correct (meeting strategic objectives, rejecting unnecessary features, requiring proof, listening to customer needs, staying within a financial envelope), but without any balance.

Isn’t this the product owner’s job?

Product management processes are ostensibly designed to bring sanity to prioritisation, but can all-too-easily act as a block to innovation by only allowing requirements through that the process owner deems fit. Let’s be clear — being a product owner is thankless at the best of times. Trying to keep all internal and external stakeholders happy is a Sisyphean task.

The very nature of hard prioritisation given limited resources guarantees at least one group of stakeholders will be unhappy every product release. It is a very human reaction for a product manager to fall back on ‘the process’ as the one weapon they have to push back on over-emotional commercial people or over-analytical technical people (excuse the generalisation) given the imperfect data they have to work with.

A common language

The problem here is a not really a lack of data — there is plenty of that held in all sorts of spreadsheets, kanban boards and sales reports across the organisation. The issue is that there is no single view of the data that all stakeholders can easily understand. In short — every stakeholder’s list is probably extremely relevant and important — but for very different reasons. We need to find a common measurement framework that ensures all stakeholders are represented. We then need a way to visually convey that data in a form that management teams and product boards can actively use in their planning and prioritisation meetings, fostering positive and constructive communication between stakeholders.

A Measurement Framework

Over the next few articles I’ll be looking at the different dimensions that can be used to build a measurement framework that allow stakeholders to assess each feature objectively. These include:

• Customer demand
• Market need
• Strategic priority
• Revenue potential
• Platform need

I will look at templates and tools that help to track, visualise and prioritise, and look at the optimum ways to present the resulting roadmap to internal and external stakeholders.