Product Manager vs. Product Owner: Roles explained

People often contact me wanting to learn more about product management. Either they want to be a product manager or they want to hire one. As someone who has been in the industry a long time, I am acutely aware as to how confusing the role can be for leaders, for teams and for those transitioning into the role. What does a product manager do? Why are they necessary? And what’s a product owner? Confounding the confusion is that sometimes people in the industry will often use several terms interchangeably even though they have unique meanings. Product manager, product owner, product strategist, product leader—what’s the difference? It’s nuanced, but by defining a few key priorities and responsibilities in each role, we can help clear up the confusion.

Product Manager

A product manager makes decisions about what a development team should be working on. They do that by:

  • listening to users to identify and understand their problems
  • learning about and digging into business goals
  • seeking out recommended approaches and solutions from their development teams

Product managers internalize all of that information, weigh the costs and benefits of moving in a particular direction, and then decide which way to head. People tend to see a product manager’s output as a product vision, focused user problems for the team to solve, and/or a roadmap.

Product managers are valuable because they don’t have an incentive which aligns them with any specific company department. Product managers want to solve user problems, they want their business to achieve its goals, and they want their development teams’ work to be feasible (and awesome). Their empathy is spread equally. It’s this lack of bias, or at least the attempt to squelch the bias, that allows them to make excellent decisions.

Product Owner

Originally, a product owner was a position on a Scrum team. This role would be filled by anyone in the organization who had a vested interest in the development and success of a product and could be the “voice of the customer” for the Scrum team. If the team, for instance, is building an app to accept customer lead information, a marketing professional could be the Product Owner. The marketer understands the needs of customers who complete a lead form, they understand the business requirements and, thus, they could help define the order of the tasks or projects for the development team.

In software companies, the role of product owner is often filled by product managers because teams need someone who is dedicated to helping them move work forward. If product managers take on this role, they tend to be focused more on the delivery aspects of software development than on the strategy or research functions of product management.

Product Strategist

Product strategist is a title often used in consulting. Because consulting or development agencies work with clients, they really need to have a product owner in the client company who can make the final decision and be the voice of the customer, particularly if the engagement is about simply delivering completed software.

These agencies often want to expand their reach and have more influence earlier in the process, so the role of strategist was created. This person will work with clients to help them become clearer about what they want to build. Sometimes that will involve talking to customers, but other times it will mean conducting workshops to help clients articulate what’s in their heads.

Product Leader

Some people—like me—use this term simply to avoid painting ourselves into a box. We like to say that we can do all the things in all the ways because we’re really flexible and can lead people down a certain path. I’ll admit, it’s kind of a made-up term. Sorry if we confuse you.


I hope that a more detailed explanation of each role has made a distinction. Remember: A lot of people use these terms interchangeably rather than being specific about what they want or need. So when you hear one of these terms, the best thing you can do is ask people what they mean or what they are hoping the person in the role will do. If they can’t clarify this for you, then use these explanations to ask them questions and help them narrow it down.

Metrics that Matter

Company after company quips that their teams “make data-driven decisions”. But when you ask them which metrics they are currently tracking, they typically respond with Daily Active Users (DAU) and downloads. Both of these metrics are very popular because they make it easy for companies to compare themselves to their competitors (a key fundraising tactic for startups) and because they are super easy to track. Simply add Google Analytics to your product, log into their pre-made dashboard, and find your answers instantly! Unfortunately, it’s impossible to make any product decisions based solely on these metrics because they’re vanity metrics. If we are going to make “data-driven decisions,” we need to analyze metrics that will help us make decisions; we need actionable metrics.

There are three types of metrics product managers should care about:


Simply tracking the number of users is not enough. Rather, it’s important to take a more nuanced look at your users. A detailed look at your users will make it harder to compare your company to others, but it will give you more important information about what to do next with your product. The metric I suggest most often is repeat usage. Repeat usage of your product can tell you a lot about where you need to dig with your user interviews. If users are not coming back to your product, you know you have a market fit problem. Either you haven’t found your market yet, or you are not solving a big enough problem for the market you found. So when it comes to making a decision about what to do next, building on new features or doing small optimizations are probably not going to get you anywhere. You should instead go back and validate your value proposition and ensure that you are both meeting it with your existing product and that you have identified a customer segment that will benefit from what you’ve built.

