I’ve blogged before (many times, The Product Owner role (August 2009), Requirements: The next challenge for Agile (February 2009), Books for Product Managers (December 2008) among others) about the Product Manager role. However, Product Managers, or to give them their full title, Technical Product Managers, only really exist in genuine software product companies (including software as a service models). In corporate IT departments and software service companies (i.e. ones that write bespoke software for a specific customer) the role doesn’t exist.
In these companies the “needs” role is usually (or should) be filled by a Business Analyst. I blogged about these when I blogged about System Analysts earlier this year.
Both Product Managers and Business Analysts (BA) are concerned with the “what” of the software product, but how they decide this is different. Basically:
- Product Managers find the need by looking outside the company, at a market of multiple potential customers
- Business Analysts look inside the company at a single customer, with potentially many stakeholders involved
However, he BA role is much misunderstood. As a title I think it ranks second only the “Project Manager” in abuse. In some places BAs are really System Analysts, in others they are Project Managers, in others they just gather the requirements. The definition I like best is “Internal Consultant.”
Thats one of the reasons I really like the Business Analysis Maturity Model.
You can view this model as model for individual career development, but I prefer to view it as a model for corporate advancement. At the “low end” BA just rather up everything “users” think they want, at the high-end the BA is responsible for discovering what the business needs to improve.
When you do this the BA role looks a lot more like a Product Manager role: its about deciding what will advance the company and product in both cases.
And its important from an Agile perspective. When the Product Owner/BA role is played as a “requirements gatherer” then there is little scope for the BA to add value and, more importantly, there is little flexibility in what is delivered. The BA becomes just the guy who communicates the need to the people who write the code.
When the BA role is played as an consultant, working with customers/users and the development team to fill a business need then the conversation changes. Rather than discussing which, and in what order, features will be developed from a given shopping list then conversation can centre on how best to satisfy a business need and maximise value.
In short, the BA Maturity Model is a critical, and until now missing, piece in understanding the BA role in Agile teams and Agile development.