Product Manager vs. Product Owner


 “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.


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 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!

Getting Sales + Product In Sync


What does an effective sales team look like at a product-led organization?


“Sales already promised it.”

I once joined a B2B company as a Product Manager in the the middle of the year, so their entire product roadmap was set and in motion.  My team was responsible for building a feature that I quickly realized did not align with our strategic initiative for the product. I questioned the purpose of this feature, and was met with the worst possible answer: “Oh, well the sales team promised it to one of our big customers, and they’ve already included it in their signed contract.” So we had to build it, and we had to build it fast, as the deadline was looming.  

With no other option but to get to work, we began interviewing, prototype testing, and gathering feedback to understand the client’s hopes for this added feature.  The results? They essentially wanted it to predict the future, which even the best of our developers assured me they could not do.  Needless to say, we didn’t have high hopes for satisfying expectations.  But instead of scrapping the feature like we should have, management instructed us to continue building “what we could.”  We couldn’t meet our customer’s end needs, but hey, at least we would meet our contractual obligations. We spent time, money and effort on a useless, disappointing feature that should never have been promised to our customer in the first place.  

So what happened here? Well without all of the above context, it might appear that this failure of a feature could be attributed to bad judgement or incompetency from Product Management.  In fact, whenever I hear a company complain that their Product Managers “lack vision,” I am not surprised to learn later that the real problem stems from a similar process to the above example.  A Product Manager is not given room to explore and identify what to build next when they are constantly behind schedule, chained to roadmaps that are full of untested features for customers who have already signed their contracts.  So who promises all of these shiny features that hijack the next 6 months of builds and hinder Product Management’s processes? The sales team.

Put simply, sales processes can be the downfall of an otherwise good Product Management process.  

How did we get here?

In traditional B2B companies, sales was the driving force behind strong businesses.  Without a great sales team on the ground bringing in contracts and solidifying clients, there would have been no company to run.  Salespeople were motivated to reel in the big fish because their salaries reflected each closed deal- client signatures were directly correlated to success.  So it’s easy to understand why it became the norm for salespeople today to promise the world in features just to snag that name on the dotted line.  

But when sales returns to the office with a new client to answer to and a list of contractual features to implement, they become the ones leading product development- not the Product Managers.  This results in a backlog so congested and long that teams struggle to keep up and satisfy requirements quarter after quarter.  There is never any time for Product Management to think strategically and proactively about the product, so a complex hodgepodge of one-off, usually broken features is delivered instead.

I’m not saying that the whole system of sales is inherently destructive.  Especially when a company is just starting off, signed contracts are its lifeblood, and product teams can really benefit from these early clients and adopters that sales works so hard to bring in.  Catering to these early clients’ needs and iterating around their feedback is necessary, and it ends up benefiting both sides of the relationship.

But as a company starts to grow, this kind of symbiotic relationship is no longer the most sustainable or beneficial model for an organization or its clients.  With more customers on the roster, the goal evolves into building a product that will scale and appeal to many, not one that satisfies the exact needs of a select few.   It’s hard, however, for the sales team and the overall company to break these habits of including the customer in the development process. When everyone is used to co-creating instead of thinking strategically, companies miss the big picture.  And this is where a reactive process becomes dangerous to the overall organization.  These product teams have not learned to look forward in order to plan their strategy, and get stuck building from a list of requests that reach short term profits and meet invalidated goals.

How do you become a product-led company?

For your sales and product teams to work in blissful harmony together, two things need to change.  First, sales needs to rethink their process from a product-led company point of view.  Second, your organization needs to shift their sales team’s source of motivation so that compensation does not directly correlate to signed contracts.

How do you teach product to sales?

Sales should continue to be the first line of contact between the organization and the client- a focus on building strong relationships and a desire to help those potential clients get what they need is still key.  But the method at which they approach this relationship must change.  Sales teams could benefit from the same user experience or user interview techniques that product teams rely on.

Clients typically talk in solutions- they’ll say things like, “we need a button for this” or “we need to build an app to give our customers this.”  But it is your internal product team’s job to hear these solution ideas and work backwards to identify their actual problem. Only then can they figure out what the best feature solutions may be.  Sales teams, then, should be talking to clients from this same product point of view.  They need to be able to empathize and understand their clients’ problems, so instead of, “I promise our company will build that feature you want,” it’s, “I promise our company can help solve your problem.”  Then, after gathering an understanding of the problem from multiple clients and seeing how it applies globally, sales can return to product with valuable information that lets the product team figure out how best to move forward.  This halts the dangerous cycle of promising unvalidated or planned features, and instead puts sales and product on the same page. Sales essentially becomes the first line of contact between product and client, rather than acting as an indirect conflict of interest with the product team.

