What Emotion Does Your Roadmap Bring?

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.

Roadmap reviewDiagram 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.

Can’t See the Future without a Vision

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.

Avoid Product Liposuction

One of the biggest mistakes a Product Owner can make is to want it all. I’ve heard Product Owners say, “We need all these features and nothing can be omitted.” My first reaction to this statement was “Really? NOTHING?” Product Owners commonly fear taking away features from clients or not giving the client everything they asked for. As a former developer, I often wondered what type of customers or users would require everything the Product Owner was asking us to create. Some features or capabilities just didn’t seem worth the effort it would take to build let alone maintain them. Others didn’t make sense that a client would even want them. If your product owner is making this type of statement and more importantly pouring on more questionable “must haves,” then you need to sit her down and explain to her the pitfalls of having a morbidly obese product that will eventually need liposuction to survive.

One of the core problems with making a product fat with “nice to haves” is the cost and time to maintain those features. Any time a new feature is added, developers and testers must account for testing ancillary code on lessor used features impacted by the new request. Regression testing as well as potentially breaking other areas is increased. These necessary activities to ensure product quality take time, effort and money. When developers and testers are focusing on ensuring less valuable features stay intact it takes away from implementing new and more valuable features. So as the team builds all the “must haves”, the product becomes obese and complex to maintain with little room left to build muscle…you know the features and capabilities that strengthen the product. Quickly the product becomes inflexible and unable to scale without huge risk and cost. The ability to get features out to the market quickly vanishes. The product becomes a liposuction candidate for excess fat removal to allow for muscle growth.

Product Owners, listen up. There are times when even a highly used feature could be replaced with something more valuable or modern. Learn what problems the end users really have and what features they use, don’t use or truly need and why. Often end users get complacent and believe an invaluable capability is necessary when really their needs have changed and evolved without them knowing it. Your product must evolve beyond what your user base believes is critical. That means letting go of features to create room for new muscle. If you’re squeamish about this idea think of the iPhone 7.

Apple took away, what many considered a highly valuable feature, the headphone jack. The removal of the jack allowed for a thinner phone with a wrap around screen. The benefit of a smaller, lightweight phone with more screen space was greater than having an embedded headphone jack. Additionally, the new approach to connecting audibly with the iPhone 7 brought greater quality sound than before. Definite added bonus. So, before you make that statement you need it all, think about your product diet, its fat and the amount of muscle your product contains. Avoid product liposuction by focusing on features which help create product muscle (aka the features that matter to your clients). Don’t let your product consume empty calories or “must haves” which only create a maintenance, testing, development nightmare for you and your development team. Focus on creating products that your customers will really want and can use to solve their future problems instead of products that are full of useless fat that solved last year’s problem.