Roadmap Story Part 1: What is a product roadmap and why you need it

What is a product roadmap?

To me a roadmap is a visualisation of a growth plan, and the purpose of it is to provide a clear direction, enough context, so we can communicate and align better. Creating, updating and maintaining roadmap, while managing product build and release are part of product manager's role. And many seasoned product managers would know exactly how they would like the roadmap to represent that view. What's been falling through the cracks are clear communication to make sure everyone is aligned, including the executives and the development team.

And why do you need a roadmap?

One of the big milestones in the my initial 3 months with Localz is about building a roadmap. I have been involved in executing roadmap in the past, or making a light touch roadmap when pitching my hackathon ideas. But going through this with almost from the start to where it is today, I look at roadmap very differently than before.

In the past I have seen a list of features (may or may not form a coherent story) sit on a series of timelines that is called roadmap. This time, we spent serious time and energy to create a roadmap that would align with our Iconomy fulfilment vision for Localz.

When I just joined Localz I didn't own a product line, and was asked to help putting together a pack of our roadmap with information provided by the other 2 product managers. (below is the old draft as part of a pack representing the roadmap view)

Quickly I have found that having an artifact doesn't mean we are aligned. We had product managers thought putting product roadmap in 1 slide is irrelevant to manage the product line, which may also take away the focus of that product; we have executives thought the features on the roadmap are not accurate. We have people thought release plan is same as roadmap and expect the same granularity of features across the roadmap. And personally I think it was really hard to maintain product roadmap in a slide where you don't have the space to provide a single view with enough supporting details. Pretty much no one can fully agree on what should be on when.

When I look at the problems we had experienced with then roadmap, it actually highlighted a few contributing factors of the situation: the abundance of market opportunities could quite easily sway our priorities; the lack of constant check of new opportunities against our vision, which could generate a lot of work that aren't necessarily helping us achieve our vision quicker.

Ironically, having a good roadmap that is aligned with our vision can solve the above mentioned problems and beyond.

So what is a good roadmap?

1. It has stories: A good roadmap will have a clear and medium level of details that can be easily communicated in a business language with executives, marketing and sales teams, so it helps us to share our vision, with actionable plans. And helps us to sell our existing and upcoming products better; Let me quickly explain what I mean by business language. As a technology startup, there are a lot of technical capabilities shared among products, but we bundle certain technical components to form product features that can be easily understood and addressed to the market.

It is like cotton fabric can be used to make a shift dress, a pillow case and many more, but it's easier to market a product as organic cotton underwear than we can make anything you want from cottons.

2. It clarifies future paths (and eliminates the paths we won't take): A good roadmap will also have near term and long term ideas to be validated, flushed out and shaped. And this is a key part of product management: what should we build next? One of the common scenes I have seen is mistaken submitted ideas as committed ideas to build. It is an art of balance to understand the market size, the pain points, the user experience and the opportunity cost of doing A that would push out B and C etc. 3. It has clear priorities: A good roadmap should also turn the validated and committed new ideas into features, in a way they are prioritised to provide maximum market value and customer experience, within the sustainable development capacity. And this is another key part of product management: determine when to build what. To often I have seen a demand to want them all and want them now (even if the ideas align with our visions)

With all those in mind, I created a product development process flow as per below, where I try to convey the message that careful thoughts and validation are required at product concept stages without shutting down people's ideas; the ruthlessness is required during product development to prioritise features and be fully aware of the trade offs; and the organised and proactive communication with sales and marketing for the preparation of product implementation with new and existing clients.

Again, a plan is not a good plan if it cannot be shared, agreed and executed. While we chipping away ambiguities in this constant evolving roadmap, I believe we are on the right track and started to have really meaningful discussions with executive teams and were able to come to a consensus of sticking to the short term plans.

Here is how our current roadmap looks like, that lives on a cloud tool, reflecting changes in real time.

To find out how we build the roadmap, continue with Part 2: How we built our product roadmap.