Another way to look at repeat usage is by measuring your retention rate. This metric can be calculated in many different ways, but the most common method in analytics applications is rolling retention. Rolling retention tells you whether or not users have returned to your product in a given time period. (If you want to learn how to calculate retention, this post at AppLift explains it very simply.) Retention is an excellent metric to use once you have an established product because you’re most likely gaining and losing a lot of users each month. By using retention along with cohort analysis, you can determine whether your newer users are returning to your product, rather than mixing them into the same data as your established users.


Conversion metrics are the most versatile and powerful for making day-to-day decisions. A conversion is the number or percentage of people who complete a given task within your product. The most impactful conversion metrics are based on the value proposition of your product. What did you promise your users? What did you tell them they would be able to achieve with your product? That is the conversion you should be tracking.

If we look at some examples of popular products and their value propositions, we can deduce what some of their conversion metrics might be. Evernote, for example, has put forth this value proposition: “Get organized. Work smarter. Remember everything.” One of their conversion metrics might be as simple as “a note created.” But if they find that users who create five or more notes per day use more tags to stay organized and thus stay paid customers longer, they might make their conversions both the creation of the fifth note and that tags were added.

That brings us to funnels. Funnels are a popular way of using conversion metrics. With a funnel, you look at how many users continued through a series of actions, like adding notes in Evernote. By examining which actions users complete before and after meaningful conversions, you can determine which actions in your product lead to more engaged users or more revenue. You can then find other ways within your product to encourage users down those paths.


At the end of the day, your company and product only exist if people buy your product. Simply tracking total revenue, however, is way too broad a metric for making product decisions. A better way for a product team to approach revenue is to instead measure the amount of each sale, or the revenue generated from a particular group of users. People have many different reasons for why and how they spend their money. By focusing on segments rather than the aggregate, you can isolate different groups’ motivations for buying and modify your product to provide them with something that they feel is worth spending their money on.


Everyone loves to say they are data-driven. What people really mean when they say that is that they want to use data to help them make decisions. To do that, product people need to focus on tracking actionable metrics and leave the vanity metrics for press releases and board review slide decks.


Originally written for the blog on L4

Making the Most of User Interviews

My colleague at L4 Digital, Lisa Kream, interviewed me to learn more about how to conduct user interviews.  The post was originally written for the blog on L4


Lisa: When you begin a new project, one of the very first things that you and your team do is conduct user interviews. User interviews help your team answer some very crucial questions: Who will be using our product? Why do they need to use it? What’s their problem, and how can we solve it?

The answers to these questions ultimately determine how successful you and your team will be, as users’ problems inform the very vision and direction of your product. Conducting a meaningful user interview, then, in which you truly learn about your users and listen to their needs, is of the utmost importance.

That is, unfortunately, all the insight that I have to offer. I know that user interviews are a crucial part of the development process, but my expertise ends there.

To further explore why they’re important, and to provide guidance around conducting better, more productive user interviews, I’ve conducted an interview of my own. I sat down with Tricia Cervenan, a Senior Product Manager at L4 Digital, to learn more about this process. Tricia brings ten years of stellar product management experience to the table, and is more qualified than most (and definitely more qualified than I) to help you get the most out of your user interviews.


Lisa: Thanks for joining me, Tricia! Firstly, can you explain in a bit more detail what a user interview is?

Tricia: When those of us in product development start a new project, we have assumptions about the kind of problems users have and what a solution to those problems might be. As user-focused practitioners, we need to validate that the problems we think users have are real. We do this through the user interview. User interviews were introduced in the 1990s as “context interviews” by Wixon, Holtzblatt and Knox. In these interviews, you observe user behavior in a natural environment, and ask users questions in an attempt to understand and verify what motivates their behavior.

The term “user interview” is a bit broader than “context interview”, and really implies that users will be asked a series of questions. It’s important to ensure that the spirit of the context interview is maintained, however, and that questions are focused on previous or observed behavior rather than what-if scenarios that ask users to predict what they will do in the future.


