In my consulting practice I visit many companies. In the younger companies (say, 20 years old or younger) the role of the Business Analyst is often non-existent or, at best, a relic of the “early days.” In these, usually Agile, companies, product managers lead the charge with product vision, ownership, customer development, competitive analysis and product strategy. In older companies (2o+ years) product management is a relatively new profession being added mainly as a response to what these companies are seeing these younger companies do as well as a recruiting tool to gain the attention of younger applicants.
This often leads to significant organizational confusion about the distribution of duties and responsibilities between these two roles. To be quite frank, it’s left me confused as well. Product manager seems to be the modern evolution of the Business Analyst and yet, if you ask a BA I doubt she would agree. I’m at the point now where it’s really not clear to me what the difference is between these two roles. To help clarify my own thinking I put together the diagram below. It’s rough, unfinished and not well thought-through but I wanted to get something down and start drawing reactions from the community.
So, looking at the diagram as a starting point for the conversation, what do you believe is the difference between a Business Analyst and Product Manager?
[Jeff]
I think that’s about right, except I might add ‘requirements gathering’ into the shared slice, and say “Can function as a PO” on the left, since it’s by no means a given.
Like you, I’m really not clear about the distinction, so this was helpful. That said, it’s actually clearer than “product owner” and “product manager”. As a PO, I have all the responsibilities that you list under PdM, but as the latter I often didn’t have as much of the business model side. Of course it differs by organization.
agreed
IME I’ve found a lot of BA come with solid technical experience, leading to a common thread of activity in practice that includes technical analysis and specification in there, perhaps even some kind of high level technical architecture / technical design (Enterprise or no) in the BA section
How does that compare to the product management role then?
Next, I’d like to see the Venn diagram showing where UX overlaps with both of these. As a UX lead, I’ve seen myself wearing a lot of these hats.
One thing at a time 🙂
Seriously though, there is a ton of overlap. That being said, I need to work this one out first because I’ve been in too many organizations that have both roles and they don’t often play nice.
Hear, hear. That’s been my experience as well… I think a diagram like this would be helpful at the beginning of a new project for establishing who does what.
One comment on a cross-post of this over on LinkedIn mentioned a knowledge and responsibility for product analytics. I think this is missing from the diagram.
@gothelf:disqus – you draw the distinction between between older and younger companies, but I’ve always noticed that for companies that have BAs there is some historical tie to an IT-centric organization (that mostly focuses on serving internal customers & processes), while companies that have Product Managers tend to be focused more on some external-facing Product and users outside the company. I wonder if you or others have seen this pattern as well?
Sounds to me that these “IT-centric” organizations line up with my “older companies” denomination. That being said, Google has technically-focused, IT-centric product managers.
Scrum does a good job of drawing the distinction between Product Owner and Product Manager, and I would say PO is basically the new BA: “internal” and tactical focus on developing requirements artifacts (e.g. user stories), day-to-day interface with dev teams, sprint backlog grooming, etc. As opposed to “external” and strategic focus of PMs on market, customers, vision, roadmaps, etc. PMs can serve as POs, but it’s usually too much work for one person unless you’re talking about an early stage startup. I’d say 9 times out of 10 if someone is hiring BAs they are not an Agile shop.
So if BA is the PO does that then mean that PO’s are internally facing while PM’s are externally facing?
A company I worked with recently had this structure and it felt awkward to me because it left market insight, customer discovery and a general sense of the customer at least 1-2 touch points away from the team. Do you think that’s a risk with this model?
Also, why is a company likely not using Agile if it’s hiring BA’s?
The answer to your first question is “yes.” The reality is that not everyone can spend tons of time interacting with customers… As a PM I probably spend 50% of my time with customers; there is obviously no way our engineers could afford to do that. Representing the VOC for the rest of the team is a huge part of the PM’s job. They need to make sure that even if you’re 1-2 touchpoints away from the customer you still have a good sense of the problems you need to solve as a developer/designer/PO/whatever. And, yes, I believe the team should interact directly with customers from time to time, and it’s the PMs job to facilitate this. So I guess there is a risk that the team will be “out of touch,” but in my mind that’s just the same as saying there is a risk you will hire bad PMs.
As for why I suspect any company hiring BAs is not Agile… Generally speaking, I find that organizations adopt the job titles that fit the process frameworks they are using. If you’re doing Scrum, you stop hiring “project managers” and start hiring “scrum masters.” I think you also stop hiring BAs and start hiring POs. If you take a look at any of your favorite Scrum how-to manuals none of them will reference the BA role. The job titles you hand out are definitely a reflection of how you approach your work.
As my company began to adopt Agile, role titles began changing too. We use to have Product Managers as our Product Owners. It became very clear they were stretched way too thin. They didn’t have enough time to externally speak with customers and have capacity to always be available for an Agile team. We now have two very distinct roles, Product Manager (under marketing, external facing) and Product Owner (under technology, internal facing). Product Owners work closely with Product Managers creating the high level vision however it’s the Product Owner that breaks epics down into User Stories, work daily with the Agile team, grooming stories, planning sprints & working with UX.
Bingo. Well said. That is exactly what I have seen in multiple places. It’s also textbook Scrum, to whatever extent you care about that sort of thing.
Interesting read. So coming at it from a BA who has transitioned over the last ten years from Waterfall to Agile there are a few points I’d like to raise. As a BA I feel it’s my role to enable and facilitate product visions and goals into something tangible that a dev team can work with, i.e. stories. I work closely with my product manager to help shape the roadmap, gently persuade release strategy (using stats and data as my weapon of choice) and then materialising stories and running ‘3 Amigos’ sessions with dev and QA at the time of playing the story.
Although this could be argued as something a product manager / owner should be in control of in my world due to the workload they have of vision, managing external / internal stakeholders and strategy, there just aren’t enough hours in the day to be on the ground with the delivery team while stories are being played out.
As your article alludes to I don’t think it’s that black and white, and by no means in my experience is the presence of a BA an indicator of a company not being ‘Agile’.
Based on this, it sounds to me like, at least in your case, BA is a step in the career path to a broader product management role?
Yep, that’s a fair observation. In the organisation I work in the natural career path for a BA is into product management. For me personally though I’m loving being on the ground with the team too much to make that transition yet.
Guess the point I’m trying to make is that there is space for both roles in an agile environment from my experience. Although you’re not the first person I’ve come across who questioned the difference between the two roles 🙂
So Pragmatic Marketing has a good framework that defines everything involved in product management. http://www.pragmaticmarketing.com/about-us/framework They also have a good article that shows how these really divide pretty nicely into three separate areas, strategic, technical, and marketing http://www.pragmaticmarketing.com/resources/product-management-triad. All of these things need to get done, it’s simply a matter of who does them. In my experience, someone called a Product Manager generally would focus a bit more on the strategic side of the framework while a BA is generally focused more on the technical side. As Pragmatic Marketing suggest, I’ve also heard the title Technical Product Manager. Unfortunately I’m not sure you’re going to find a good answer to your question as I think it varies company to company.
I think a better approach may be using something like the diagram you created or the Pragmatic Marketing framework and figure out who is doing what. A scrum team needs someone doing those items in the technical portion of the framework (lower left). If the person chosen as the Product Owner has the time and knowledge to do those things great. If not, adding a BA to help out might be necessary. As someone else pointed out, I often see a BA in a IT focused organization to help the customer (Product Owner) talk to the team better (kind of a translator). I’ve also seen this in a consultant model. So when the Product Owner is the actual customer or someone more strategic focused, having someone else (often called a BA) to help with the day to day and more technical aspect can be helpful.
So the overall theme here (and with some other comments) is that BA’s are commonly more technical than PdM’s, right? I realize the organizational context dictates more of this than job titles but wonder how common this generalization is.
Hi Jeff,
great to see you in Dublin last week. Hope you got over the naked incident!
I’ve a real problem with “requirements gathering” – it’s as if there are all these requirements floating around like butterflies and you just need to catch them and order them.
Unfortunately, there’s not enough actual analysis done on whether these requirements are actually worth pursuing.
Lar
So is it a BA who does this analysis?
I believe the BA does the analysis.
Not always, some big global companies I’ve worked with, “gather requirements”, list them in Excel and reflect what everybody wants so everyone is kind of happy.
But because they’re written in English, they’re so ambiguous so as to have broad agreement but no one really checking whether it’s actually a good idea.
The areas of overlap are either so generic (eg ‘tactical focus’) that nearly anyone with a stake in the product might be considered to do/have them, or relatively new things that BAs and Product Mgrs rarely if ever used to do or that weren’t recognized activities until a few years ago (story gathering/writing).
The notion that the BA *owns* the product (and its roadmap, strategy, etc) is a new thing. 5-10 years ago BAs would not be considered to own anything but their deliverables; the *business* owned the product, the BA was the bridge between the business and delivery, etc etc.
It all comes down to the responsibilities anyone with either of these titles actually has in any given organization/project – they aren’t timeless, natural, immutable qualities.
How is product manager any more a ‘natural’ evolution from BA than, say, the ‘traditional’ one of project manager?
As a Business Analyst I think one of the most important functions of the BA is ensuring clarity which is part is achieved in a number of ways.
1. Translating business jargon into plain, concise and clear English
2. Translating technical jargon into simple concise and clear English
3. Problem Analysis – Too often I see projects getting way off track because they never defined the problem they are trying to solve, who they are solving it for, what’s causing the problem, and focusing solutions on the causes.
4. Champion Product Vision – If the Product Manager is the creator of the vision the BA is the champion that helps to defend it.
Lastly I personally believe that the BA should be part of the business model generation. Being involved at that early stage can help cut down a lot of wasted time on pursuing business models that don’t properly support the vision. Since the PM has so many other considerations it could be easy for him or her to lose focus. A BA can help champion the vision during this critical stage.
I also think that whether or not the BA should be the PO is debatable. I’m not entirely sure on which side I would choose either but since I stated earlier that the BA is like a champion for the PM my gut says that is the role of a Product Owner so perhaps yes that’s how it should be.
I agree with the comment in your post that the Product Manager is the modern evolution of the Business Analyst. the company I work for has got both jobs and there is a great deal of overlap between the two – I deliberately left out Product Owner which could be done by either.
I also think that the diagram is somewhat simplistic as it refers to the outputs each job produces rather than its’ goal. My view of a BA is to be talking to “users” in the broadest sense to understand the problem domain and identify what new impacts we want from our applications. Product Management being a newer discipline has a broader remit than that of a traditional BA but I know plenty who would make exceptional Product Managers.
In my opinion the distinction between the roles are very clear! But as you say, their tasks are very similar and the roles are therefore very often confused.
The business analyst (BA) is analysing the business (or a part of it) in order to find improvement areas. In a way they are responsible for making the business efficient and competitive.
The product manager (PM) is responsible for making one or more products of the business competitive.
Both BAs and PMs can be enrolled in projects, and if it’s a Scrum project, their natural role would be that of the Product Owner.
What you have written in the diagram are tools and techniques used by both BAs and PMs in their daily works. Some of them are more project-oriented like use case and backlog-grooming while others are more line-oriented.
Thank you for raising this question. It’s a great post.