Product Ownership Questions Answered

In her webinar, Product Ownership in the Real World, Senior Product Manager and Agile Leader at Adobe Melissa Pickering shared insight and advice around how to show up, claim your place, and do the work as a product owner. She also addressed thoughtful questions. Read on to see how she responded.

On The Role of the Product Owner 

Do you believe a successful product owner should have a software development background, i.e. computer science degree, experience working as a developer, etc.? What would you recommend to a new product owner who does not have this background? 

I don't believe that a product owner has to have a software background, especially now that product owners are working in many different industries in many different roles. More and more, teams are not necessarily even building software. But let’s assume that your team is building software, do you have to have a software background? The answer is no. 

Your role is to represent the customer, not to say how to develop the product. You can make a contribution without getting into specifics and saying how to build it. 

Representing the customer can be tough. Sometimes the team will want to build it in one way but your instinct may be to do it another way. You do need to spend enough time with customers to understand their needs. And you need to spend the time with the team to understand the things that get in the way of meeting those needs. Just ask. Say, “I want to learn more about the challenges that you face.” And then listen. Because there are many, many real barriers to technical implementations that will be helpful for you to understand, and at the end of the day you don't have to have a technical background to learn about those obstacles.

How do we differentiate between the product owner and the product manager? And can both roles be a single person?

This is actually a controversial question. If you Google product owner versus product manager, you will get about 100 different answers. In my current role, there is a product owner and there is a product manager. And we work very closely together and we overlap a lot. 

In my experience, product managers tend to do more customer-facing interactions. And product owners tend to face the team and interact with the team. If you're lucky enough to have enough people to split that role between two individuals, great. But lots of times you're forced to balance the amount of time you spend with the team and the amount of time you are able to spend with customers. Both parts are needed. Some companies choose to do it with one role; some use two.

There's a difference between a “perfect scrum environment” and the environments that many product owners are actually operating in. The Scrum Guide doesn't mention product managers but that doesn't mean that you're not working with one. In larger organizations, there's a lot of complexity. There's a lot to keep track of and a lot to measure and a lot of customers. So all of that is just harder to separate and harder to do as one person when you do it at scale.

On The Product Backlog 

Do you have a tool you use to reduce accidental scope creep? 

If you mean a software tool, no. If you mean personal techniques, sure. The tool is, go to your bathroom mirror and practice saying no. 

It is so hard because a lot of ideas that come through and that end up as scope creep are things that you want and you know the customer wants, too. So the tool I use is just to always remember, “We have to get something out the door in order to get more feedback on it.” And remembering that helps me to say no. It just takes practice practice.

How does a large and mature organization deal with pushing out a "just good enough" feature to customers?

Even medium-sized companies don’t have the same processes across all groups within the organization, and this is magnified in a large organization. Larger companies may make use of beta programs and have various communication channels set up with their customers. These types of channels vary with each organization. These channels provide a way to continuously talk about iterations and set expectations of what will be delivered, when and why. 

You can do iterative feature development at a large organization – but it should involve more testing. Test, test, and test some more to make sure you don’t interrupt or break something that already exists. It’s also imperative to stay aligned with the various teams that your releases may impact.

On Pleasing the Customer and Other Stakeholders

You mentioned that the customer goals were the product owner's goals. Can there be a divergence from the customer's goal/ask and what the product vision is?  Should that really be addressed by the product manager? What if what customers are asking for doesn't align with my product vision? 

If one customer is asking for something, and it doesn't align with the product vision, then that might be a unique situation you can ignore. If a larger percentage of your customers are asking for something, and it's not the product vision, then you need to ask yourself a couple questions like:

• Are we building the right thing? 

• Is the customer telling us something by saying these things that don't seem to connect with the product vision? 

• Is the product vision off a little bit? 

• Are we working with the right audience? For example, have we built something for a team or team level activity, but all of our customers' feedback is coming from executives? 

• Does that feedback actually counter what you're building? 

• Or are you targeting the wrong folks in order to get feedback, the actual users versus the buyers? 

I would say, to the original question about customer’s goals or the product goals, you don't write the product goal, like, “the customer wants to increase revenue, or customers want to balance their own supply and demand abilities.” Instead, establish their end goal and go from there.

Do you have a standard set of questions/criteria for your initial meetings with customers?

I do. Here is an example. At Adobe, we work on an agile work management product and so my questions are geared towards those particular customers. I have about 12 questions: 

• Tell me a little bit about your organization. 

• What part of the organization are you in? 

• What are you responsible for? 

• What are you trying to achieve? 

• What challenges are you trying to solve? 

• Why are you using our tool to do it? 

• How many people or teams are we talking about using this functionality (to find out about scope)?

• What do you want to get out of our meeting? I ask this because sometimes, customers want to talk about the roadmap, your vision, and your concepts. And sometimes they want a demo of functionality as it is today. 

You are ultimately looking for customer feedback, whether you work in software or not. We typically have some screenshots or a prototype. And we literally ask them to either walk through a flow; to tell us how they would do x or how they would do y (UX and design). And this is where we partner with them, if you're lucky enough to have customers to work with you this way. 

What are some of your strategies for dealing with the loudest voices or "highest-paid-person” opinions?

Be confident and represent your customer. Often, the loudest voice in the room is 100% not the correct answer, right? There is no one person that has the right solution to build. So if you have had customer conversations and incorporated feedback from different areas, then you have something to put in front of people and say, this is what the evidence says is what people are actually looking for. Don't make it about the person, make it about the product or feature. Focus on the thing that the customer is asking for, and then just bring evidence, go to metrics, use data to have those conversations. 

Sometimes you may have to compromise if there's some nugget in their feedback that's actually valid. Sometimes you have to compromise to build relationships and help them trust that you are bringing together the right stuff. Eventually the loudest voice might start advocating for you. 

Curious about how you keep various levels of stakeholders up to date on your team's work.

This could be different for each organization, but I generally do a monthly mashup to align with stakeholders, separate from a sprint review. In a larger organization, the number of stakeholders may be too numerous to get good feedback from during a review for the team, so a separate meeting may be best to keep the conversations focused between product feedback from users and alignment with stakeholders. Anyone is invited to the mashup and the agenda is co-created by attendees.

Could you please share your experience with metrics relevant to customer satisfaction?

There is a difference between overall customer satisfaction and feature satisfaction. NPS score is a generally accepted measure of how likely someone is to recommend your service/product/company. However, there is no easy way to measure feature satisfaction. To understand if something you released was positively accepted by your users, look at validation testing and more specifically, hands-on testing with users rather than a poll. It may be tempting to leave specific feature feedback to a poll or survey, but there is a lot you miss out on from the user if you don’t sit down with them and see how they use your feature or the entire product. After a number of interactions with your users, you can start to see trends in how they feel about your product. 

Also, work with brand marketing and customer success teams, anyone who is measuring overall product satisfaction. Work with the teams that are connected directly to customers for their insights;  they may have tools to measure sentiment.

======

MORE: Questions and Related Articles about Product Ownership

How many story points can we assign for one day or 8 hour work ? There seem to be different opinions, so I am looking in general at what the industry is following. And, how many points can we assign per 15 day sprint? 
Answer

At what point does the product owner do user story mapping?
Answer

If you are working on a defect, how do you break it into a couple of stories, when you know that it can't be finished in a sprint? 
Answer

When you meet with the sprint team to work on the stories, are you doing that in a user story workshop, refinement, or a separate meeting?
Answer

How does a new product owner acquire domain knowledge and build their expertise ?
Answer