Lisa: Why bother conducting a user interview?

Tricia: We have assumptions about our users’ problems, and we need to validate whether those assumptions are accurate. Oftentimes, teams will build directly off their assumptions without having first proven that a problem is real by observing user behavior and asking questions.

Where quantitative data tells us that there is a problem, user interviews and qualitative research tells us what the problem is and why it exists. If we see one of our conversion metrics decline, digging into the quantitative data will only tell us so much. And if we know and understand our market, we can even make inferences about what might have changed. But without talking to people, we can’t truly understand how they feel about the change. The last thing we want is to be forced to run a hundred tests when a few conversations with users could narrow the field of possible and probable solutions down to something much more manageable (and time efficient).


Lisa: What if you conduct a bad user interview? What are the consequences for your team and your product?

Tricia: The biggest risk of a poorly-conducted interview is the potential for introducing bias into our data. Bias leads us to believe we understand which problems users have when, in reality, this may not be true. There are many biases that come into play, and the ones I’ve encountered the most are confirmation bias and diagnosis bias. Confirmation bias shows up when we focus our line of questioning on the behavior we expect to see or to prove our assumptions. Diagnosis bias occurs when we start interviewing, make a judgement, and then spend the rest of the interview asking questions that confirm our judgement. By injecting bias into our research, we don’t get a truthful answer as to whether a problem is real and whether it’s worth solving.

Lisa: How can our readers conduct better user interviews? What are your top three tips?

Tricia: First, build rapport with your interviewee. Remember that you’re asking someone to be a bit vulnerable and tell you why they’re making the decisions they are. You’re also asking them to be honest. Not everyone is introspective enough to reveal that much about themselves and how they feel without trusting the person on the other side. Start interviews by easing in and assuring participants that there is no right or wrong answer, that they won’t hurt your feelings, and that you’re simply trying to understand how they use a product. Then follow up with softball questions that are easy for them to answer.

What types of technology do you own?

Tell me about your favorite app. Why do you like it?

Tell me about the last time you went grocery/clothes/car/furniture/etc. shopping.

The goal is to get them to start opening up early so that when you get to the meatier questions, they feel more comfortable revealing their deeper feelings.

Second, stop talking. When you ask people to answer questions, you need to give them the space to do so. When you hear a pause after someone has stopped talking, count to five and, more often than not, they will continue talking, both because they have more to say and to fill the silence. One of your goals during the interview is for users to reveal insight into their behavior, and our silences allow users to feel like there is room in the conversation for them to do so.

Third, don’t pitch your product or idea. We’re not salespeople on a grassroots mission to get five more people to use our product. We are researchers looking to learn from our users so that we can build solutions that solve their problems. Pitching our ideas only serves to make us feel better about our assumptions; it doesn’t prove or disprove them. Pause and reevaluate your line of questioning if you find yourself saying things like:

The product does that. Here’s how you do it.

We’re planning to build feature X. Would that be something you would like?

We’ve built this great new product that could make your life easier. Does that sound like something you’d be interested in?


I love talking about how to do user interviews. If you want to read more, I’ve also written a post for General Assembly on this topic.

Hey, What’s Your Problem?

There are a lot of failed products out there, but we never hear about them*. No one markets their failures; they only market their successes. But these failures do exist, and they’ve failed because they didn’t solve a real user problem. It’s not that the product wasn’t innovative or well built. Rather, it’s that earlier in the development process, no one asked enough questions, both of users and of themselves.

At the first sign of a problem, we have a tendency to jump right to finding a solution for it. The urge to fix what appears to be broken is prevalent throughout our lives.

Imagine this: You’re talking to a friend about some problem you have, and you get halfway through describing our problem when your friend pipes in with, “why don’t you just do X?” You start to explain to your friend that that won’t work because of Y. Your friend responds by telling you that you should instead do Z.

This cycle continues until you both get tired, and you leave the conversation unsatisfied, feeling as though you volleyed words back and forth but never really heard one other. You are left trying to figure out how to solve your problem on your own.

