Product Manager vs. Product Owner

cat-crisis

 “What is the difference between a Product Owner and a Product Manager?”

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.

Product Owner is a role you play on a Scrum team. Product Manager is the job.

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. They’re 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.

SAFe_PO_PM

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.

——

Product Institute is our online 10 week course in Product Management that runs once a month. Come join us for our next class!

Student Spotlight: Kristen Ablamsky

SS3

Product Institute is an online school for Product Managers looking to level up their skills. We’re featuring some of our recent graduates and asking them to share their experiences, both in the field and in our class.

Our next student is Kristen Ablamsky, a co-founder of a very new, very exciting startup. With a background in social and digital strategy, Kristen is new to Product Management and looked to Product Institute as a core resource for learning on the job. 

Can you tell our readers about your current role, and how you got into Product Management?

I’m the co-founder of an early stage startup called Start Hatching that helps nonprofits and social impact organizations find high quality freelancers who are passionate about their cause. Soon into my adventures in company starting, it became VERY clear that we needed someone to focus on not just our business strategy, but our people strategy. Someone to answer, “what do our customers need and how do we keep building a better solution?”

What was your favorite part about being a student at Product Institute? 

The videos are incredibly engaging, and the downloadable takeaways are priceless. I tap into my “Product Institute” folder every time I’m searching for a better way to find new answers. The Slack channel helped to apply these class materials to the real day-to-day, and to connect with others in the PM field- if you’re in NYC, we’ve got a routine meet up and you’re more than welcome to join us!

How has the Product Institute impacted the way you approach product management? 

I’ve learned that making good decisions in product management comes down to your ability to look at the facts with a fresh point of view. This means knowing how to collaborate with your team to identify user truths. There’s no one way to do that, more like one million ways, and you just need to find what works for you and your team.

What do you think is the hardest thing about product management? 

Knowing that every product roadmap is paved with lots of unkown unknowns that will completely twist up potentially ALL pre-existing notions of what will solve for your customer’s needs is frankly…frightening. But it’s also what makes product management so. much. fun. How can we, as Product Managers, get better and better at identifying, listening, and creating based on new truths?

Why do you love product management? 

Product management uses logic and reason to fuel creativity. It requires a knowledge of people, and not just the willingness to collaborate, but the desire to. And all of it is damn right challenging. For me, it doesn’t get much better than that.

—–

If you’re interested in learning more about Product Institute, you can visit our site for a full curriculum outline, an introduction to our Product Management coaches, and answers to FAQs.

Enrollment for our next two online classes is now open

For a limited time, get $100 off of our April 3rd class with code APRIL17.

We also have executive level options for VPs of Product, CTOs, Directors of Product, and CPOs. If you have a team of 5 or more you would like to enroll, please reach out to me at melissa[at]produxlabs.com

Student Spotlight: Dave Masters

 SSspotliight.001

Product Institute is an online school for Product Managers looking to level up their skills. We’re featuring some of our recent graduates and asking them to share their experiences, both in the field and in our class.  First up: Dave Masters, a Product Manager with 8 years experience in the role, most recently at Doorsteps in NYC.

—–

Hi Dave! Can you tell our readers about your current role, and how you got into Product Management? 

Sure! I work for a company called Doorsteps, which helps to remove the frustration of finding and renting an apartment. I head up a cross functional team and set the strategic direction of our product. I got into Product Management via sales and support roles which took me into working on internal systems products. From there I’ve evolved more into consumer facing products.

What was your favorite part about being a student at Product Institute? 

Lots to choose from! The class is filled with super relevant content for PM’s of all levels. It’s presented in a digestible, entertaining format, which I legit looked forward to working on each week. Additionally, it has an international community of students who share great articles & provide alternate takes on issues that Product people deal with regularly. Also, here in NYC, I’ve connected with a few other students and we’ve been meeting in person to talk shop!

How has the Product Institute impacted the way you approach Product Management?  

As product management evolves, our toolkits need to evolve. This course has helped bring forward ideas and frameworks for all steps of the product lifecycle. Some of it was brand new to me like the Product Kata,  and reinforces themes such as focusing on outcomes instead of output. It’s also helped me reverse some bad habits that are easy to fall into.

What do you think is the hardest thing about Product Management?

It’s probably a tie between stakeholder buy-in and developing a comfort  level of uncertainty in a product roadmap. Getting comfortable myself with that way of thinking is not nearly as hard as getting others to buy in to outcomes & goals realized vs features delivered.

