If you are a business analyst, you have probably wondered at some point how to convince people at your organization about the value you provide and grow your business analyst career.
I’ve been there, and have found that the best way to do that is to show, not tell.
Don’t spend your time and energy proclaiming the value of business analysis; take actions that help your organization solve it’s customers’ problems.
I’ve found many ideas that people apply to building products for sale can be applied to software used internal to an organization. That’s the reason I use the term internal product throughout Inside Product Management.
That also means that business analysts are product people too. It just so happens that the products they work on tend to be used for use inside the organization, or are used by the organization’s customers, but not necessarily sold to them. (Think of your organization’s website or mobile app.)
It can be helpful to look to product management for ways to supplement your business analysis skills with ways to be customer and user focused even when you’re working on an internal product.
To understand why that’s the case, let’s look at the different perspectives and the different activities that product people (including business analysts) do.
People you interact with have different perspectives about your product
In an earlier post, I discussed the different perspectives people take to view your product. As a reminder, those perspectives are:
Customers – People who buy the product
Users – People who use the product
Stakeholders – people within your organization who are involved with the product but don’t build it, buy it, or use it.
Development team – People who build, test and deliver the product
You want to be aware of those perspectives because the different activities product people do are based large part on which perspective(s) they are primarily concerned about.
Stuff product people do
When you ask product people what they do, they will more often than not describe it one of three ways: product management, product ownership, or business analysis.
These activities share many similarities.
Their differences can best be described by which of the above perspective they tend to focus the most on.
I’ll be the first to admit that the name of the activity doesn’t exactly line up with a literal definition of the chosen terms might indicate. I don’t want to create any more new terms than I already have, so the descriptions below reflect common practice.
Product management focuses on understanding the problems that customers and users are trying to solve.
Product ownership focuses on supporting the development team by providing priority decisions, answering questions, and connecting the team with subject matter experts when needed.
Business analysis focuses on understanding stakeholders and the needs of the organization through describing the relevant rules, process, and data.
Why this matters for business analysts
Product people who work on internal products tend to have the title product owner or business analyst and generally do the activities that match their title.
There’s rarely someone with product management skills working on internal products, and the decisions that go along with product management (what problem are we solving, should we solve this problem and so on) occur in a haphazard fashion at best.
Those decisions usually get made by a sponsor from the business unit that “owns” the process the internal product is intended to serve. The decisions are usually made based on solutions focused thinking rather than from a position of understanding the problem.
You can close that gap by applying product management techniques to guide your sponsor into clarifying the need you’re trying to satisfy. You may even be able to drive discussions about whether the need is the right thing to satisfy at this particular moment.
Even if you find you don’t (yet) have the influence to guide what initiatives your organization does, you can still drive better understanding of the user as you work on a solution with the team.
Some business analysis techniques can help you do that and when you supplement them with techniques more commonly associated with product management you can be even more effective.
If you’re a business analysts who wants to demonstrate your value, view your main role as satisfying your organization’s customers needs and be willing to look to other, related fields to help you accomplish that.
Here are a variety of perspectives on the intersection of product management, product ownership and business analysis. I encourage you to look at these various perspectives and decide for yourself.
It’s common to hear “we need this kind of expert for this project” or more frequently “we don’t need that role on this project.” It’s actually a lot more nuanced than that. Chris Matts explains why you need to understand whether your work is complicated or complex (as defined by the Cynefin model) and what implications that has for business analysis and product management.
The reader’s digest version: product management is best for complex situations (where you don’t know what the problem is). Business analysis is best for complicated situations (where you need to identify all the places that your solution needs to address)
The PM Rung on the BA Career Ladder
A while back I got involved in a conversation about whether business analyst is a stepping stone for project management. The short answer is “not necessarily”.
I do think that there is a PM role that does make a natural rung on the business analysis career ladder, though not a mandatory one.
That role is product management. I shared my full thoughts on the topic on LinkedIn.
Bridging the Gap between Product Manager and Business Analyst roles
The product manager role and business analyst role go hand in hand. Many product managers get their start as business analysts, and as a product manager, you can expect to work closely with a business analyst.
What’s the difference between the two roles? And how do you transition from one role to another?
That’s the question Laura Brandenburg addressed in a recent video and post.
Throwing the Product Owner in the Mix
Implicit in this type of discussion is the ongoing discussion/debate/argument of product owner vs product manager. I’ve shared a variety of perspectives on that debate in earlier posts.
Ellen Gottesdiener recently chimed in on that discussion and I include it her because of her perspective of the product owner straddling both discovery and delivery activities.
Should we even suggest that BA’s can be Internal Product Managers?
I’d be remiss if I didn’t include Joshua Arnold’s perspectives on whether applying product management thinking to internal products is even warranted.
I think it is, but his point about remembering who your actual customers are is key in that discussion.