Product Roles, Part 1: Product Managers, Product Owners, Business Analysts

We have many words for people who shepherd the business value of a product. The many words aren't a problem, as long as we can all agree on what these various people are and they take responsibility for. When we don't agree, we run the risk of not managing our strategy, not thinking in terms of problems, and not managing our tactics. Here's how I think of the various agile product roles: product managers, product owners, and business analysts.

Product Managers Manage the Product's Strategy

Someone (and I do mean one person) champions the product to the customers, to the people who make the strategic decisions for the company, and to the people inside the organization.

That person might work with customers to understand the various problems the customer has. That person might then work with other people in the organization to define the problems the organization wants to solve for those people.

The product champion/product manager also works with the people who make strategic decisions for the organization. That group of people might have several names:

• Operations committee/group/team
• Project portfolio team
• PMO (Project Management Office)

Whatever their name, these people take the organization's strategy and decide which mix of products and services the company will offer to fulfill its strategy. (I wrote about my approach to strategy in Manage Your Project Portfolio.)

You might call this person a product champion, product manager, or something else that denotes the strategic part of this person's role.

(I do not like “Chief Product Owner” because I don't like “Chief” anything in an agile approach. And, the words “Chief Product Owner” don't describe the strategic nature of the position.)

A product champion spends much of their time with customers, with salespeople (to see potential problems to solve), and with the senior managers who define the organization's strategy.

Note: strategic planning cannot occur once a year. It needs to be ongoing and iterative. Guess that's another blog post.

I think of the product manager/product champion as defining the “problem in the large.” That's one of the reasons they love their big picture roadmaps. Those roadmaps help people peer into the future of the product and strategy.

And, the product champion needs to work with the people who actually work with teams, the product owners. When they do, they create product roadmaps as a team.

Product Owners Define Problems for Teams to Solve

Teams need problems to solve. They don't need to be told to “create a radio button” or “use this field” or to be told a specific design/implementation detail such as, “use a watchdog timer.” Those are details that help solve a problem.  That's the wrong level of details for teams.

Teams will know what to do if someone defines problems for them to solve. Product owners define those problems.

Product owners straddle the big picture view and the near-term view. They work with the team to create a project vision. The vision has the purpose and release criteria for this release.

That means the near-term view has experiments, minimum viable products, minimum marketable features, all the interim deliverables. Interim deliverables create decision points for the project/program:

• As an organization, have we done enough for now for this product? Is it time to switch this team to another product?
• For the product, what decisions do we need to make next? How little can we do to get to a decision point?
• Is there any more value in the backlog for this product, now?

You might have other questions.

These questions and the effort they imply means the product owner affiliates with the team, and works with the product champion.

The product owner has these deliverables:

• A few weeks to a few months-long view of the product roadmap, showing all the deliverables including experiments. Roadmaps show problems to solve, often in the form of feature sets.
• Possibly an impact map to be able to decide between everything the team has to do “now.”
• Well-defined stories for the next couple of weeks or a month. My experience: creating a week or two of well-defined stories is often enough, as long as the planning rolling wave is short.
• Work with the team on a daily basis to explain/refine problems or stories, and to accept/explain stories. Even when POs define stories well, when they see them they do the face-palm thing. They realize what they really wanted.

Because POs work with the team daily, they can't often go see customers. they might need help understanding the problems the product manager sees. The Business Analyst (BA) might help with that.

BAs Help Refine the Problem Statement

BAs clarify the problem statement. BAs might interview customers and potential customers to help everyone understand what's going on. BAs might even help define stories and acceptance criteria for the team.

If you need them, BAs can straddle the vagueness from the product champion and the detail of the PO.

What Role(s) Do You Need?

In a small organization, the product manager is the product owner is the BA. Yes, they attempt to play all roles. They are often called a Product Owner (PO) or a Product Manager.

That person often feels pulled in too many directions to do his or her job well. That’s because they are supposed to all of these things:

• See and possibly define part of the organizational strategy
• Translate that strategy into feature sets
• Work with the customer to define the problems
• Work with the team to explain the problems, create the feature sets, and stories
• Work with the team to verify a given story solved a particular problem the way this person represented it from the customer
• Check with the customer to make the solution fixed the customer’s problem(s)

If you have a one-product small organization with one or two teams, this can work. It's a lot of work for the PO, but it's doable.

As soon as one person is supposed to champion more than one product or work with more than one team, this becomes unsustainable pace.

Yes, we normally think about sustainable pace for development teams. We need to think about sustainable pace for POs, too.

A product value team can help the various roles create a sustainable pace. More on that in the next post.

The series:

• Product Roles, Part 1: Product Managers, Product Owners, Business Analysts
• Product Roles, Part 2: The Product Value Team
• Product Roles, Part 3: Product or Feature Teams
• Product Roles, Part 4: Product Orientation and the Role of Projects
• Product Roles, Part 5: Component Teams to Create Slices
• Product Roles, Part 6: Shorten Feedback Loops
• Product Roles, Part 7: Collaboration for Short Feedback Loops
• Product Roles, Part 8, Summary