Author: Sphoorthy Pamaraju

The decision is made! The product manager decided to overhaul the legacy B2B web-based software product recently acquired from another company. The aim is to enhance its feature set, improve the user experience, transition it to modern infrastructure and technology, and rebrand it with the new company’s name. Being new to the product, the product manager is not informative on all of its features, like what can be kept and enhanced vs. killed and replaced. This article talks about how a business analyst (BA) could immensely help the product manager and development team when modernizing a legacy product and how product managers can use their work for decision-making.

Any modernization project looks daunting initially, but if done systematically and strategically, it is less stressful. Current state analysis is a crucial step in such projects, and BA could start this activity by evaluating the existing state of the following components in the product:

• Process flows
• User flows
• CRUD operations in the UI
• APIs and their definition
• High-level functional and technical architecture
• Data model
• External interfaces
• Business logic, etc.

To perform the above evaluation, the following are a few sources of information:

• Jira/Rally/other scrum tools, Confluence/other document management tools
• Training material and help content(if any)
• Demos or walkthroughs by SMEs
• Source code
• Wireframes or UI mockups
• Browser developer tools
• Problems raised by the customer with L3 support
• Client interviews
• Database(s)

After collecting information, a major challenge comes in correlating two or more pieces. As we know, nowadays, due to the adoption of agile delivery, teams deliver features incrementally, and it is hard to find a single source of truth on the latest state of the product’s functionality. In that case, going through different versions of resources and making sense of the information is a tough task.

To understand what a particular functionality does, it is always better to look through resources and their versions with the help of epic or feature numbers, user story numbers, or functionality/business process names and correlate them with various sources of information. This is a laborious and focused activity, and all the credit for this heavy lifting goes to BA or anyone who does it.

Advertisement

To avoid such challenges in the future, it is always best practice for business analysts or developers to tag user stories, features, or epic numbers . while working on documentation pages or code pull requests. Sometimes teams are in a rush to deliver a quick fix, and documentation is the last priority for them, so documentation or user story acceptance criteria may not exist at all. In those cases, it is a good idea to talk to people who worked on those fixes to understand what has been built.

After this activity, BA could produce traceability between the functionality name, its description, impacted user flows, impacted process flows, links to legacy UI or UI mockups, API endpoints, database entities and attributes impacted, business logic (if any), and finally customer feedback.

Overall, this intense and time-consuming analysis helps in gaining insights into the existing state of the product, data processing, how well it is adopted by customers, and how satisfied they are. Opportunities for product extension or enhancement can be explored based on this analysis and other techniques that align product strategy (product strategy contains a high-level plan for what the product thinks of doing about the product). For example, the goal could be to elevate the product to match its competitor by XXXX year, and competitor analysis can be used to identify gaps the product has with its competitors.

Focus group discussions and brainstorming sessions between product managers, architects, business analysts, UI/UX designers, and developers could help flush out feasible improvements or extensions to the product. In many large companies, cross-functional initiatives are quite common. It is important to involve experts from cross-functional teams, for example, infrastructure, security, and legal experts, in these discussions for their valuable feedback. Also, in companies with multiple product portfolios, the key objective is to maximize the efficient utilization of shared and common components within the platform across products.

This approach is called the product and platform model. To adhere to this model, platform requirements must be given priority. These interactions are wise to have immediately after the commencement of any project initiative and, if possible, even before, as they help the product manager pitch requirements that are achievable and align with organizational goals and objectives. All of this collaboration with different stakeholders helps product managers come up with future requirements with confidence, and requirements can move through the design and development phases with fewer roadblocks.

Conclusion:

I would like to break the myth that product managers are solely responsible for requirements. BA plays a pivotal role in supporting product managers with their in-depth analysis and helping them enrich the product. Collaboration among the product manager, BA, and other cross-functional team members brings unique perspectives and insights, leading to more comprehensive and feasible requirements.