Users experience a similar feeling of dissatisfaction when we put products in front of them that might be lovely solutions to a problem, but don’t quite solve their problem. If we’re lucky, users will tell us how we got it wrong. In most cases, though, they’ll just stop using our product, and we’re stuck trying to figure out why.

But this doesn’t have to happen, so long as you approach your product with a clean slate and no pre-defined solution. Have no agenda other than to truly understand what problems are worthy of your efforts.

Re-thinking Product Management: A New Approach

Imagine the solutions that you could come up with if you knew that what Sally really wanted to do was save and share memories of her life, rather than focusing on the fact that she can’t take pictures.The first step in shifting toward this alternative method of product development is understanding the difference between a problem and a solution. A problem is a goal or objective that a user would like to achieve, but can’t. A solution is a product or process that can help a user achieve that goal or objective.

Oftentimes, when I ask a team which problems they’re solving, I hear them describe a solution that they want to build, but attempt to frame it as the problem: “Sally can’t take pictures.” “Michael wants to edit photos.” “Lucy needs more font options.” When this solution-focused work is taken to teams, it jeopardizes any alternative, innovative solutions the team could develop.

Imagine the solutions that you could come up with if you knew that what Sally really wanted to do was save and share memories of her life, rather than focusing on the fact that she can’t take pictures. What if you knew that the real reason that Michael wants to edit his photos is because he has an unsteady hand and always takes blurry pictures?

The second step in shifting toward this new methodology is to dig deeper when talking to users and collaborating with your team. Consider, for example, the issue that Sally can’t take pictures. If that “problem” is brought to your team, the conversation that follows might sound something like this:

Sally can’t take pictures.
Okay, so we need to put a camera in the app.

Well, she already has a camera in the OS. Do we really need to add a camera?
Okay, we’ll link out to the existing camera and build a way for her to see the shutter inside our app.

We shouldn’t need to link to existing software. That seems like a disjointed experience. Are there any other solutions?
Well, we could put a camera in the app.


But what if you found your inner two-year-old, and asked why?

Sally can’t take pictures.
Why does she need to?

Because she has kids.
Why does she want to take pictures of them?

She wants to remember what they looked like and did as children so that she can show them when they get older.
Why does she want pictures?

Because she wants to easily share these moments with her family members.

In that exchange, we learn so much more about our user. It’s then possible for us to stop focusing solely on adding a camera to our product and instead figure out a way for Sally to share her memories with family members.

It’s common in product development to get caught up in the solutions we love or the ideas we have. This method, unfortunately, leads to an abundance of features and products that users don’t want, can’t use, and/or don’t need. If we focus on understanding the underlying problems that people have, we can build stronger, more meaningful, and more successful products we feel good about.


*There’s a museum of the most popular product failures, and at least one website for those that probably never made it to your computer screen.


Originally written for the blog on L4

Random Musings From the Road – Leg 7


1. I was kind of disappointed. There was no “Welcome to Washington” sign. On the bridge on I-5, it just said “Entering Washington” on a small green sign. I wanted to be welcomed!

2. Two days ago, I mentioned that I’d be curious to see what littering signs work best. Washington’s is kind of funny: Litter and it will hurt.  I read that one as “Litter and I will END YOU”.

3. There are Three Copper Monuments on the side of the road. They were pretty random. Apparently they are paying tribute to Mother Theresa, victims of the Holocaust, and American Indians.

4. This is the first leg where I didn’t worry about running out of gas because I couldn’t find a gas station. I was in some pretty remote areas on this trip, but the journey from Portland to Seattle was very urban. So there were gas stations along the whole trip. Less stressful.

5. A couple of times there was this sign that said “Entering to away zone. No parking next [number] miles.” So… you can park on an interstate in Washington? Cars are always towed if they are left on the interstate and not claimed in a three days. I don’t get it.

6. I saw them in one other state too, but today on I-5 I saw “Speedometer Check” sections. I was curious as to how these would work, so I looked up the directions. Okay, so it’s Yahoo Answers, but the response makes sense. That being said, it seems like a lot of work. And yet, states are worried about texting while driving.

7. West coast states like to use “city center” rather than downtown.

