Need a Product Roadmap that stands scrutiny ?

A Product Roadmap is great for communicating your vision.  What’s challenging about building one is that stakeholders often have strong opinions and differing interpretations of user or market research.

How can we resolve this painlessly?

Why Product Roadmap choices mean trade-offs

In this short series, I look at how Roadmaps can improve your product development and decision making by building consensus among your team and confidence in other stakeholders – however demanding they are.

Here’s the opportunity: Do you have a great product idea? Fantastic innovative ideas – ones you think will disrupt and blast the competition out of the water?

Or perhaps you’ve done a digital audit and now have a keen insight into what’s needed in your product portfolio to propel your business to growth?

Here’s the challenge: You know it’s not enough just to have a good idea, or simply to recognise a particular gap in the market – you need to take practical steps.

Vision alone is not enough to make it happen

In a previous blog, I outlined some of the digital product development challenges you might face.

To make your idea happen, you may be lucky enough to have a ready team of like minded people willing to leap into a learning cycle with a Lean Start Up. Good luck, it could be a life changing journey.

For many teams, however, there will be influential stakeholders –  important but less engaged than a development centred team: people to convince, enthuse, cajole – perhaps even before you start. They may even be critical gate-keepers for your programme.

Even some of the best and most supportive stakeholders can be unreasonable – asking about your idea and how you are going to make it happen. They will want to know long before you feel you’ve worked all these things out. They may expect you have examined options and can show choices that line up for their approval. Answers will need to stand early scrutiny –  these stakeholders may not be entirely comfortable with signing up to an Agile approach which to them looks like an open-ended voyage of discovery.

Project leaders and developers ask us about this:

• “I am caught in the middle of multiple stakeholders with strong, opinions and differing interpretations of user or market research.”

• “How do I build consensus then set a direction and first steps for our development that stands scrutiny and establishes confidence?”

With this in mind, a good Product Roadmap needs to be more than a sequence of features – it needs to show a reasoned route through the landscape that the product fits into. This will need trade-offs – striking a balance or priority between apparently conflicting demands.

“A good Product Roadmap needs to show a route through the landscape that the product fits into”

When a Product Roadmap is built the right way, people find that as well building consensus for a route forward it improves both their product and their approach to making choices later during development.  Here’s what they say:

Start with common ground – three things all products need to be!

The consensus is about finding something everyone can agree with. Design Thinking and many many other approaches suggest that a product needs to be three things:

• What is desirable:  is this wanted?
• What is feasible:   can we do this?
• What is viable:  should we do this?

We find people agree more on less on this.  We need to meet all of these things as best we can and for the most stakeholders we can.  That’s easier said than done – these balancing acts are trade-offs.

“There are no solutions, only trade-offs”

Thomas Sowell  – American economist & political philosopher

Two common ways to find trade-offs

• Planned projects
• Lean Start-up methodologies

Perfect plans. The premise of planned projects is that they start with a specification – though strictly these may be requirements in a Waterfall based development.  Requirements often focus on the technical and tangible elements needed from a product at the completion of development. If these do encapsulate what’s needed; the technology is proven and the budget realistic it can work well.

However, where there is less certainty – and this is common –  projects can spend a lot of time “hunting” an acceptable set of Desirable-Feasible-Viable trade-offs.  This means changing directions frequently as key trade-offs are identified. Typical examples include commercial issues, practical build considerations or technology not performing as you expected.  This unnerves the most supportive of stakeholders and is wasteful.

Go Lean. The problems of “predicting a perfect specification” have been recognised by techniques such as Lean which adopt an Agile approach to development. Start a product small and build in small steps to avoid having to predict far ahead.

Agile may reduce direction change by making smaller steps towards a product – using frequent feedback and “human scale” planning in the nearer-term. With this realism, Lean and Agile have made great contributions to both business incubation and development methodology.

Lean and Agile can be great in practice. However, at the same time, they can scare some folks who have an important stake.  Starting Lean or Agile can look like a leap into the unknown. This uncertainty can mean Agile looks uncontrolled with stakeholders sensitised to small changes in direction.

A summary?  Development: Not easy

So, if heading straight to a specified product is near impossible – resulting in a meandering development path –  while Agile can be scary, feel ‘uncontrolled’ and lack evidence to show where you are headed, what’s the alternative?

In truth, at some level, most businesses need show evidence of their plans. They work with budgets; need to anticipate their product future and have to anticipate resource needs some way ahead. However, we can do better than being hamstrung by a rigid project plan.

A third way:  Can Enterprise Roadmapping help?

An excellent approach to aid your product definition and the delivery plan is Roadmapping. Roadmapping captures the best knowledge available at the start and maps an appropriate route through that landscape.

Roadmapping gives you a great head-start before you start building a business by Lean, developing by Agile or planning a Waterfall project. It maps a route for all to see and the help make decisions you will need to make later too.

It’s smart in the way it accounts for factors which are often ignored by traditional planning approaches and builds consensus at the same time. This approach helps you make decisions you will need to make later in an agile way too.

Here is a generic roadmap. It gives a high level, top to bottom view of your venture – with a Product development stream through the centre. The roadmap shows an enterprise viewpoint – a whole picture of a development route on a page with the negotiated trade-offs shown.

This view is built in three swim-lanes:

• Market & Business:  The top shows what you know about your target market and business along with product releases you might make in response
• Product:  The middle maps out a likely product development route in a series of likely steps to meet market needs.  Innovation milestones show prototype / MVP / candidate releases which test a hypothesis or reduce risks.
• Technology & Resource:  The lower swim-lane shows what you expect to need to respond to build the Products above.

Isn’t this just a Project Plan or Feature Release sequence?

The product swim-lane in an Enterprise Roadmap shows Products or features in the sequence.  However, rather than a simple feature “release plan”, it shows a range of candidate Products or features that have consensus on what seems to best meet market and business needs. There is a route through the landscape that shows all the best knowledge we have today along with issues you expect to navigate while you develop your releasable product.

“A Roadmap is a balance between a hard and fast linear plan that may be impossible to follow, and an invitation to go on an uncertain journey of discovery while we develop.”

What is different is that there are ‘options’ shown on the map. We show more options and alternatives where we have less certainty about the future.  For example, there may be a range of technologies that are candidates to be used.  Some may be used initially, but we are unsure if they will make it through to the final product. The value is that you have considered options for the future – not in time-consuming detail, but as a first look.

Our approach also contrasts with a simple Product Roadmap that only shows what has been decided, without the supporting evidence or options available to us right now.

Stakeholder helper

When complete, an Enterprise Roadmap shows a welcome depth of thinking to quizzical stakeholders in an easy to absorb format. This can be powerful to build confidence and consensus around a realistic Product Roadmap and to start your route to success

Need help to start and build a successful digital product?

Our team at Digital Works Group can help you create digital products and services, using roadmaps and other techniques, so you get these benefits:

• Help you understand and match market needs with technology and resources
• Minimise the time to launch a successful product or service created by any development method
• Cost savings by reducing  wasteful development mistakes
• Build strong collaboration across development teams and wider stakeholders