Product Manager vs. Business Analyst
In certain companies, mostly those that have an IT heritage (see https://svpg.com/moving-from-it-to-product-organization), there may be an additional role somewhere in the product organization either in product management or in the product development organization that may be called ‘Business Analyst.’
This is not to be confused with the Business Analyst role in product organizations where the person is responsible for analyzing the business metrics and analytics. I¹m referring to a very different role here.
In IT organizations (those doing either internal software or custom software) ‘business analysts’ are often responsible for the gathering the detailed product requirements.
Imagine a typical custom software project, where the customer might be someone like an HR manager needing some sort of benefits related application. There may be a handful of IT developers that are available to code, but who is it that translates the HR manager’s business needs into something the developers can build? In an IT/custom software organization you almost never have product managers, so there¹s a need for someone to do this requirements capture / requirements definition role. One common term for this role is ‘Business Analyst’ and in fact the term and role has been around for more than 30 years.
The problem arises when this IT/custom software model is inserted into a product software organization, which typically has the role of product manager responsible for defining the product.
The first reaction of most product managers brought into such an organization is to try to understand who are these people and aren’t they doing essentially the same job that I’m supposed to do?
This is especially common if the engineering organization has grown attached to their business analysts and lean on them heavily for the detailed product requirements.
Unfortunately, this is yet another example of the two-people, one-role problem that I have highlighted earlier (see https://svpg.com/product-management-vs-marketing). It’s the same basic issue as the ‘business product manager’ vs. ‘technical product manager’ split, with all the same pitfalls.
To be clear, I¹m against this split in either form. Each product (or product area) needs that clear owner that¹s accountable and responsible for everything from high-level objectives to the details of the user experience.
The good news is that often these business analysts have the potential to be excellent product managers.
One exception to this is when the business analyst is not actually capturing the customer requirements, but instead they are documenting the internal systems design (aka internal spec). Occasionally I find the business analysts really playing this internal documentation role. I think there are other issues with that, but in this case it really has to do with how the engineering organization wants to operate, so it¹s outside of the scope of product management.
If you are a product software organization, and if you have business analysts trying to split the responsibility of product definition with the product manager, I’d encourage you to take a hard look at how the roles are defined and staffed in your organization. Identify the true product managers, and empower them to own product definition completely, from the high-level to the details. Clear ownership and clear accountability.