Why do you love Product Management?

I love the challenge of it all! It’s a big role which no two days are the same. Not to mention the satisfaction of hearing/seeing people get value out of products you help deliver!

—–

If you’re interested in learning more about Product Institute, you can visit our site for a full curriculum outline, an introduction to our Product Management coaches, and answers to FAQs.

Enrollment for our next two online classes is now open.  For a limited time, get $100 off of our April 3rd class with code APRIL17. We also have executive level options for VPs of Product, CTOs, Directors of Product, and CPOs.

The Product Kata

A while ago, I was introducing the Kanban Kata by Hakan Forss to a team that was struggling to meet their deadline. They had failed twice before and their jobs were in jeopardy. Implementing Continuous Improvement and Kata helped the teams create better processes and remove bottlenecks. I was the coach that took them through the motions that Hakan eloquently teaches, which is based on the Toyota Kata by Mike Rother. The team was able to solve their own problems by getting into a habit of learning. They shipped on time, and kept their jobs.

As I was working with the Kanban team, I realized that I was using this process to create successful products. This framework was just much clearer than the way I was going about it in my own head.

Before I tell you how to apply this to products and Product Management, let’s first start with the fundamentals.

Toyota Kata is a Continuous Improvement framework that creates the habit of improving by focusing on learning. It’s teaches you how to analyze problems and then create small experiments to solve them. This is the secret sauce that made Toyota great. Every team member was responsible for improving the company’s processes. With thousands of people flexing their problem solving muscles daily, they were able to reduce waste while delivering the highest quality.

The 4 steps of Toyota Kata are fairly simple.

Management will set the challenge while the teams grasp the current condition and establish target conditions.

Next, you follow the Coaching Kata to plan the steps to get to the next target condition. The coach is a team member who asks the the following questions during every meeting. The whole team then answers and plans the work.

This is a very quick overview, but If you want to learn more about Kata you should visit Mike Rother’s page or read his book (which I highly recommend).

Hakan took these processes and applied them to improving the Kanban, which ultimately improves you work. I’ve been taking these principles and applying them to building software products. I call it Product Kata.

Continuous_Product_Improvement

Following the Product Kata helps us take small steps to learn about our customers’ needs, and start solving their problems faster.

If you’ve been at one of my talks, you may have heard about a disaster project I built a few years ago. I was working at an ecommerce company that sold items that celebrity “sellers” endorsed. At the beginning of the year, management tasked my team with building a Seller Portal, where all of the celebrities could manage their own stores. We set out to interview a few of them and find out what they needed.

For the next quarter, we built a portal for them and released it. Long story short, no one ended up using it. We really didn’t understand their needs from the short time we spent interviewing them. We built them a complicated tool that was bloated with useless features. We ended up rebuilding the portal and eventually found something that they wanted to use.

So how would we have done this if we used Product Kata? Here’s an idea of what that might look like:

First, we would have understood the direction.

It was incredibly costly for us to manage our seller’s stores. A quarter of our employees were spending upwards of 15 hours each week on the phone with the sellers to answer their questions. Our management gave us the challenge of figuring out how to make our sellers self sufficient. Now, a note about challenges – they are lofty goals. Sometimes we’ll never reach this goal exactly, but we’re going to get as close as we possibly can.

Direction/Challenge: Make our sellers completely self sufficient in managing their stores.

But how do we get there? The first time we built this portal, we jumped to the first solution we could think of too quickly – build them software that does everything. We didn’t stop to consider that there are a million unknowns in reaching that lofty goal. We didn’t know what the sellers were calling about now. We didn’t know their technology habits. We didn’t know which ones called more than others.

When you run the Product Kata, you recognize that these questions are just obstacles that need to be addressed to get to your next target condition.

So what would be our target condition? Since we’re not sure how to get to the final result yet, what is one step towards it that we can take. We can start with reducing the number of calls a week, which would help free up our staff.

Target Condition: Sellers call office less than twice a week.

At the present, they were calling more than twice a week but we weren’t sure exactly how much. This was our first obstacle. In order to improve something, you need to be able to measure the change.

Obstacle: We’re not sure how often sellers are calling now.

CPI_-_1

 

The first thing we need to do is answer this question quickly. We can ask the staff who answer the seller’s calls to measure how often they call for the next week. Right now, we think they’re calling about 4 times each per week.

