Aligning a Product Tech Stack

Problem

As I joined my current company, I learned that our healthcare product was not on the same tech stack as other products. It was launched a couple of years after all the other products were launched and was widely considered to be a side-product developed outside of the core product suite. Since we developed a multi-product strategy that should sync different products within each line of business I tried my best to bring it on the same tech stack.

Actions taken

As a sales-driven company, we would be only moving forward when we would have a customer. Therefore, I had to find the right customer for whom we should build the product again, this time on the new tech stack. We tried to identify one long-term project that would help us tip the balance and convince the business that it would be worth both in terms of the cost and risk.

Unfortunately, we struggled to find a good customer that would justify our effort. We had to find a project where the new tech stack would bring significant added value both to customers and the delivery team. In this particular case, we identified a set of new features that could be only built on the new stack. In other circumstances, it could be something else like the integration with other products, for example.

Then, I had to demonstrate to the stakeholders that the risk was minimal and that we could mitigate it. We did a planning exercise that consisted of the two gap analyses: one that compared the possibilities available to customers if the project would be built on the new stack in comparison with the old tech stack; and the other that compared our company-wide project methodology and a specific methodology for this project that was based on four to six months delivery cycle.

Finding an ally on the delivery side was crucial. I knew that our ally should be someone who would be convinced that our project would contribute to the successful implementation of the company’s strategy and bring value to the business. Moreover, an ally should trust our product vision beyond its most immediate impact. When the decision to move to the new tech stack was challenged at one point, our ally was someone who was decisive that should be sticking with it and that our product strategy was the right one. It was far more influential than having the product team making their own case.

Finally, we had our first project moved to the new tech stack. We chose a project whose added value was evident and that could showcase the most obvious advantages without us having to go around and persuade people to support us.

Lessons learned

• Do things in their own time. I tried to implement the new product strategy before I had secured alignment with other stakeholders. That didn’t work out, because I tried to run before I could walk. I was convinced that if we would run we would be faster, but the rest of the company was worried that we would stumble and fall.
• There is no point in sharing a big picture with all stakeholders. If everyone is focused on the next six weeks, sharing where you plan to be in one year, won’t get you any attention, let alone support for your project. Even if you break it down into successive six weeks, it will still be projected far into the future.
• If possible, go for dual allyship. Secure the support from two allies --- one on the business and the other on the technical side.