Yet Another Post Pondering Business Analyst vs. Product Managers

You may have heard there are many paths to product ownership or product management. I'd like to help encourage people interested in product roles by sharing some of my own observations in my own journey into product management. This post ponders titles and roles, the overlap between responsibilities across various jobs, a nod to Maslow's Hierarchy of Needs, and a reminder that evolution is not a ladder.

I'm most familiar with the version of the business analyst (BA) that bridges the "gap" between the business and development teams. In internal and external roles as a business analyst, I would be responsible for discovering and documenting anything from business problems to detailed user stories and the eventual requirements for the technical solution.

Research

My own journey started as a Web development intern with a side responsibility for research. That evolved into an "internet research associate" position focused on all kinds of research.

As an example prompt, I would research and evaluate competitors and internally share a summary of their products and services. I've investigated health-related technologies such as heart rate monitors or fitness trackers at a time before they became mainstream. Web accessibility and other compliance topics would come up. The prompt that shifted my career path was a search for "a CMS that didn't take over your websites."

That led to questions to various vendors, demos, and the eventual selection of SDL Tridion (Sites) to manage around a dozen websites covering both public websites and a partner extranet. To help understand and implement the solution, I was offered and accepted a “Web Business Analyst” role.

At the time, I assumed the next step for a BA would be something like Project Manager or some kind of "leader of teams." In some ways, I would eventually be right, but not in the ways I imagined.

A Proliferation of Titles and Roles

First of all, my company had different departments, some of which had their own BA roles, independent of my group. So the expectations, meetings, and career paths for people with similar titles in the same company don't necessarily align.

I've seen these differences come from product, department, or location. I've also learned to not worry about such inconsistencies. As an employee in a large enough organization, you might ask and encourage the company to align, but roles and people change. Focus on the problems you're solving, help and encourage those with similar problems, and go from there.

In a broader sense, I have also seen an overlap between user experience (UX) activities and those that have traditionally fallen under business analysis. Similarly, there is an overlap between Product Manager and Product Owner roles and responsibilities. For a good comparison, see Melissa Perri's distinction that "Product Owner is a role you play on a Scrum team. Product Manager is the job.".

If I were to suggest some hypothetical expectations of a few information technology roles, it might look something like this.

This is just an example to suggest product-related roles may work more across the business and deal with customers more than user experience and business analyst roles. The actual mix of skills and expectations will vary by company, title, and your own contribution to a given role.

This post by Brian de Haff on this blog post for Aha! suggests similar differences in that product managers are a bit more outward-facing than business analysts, whereas BAs focus more on technical specifications rather than business requirements.

In practice, across the projects I've run, these aren't rules but rather guidelines. As a software consultant in a BA role, I've had to work with stakeholders and work with customers. Conversely, now as a product owner, I will still address technical specifications when needed.

Hierarchy of Roles and Team Members: Basics First

I see titles and roles split based on how the industry has evolved as well as the size of organizations.

For small organizations or start-ups, you might start with a few “do-it-all” engineers. Go back a decade or so and all web-related activities fell under "webmaster."

When an organization is big enough for more of a cross-functional team, you might start adding roles to get to the following roles within a team.

• Product Manager or Product Owner
• Designer
• Engineer
• Quality Assurance

As an organization scales up, they will add more teams, possibly mixing in more roles for cross-functional and multidisciplinary teams. This might progress, in an order such as:

1. Just engineers
2. Engineers plus quality assurance, QA
3. Engineers, QA, plus a part-to-full-time Scrum Maser
4. Etc.

We can visualize this kind of hierarchy of team needs with something like this, where it makes sense to fill out roles in the bottom before adding more on top.

The point here isn't to suggest a hierarchy of importance, but rather that it doesn't make sense to add testers if there is no code. Nor do you need more processes and connections to the business if there isn't much of a team. 

To grow this out, we might have more granular roles such as the following, though not necessarily all within the same team:

• Product Manager
• Product Owner
• Scrum Master
• User Experience (UX) Researcher
• User Experience (UX) Designer
• Front-end Engineer
• Back-end Engineer
• Quality Assurance (QA) focused on functional testing
• Quality Assurance focused on automated testing

A more internally-focused team might have a BA instead of a designer. And a large-enough organization might have both. Many teams I’ve worked with have people with a range of skills as “hybrid” team members with a particular specialty, but a broad understanding of technology as individuals with “T-shaped” skills.

When in doubt, I've learned to always start with good, solid engineers. A mix of backgrounds and experience is good and I prefer enthusiasm and attitude over experience. If you don't have enough engineers, the QA manager might not let you have more QA engineers. :-) Without proper testing, then the pressure for comprehensive, prescriptive requirements upfront increases while it gets harder to identify edge cases and issues during design and build phases.

I've seen QA also work well as a path to product roles. By understanding how something works and asking "why" enough times, the curious and inquisitive will eventually end up at the customer.

Finally, as the industry recognizes that good UX design can and should also be applied to internal systems, I expect the blur between UX and BA would increase.

Experience

Let me be clear that similar to evolutionary theory, stages in career development is not a ladder. Over a decade ago I had the misguided notion that certain roles were the next natural step after other, more junior roles.

In this post by Laura Brandenburg, she concludes that the BA role could be an interim step to Product Management (PM), to which I agree. Similarly, Kevin Brennan suggests product management might be a good fit for a BA interested in executing their own vision.

However, it's not the only path for a BA, who might continue in an analysis role, work as an external resource as a consultant, or perhaps move into a management role. Personally, I went into cross-functional Project Management and then Project Management within IT operations before I realized I enjoyed working with customers slightly more than vendors. Ultimately, your own path will depend on your interests, aptitude, and opportunities while you might adjust the dimensions mentioned above to focus more or less on working with stakeholders, requirements, specifications, or customers.

You might also opt between a more individual contributor versus a more managerial or leadership role. There are developers, leads, and subject matter experts who have years of experience in their respective roles as invaluable team members. You might opt to fight Peter's Principle and find the role or work you love, without worrying about the specific title. Though when in doubt and to keep things interesting, find a way to grow years of experience rather than the same year, several times.