Step: Staff measures how often sellers are calling by counting calls over one week.

Expected: We believe they are calling about 4 times a week now.

When planning experiments, you want to reduce the time between learning so you can move quickly to your target conditions. Steps shouldn’t take more than a week where possible. If they do take longer, try to break them down.

 

CPI_-_2

 

What did we learn? In reality, the curators were calling 7 times per week, almost double what we thought. Woah.

Learned: Sellers were calling 7 times per week.

We then measured our current condition again and found out nothing had change. We hadn’t met our target condition yet so we asked ourselves what obstacles are we facing now, and continued experimenting.

Current Condition: Sellers were calling 7 times per week.

Is the target condition met?: No.

We learned more about why the sellers were calling and which were the most frequent asks. Now we were able to start solving their problems.

CPI-_5

 

SIDEBAR: The first three iterations of here we weren’t experimenting because we still did not have data around the current condition. We had to clarify exactly where we are what problems needed to be solved before we moved on. This is a step most people miss when they start experimenting. They will jump in without making the current condition very clear.

We tackled getting them to call less for revenue by providing them with a weekly email. We found out they wanted a more frequent update, especially when they had a lot of sales going during that week. Most of the time, the sellers were not putting new sales out but every once in a while they had a booming week where they launched a bunch of new products. They wanted to know the return on them every day so they knew which ones to promote more to their audiences on social media.

Current Condition: Sellers are calling 5 times per week.

Obstacle: Have sellers call less for revenue.

Step: Staff would provide the sellers with a weekly email about their revenue. Measuring amount of calls abotu revenue over two weeks.

Expected: The sellers will stop calling for revenue all together.

Learned: Sellers want revenue updates every day so they can promote the best sellers on social media.

Have we met our target condition?: No

It’s also important that every step you take, you also say how you will measure its progress. A step with no measurements can’t tell you if you are improving.

CPI-3

Providing them with their revenue every day through email cut down the phone calls to three times a week. We continued experimenting like this until we got it down to once a week, freeing up many hours for our staff to work on other things.

CPI_-_4

If you look at these steps, you will see that we weren’t building new features for the sellers. That would have taken a lot of time, and we wanted to learn quickly. The biggest mistake we made at our first pass of the portal was including monthly revenue, but not daily revenue. Every seller was pissed off by this, but it took four months to learn. With Kata, we learned this in a matter of three weeks, and we were able to include it in a wildly more successful future version.

Learning is one of the most important parts of the product development cycle, but too often we skip over these steps and just rush into creating products. When we work with Product Katas, we can address each thing we need to learn and then incorporate that into the final products. Not only is this a faster way of working, but we have a much better shot at getting the product right the first time.

This was an incredibly brief blog post and I didn’t have the space to go over all the nuances with planning Product Katas. If you have any questions please comment below and I’ll answer them. If you want to learn this way of working, reach out to me at melissa@produxlabs.com.

Creating Effective MVPs coming to NYC!

Creating Effective MVPs Full Day workshop is coming to NYC on July 16, 2015!

Full Day Workshop on July 16, 2015 in Manhattan (9:30am – 5:00pm)

Only 20 tickets available! Buy Tickets Now

Traditionally there is usually little validation before work begins on a new product; and teams end up wasting time building something that no one wants. User Experience suffers and companies are left with products and features that remain unused. MVPs; or Minimum Viable Products; can boost a product’s user experience exponentially. Teams who implement MVPs correctly will learn more about customers, waste less time, and deliver usable solutions faster. But, MVPs are wildly misunderstood today, and setting up one wrong can deliver false results.

In this workshop you will learn the ins and outs of creating MVPs and how to introduce this concept into your companies successfully.

What you will learn:
In this hands on workshop, Melissa will teach you framework for creating effective MVP experiments while practicing the fundamentals. You’ll also learn:

  • How an MVP is one of the most effective tools you can use to learn about your customers
  • How to formulate problem and customer hypothesis
  • How to align product experiments with your KPIs
  • How product development teams, marketing, and the business can work together in this process
  • How focusing your teams on experiments rather than features can save your companies years of development costs
  • How to iterate on feedback from your customers to plan experiments
  • How to integrate Minimum Viable Products into your Product Roadmaps

Who should attend:
Product Managers, UX designers, developers, stakeholders and team leads.