How do you motivate your sales teams?

Stop relying solely on closed contracts to measure the success of your sales team.  It’s certainly the easiest way to measure success, but it also hurts your entire organization when used as the sole metric.

Often times, sales teams will bring in clients who ultimately are not the best fit for your business or your product.  This leads to a revolving door of unsatisfied clients, who loved what sales had to say but not what the product could realistically deliver.  Instead, motivate your team to not just close any contracts, but the right contracts.   Balance the number of signed clients with the strength and commitment level of that client. Then, teach your sales team to work closely with your product team by providing information that they are in a unique position to gather- feedback on problems, competitors, market trends, customer satisfaction, and value propositions.  

How can the product team Help?

By keeping communication open! The product team’s process, including their roadmap, should be easily accessible and clear to your sales team.  Imagine how much it will help sales to be able to walk into pitches with a strong understanding of what features are in build mode, what kinds of bugs are being fixed, etc.  They will be able to sell based on the reality of where the product is today and where it is likely headed in the future.  Just make sure to clarify to the sales team that there is a process in place, and just because something is in a roadmap as a considered feature does not mean it is absolutely getting built.

Every part of an organization affects Product Management.  Sales needs to be better equipped with the tools and processes of a strong product team, so that their client/company communication is in line with the realities of the product itself.  So encourage the following language the next time your sales team meets with potential clients:  “I completely understand your problem. Let me talk to my development team to see how we might be able to solve it for you.”

Learn more about this and other Product Management best practices by enrolling in Product Institute, our online PM school.

Our next class starts in May 8th! Sign up for our mailing list on the top right of this page to receive notifications regarding the class.



Student Spotlight: Kristen Ablamsky


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]

Student Spotlight: Dave Masters


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.

Effective Product Roadmaps

Product Roadmaps, in general, are confusing. The truth? Even the most experienced Product Managers still don’t have them fully figured out.

Three years ago I wrote a blog post about Rethinking the Product Roadmap, in which I advocated for a focus on solving customer problems instead of listing out features with deadlines. I received lots of feedback on the post, much of it praise, but also some criticism. The biggest takeaway comment for me was, “This is great for new products in the Discovery Phase, but what about accounting for products that we have already validated and need to build?”

In the time since, I’ve been working with clients to find what works best in real life situations. I want to share with you the framework that I have found, which allows for a balance of discovery and delivery and takes us out of that laundry list of features. But first, let’s talk about Roadmaps in general, and how they got us on the wrong track to begin with.

Think back, before Google Maps, to what a real roadmap was- those things with tiny, tiny city names and thousands of squiggly lines.  The ones that made it so you could never drive alone because you needed a copilot, someone to wrangle the giant map and dictate to you how to navigate from point A to point B. Yeah THOSE things.


Well that’s where the term Roadmap actually comes from.  When using a roadmap, you always knew where you were and where you wanted to go, and you had all these different routes to choose from. Some routes were shorter, some were longer but more scenic. It was ultimately up to you to choose your optimal path. Product Roadmaps should work just like their namesake, but their intended purpose was lost somewhere along the way. Now, Roadmaps function more like Gantt Charts.

Gantt Charts are a project management tool used to keep track of timelines and due dates. While Gantt Charts are fine for large manufacturing projects, they do not work well for most software situations because of the uncertainty around development.

When we’re first deciding what software product we should be exploring, we don’t know what our users want, and thus we are not exactly sure what the finished product will look like. This makes it nearly impossible to estimate how long the product will take to build. Yet, we still use this Gantt Chart model to plan our work, which locks us into delivering solutions by certain dates. Teams get frustrated that there is no perceived flexibility in these plans, and management gets mad when teams don’t deliver on time. The result is a bunch of feature releases that don’t make a difference for our users.

Instead, we need a model that helps us take into account uncertainty and allows us the flexibility for both discovery and delivery. To do this, we focus on Product Roadmaps that are made up of outcomes, a theme, and hypotheses, and we leave out any unvalidated solutions or features.

Let’s look at an example I created of a completed Product Roadmap for one team. I’m using the New York Health Exchange’s website as an example of a product as I can easily pin down things that need to be fixed- like, lots of things. I’ve never worked with them, and I don’t claim to have knowledge about how they function internally, but I am a customer of the website. This is how I would approach improving the product if I were working with them.



The top section of our Roadmap outlines our Vision, Challenge, and Target Condition, which reflect the goals outlined in my post on Product Strategy.  A Product Roadmap should be aligned around these same goals and help communicate the tactics to reach them.

