In this Blog Article we are going to discuss how to optimize your Product Roadmap, to ensure that you don’t try to do too much or do too little.
When creating a Software Product Roadmap there is always a balancing act between what Features you want to include in a Release, how much time you have, and what you are willing to Invest in the Release.
From a Business perspective every Executive wants to have a Product that they can sell as quickly as possible and for the lowest cost. Unfortunately, in most cases this is not realistic - it’s going to take time, because developing software is inherently complex. At the same time, you also need to guard against the team making things too complex.
It is very easy for a Technical Team to think about all of the thousands of possibilities that any given Application may need to handle. After all, that is their job and you want them to do that - to a degree. You have to do some Risk Analysis on every major Application Module to determine whether or not it really needs to be done now, as part of this Release, or can it be scheduled for a Future Release, or even not done at all.
Questions you should ask, to challenge the Team is they are trying to “Boil the Ocean:”
At the same time, you can encounter situations where someone who is moderately technical creates a quick and dirty Demonstration and suggests how easy and simple it is to build. And because of this Demo, the Executives believe incorrectly that suddenly we will get a Product that we can start selling. This typically happens when you have someone who is a Product Manager or a Pre-Sales Engineer creating a Demo for a potential product, which may or may not ever be built or function in the way they are demonstrating. But they are doing this to Sell a Concept.
A Demo of course only takes maybe a couple of days to create and it doesn’t really work, it only appears to work. And when you open the hood and start looking at the engine, you know it will never work as designed. It’s a POS, but anyone looking at the car believed incorrectly that it would work.
As technology professionals, there are certainly times when we need to create Product Demos and show them. However, we must guard against having the audience believe this is a fully functional product or that we will have a sellable product next week. There are thousands of things that must be done to turn a Demo into an actual Software Product.
Unfortunately, I’ve seen both of these “movies” several times in my career.
At Avalon Software a mid-tier ERP manufacturer, we were trying to Boil the Ocean with our major new Release, and had to include everything in our existing Product, but also a lot of brand new features and a completely new architecture. Because of this our new Product kept getting delayed quarter after quarter, as the Development Team was in effect trying to hit a moving target. Naturally, Sales dropped off as dates were missed and ultimately the company folded.
On the other side of the coin, I had the unfortunate experience having a Product Manager & Pre-Sales Engineer create a Demo for a document management client for Microsoft Dynamics Solomon (SL), known as KwikTag SL Pro Client. The “Demo” looked fantastic. And it was also missing a serious ton of functionality, as nothing really worked. It looked pretty, but that was pretty much it. In this case the Product Manager convinced Marketing and Sales that it was an actual product, so they naturally started selling it. However, when it was implemented in the first few Clients, they all reported hundreds of missing features.
For example, the primary reason you purchase MS Dynamics SL is because you are an organization with numerous facilities and you have them set up as separate Limited Liability Companies (LLC’s). This is very common in the restaurant and hotel industry, where you may have hundreds or even thousands of locations. Unfortunately, our Product Manager did not understand this and so built the SL Pro Client to handle only a single Company. So, he was boiling a Tea Cup in this case, because you don’t buy and implement MS Dynamics SL if you only have a single Company entity.
Because of this and other major misses, it took well over 2 years to finally create a product that would work and could be implemented. The Product Manager kept saying it is done, or that it would only take 2 more weeks to finish. But this was all a fantasy, because he was only focused on what it would take him to create a Demo. He was not thinking of what it would actually take to build a working product.
Here are the Business Considerations that we need to take into consideration.
Is there a specific date that we need to have the product ready by? Is this a firm date? Is something else dependent upon us hitting this date?
The next question is that we need to separate the Steak from the Potatoes. Meaning what features are actually required - the Steak, and what features are nice to have - the Potatoes? This is very important, because you cannot simply say that every feature is absolutely required for a Release, because then you will never release the software into Production.
You have to make some hard choices and decisions about what to include and what will be included in a future Release.
Every Chief Executive Officer and Vice President of Sales, wants to know when we can start selling the new Product or the new Upgrade. As business relies on revenue coming in the door, whether you are selling a Perpetual License or a Subscription License for your software product. The challenge is that you want to start selling when the time is right and you know that the Product or Upgrade is mostly baked.
Ideally, you should not start Selling the new Product until you are in a solid Beta Cycle, where both External and Internal users are testing the Product. You want to have several External “friendly” Clients testing your new Product to ensure that you haven’t missed something that is critical. Skipping this step in the process can lead to major problems in the long term, as you definitely do not want to have Sales selling the new Product too soon where it is still in a partially built stage.
As one of my good friends once told me, “You can’t implement a Vision.” Meaning she could sell the Vision, but if the Client can’t actually use the Product, they will want their money back.
Finally, remember that with any Software Project there are 3 Aspects.
The Business can pick any of the 2, but the actual Team doing the work gets to decide the 3rd aspect. If the Business Executives try to determine all 3, the Project will fail and you will run into trouble. Avoid this whenever possible.
In this Blog Article we have discussed the balancing act that everyone goes through when creating a Product Roadmap, as well as various considerations that one needs to take into account. When balanced correctly, your Roadmap will be Predictable and Successful, which as a Business Executive is what you want. Just be cautious of pushing the envelope too far and setting the Team and the Business up for failure. It is common for a Business Executive to want things done quickly, but by rushing things you can also end up with poor quality or a Product that doesn’t meet your Client’s needs and thus cannot be sold to them.
At the same time, you must watch for Product Management and the Engineering Team from trying to build too much into the Software. Thus the high wire act.
We hope that you’ve enjoyed this Blog Article.
Thank you, David Annis.