8. I-5 rest stops are interesting. Charities work with DOT to schedule time where they bring donated goods including coffee, brownies, granola, and tea and then give those treats to visitors for free. But then they ask for donations in return. I asked if they come out ahead and it seems that because all of the goods are donated and then they keep the donated cash, they do. Like I said, interesting.

9. Just over a hill approaching exit 156 was when the city first appeared in my sights. It was amazing!! Yay!!

Random Musings From the Road – Leg 6


1. I drove along the Columbia River from Pendleton to Portland. I am so glad I stopped last night rather than driving straight through. I would have been so disappointed if I had missed the sights along the river. Seriously awesome. There was a lot of brown, but I wonder what it would look like if it was spring/summer and it was all green? I really can’t say it strongly enough, the drive was amazing. Congrats Oregon, you win.

2. There’s also a tree farm along the interstate. It was interesting to me to see all of these trees lined up perfectly in straight lines and all the same heights. Especially since it went on for about ten miles. Hey, I’m easily intrigued.

3. Falling Rocks, Fallen Rocks and Rocks. Three different signs to talk about the danger of rocks. It made me wonder, how do they choose which one to use? Also, if they choose Fallen Rocks, how do they know that rocks will fall in future to install this permanent street sign written in the past tense? Seems like the sign installers have some psychic abilities.

4. Also, for the first time in all the times I’ve seen those types of signs, I actually saw rocks falling.

5. I passed three dams in the journey. All of them are very patriotic. I had no idea that intercontinental dams represented our country so proudly.

6. There’s a part of WB I-84 around mile marker 95 where there is water on both sides of the roadway. It’s kind of like you’re driving in the river.

7. Diverting onto Historic US-Highway 30 to see the waterfalls was totally worth it.

8. Deschutes Brewery in Portland has a very tasty selection right now. And their food was really good. I’d recommend.

Random Musings From the Road – Leg 5


1. Idaho smells. Seriously. The entire state smells like animals. I noticed the stench before I even saw an animal. And it lasted through the entire drive.

2. I noticed when I got to Idaho a sign that says “Idaho is too great to litter.” All the other states just listed a fine for littering. The economist in me really wants to do or see if there is a study that reveals whether the statements about fines or the statement appealing to state beauty is more effective.

3. I stopped in Twin Falls to grab lunch and see a famous bridge. Apparently its a very popular bridge to BASE jump off of. I was actually pretty disappointed when I didn’t see any BASE jumpers. The bridge is over a canyon and Snake River. Very pretty. Also, the people of Twin Falls decided to put a golf course at the bottom of the canyon and a strip mall at the top of it. Take that, Arizona. Your canyon doesn’t have a golf course and a strip mall. #justsayin

4. I saw a traveler from Michigan. Someone else making a long cross country trip too!

5. Apparently all of Oregon is full service gas stations. Personally, I find full service gas stations annoying. Especially when they leave your car and forget about you.

6. Oregon has a rest area attached to Deadman Pass. I didn’t stop at that one. Would you?

7. I-84 mostly follows the Oregon Trail. So, which do you want to do? Ford the river or caulk the wagon and float?

Random Musings From the Road – Leg 4


1. Decided to visit Great Divide Brewing while in Denver. Good beer. Not so good neighborhood. I was actually more nervous walking to this brewery than I was walking in Detroit. Needless to say, I didn’t walk back.

2. Visited Root Down for dinner. Had the Butternut Squash Risotto and a complete foodgasm. Seriously, it was a spectacular blend of flavors and was cooked absolutely perfectly. I really wish they could ship me some on a weekly basis.

3. Upon returning to my hotel room, I discovered that it smelled of pot. Way to make the most of your trip fellow travelers.

4. Episode #10 of Serial dropped!

5. The drive through Wyoming was absolutely beautiful. Seeing that scenery is one of the reasons I love road tripping so much.

6. Wyoming gas is expensive. So are their oil changes. And why is regular unleaded grade 85 out here and plus is 87? On the east, regular unleaded is always 87.

7. One of the rest stops warned me to beware of rattlesnakes. Thinking they should have told me that before I stopped there.

8. Utah. Can’t say I ever thought I would visit. But here I am. I stopped at a rest stop to walk around for awhile (sitting was starting to get to me). And a nice man saw me pacing and texting and asked if I was alright. Thank you nice man for checking on me!