According to this Roadmap, Team X is working towards the overarching goal (or Challenge) of getting 99% of people who create an account on NYS of Health to sign up for insurance.

Now that we have our Challenge set, the team analyzes the customer problems standing in the way of them reaching that goal. This is the same process we outlined in the original Roadmap post. Let’s say that after user research, we find that the biggest problem for NYS of Health’s website users is that it takes a very long time to search for and find an ideal health insurance plan. It’s a confusing process and incredibly frustrating. It causes people to give up instead of sign up.

So Team X decides to tackle this problem, and sets a Target Condition that will tell them when they have reached a successful outcome. “Decrease the average time to find and purchase health insurance from 3 weeks to 2 days in Q2.” While users can only sign up once a year for health insurance, there are plenty of changes that could be implemented to make it easier once that enrollment period opens.

From there, Team X would figure out the top areas they want to explore or deliver on in Q2 to reach that Target Condition. We call these Themes. For example, the “Search Enhancements” Theme will include all the UX work needed to simplify the search for health insurance options.

In order to answer the question, “Why are we exploring this theme?” we write a Hypothesis or Problem Statement. When products are still in the Discovery Phase, we are still validating the problem and solution, so we want to state what we know and what we don’t know. Our Hypothesis should support that we believe our solution will solve the biggest problem.

So with our Search Enhancements Theme we are in Delivery Phase, and our Hypothesis is “We believe that by enhancing the filter options to reflect the top deciding factors that shoppers make when choosing a health insurance, we will make it easier for them to narrow down their choices and find the right health insurance.” We have already validated that people have problems narrowing down their choices to find the right health insurance, and we think that offering some enhancements to the filter options can solve that problem.

Our last theme, Subsidy Communication, is an example of a problem that is still very early in Discovery Phase. We have identified that there is a very low conversion rate for people who qualify for Subsidies, and we want to investigate why that is. We have a few ideas but we have not yet validated them. So we need to clearly communicate our Hypothesis, highlighting what we know (“the people who would get Health Insurance for almost free are converting at a very low rate”) and what we don’t know (“we are not sure if people leave before they know if they whether or not they qualify for subsidies, or if they just don’t understand our explanation of subsidies”).

After the Hypothesis section comes the “Outcomes” – the most important part of our Roadmap. Here, we state what we hope to achieve by solving this problem or proving this Hypothesis. Each Outcome should relate back to the Target Condition in some way. All of our work is going to help us reach the Target Condition, so it would be a pretty boring Roadmap if every Outcome for each theme is just a repetition of that goal. Instead, think about how each of those changes or improvements signals a move towards your goal.

For example, with the Search Enhancements, we can tell if we are making it easier for people to search by measuring the qualitative components of frustration and the quantitative components of decreasing the time to identify an option. You want to make sure you are focusing on a good combination of both business and user outcomes in these sections, and make them measurable.

The last two sections deal with status and priority. The Status should state where you are in the Discovery versus Delivery phase. If you are in the Discovery Phase, you’re delivering to learn, so your focus is on experimentation over releasing features.  In the Delivery phase, you’ll be delivering valuable features and solutions to users. Sit down with your team and define what this means within your company, and then share these definitions with the rest of the company so there is mutual understanding.

Notice here that our Roadmap does not include any specifics on how we plan on tackling these problems.  This is because we are still experimenting with options- we haven’t laid out a plan to implement a set of features or solution components.

The above example is only one team’s Roadmap. There might be many other teams working towards this same Challenge, but they would all have different Target Conditions. These Roadmaps could then be combined into a Portfolio Roadmap that could be communicated across different levels of the business, like so:

Good Roadmap - FDS portfolio.007

It’s important to remember that a Roadmap is a communication tool first and foremost. It’s meant to align teams across time horizons and goals. Management should be goal and Vision setting with a timeline of  6 months to a few years, while teams should be looking at a smaller timeline, from quarters up to 6 months. There should be an accompanying strategy document that addresses how these goals help the company reach its Vision, but the Roadmap itself does not serve that purpose.

Roadmaps are a living document. If you invalidate a theme, update it. If you’ve changed a goal, update it. There is no reason you should be struggling to work around a Roadmap that does not work for you. When you’re communicating with customers, focus on how you are going to solve their problems, not how you are going to deliver their features. Your customers care first and foremost about the value they are receiving.




We teach Product Roadmaps in our 10 week online course at

Product Institute.

The next class will start in April 2017. Use APRIL17 for $100 off.

Sign up for our mailing list on the top, right hand side of this page to be notified when we launch our next class.