Good business analysts think like product managers

As is the case with many titles in the professional IT world, business analyst and product manager share many commonalities. The role of product manager requires sharp business analyst skills and business analysis branches into many of the same areas a product manager works within. Product managers partner with IT, finance, sales, marketing and the executives of the company to determine and chart a course for their products. They do this all while managing the necessary resources to execute successful delivery and stabilization of what’s currently on the market. Business analysts work with IT, finance, sales, marketing and the executives of the company to determine the appropriate requirements the software or product must include to contribute to the goals set by these departments.
When a business analyst works like a product manager, they take a holistic approach to requirements gathering and process mapping. Rather than simply taking notes during meetings, responding to emails and calls as they come in, and setting up meetings with stakeholders to identify gaps in the current solution, good business analysts create and document a landscape in which all stakeholders and departments have equal share. In order to do so, they must approach requirements gathering with the big picture in mind – similar to a product manager.
Developers want to develop, testers want to test, project managers want to plan and manage the timing of resources, and everyone else just wants to know when it will be done and what it will do. The good business analyst then must work in between these teams, not as a “translator” per se, but as someone who is thinking of the broader goals of the product. Ideas become features, and features become product sales because the good business analyst asks questions beyond “what should it do?”
One of the more complicated aspects to business analysis is managing competing priorities for the timing of planned functionality to become available. As an example, let’s say marketing needs the software to produce an interface allowing them to enter details about an email campaign which they plan to launch in the next two weeks. At the same time, sales would like to demo completely different functionality that a client has requested to see before they buy more licenses and the timeline is critical. There is no product manager role on the team and the developers need to know what the functionality is supposed to do and when each functional area needs to be completed. In addition, the QA team has to plan their testing and the project manager needs to know how long it will take to complete the development and testing, which hinges on what is required by the marketing and sales teams to call the feature set “done”.
The executives are looking to the product team to give them the information they need to set priorities. But what’s the bigger picture? Can the functionality required by marketing and sales be delivered in such a way that makes it possible to meet both deadlines? Is there existing functionality in the product that could be refactored or leveraged to reduce the amount of time required to make both teams happy now and going forward?
A good business analyst asks tougher questions and makes stakeholders think about why they need the feature added or changed to gain an understanding of how they perceive things as they are today – and what they could be in the future. A good business analyst gathers product roadmap level requirements in addition to sprint level requirements to reduce the amount of effort needed to produce better feature sets in the future. A good business analyst inquires about what the perceived future of the product will be to all stakeholders, not just the executives. Is this supposed to be an internal tool for marketing or are we trying to sell more licenses to our existing customer base? Of course, the answer many times is “both”, so a good business analyst now must decide themselves how to meet both requirements. That way, the developers know what they’re supposed to do, the QA team knows how to test it, the PM knows how long it will take, the sales team can sell more licenses and the executives see a faster return on investment – sounds a bit like product management.