In the technology industry we often create products. Products solve one or more customer problems. Starting from the Customer Problems and needs, working back, and inferring what may help solve problems is important. Often companies do extensive surveys – quantitative and qualitative – to understand the needs and formulate plans. However, sometimes any number of interviews will not reveal latent needs unless one intuits their way through.
“If I had asked people what they wanted, they would have said faster horses.”
an old adage attributed to Henry Ford regarding innovating and creating cars. https://hbr.org/2011/08/henry-ford-never-said-the-fast
In addition to asking customers, we also have to look at our assets (or liabilities) to determine what course of action to take. In a team environment, the front line engineer or product person has tremendous insights about what helps them to be productive (or not). The end-customer, sales and marketing people have context about what may work in the marketplace or what deficits need to be rectified. Some of the identified items may not grow the revenue or profits immediately, but can clear path for future growth once some bottlenecks are eliminated. For instance, several years back one of my engineers wanted to build a system to analyze logs for the app store usage. He claimed that this will help us to find customer failures faster. There was no direct attribution to revenue or profit. That said, once we built this system in a shoestring budget, we discovered that there were a handful of bugs that caused significant failures for customer requests. Once we fixed these, we saw more traffic and increased conversions of app purchases in our application store.
On the net we can find a lot of articles about creating roadmaps (Example: How to create a product roadmap). In addition we have to look at the applied context with respect to a team, state of technology, evolution of customer demands, trends in the market, budget, etc. Of most significance is the willingness to embrace unknowns. Any attempt to craft roadmaps means we have to assert a direction and intent. Some organizations are willing to have bold stance (after due diligence and analysis) while several organizations are not prepared. This can be a challenge in bringing along team and organization. I had found that crafting tentative roadmaps that I call directional roadmaps are useful to get conversations started. Repeated discussions and refinements can help us frame a solid path forward.
Here are a few tips that can help in creating such directional roadmap.
-
- Start with an end in mind
- Create a list based on no constraints (aka brainstorm list)
- Inventory the current technology landscape to know issues
- Inventory the past few months (up to a couple of years) of items completed. Past is a good indication for future demands.
- Ask the engineers on demands (without commitment)
- Ask customers or customer champs (sales + marketing) on opportunities
- Assign priority and sort items
- Cluster the list of items into macro groups
- Craft themes for the clusters
- Assign items and clusters on a timeline
- Share and gain feedback on the draft created
- Iterate and repeat above steps a few times
Above steps can get us in the direction of crafting a roadmap for what is possible. The next big step in the journey is to convert the possible into the feasible. By feasible, I mean we apply the budget and capacity on when to tackle the problems. Separately we also need to line up support on who can get this work done to turn the feasible items into delivered items.
The entire preparation may take a few days for the first time. Do not loose heart. I had done such directional roadmaps for tens of projects. Take small steps and we will be surprised at what we find we had created at the end of the preparation.
Leave a Reply