It?s an interesting question and one that takes time to unpack. Let?s look at where these terms and disciplines originated from and how some common frameworks explain them.
When I started my career, I was called a Business Analyst. I did very little ?business analysis? as we would look at it in traditional IT companies. Honestly, I did very little of what I teach as Product Management now either. I was tasked with gathering the requirements from sales, coming up with a solution, designing it, and then shipping the specification document to development to be built.
I went on being called a Business Analyst as I worked at banks and other financial services companies. I wasn?t called a Product Manager until I bailed out of that and landed in a startup. It was all the same work I had been doing before, but now it had a different name. I liked this name. ?Product Manager? seemed to have gravitas to it, and when I looked at other tech companies in the Valley, I could see a clear career path carved out for me whereas Business Analysts were different at every company.
I had not heard of the term Product Owner until years later. The first time I heard the term, I asked someone what it meant. They told me it was the same as a Product Manager, but it was a term used in Scrum. We had been using Scrum for years, but I was still called a Product Manager, so the fact that they would be interchangeable made sense to me. I rarely thought about it after that.
That was until I had my first experience teaching Product Management at a company using the SAFe framework. I was doing a workshop for a very large bank when one of the attendees chimed in.
?You are teaching us to talk to users, but I am a Product Owner. The Product Manager talks to all the users and tells us what the requirements are. I spend all my time writing user stories out of these and working with the team to execute on the solution. I?m confused.?
This is when I started digging into the differences between these two roles and how different philosophies teach them. In order to understand how we got here
Product Management can be traced back to 1931. Hewlett Packard was one of the first tech companies to implement this job and organize itself by products back in the 1940s. Most Silicon Valley companies have had Product Managers from the start, and many of my friends who have worked there in the 80s and 90s were indeed, Product Managers. So this discipline is not new, but it is evolving rapidly as more companies start shifting into software organizations and start structuring themselves around products.
Scrum came on the scene just before the Agile Manifesto was written in 2001. It introduced the concept of a Product Owner. This was a person who was a proxy for the customer and would tell the developers the requirements for what needed to be built. In early days, when many of the creators of these processes were working as consultants in companies, the Product Owner was the customer ? an internal person in the business who would sit with the team and prioritize the backlog of work. In fact, the 2017 learning objectives for their Certified Scrum Product Owner Certification by Scrum Alliance states, ?Teach that the role of the Product Owner is typically played by the customer, or customer representative, such as a product manager.?
When you look at the role of the Product Owner in most Scrum literature, their three main responsibilities include the following:
- Define the product backlog and create actionable user stories for the development teams. (Who creates the user stories varies depending on Scrum training)
- Groom and prioritize the work in the backlog.
- Accept the completed user stories to make sure the work fulfills the criteria.
While curriculum change between teachers and organizations, these are the things that are mostly focused on during the two day courses to certify Product Owners. While Scrum has a lot of information on the processes and rituals of what to do as a Product Owner, it leaves lots of questions that are important for creating successful products unanswered. These mostly center around ?How do we know we are building the right thing??
This is where the Product Management comes in. A good Product Manager is taught how to prioritize work against clear outcome oriented goals, how to discover and validate real customer and business value, and what processes are needed to reduce the uncertainty that the product will succeed in market.
Without this background in Product Management, someone can effectively go through the motions of Product Owner role in Scrum, but they can never be successful in making sure they are building the right thing.
If you take your Scrum team away, if you take Scrum away as a process for your organization, you are still a Product Manager. Product Management and Scrum work together well, but Product Management is not dependent on Scrum. It can and should exist with any framework or process.
I recently had a Product Owner whose developers were moved to another part of the organization come to me because they were worried they could not be a product person at this company any longer. Their entire identity seemingly hinged on having a team of developers.
As a Product Manager your roles and responsibilities will change depending on your context and the stage of your product. Without a Scrum team or with a smaller team, you might be doing more strategy and validation work with problem discovery in a product that has not been defined yet. With a Scrum team, you may be more focused on the execution of solutions. As a manager of Product Managers, you might be leading strategy for a larger part of the product and coaching your teams to discover and execute well.
The SAFe framework teaches this differently, and I think it?s one of the weakest points in the entire framework. In SAFe, Product Managers are the managers of Product Owners and are responsible for external facing interactions and work. They speak to the customers, they define the requirements and scope of the products to be built, and they communicate this down to the Product Owners. The Product Owners are internal facing, define the components of the solution, and work with developers to ship it.
I?ve trained dozens of teams who are using SAFe and I have never seen this work well. The Product Owners are disconnected from their users and incapable of creating effective solutions for them that really solve their problems, because they do not understand the problems well. The Product Managers are essentially waterfalling down the requirements to them and the teams are not allowed to prove if these are the right things to build or not. No one is doing validation work.
I have listened to many arguments that Product Owners do not have time to do both roles. In the current context, that?s true. The Product Owners I speak with spend 40 hours a week writing user stories. At that point, you have to ask yourself, are those user stories even valuable? What are they prioritizing them against? How do they know it will solve a problem?
If you have one person spending that much time writing user stories each week, every week, you are falling into The Build Trap ? concentrating on the quantity of items you release and not the quality.
With a good strategy framework in place and ruthless prioritization around a few key goals, one person can effectively talk to customers, understand their problems, and help to define the solutions with the team. Even the CEO of Scrum.org agrees this can be the case, albeit, it seems, begrudgingly. Scrum Inc also says that the Product Owner should spend half their time talking to customers, and half working with the team. I?m not 100% on board with this split, but the direction is good. The amount of external vs internal work will shift depending on the maturity and success of your product. You should never be doing all this work at once.
I teach my clients that Product Managers in senior roles (VPs or Product Leads or middle managers) concentrate on defining the vision and strategy for the teams based on market research, an understanding of company goals and strategy, and by looking at the current state of success of their products. The Product Managers without Scrum teams or with smaller teams (a UX Designer and one developer, for example) help validate and contribute to that strategy for future products. Once we validate the direction, we create larger Scrum teams around these people and build out solutions.
It?s important to have this flexibility in team size as well depending on the stage of your product. If you give a Product Manager a large scrum team?s backlog to keep filling while you are in discovery mode, they will keep that backlog filled. But, they will also be torn between keeping work flowing to the developers and trying to do the work to validate direction. As a result, neither gets done well.
If you want to build products that create value for your businesses and customers, you need good Product Management foundations in your company. If you want a career path for your people, you need to give them this foundation so they can grow into more senior roles. So remind your people they are all Product Managers. They may be playing the role of a Product Owner on a Scrum team most days, but we still need them to think like a Product Manager and validate that we are building the right things.
? ?
Melissa Perri is the CEO of Produx Labs, a consultancy that helps organizations learn and adopt good Product Management and Product Leadership practices. She runs an online school for product managers at Product Institute and for product leaders at CPO Accelerator. She is a senior lecturer at Harvard Business School.
This was originally posted on melissaperri.com
