What is a Business Analyst?

So what is it you’d say you dooooo here?

What the Bob’s are asking here is really, “What is a BA, a business analyst?”

To clarify real quick this is in the software development sense. We’re not talking about business analysts who analyze metrics and models as you might see in a finance office.

If you’ve worked with a business analyst you know very clearly what this role is; if not you’re as equally unclear what a business analyst is. I’ll commonly see and interview people who have the perfect skill mix of a BA but don’t even realize it. Do my parents know what we, the business analysts do? That’s probably the best litmus test.

To help them and their peers, as well as those who will eventually interact with a software development business analysts, I want to explain who we are and what we do.

Business Analysts Define the Product

Often a business analyst is best boiled down as the person doing the requirements gathering.

But let’s look closer. What are requirements?

Well, requirements are customer needs that have been turned into something specific and technical, something that a team of developers can build toward.

A customer may say, “I need to be able to see my store’s daily sales totals.” Ok…and what else? If you passed that singular statement onto a developer they might build a web dashboard filled with flashy charts, tons of drill downs and even a useful infographic that updates in real time. But what if all the customer wanted was an email in their inbox each morning that looked good on a small phone screen, listing only the stores that missed sales targets the previous day? Two very different solutions to the same problem.

Your role as a software BA is to define the right solution for the customer. And in so doing you’re defining the product. You’re really the product manager/owner.

The thing about calling yourself the “product manager” is that now you’ve got a much more tangible title, a concept that means something to someone without any direct experience.

Back to the original statement in this section then, there are three concepts we can distill out of what a software BA does in relation to being a product manager:

  1. Who is the customer really?
  2. What does the developer relationship look like, and who else do you work with?
  3. What is the product? What are you responsible for defining?

1. Who Is The Customer?

The thing with the customer is that there’s not just one. You might reasonably have a half dozen different customers to build a single solution for, specially if you’re in an enterprise software environment.

Of course there’s the financial customer who pays for your product. Their needs must be met or they won’t write you a check.

But sometimes the end user is someone completely different from the customer. Take for example a large company building software for its warehouse employees, but designing, developing and paying for the product from corporate HQ.

And in addition to the end user you’ll have the end user’s manager, who may not use your product but will be very attuned to any impacts your software has on his/her team’s productivity.

When you start building your product you’ll also need to ensure that the designers and developers can technically achieve what you want to build, especially given any time and budget constraints.

So maybe the better question is, who isn’t the customer? The product manager needs to uncover the needs from all of the stakeholders, of which there are many. Then, they’ll need to be knowledgeable enough about each stakeholder’s requirements and relative prioritization to make decisions that are in the best interest of the product.

2. Where Does the Product Manager’s Role End?

It depends. Of course it does. But there are four general handoff points to key in on.

1. Customers

We’ve already covered customers, so you know that the customer expresses their problems to the product manager. Requirements elicitation, user testing, research, interviews and more are all used to gather and prioritize what customer needs should go into the product.

2. Developers

Once you know what your customer needs, you’ll need to translate this into a format that’s more specific and tangible for developers. User stories and use cases, wireframes, user flows and technical requirements are all created and handed off to the development team.

3. Designers

Designers and product managers work very closely. Often times the user experience designer will voice the concerns, and it’s up to the product manager to balance those concerns against the other customer constraints. Based on your interactions with the customer, the product manager will also provide a lot of the research inputs into the UX process.

4. Project Managers

Again, lots of overlap. However, at the same time there’s a distinct difference. Project managers focus on scoping and timelines, whereas the product manager focuses on the work that satisfies that scope.

3. What is the Product?

The product isn’t merely what the user sees on their screen. The product is everything. It’s…

  • the functionality,
  • the technical architecture<,/li>
  • the marketing,
  • the business case, and
  • the onboarding and training.

The product manager is the classic renaissance man. You’re the jack-of-all-trades who knows everything about the product, although in so doing you don’t have the time to dedicate to any one area of expertise.

Wrapping this all up, is it helpful? Do you have a better understanding now of who this person might be within your organization? And how does the role in your company compare to ours?

Finally, thanks to Marty Cagan of the Silicon Valley Product Group for his many posts that have helped me turn many of these ideas into explainable concepts.