9. Driving through the Utah mountains is nicer than the West Virginia mountains. However, there are a couple of curious things. First, apparently there is frequent wildlife crossing on the interstate? Seems like the wildlife doesn’t understand that getting hit at 80mph isn’t awesome. Second, the road is between the side of a mountain and a concrete barrier. The barrier is constructed from those triangle shaped blocks that seemed to be used as temporary dividers during construction. I am really hoping that they were permanently attached to the road in some way because it seems like if you were going fast enough and ran into them, they’d easily get pushed over the side of the mountain and then so would you.

10. Utah has the grossest bathrooms.

11. Park City, Utah looks like an REI on the side of a mountain.

12. Seriously, can someone please send me some of that risotto?

Random Musings From the Road – Leg 3


1. Why do gas stations have stickers on the pumps saying they don’t take checks? Is there really a demand for people paying with checks? I mean, even in the last ten years has there been a demand for people paying for gas with checks?

2. Between you and me, I love turnpikes. Yup, that’s right. I don’t even care that they cost money. I love that they have less traffic, easy on/off services, and no potholes. There are people out there who detest that they are toll roads and thus, refuse to drive on them. I, on the other hand, welcome their overarching hatred. It just leaves more open road for me.

3. Off the expressway in eastern Kansas is Fort Riley, I could actually see all of the tanks and military helicopters and things. I don’t think I’ve ever seen inside of a base before so it was kinda cool to me. Most of the ones I’ve driven past before have high walls around them.

4. Kansas is a tease. I went into it thinking that it was going to very boring and flat and a struggle to get through. Like Ohio. But then I started out on the eastern side with the turnpike (yay!) and transitioned into some not-so-flat landscapes. It all looked like a very promising day. I was excited thinking Kansas was going to surprise me. But no, then it went unbelievably flat and utterly boring.

5. The World’s Largest Ball of Twine is in Kansas. I saw it. It was the highlight of that stretch of driving. #sad

6. Driving across the country has made me realize how incredibly unoriginal we are with city names. Manhattan, Kansas anyone? How about Minneapolis, Kansas?

7. What’s with all the Pizza Huts in Kansas?

8. The wind farms in eastern Colorado are prettier than all the oil drills in Kansas.

9. I finished listening to Think Like a Freak on this leg and the authors economically confirmed my saying “Quit if its not any fun“. Happy I now have validation. Thanks guys.

10. 75 mph interstates. Yay!

Final thoughts… Avoid driving the width of Kansas if possible. If not possible, drive 75 mph and hurry through.

Random Musings From The Road – Leg 2


1. There was a traffic jam on I-24 in Nashville, so I detoured up US-431 out of the city. Super cute little town. I stand by my previous post: Get off the expressway when you can. You never know what you will see.

2. I have previously suggested to Apple that they need to add a feature to Maps that lets you have a start and end point, but where you can detour off of the route if you want to go to Starbucks or something. Basically, it would search for Starbucks’ along the route. Well, they haven’t added that feature yet, but I did find an app that was made just for this purpose. It’s called TripStop. It’s a fairly nice app that I think accomplishes the job well. My only constructive feedback would be that I think the input boxes could be made bigger so they are more easily tappable while driving. Also, if no results return, it would be nice if it let you know how far you would have to go to find the thing you are looking for.

3. There’s a road in Paducah, TN called Husband Road. I wonder what happens on that road that someone came up with that name?

4. Whatever happened to The Dave Matthews Band? One of their songs came on and I realized I haven’t heard about them in a little while.

5. Holy shit its cold up north. I did not plan well for this.

6. Panera Bread is known as St. Louis Bread Company in St. Louis. Other than people who live there, I suppose, who knew?

7. Rest stops can be a bit creepy when they are empty except for some truckers and it’s dark outside. I almost locked both doors while I was in there. But then I remembered I kickbox. I could take ’em, right?

8. Facebook recently updated their app and it’s killing my battery. Ugh.

9. St. Louis is quite a sleepy town. But they have a really big arch.


All in all, a pretty uneventful day.