What’s the difference between BA, PM and PO?
Hello, everybody. Welcome
to the Brazilian BA guest. Today I have the honor to receive
here someone that is considered as the father of the BABOK
guide. My good friend, Kevin Brennan. Hello, Kevin, how are you? Hi Fabricio. I'm good. How are you? I'm fine. Thanks and glad for
having you here. It's an honor. And I have a good question
for you. Are you ready? I think so. Yes. So the question for you today is, "what's the difference
between business analyst, product manager and product owner?" BA, PM and PO. What's the difference
from this soup of letters? Yeah, I know that that's been a
confusing issue for a lot of people. Really. The difference is that fundamentally a BA is somebody who can go
into an organization, look at the processes, the
work that's being done, the people who are involved and kind
of figure out what solutions look like. A product manager is
somebody who goes out to consumers or to enterprises
and looks at that as a market, they have to figure out what it is
that people are willing to pay for.
What kind of solutions are
they interested in acquiring? What will make them buy or not buy? And I think a big part of the confusing
comes from the fact that product in English has two distinct meanings.
The first is something you sell, right? Something that you put out in
the market for people to buy an iPhone, a newspaper, a detergent… These are all products in that sense, but product can also mean
the outcome of a work process. So when you have a project, you build something and
that is called a product. And the product owner title actually comes from that second meaning
of the word product. So the product owner role
in scrum is the person who is ultimately accountable
for telling the development team what it is that they
are supposed to be building.
That's not to say that the development
team can't talk to other people. They can't talk to stakeholders,
they can't talk to customers. No, no, that's absolutely not the case. The product owner is not their
sole source of information, but when it comes down to deciding, "okay, we're in a sprint" – because
the term comes from scrum, where you have sprints -"what are
we going to build in this sprint?" "And how will we know that we have
delivered on the goal of that sprint?" The product owner is the
person they can go to and ask, how do we know we have finished? What
is it that we're supposed to construct? And the product owner is the person
who will give them a definitive answer for that sprint.
So the product owner role
is an interface for the team and the product owner role could be
performed by a business representative, an executive, it could be a product manager for
something that's being sold out in the marketplace, or it could be a business analyst for
something that's being used inside an organization. That's really interesting. This difference to make
about the meaning of product. And if I understood it
right, please let me know. When you're saying
about the product owner, you are saying the product as the
result of an initiative or a project or an endeavor. And when you're
saying product manager, you're using that other
meaning of product, that is something that is sellable
to the markets.
Is that correct? That's correct. Yeah. A product manager is somebody
who's going to go out there. They're going to talk to customers. They're going to look at
what competitors are doing. They're going to be looking at a whole
range of things and trying to figure out what features are needed for, especially
in the case of a software product, for that software to sell. Now, they may turn around next a product owner
to the team and say could next sprint work on this? Or they may have somebody who takes
on that responsibility within the team and especially with
large software products, you end up with product owners who may
own one feature off the product, right? I've seen cases where commercial products
have somebody in charge of search and somebody in charge of user experience
and a whole bunch of different areas.
But yes, the product owner is somebody who
plays a role of a development team, particularly in scrum, but the term is spread to other
agile area of methodologies. Interesting! If we see products in this
two different scenarios, we have the marketable product
(let's call it that because it's saleable) and we have the product
from the result of initiatives, and we have another
instance, to complete this comparison, that is the
business and the business is in a higher perspective.
When
I see products, our products, marketable products or
products from initiatives, because the business should set a boundary around all those things.
When we see a business analyst, should this person have
this understanding? Um, yeah. And there's other
factors that go into too, right? So if I'm a product manager, I'm looking at what services we
develop, what products we put in place, but product managers know, and generally don't care how that
product or service gets delivered, right? That's not their problem. Somebody inside the business has to
figure out what are the capabilities you need to deliver that product? What are the processes that people are
going to have to follow in order to create that product or service. What
are the technologies that support it? And that's more the space that business
analysts has traditionally played.
Now we have business architects who
are also becoming part of this picture at a higher level, looking at the full scope of capabilities
that a business needs to deliver all its products and services,
not just a particular product. Interesting. Something that, for me, in my point of view makes this more
confusing is that those terms were defined in different contexts. The product owner, as you
said, was defined in scrum. So it's a framework for
delivering a product incrementally. So when we say about business analyst, it's defined it in the
BABOK guide by IIBA. So it's not looking for the
delivery of a product incrementally. It's a wider perspective with
strategic… And it defines: "everyone who does business
analysis is a business analyst".
And in this perspective, all those roles, even the product manager and the
product owner could be a business analyst as they should understand
processes and stakeholders and needs and recommend
solutions. Is that correct? Yeah. I mean, when we were developing the business
analysis body of knowledge (BABOK Guide), we actually did look at the boundary
between product management and business analysis. And it really came down
to that perspective, and that view. The business analyst looks inward to the
"How do business delivers product and services?". The product manager looks more outward
towards "Which products and services should be built?" But of course
there's overlap. From my perspective, all of these kind of professions,
business architecture, product management, business analysis, and others are all really
part of one broad family of roles. And, you know, you
and I have talked about that.
There's no generally accepted
term for what that is, but I think it's definitely fair to say
that they are all closely related and they use a lot of the same skillset. So somebody coming out from a
business analysis background has the kind of logical thinking and understanding
of defining software features, capabilities, and understanding processes. And for a lot of products you need to
figure out how something fits into a process, because you're
only part of that stream. That can make for an effective
product manager.
And certainly again, a BA, especially a good BA, is probably very well suited to be a
product owner because the main difference in terms of what a
product owner needs to do, especially for something that's being
built for the use of the enterprise itself. A business analyst is…
Generally speaking that authority. Most BAs report into somebody who
makes those determinations at the end. The BA may recommend something, but short of that it's really the same
thing.
I mean, if you take a BA and say: "You decide, you figure it out."
You've got a product owner. That's it. It's an authority stuff, right? Yeah. Probably some focus on the
product and the team, but… I'm aligned with you and
talking about "aligned", I know you were working for
an organization called Aligned Outcomes. And working as a chief
of business architects, that's another role
you introduced us here. Could you talk a little bit about your
company and what you're doing there? Sure.
I've just joined a
company called Aligned Outcomes, as you mentioned, it's a
startup based in here in Canada, they're headquartered in Calgary. And what we do is we have a product
that's been developed over a number of years that we are now kind of
taking out more to the market. It is designed to help you
build a digital twin, sorry, never buzzword, but digital twin of
an organization. So what we can do is: we go into a company, we kind of work through all the
processes and organizational structure and capabilities that you
use to deliver your products and services, and we can replicate
them inside our software. And from that, we can develop scenarios to tell business
executives what will happen if they want to change a business process or
what they need to do in terms of their capabilities, processes, if they
want to roll out new product. Or all sorts of other business
changes, and we can tell them, get a much greater degree of understanding
of what will happen when they make those changes.
Who will be affected?
How will they will be affected? How the jobs might change,
in terms of workload? And basically give organizations
a much better insight into what changing will mean for them. So
that's the chef business architect. My job is to come in there and I'm
going to be working on developing and enhancing the methodology and
ultimately leading a team of business architects who will be going into our
customers and helping them make those changes.
That's amazing. That's a way to simulate their
organization into a software and test possible solutions that
are very hard to test, not even having to create a MVP. You just simulate that on the
computer. It's very interesting. I would like to hear a little more about
business architecture and I would like to invite you to another chapter,
other day, to talk about that. Yeah. I'm looking forward to it.
It'll be a good conversation. That's nice. And if people was
to talk to you and reach you, where can they find you? I can be reached at
kevin.brennan@alignedoutcomes.com. Kevin, thank you so much
for being here today, and I'm glad to have you, and I'm really expecting for the next one.
Yeah. Thank you for Fabricio. It's
been too long since we talked. I'm really glad to catch up. My pleasure. Bye. Bye..
