Let's discuss the role of a product manager during migration from legacy to new technology. On the read of it, it sounds like an engineering job, but believe me, PMs can create a huge difference during transformation. In this article, you will learn:
- Product managers’ role during transformation or technology migration. I insist on going back to the drawing board and work out the problem again. This is the time to bring back old use cases that you had put in the bag due to multiple constraints.
- Managing your roadmaps during the transition period. Not just your roadmap but also influencing partner team roadmap through evangelism and stakeholder alignment.
- Pitfalls to avoid as a product manager during the transition period.
In enterprise or legacy organizations of a certain scale, replacing legacy solutions and software is part of the organization's journey to battle discontinuity and continue to scale its operations. In startups, there is usually no drag of technology, and they do not go through the transformation process.
What is technology transformation?
Transformation is the moving of technology that has an existing customer base and is a source of revenue (website) or cost (backend platform to support operations) for the organization to a newer technology that can:
- Scale organizations product offerings (moving from on-premises servers to the cloud)
- Increase revenue by onboarding more customers faster.
- Increase the breadth of product offerings by an organization.
- Increase interoperability among products.
- Increase customer satisfaction (increased software agility to improve customer interaction)
- Reduce costs (backend software with a high defect rate to a new version with a low defect rate or high maintenance cost of the legacy system – monolith vs microservices). I have written on monolith vs microservices transition in the past, you can click here for more details.
Why do organizations face problems with transformation?
Bain & Company conducted research with over 300 companies to identify the success rate of transformation projects (technology + non-technology). They conducted two surveys in a span of a decade. The first survey was conducted in 2013, and the next one in 2023. Below are the results of the survey.
Source: HBR
The most notable reasons for these failed transformation attempts arise from a lack of urgency, insufficient leadership, limited vision, poor communication, and a shortage of quick wins.
There is a gap where a key personality that should drive and fill these gaps is often not present or leading these transformations. I believe that the key personality to be a product manager who can thrive in challenging conditions of transformation. They will create a vision – what is the state. They will manage stakeholders, align them with product/transformation and organizational goals, and create a roadmap that highlights short wins along the process of transformation.
If this is well known, then why do companies not involve product managers in transformation projects, or is it that product managers do not want to be involved in such projects? In my observation, product managers (with organization and leadership backing) avoid participation in transformation initiatives, citing it to be:
- An engineering activity or engineering led. PMs and organizations consider platforms to be lift and shift operations or architectural-driven projects (for example, moving from monolith to microservices)
- There is limited PM scope for product discovery or analysis. Instead, organizations focus on tech discoveries, taking an approach to finding a technological alternative to solve existing technological limitations.
- Transformation is a long-term undertaking. Depending on its nature, it often takes 1-2 years. A long-term commitment forces organizations and leadership to put PM/Strategy resources into something they consider a better use of their time.
I disagree with these notions, and this is where organizations and leadership lack the understanding of the goals to be achieved from the transformation projects.
When the leadership takes transformation as an engineering-only project and assigns product management to other projects, they treat it as a lift and shift project. But product management should be kept intact and used as a function for key value drivers. It is an opportunity to not just perform lift and shift of technology but rally the organization to drive:
- Stakeholder alignment
- Solve unmet customer needs (reset and regroup)
- Move to scalable technology
Role of a product manager during transformation
The goal of product management is to bring value via the ongoing projects they are involved with. So, the best way to assist the use case for product management involvement during transformation is to showcase its value and here I am going to use my example and then move towards generalization of this topic.
Background and problem statement
Our monolithic architecture struggles with high compute volumes and diverse order data, causing major data processing failures. These failures have resulted in inaccurate delivery estimates being presented to customers, prompting a high volume of customer service inquiries regarding order statuses.
Integration issues with partners and ineffective change management with suppliers compound the problem, disrupting the flow and accuracy of data into our platform. This has a direct impact on customer satisfaction and operational efficiency, highlighting the need for a more robust and scalable solution to manage the dynamic requirements of our supply chain data processing.
How did I approach this problem to support transformation and create value for my company and customers?
The role of a product manager is to support all phases, either directly or indirectly. Continuous value generation should be the goal.
Chapter 1 – Product Discovery
Time to rethink - Going back to the drawing board is not a bad idea. A deeper dive into the problem is how the product transformation should start. The most important thing is to establish relevant value for the customer, organization, and your team.
To ensure you will provide value, start with the analysis of four types of risks – Value, Usability, Feasibility, and Viability. Here are some of the questions I asked and validated before starting the full-blown engineering tech discovery.
Pitfalls to avoid
Halo effect: The halo effect occurs when a positive or negative trait influences overall judgment, potentially leading to erroneous cause-and-effect relationships. This has both positive and negative impacts on product management. The halo effect can mislead by correlating problems with incorrect causes. To avoid this trap:
- Objective analysis: Assess problems and strategies independently.
- Continual improvement: Focus on actual product upgrades and innovations.
Before is the framework I have used to perform product discovery, avoiding common pitfalls.
- Value and usability risk – Understanding what customers need and value.
- Value risk questions
- Are wrong estimated dates a problem for the customer?
- Do customers care about dates post-order? If so, how much?
- Do customers care about exact dates, or would a ballpark date do fine?
- Usability risk questions
- If we provide a better-estimated date, will customers stop calling?
- Do customers only call about dates, or are they calling about other topics, and dates happen to be a side conversation?
- Feasibility risk - Understanding technical feasibility
- What will the new technology look like?
- Why is the new technology better than the existing one?
- How much will it cost to build the technology?
- Creating cumulative cost to build vs. cumulative value to customer s-curve to identify incremental value, we can deliver and cost to deliver that value.
As you can see in the figure below (image 1), we were able to generate significant value with 80% of the cost, but the remaining 2% of value required the remaining 20% of the cost. These are the points; you should ask yourself as a PM while building strategy and see up to what point you want to solve a problem.
- Viability risk - Why should our company care about this? We know our organization is in the e-commerce business and part of it is to ensure products are delivered in good condition and on time to our customers. A great delivery experience ensures a positive experience which builds NPS. A good delivery also ensures a repeat customer. In this sense, it is a problem we should approach.
Based on the answer to these questions, we went ahead with prototype testing for one of the simplest use cases. The results showed that there was a reduction in call volumes, and we were able to establish success via our north star, which was to reduce calls.
By the end of discovery, you should have a thorough understanding of the problem and should be able to explain this problem to leaders and other stakeholders. The problem discovery document should highlight all risks and assumptions that were made. These are the assumptions that you will vet during the measurement phase.
Further, you should be ready with the metrics that you think will help measure the success of this project. The north star should be identified and used as a center point to bind all stakeholders.
Identifying stakeholders
Transformation projects are not team-specific; they disrupt the impacted teams and their processes. To have a successful transformation, you need to have leadership backing that can provide you with the necessary support required from impacted teams.
Leadership must mandate the change and provide a tentative timeline as to when the transformation should be completed. To support your leadership, a product manager must do thorough research on which stakeholders are required to participate in the program.
You should also understand the current priorities on these teams’ roadmap and what are the priorities available for trade-off if your project/program is to be accommodated. Each project should have value and benefits listed in terms of the customer or the organization. This will help your leadership support the trade-off discussion by doing an apples-to-apples comparison.
Evangelism or stakeholder buy-in?
After the stakeholders are identified, the product manager should start the evangelism process and create a buy-in from all stakeholders. This would require you to present your discovery findings and ensure stakeholders are aligned on the value you are providing to the organization and customers by solving the problem.
Dealing with tough stakeholders – there will always be stakeholders that are opposed to the change or why change now. At this point, I usually get support from leadership to on-board them on the project and its timelines. This is why I mentioned gaining leadership support before starting evangelism (see point above). Leadership’s role is critical in helping you get buy-in from all parties before execution begins.
As an outcome of the stakeholder buy-in, I created a signed-off domain boundaries document. This document defines the principles, roles, and responsibilities of the teams involved. This document should be created in partnership with your engineering and design teams. They should contribute and then own the functionalities your engineering will own vs others.
I would strongly recommend getting a program/project manager for a large transformation. These kinds of transformations require a lot of meetings and alignments. As a Product manager, I would preserve time for more strategic portions of the transformation and let the project manager drive the tactical portions. Having said that, I am not at all saying you should not be involved, rather use your time judiciously.
Execution
Finally, the time has come when you put all hands-on deck and start the execution. I would recommend this process for your team to prioritize work to bring incremental value to the project.
We must remember the S-curve from above (image 1), a lot of initial effort goes in before you can start to see the light at the end of the tunnel. Remember, as a lead product manager, it is your responsibility to align the roadmap across all teams involved. You should drive how other teams prioritize and align with the overall vision of the project.
- Discuss with your lead engineer and lead architect what are the foundational principles of your new platform.
- What support is needed from other teams to build this foundation?
- Do we have the right resources (talent pool) to build the product?
- How do we bring agility to the development process, where we can respond quickly to differing needs? As a PM you need to ensure that the roadmap is not glued together but it is like a puzzle where you have the option to move the pieces around depending on the need of the hour.
- Create an assessment of what value each sprint, quarter, and milestone will bring to the overall project. This ensures that as a PM you can deliver constant value and keep leadership in the loop on the progress towards the end goal.
- Identify risks at each level to ensure there is tracking of risks. ROAM board is a good way to track program risks.
Execution is not about just engineering going to work. As a PM, you need to be constantly involved with stakeholders and keep track of progress. Use the project manager to drive stakeholders towards meeting deadlines. The project manager should report to the leader sponsoring this project. This ensures that the Project Manager has sway over stakeholders and can guide them towards the goals.
As a PM, you need to work with your analytics and ensure all data measurement pipelines are up to date and you are ready to measure results as and when the project starts to deliver value.
You should have a north star metric that you want to impact. This will be your primary metric, followed by secondary KPIs. I have provided a detailed process for creating your North Star metric in this blog. Please refer to learn more. Here is the NSM and secondary metrics that I created for the purposes of my project.
Bonus tip 1: I learned this the hard way. It does not matter if you have the commitment from the stakeholders to meet deadlines. There will be teams that will miss deadlines because they prioritized other projects over yours. The sponsor of those projects is a strong leader, and it is difficult to get him on board with your project.
What I have observed is the concept of Tiger teams working best for long-term transformation projects. Where impacted teams loan a portion of their capacity via an engineer or two to work solely on the transformation. This requires a lot of discussion and trade-offs with leadership.
In the end, if you have a commitment, the hassles are reduced (they don't go away), and you get a dedicated resource that will solely focus on one job. Again, this is very organization-specific. Your organization may not support such an idea or may not have enough capacity to loan resources.
Bonus tip 2: I would refrain from hiring contractors for such jobs. Nothing against the ability of contractors to deliver but it's the principle of ownership. Contractors are not owners; their job is to write code; they are not responsible for the quality and execution. Further, they are paid by hours, and it takes a lot of time to onboard them on the technology stack and then get quality output.
Measure and adapt
Changes are part of life; they are sure as hell part of a transformation project. Things you plan for will change and will impact your deliverables. Be ready to adapt.
You can do a phenomenal job during discovery, but there might still be use cases that you missed or did not consider. These are outliers; otherwise, you would have caught them. As soon as you launch the first iteration of your product, internal users (generally product operations) will complain that a particular use case is failing.
Spend time with your operations partners to understand
- Why is this use case failing?
- Are there specific requirements that you missed?
- Why is this use case important?
- Refer to the s-curve. If you created a hack to solve it, would it help?
Get with your engineering partners, stakeholders, and designers to get them to understand the use case and seek opinions and options. Your job is to ensure that everyone is aligned on the problem.
Create all possible options as solutions and the effort required to build each solution. Also, understand the impact of each solution on the existing infrastructure. Remember, doing nothing is also an option.
Bring in appropriate leaders in the loop to brief them on the problem and the solution that is designed to solve the problem. Share all options that were on the table and why that solution was identified as the best option. Be ready to speak about the tradeoffs that you considered. Prepare yourself well as it will not be an easy sell.
Once the leaders are in the loop and the right path has been established, get back operations to ensure buy-in. Be ready for an escalation. If the outcome you are presenting is not the one the operation team is expecting, they will escalate. Present your case well, and at some point, let the leaders handle the conversation.
Be empathetic, product operations represent your customer, they mean no harm. For you, it is not about a specific customer or a specific use case but rather about the overall value you are trying to bring to the table. Being firm with appropriate reasoning is a good quality that will help you succeed.
Continuously measure your north star and secondary KPIs to represent success. At every milestone check, what you are measuring represents true success. Getting the north star right in the first iteration is not ideal and not easy. It will take iterations to get to the right KPIs and north star that will represent your success.
Transformation
Transformation is the process of switching over your legacy services, processes, and operations to a new platform that you just built. It will fundamentally change how you deliver value to your customers and organization. It will be a cultural change that requires a mindset shift to use new services and processes.
By the time transformation starts, you will have spent months getting to this point. Transformation is one of the most challenging parts, and a lot of things can go wrong here. But first, key things to keep in mind during transformation:
- Ensuring backward compatibility – Backward compatibility refers to a software system's ability to be interoperable between new and legacy systems. It ensures the functionality supported by legacy systems will continue to be supported on legacy systems until new systems can support existing operations.
New services or processes that you created will change the way your company operates its business. Old services cannot be switched off at once. Your team needs to ensure all partners that use old services are satisfied with the quality and integrity of data shared via new services.
After a sign-off has been received from all partners, your team should start the process of switching off legacy services. I would ensure that legacy services are switched off in a way that you can turn them on again if a need arises. The best option is to use feature toggles or flags.
An example of how beneficial backward compatibility can be for organizations can be learned from Adobe. HBR case study11 states that it is beneficial for organizations when backward compatibility is maintained between the new SaaS offering and legacy perpetual offering. It is seen as a positive sign by the market, which instills confidence in the shareholders that there is limited impact on customers, which reduces the churn rate.
- Change management processes – Even before you start the transformation, change management for the transformation should start. Stakeholders, leaders, and users should be constantly updated on the progress and release of new features. It is not bad to continuously remind them about the value of this project and share your North Star metrics. Processes to initiate change management include:
- Release notes – At every release notify appropriate parties about the change and how it will impact their operations and day-to-day. Mention what has changed and how the new service will operate. You should use the project manager to send the release notes as the changes span across multiple teams.
- Office hours – I usually host office hours bi-weekly for 30 minutes during the entire transformation journey. Invite any and everyone who wants to understand the change. It is a good idea to keep a log where an attendee can enter their questions in advance so that you can come prepared.
- Monthly newsletter – Send a monthly newsletter highlighting the progress on the project, upcoming risks and how you are managing them, FAQs regarding this project, and key metrics. Invite readers to ask questions and put comments on this newsletter. This ensures they are engaged through the process.
Things that can go wrong during the transformation:
- New services not working for all use cases. As you start launching services one by one, you will start to realize that not all services are working as expected. Your project manager should lead this, and he must create a backlog of items and ensure the right teams are taking appropriate actions.
This is not just about creating tickets; on certain occasions, you will have to get back on the drawing board and hash out solutions. One issue can span across multiple teams and the project manager needs to rally behind these teams to get this thing.
- It is always good to set expectations “moderate or not aggressive” with leadership regarding the timelines. People track timelines and leaders sure do. As a product manager, you should not be directly responsible for the timelines but should be in charge and should present tradeoffs.
Suggest the timeline but never put your neck on the line saying you are X% confident to get this delivered. As services start to go live on the new platform, bugs will create a big backlog that will require a good chunk of work.
- Complaining users, you cannot get rid of them. It's best to work with them and help them understand why we are going through this transformation. You will have to set your ego aside and empathize because change management is not easy.
It is very difficult to change routines and how people have become accustomed to existing processes. Help them understand the pains of the existing process and how your product will help solve these problems.
Wrapping up
The role of product management in an organization’s transformation journey is pivotal, far beyond the technical scope traditionally attributed to engineering. By managing roadmaps and avoiding common pitfalls, product managers ensure that transformation efforts deliver sustained value to the organization and its customers.
Embracing this role fully allows you to not only guide technological transitions but also to influence broader business strategies and outcomes. Engaging deeply in transformation projects, you can be instrumental in navigating the complexities of change and ensuring that the organization remains agile and competitive in a rapidly evolving market.
Looking to transform your own product management journey?
PLA is ready to help with Product Management Certified. Equip yourself with expert-led strategies and industry-standard tools to lead your product management strategy with confidence or land your first Product Manager role.
Product-led alliance insider
Thank you for subscribing
Level up your product-led alliance career & network with product-led alliance experts.
An email has been successfully sent to confirm your subscription.
Follow us on LinkedIn
