When I was a product manager for a commercial software company, one of the things that we regularly created was product roadmaps. These were tied to the vision for the product, and how we thought we could reach that vision. All requests to change our product were evaluated against our roadmap. Did those requests make sense? Did they compliment the direction we wanted to go? If they did, then we accepted those suggestions and would add those requests to our backlog. If the request did not fit in with our roadmap, we would evaluate if the suggestion was something new and interesting…in other words, should we shift or adjust our roadmap?
The roadmap is always a living and breathing document. It always adjusts and changes, as the market changes, as new opportunities presented themselves, as innovation happened. We used the roadmap as a guiding document, as a way to help us keep focused and to ensure that our product continued to move forward. It was also a way that we could say “no” to those requests that were not in line with the product vision. While the ideas might be fantastic and awesome, if they were not in alignment of where we wanted to take the product, then we replied with a polite thank you, but no.
The roadmap is always focused on business value. What can we create that will help solve problems, and bring the most value to our customers as possible.
Our customers always wanted to see the roadmap. They wanted to know that we were thinking about the future. They wanted to see the product grow and evolve, and it also helped them plan within their own organizations.
So why is it that we do not have product roadmaps for those products that we develop and use internally?
Many of the groups that I have worked with over the years are very reactionary in their management of their internal products. If a user requests a change, an enhancement, that request automatically gets added to the backlog. When projects are defined, many times the features included are based on ad hoc requests, without much thought into whether or not that feature makes sense for the overall direction of the product. There is little thought to the overall business value of the feature. Someone high on the management chain asked for it, thus it will be delivered.
What happens as a result? We have internal products that evolve over time into blobs. They may do a whole lot of things, but not in a focused manner, or perhaps not especially well. We tend to get our selves into technical trouble, as we don’t anticipate changing technology in operating systems, browsers, etc. These create emergency maintenance patches just to keep the products afloat. Because we are in hurry, many of these patches are not well executed, since we need to “just get the thing working again”. We create and build huge technical debt. And this technical debt has to be maintained and carried forward as the product continues to evolve.
How much better would it be if we treated our internal products just like commercial products? What is our vision for the product? How can we get there? What is the competition doing? What technical changes are coming in the future that we need to account for? That enhancement request we just received from the SVP, how does it fit into the overall vision? Let’s evaluate it to see if that is a request that we can accept, or do we need to think about adjusting our product vision…or tell the SVP no.
Just imagine…so why don’t we do this with our internal products? What is stopping us?
