One of the many artifacts a Product Owner is asked to produce is a roadmap for their product. While the strategy tells the high level execution plan and the vision depicts what the product will eventually look like, the roadmap basically tells how the product will get there and approximately when. Pretty straightforward right? Well…not quite. Putting the wrong information in a product roadmap can cause a lot of turmoil for you and your customers. It’s important to provide the right information in your roadmap to generate excitement not anger. Roadmaps are just that, a map of the road the product will take to evolve, grow and mature. Too much detail in a roadmap can cause a lot of havoc as it did in one of my previous jobs.

A Product Owner in my former company developed a roadmap for his product that was very specific and highly detailed. It gave information specifying the exact capabilities a feature would possess and the exact date these new capabilities would be released. He communicated this information not only internally but externally too. Of course, as with any project, things happened where the team could only produce a small set of the promised capabilities. Other capabilities had to wait for a later release….much later release. And because we weren’t practicing agile, the capabilities delivered weren’t necessarily the most valuable ones. When we failed to deliver those valuable features on time to our customers, they  became highly upset and started to lose faith in our product and company. The major mistake made here was providing too much detail in the roadmap. And of course not practicing agility to deliver value didn’t help either but that’s a topic for another discussion.

What could have helped here was using a roadmap with just enough detail to get our customers excited about our product rather than fueling their anger. To avoid the “you didn’t deliver these things on this date” problem, use approximations rather than specific dates. State you expect a feature to be released between Q3 and Q4 or even during a season such as summer or winter the following year. Don’t specify exact capabilities that will be delivered. Get your end users more excited about what new value they will receive rather than when they will receive it. Be careful though. You don’t want to wait too long to deliver or they will lose interest. If you’re skeptical about avoiding specific dates, here’s an example for you.

In the spring of 2017, it was announced the release of the video game Red Dead Redemption 2 would be delayed until the spring of 2018. I was really looking forward to its 2017 fall release. Notice the game’s original release was specified for a time of year, fall. No specific dates were provided and the new release date is in the spring. Again no specific dates. Even though there is a delay in releasing the game, I’m so excited about the game itself, I really don’t mind waiting til next year. Despite the fact that it would have really been an awesome birthday present this year! Even so, I don’t know exactly when in the spring of 2018 it will be released. I just know early in 2018 I get to pretend to be a gunslinger in a whole new western adventure. Wouldn’t you rather have this feeling of excitement in your customers than creating a roadmap that makes them angry with you and likely to purchase something else instead?

Finally, review your roadmap regularly based on the product and market maturities as shown below. Constant review of your roadmap will ensure you and your teams are working on the right things and quickly communicating changes.

Diagram courtesy of Roman Pichler

I can say when we incorporated the approximation roadmap approach and reviewed our roadmap frequently according to the product and market maturity levels, we improved our relationship with our customers and our internal staff. We were able to fulfill our goals of delivering features and came closer to hitting our revenue targets. No matter which type of roadmap you choose to use, use one and be vague on purpose about release dates. Your roadmap helps you reach your destination by minimizing frustration, detours and wasted time or effort you’d experience without one. Done right, it keeps your customers happy with anticipation of your upcoming product release.

I recently worked with a team which constantly asked for the product vision. Leadership happily provided it and held several group sessions to do so. While Leadership was reveling in their ability to accommodate the request of the team members and demonstrate their servant leadership, the team members where huddled around privately complaining how leadership presented a strategy and not a vision. This cycle of presenting a strategy rather than a vision by leadership went on for months finally resulting in both sides getting very frustrated with one another. Despite the Leadership’s efforts to provide a vision to the teams, the team members were still at a loss for what they were trying to build.

Leadership was angry because they didn’t understand why teams weren’t getting it. The team members were angry because Leadership wasn’t getting what the team wanted. Does this situation sound familiar? Vision and strategy often collide where one is thought to be the other. A strategy is high level and explains how you plan to execute or realize the vision. The vision is the REASON behind the product such as “I want to promote teenage health” or “I want at risk kids to believe they have a chance to go to college”.

Teams need a vision so they know how to proceed forward and to feel confident they are making the right decisions at a lower level to support the future vision for the product. When the vision is sketchy and a bit muddled, the possibilities are endless so they wander around wondering which one to shoot for. Teams need clear direction on which possibility they need to strive for. You can imagine if someone came to you and said, “Build devices to transport people anywhere” how difficult it would be to know where to begin. You may understand the importance and why but you don’t know the ultimate vision. Is the vision to capture the outer-space market? That may require some expensive equipment, materials and specific skill sets. Or is the vision to make travel on earth easier?

A vision should create a picture and ignite emotion and excitement. For example, “Our vision is to disrupt the transportation industry and allow people to travel instantaneously without the need of an automobile or plane.” What vision did you just create in your mind? Was it the same as the one you thought of when you read the vision of building devices to transport people anywhere? Which one created more emotion, excitement? Without a vision of what the future will look like, strategies, roadmaps and business value means nothing to teams building your product.

If you’re a Product Manager and you want your teams to understand your vision and get behind it, ask them what they are looking for in a vision. Translate your existing vision if necessary so they understand it and can get excited about it.  It’s much easier to build products when you have an idea of what the future of the product may be. Don’t underestimate a good vision and its impact. Also don’t confuse vision with strategy. Remember, your vision is the foundation that supports the future. When people can embrace and see the vision in their minds ideas, thoughts and enthusiasm flow effortlessly.