My move from Business Analyst to Product Manager- what changed?
I am frequently asked about the difference between Business Analyst and Product Manager roles, and I have been finding this question in my inbox from friends, colleagues, and Linkedin family a lot recently. So, I am writing this quick read to help give some clarity, with on-the-job examples of differences in role, responsibilities, and expectations from BA vs PM role.
Business analysts often look for the logical career paths for their role. A lot of Product Managers come from the BA ranks. There is definitely 30% or more overlap between these roles and it varies based on the size of the organization. In my move from business analyst to PM role, I found that the biggest thing to learn is to become more strategic in my thinking and behavior. As a PM, I am often expected to know everything and help everyone else do their job better. It means that wherever the roadblocks are, you should be able to manage those. And, you have to be able to talk strategy, especially when it comes to stakeholders.
People’s definition of Product Management is that they are the CEO of the product, but in reality, it is much more than that. 😆
To explain the differences between BA and PM roles, I am breaking down my experience into various challenges I faced and what small wins looked like, with, of course, some on-the-job examples. :)
Business Analyst Role
Top challenges that I faced-
- Breaking down a complex problem.
Example: The bug backlog is growing in size. We need a mechanism to label, track and assign the bugs to the right teams. Create a process for it. - Finding the right solutions. What is the best approach? What are the pros and cons of various approaches?
Example: We want to retire a legacy capability, create a new capability, and migrate customers over to a new system. Working with engineering leads to define what should the design look like? - Ensuring continuous progress.
Example: Keep a ready backlog with at least two sprints worth of work for engineering teams. Remove impediments where needed.
- Documenting requirements clearly.
Example: Keep a single source of truth. Something that makes sense for non-tech folks and engineering teams. A functional product requirement document, with non-functional details covered. Elaborating the project with the tiniest of the loopholes or hidden secrets. - Maintain a good relationship with engineering.
Example: Deliver difficult messages when needed, like changing priorities, urgent bugs that need support over a weekend, but ‘belong’ to the team, and maintain a healthy relationship.
What wins looked like; big or small-
- Resolved a conflict
Example: Resolved a conflict between dev and QA. - Negotiated a solution between commercial/business teams and engineering teams.
Example: Negotiated a solution that was aligned with business strategy(the expected outcome), and can be delivered in less time(using an approach that could be completed in expected time)! - Increased team’s velocity because of clear requirements (Written + verbal +a bit of encouragement and positivity)
Example: Excellently written documentation, ranging from product requirement documents to user stories, to how-to guide and fact sheets, providing clarity to different teams. - Managed right expectations with respect to scope and timelines
Example: Sharing clearly written scope documents, proactively tracking the progress, and communicating timelines to stakeholders. - Conduct successful demos
Example: bring stakeholders together, give an overview of project scope, deliverables, timelines, and when ready, show progress through live demos.
Product Manager Role
Top challenges that I faced-
All of the above plus a few more things 😁
- Develop a decent idea of what your customers want
Example: Stay on the hunt to find customers to talk to, understand their needs and challenges. - What to build next? Why?
Example: Decide from a pool of ideas, which one deserves the most attention with a solid reason to back it up.
- Dealing with competing priorities.
Example: Deciding between enterprise customers’ ‘unique’ requests VS product roadmap - Identifying the right metrics. Measuring the outcome
Example: defining product success metrics, related to adoption, awareness, engagement, revenue, renewals. - Making a case for investment.
Example: create a business plan, show value, customer benefit, business benefit, and return of investment. Justify it to get the right resources. - Listing to EVERYONE. Keeping EVERYONE updated. Frequent communication with various teams
Example: taking feedback from support teams, services teams, commercial teams, for new capabilities to be launched and keep them updated about what’s coming next. - Pulling yourself out of the weeds and thinking about the bigger picture
Example: indulging in technical conversations and understanding technical challenges, but not letting them overpower customer-first decisions.
What wins looked like-
- Producing a clear roadmap, with buy-in from senior leadership and blessings from customers!
Example: roadmap accepted by senior stakeholders, key customers/partners. - Positive customer feedback. NPS/CES
Example: NPS score increased based on a recently launched product capability. - Good adoption of new features
Example: A newly launched feedback is getting used as expected, with high adoption, and high frequency of usage. - Reduction in number of support requests
Example: support requests and issues raised by support teams are reduced as an outcome of product upgrades. - Operating in an agile manner, planned product iterations, and frequent releases
Example: plan product launches in phases, iteratively realizing value, so time to market is reduced and the upgrades reach customers sooner!
Now.
I do feel that the move from Business Analyst to a Product Manager role is a natural evolution of the role, if you are enthusiastic enough to take up more challenges, are hungry for creating impact, and solving real-world problems energizes you.
P.S. Dear reader, I’d love to hear about your unusual product management lessons. Share it in the comments section below. Also, if you like what you just read, do recommend it, and share it with your network.
