Why should we include engineering tasks in a product roadmap?
We all have great ideas, including sending a manned satellite to Mars! But is it possible without the right technology? Definitely not. And so in this article, I ’d like to share some of my experiences and why there has to be a balance of prioritizing engineering tasks and customer value features in your roadmap.
“You have to produce results in the short-term. But you have to produce results in the long-term too. And the long-term is not simply the adding up of short-terms.”
Peter Drucker
New feature development
If you have managed to successfully capture the voice of the customer, then you ’d be able to understand their workflows.
If you understand their workflows, you ’d be able to understand their jobs to be done!
If you understand that, then you ’d be able to relay the same to your team.
And only then, would you be able to come up with the 1st MVP of your product.
Why is all of this context important to your team?
Reversing architectural changes is costly.
Foundationally, it may influence the selection of vendors, technology
- This one time, we were changing our messaging technology from TIBCO to Amazon MQ. It was marketed as a very simple change but the teams involved had to work nights and weekends to get it in!
As part of product discovery, you would have had an idea of the volume on your application. This means you need to performance test your application and determine if it satisfies the expectations of your customer. There is another aspect if your application is on the cloud. You are charged by the hosting company like AWS and so you have to be mindful of that.
Re-architecting an application
Regardless of industry, in fact in all companies I have worked with, I have noted this pattern. Initially, we ONLY focus on the customer features to the point that it slows down the releases. These are few signs -
Even for small enhancements, it takes a long time to release the changes. So, it is important to assess the application architecture every couple of months. Developers are frustrated that they cannot work on new technologies.
Product managers feel frustrated that they cannot release frequent value for customers. Unless they have an appreciation for this challenge of their application turning into a monolith, they wouldn’t prioritize the technical spikes & tasks to constantly update the product to newer technologies.
What happens if the application turns into a monolith?
Engineers have to migrate customer data into the new application.
Data quality is a very important issue i.e. in my experience, we have to correct their data prior to migration.
Basically, at this time, you cannot deliver new features to customers.
These are infrastructure upgrades that have NOTHING to do with business logic but need to be done so that our app can use the technology. After all, even vendors like AWS, PCF etc. retire their products at a certain date. In the past, I have been “accused” of considering this in my roadmap. A small engineering task is something I wouldn’t add in my roadmap but if it is a gigantic change that truly affects providing service to your customers then you should consider adding it to your roadmap!
My products are now on the cloud. But the cycle still continues. The concept of infrastructure upgrades still goes on.
There are many companies with products on-premise and want to move onto the cloud. It takes time if you are aiming for the same. You need to strategize for the services you are going to offer before your cloud-based application is live.
- The migration process has been tedious. It isn’t a one-size-fits-all. Since AWS offers a LOT of products in its suite, our engineering managers have to decide the best technology that works for them.
Another example is the change of code repository to GitHub for faster deployments.
Final Thoughts
Every app has a lifecycle and so we need to ensure that we are using the correct technologies for the same. Unless that happens, we will not be able to provide the value to customers. This also has an impact on the employees.
Developers get frustrated, having to use tedious ways to execute simple requirements. They might be frustrated and finally build their own solutions, if they don’t have clear guidelines. For eg: Use React only for UI or we have to move to GitHub by a certain date as a code repository.
Product managers are also frustrated with not being able to deliver business value to customers. We can’t prioritize this either if they don’t appreciate all of the above OR the org KPIs (i.e. goals) are too aggressive, thereby forcing the product team to forgo the technical requirements. You don’t have to be technical but understand basic concepts and talk to your developers to understand what and why they are asking. It isn’t us vs. them!
Let us do this balancing act!!