Why should business analysts care about product management?

The business analyst title has an identity problem.

If you ask 10 business analysts from 10 different companies you’re likely to get a few (up to 10) different descriptions of what they do on a day to day basis.

You may hear things such as:

Identifying business process changes
Eliciting requirements for custom software development
Configuring SaaS software
Performing business analytics
Analyzing the financials of a business and it’s products

And there are probably other activities that I’ve forgotten.

Depending on what you do from that above list, the prospect of being a product person may excite you, elicit a shrug, or turn your stomach.

But if you work on custom software development efforts now, you may be a product person working on a product.

Business Analysis and custom software development

Organizations have developed software for their own use for decades. Business analysts have often been a part of those efforts.

The idea of product has come into play with the recent trend that organizations need to treat all of the software development work they do as software product development – also known as shifting from project to product.

Project orientation

In a project approach, when an organization performs custom software development for its own use it forms a project team that is assigned a particular solution to deliver.

A business analyst in this setting elicits, analyzes, and documents requirements to find answers to known problems and deal with complicated systems. As part of those efforts you build a deep understanding of business processes, rules, and data through close work with stakeholders and users. You work as part of a project team to deliver a solution.

Product orientation

Theoretically, if your product team is empowered, organization leadership asks the product team to address specific problems and discover and deliver the appropriate solution(s). The product team works to understand the problem, and identify a valuable, viable, feasible, and usable solution to that problem. Product managers weigh in on the valuable and viable aspects of the solution.

When organizations who develop software for their own use adopt a product approach, they view that software as internal products. They’ll often form product teams around those different systems.

Unfortunately, most product teams that work on internal products still get assigned solutions to deliver. Your product team may be in that situation, but it doesn’t mean you’re stuck there.

You can use the solution you’re assigned to deliver as feedback to identify the problem you’ve been implicitly asked to solve. Then your product team can look for a valuable, viable, feasible, and usable solution. That solution may or may not be the one you were originally asked to deliver.

How business analysts fit into product teams

So where can business analysts fit into this?

The short answer is that a business analysis skill set uniquely positions you to fill the product management role for an internal product.

As for the longer answer…

Let me explain, no there’s too much. Let me sum up.

Business analysts deal with viability

As I mentioned in a previous issue of Inside**Product** (and initially in the Q4 Volume of BA Digest)

When you work on tech products, viability means the solution works within constraints from other departments, such as marketing, sales, finance, service, legal, and compliance.

When you work on an internal product – software an organization builds for its own use the meaning of viability shifts in a subtle, but important way. The department constraints you’re concerned about are those departments that will use the software you build.

In either case, you can describe those constraints in terms of the rules, data, and processes that make the solution work.

Sound familiar? Right, those are a business analyst’s sweet spot.

Business analysts should deal with value

There is a lot of talk in business analyst circles about asking the right questions and trying to figure out what problem to solve.

Successful business analysts have learned to add this tool to their toolkit. Others may still need a little convincing that it’s part of their role.

The shorthand for this particular tool is often referred to as “value”, which is also one of the four product risks – that your solution benefits customers and they will use it.

And as it turns out, the real power in seeking value is not only understanding what problem to solve, but also determining if it’s worth solving.

That means:

Understanding how your organization operates, which business analysts are well equipped to handle (see the discussion on viability above), and
Understanding how your business makes and spends money.

Knowledge of #2 is what allows you to answer the is it worth it question, and it’s not unreasonable to expect business analysts to know it.

Business analysts know how to work with developers

If you’ve worked with teams building custom software, your probably familiar with most aspects of product ownership, even if you weren’t called a product owner.

That also means you probably have more experience working with developers than a lot of product managers who – by expectation, choice, or both – keep an arms length distance with developers.

That’s relevant because most product teams working on internal products will follow the only child model – with only one product person.

It’s what you do, not the title you have

Now, am I saying that all business analysts should move to product management for an internal product? No.

Am I saying that if you’re not a business analyst you can’t do product management for an internal product? Nope.

I am suggesting that a background in business analysis, along with experience working on teams developing software is a good foundation for product management on an internal product.

It’s also worth noting that you shouldn’t get hung up on your title. Just like business analyst, most product roles have an identity problems. Witness the ongoing debate about product manager and product owner.

While it’d be great to have common definition of titles, we’re never going to get there. Instead, figure out what titles your organization uses, what people expect from those titles, and make sure you have a title that will allow you to have the influence you need.

Thanks for reading

There’s a lot going on in the world of internal products. I created InsideProduct to help you cut through the confusion and help you successfully work on internal products.

If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, let me know.

Talk to you next time,

Kent