What do I focus on as a new Product Owner?

What do I focus on as a new Product Owner? | Humanizing Work Show | Mailbag

Some new POs come into the role as a domain expert and need to learn product management. Others are experienced product managers but are coming into a new domain. Many new POs need to grow in both areas.

In this episode, Richard answers the question: “What should I focus on as a new Product Owner?” Being a Scrum Product Owner is a big job, and it’s easy to get overwhelmed, so Richard breaks down what’s most important to focus on in the early days and in what sequence.

Learn More

Certified Scrum Product Owner Workshop (virtual, instructor-led)
Advanced Certified Scrum Product Owner Program (virtual, instructor-led)
Agile & Scrum Crash Course (online, self-guided)

Episode Transcription

Richard Lawrence

Welcome to the Humanizing Work Mailbag, where we answer questions from the Humanizing Work Community!

If you have a question you’re wrestling with, email us at mailbag@humanizingwork.com, and we’ll see if we’ve got a good answer for you.

Before we jump into today’s episode, just a quick reminder to rate and review the Humanizing Work Show in your podcast app, or if you’re watching on YouTube, would you please subscribe, like, and share today’s episode if you find it valuable? We really appreciate you spreading the word about the Humanizing Work Show.

And if you want to get access to more content we produce, not just the show, you can always sign up for our newsletter at humanizingwork.com/hwnews.

Last week, we took on the question, “What do I focus on as a new ScrumMaster?” Today, we turn our attention to the same question, but for Product Owners: “What do I focus on as a new Product Owner?” Sometimes, when we get this question it’s “…as someone totally new to Product Ownership,” other times it’s more like, “…as an experienced Product Owner but in a new domain.” So, I’m going to talk about both of those things.

A few weeks ago, in our episode on “Scrum Roles in the Real World,” I mentioned that our idea of a good Product Owner is much more than a backlog administrator. As I said in that episode—and, as I flesh out in all our Product Owner workshops—Product Ownership, done well, is learning and communicating what to build, who it’s for, and why we’re building it in collaboration with a cross-functional Scrum team and other stakeholders in order to maximize the flow of value through that team.

So, on to today’s question, how do you get started in a new role if you want to be that kind of effective Product Owner?

There are two parts to our answer:

First, Product Owners need expertise in two major areas to be effective. So, part of getting started in your role may be leveling up in one or both of those areas. So, we’ll talk about those two areas and how to grow in them.

Second, there are just a lot of practical things a new Product Owner needs to do in the role. It’s too much to handle all at once when you’re new, so we’ll talk about the best sequence in which to approach all those practical things.

Product Owners need expertise in two major areas:

First, their domain, especially the problem space—who the customer is, what problems they have, why they’re worth solving from the customer’s perspective. But also the solution space—what customer problems we address with our product, and how we do it, and why it’s worthwhile for us to solve those problems.

But Product Owners also need expertise in product management as a discipline. Just being an expert in the domain doesn’t make you an effective Product Owner. I’ve seen a lot of examples of this. There’s a whole set of practices, tools, and skills that apply across domains to go from identifying a problem to helping a team create a product to solve that problem.

Some new Product Owners come into the role as a domain expert and need to learn product management. Others are experienced product managers but are coming into a new domain. Many new Product Owners actually need to grow in both areas. They need to learn their domain more and they need to shore up their product management capability. So, how do you do each of those things?

How do you grow domain expertise? One way, of course, is to spend years and years slowly picking it up on the job, but, assuming you don’t want to do that, how do you do it?

The best approach at first is going to be talking to people with expertise in the domain. I recommend starting closest to your product and working outward from there. So, arrange conversations with a couple of people who know your product and its customers well. Perhaps a long-time developer on your team. Maybe a key business stakeholder. Perhaps an experienced salesperson—they’re actually some of my favorites because the good ones understand how to talk about the problem and the product differently with different people, which gives them range.

Now, you can’t just ask these people to bring you up to speed on the domain. That’s too big a question, and much of their knowledge is likely too familiar and too obvious and tacit to them, so they won’t think to talk about it, and you’ll miss important things. Instead, work from concrete examples. Ask something like, “What’s an example of a customer solving a meaningful problem using our product?” Follow up with questions about the customer’s context, alternatives they could have used, why the solution mattered for them, etc. Then, time permitting, you can ask, “What’s another example that’s different in key ways from the last one?” As you start to build up your own mental model, you can begin to propose examples that test the edges of your mental model, “Can you think of an example of X you could tell me about?” They might say, “No, X never happens and here’s why…” which is useful, or they might say, “Sure, here’s a story about that…” Either way, your mental model grows.

A few of these conversations gives you a baseline of knowledge close to your product that allows you to then work outward into the larger domain. The best sources as you move out, vary widely by domain. It could be books, trade journals, conferences, meetups, YouTube channels, online communities, and probably more I’m not thinking of right now. Ask the people you interviewed: “Where do you go to keep up with the latest in our field?”

If you get a chance to interview customers or observe them using your product, take advantage of that, too. But just be careful to keep the focus on the problem domain– on their world as they think about it– not on your product. New Product Owners can often become a target for pent-up feature requests, and you don’t want to end up with availability, primacy, or recency bias distorting your backlog. Get your own picture of the domain clear before getting anchored to the perspective of those first few customers who are willing to talk with you.

Finally, as you’re trying to understand the domain, dig into the landscape of competitive and adjacent products in that domain. Not just to understand how they’re positioned differently from yours—which is important—but also to look at how they talk about the domain. That can give you additional perspective on the context your product sits in.

As you collect information about the domain, you might want to capture what you’re learning outside of your head somewhere. I’ve seen some new Product Owners make a glossary of domain terms; others create a visual, like a mind map or something to organize concepts and their relationships. Once you have an artifact like that, now you have something that you can bounce off of others in your company and invite them to correct or add to it and that’s another source of conversations that can help you understand your domain better. So, those are some tips for getting up to speed on the domain side. But, as I said, Product Ownership also involves a lot of tools, practices, and skills that cut across domains—they apply everywhere.

To give just a few examples, a good Product Owner should be able to do customer research to understand the problem domain. They should be able to form hypotheses and test product assumptions. They should be able to craft and communicate a compelling vision and business case for a product. They should be able to slice a big idea into good features and user stories, prioritize those features and user stories, and collaborate with a team to build them and bring them to market.

If you need to level up on any of these skills, there are a variety of ways to do it. I’ll just share a few.

We teach workshops on these topics, most frequently our Certified Scrum Product Owner and Advanced Certified Scrum Product Owner workshops, which are much more about these skills than they are about Scrum, despite the names. Of course, many other people teach workshops like this, so it’s quite possible to find one with a style, location, and timing that works for you. It doesn’t have to be from us.
There are lots of free resources online for growing your product management skills. Podcasts like this. Meetups. Webinars. YouTube videos. Articles. Our “Humanizing Work Guide to Splitting User Stories” is a good example of the depth of content available for free on the internet today. The tradeoff with free resources, however, is that you have to piece together the materials you need instead of working through a structured curriculum.
And there are always books. I’m a big reader, so this is one of my favorite ways to learn. The challenge here is finding the right ones, actually reading them, and then actually applying them to your work. It’s easy to read a book and never do anything with it, or to start a book and never finish it.

However you approach it, put intention and effort into building your skills. It rarely happens by accident. It certainly doesn’t happen fast by accident.

So, that’s the first half of our answer to how to get started as a new Product Owner—ensure you build the expertise you need both in your domain and in the discipline of product management. Second, a new Product Owner needs to handle a number of practical things in a structured way if you’re going to avoid being overwhelmed and ineffective.

Here are a few tips on how to approach sequencing your work in your early days as a new Product Owner:

First, start at the top of the backlog. It’s really tempting to start with the big picture, and work your way down, but if you already have a team, they need to hit the ground running. They need something meaningful to do. Ask, “What’s the most important thing we could move forward right now?” Now, “future you” may not agree that that was the most important thing, but just “Based on what we know right now, what is the most important thing that we could move forward?” And then get that into enough good user stories to fill a sprint– maybe a little bit more.

If you’re joining a team that already has a backlog from a previous Product Owner, you have two options for what to do with it:

You can just take it over and refine it in place. In which case, start by cleaning up the top of the backlog first.
You can declare what I call backlog bankruptcy. Move the whole backlog into a separate place—the mechanics of that depend on your tool—and then once you’ve moved it, you treat it as a collection of possible things your team could build, but not the actual backlog.. Draw from it to build out your new backlog, but don’t treat it as a list of commitments. Now, note that the previous Product Owner, though, may have made commitments which you’re going to have to manage. So, you may be pulling a lot of that backlog back into the new one. But the act of deliberately pulling each item in or reshaping it into a new one will give you a better handle on your backlog. It’ll actually become yours.

Once you’ve given your team a sprint or two of work, at the top of the backlog, use the space, the breathing room, that you’ve just created for yourself to now zoom out to the big picture.

The first thing to look at when you zoom out is who your stakeholders are.

I’d suggest starting by building a stakeholder interaction map. This is a tool we teach in our Advanced CSPO workshop. There’s lots of nuance and variations you can do, which is why we spend a whole week of the session on stakeholder management, but here’s the quick version:

First, draw a big circle representing all your stakeholders. Divide it into 3 wedges. The first wedge (the first third of the circle), is for stakeholders who influence WHAT your team builds. They shape what items appear on your backlog. The second wedge is for stakeholders who influence HOW your team builds whatever you build. They shape your definition of done but they may not care about the specifics of what’s on your backlog. The third wedge is for stakeholders who cause you to change the sequence of items on your backlog away from prioritizing by value. These often represent dependencies. You might say something like, “I would do feature A first if I were prioritizing the most valuable items, but feature A is waiting on a dependency from an outside vendor, so I guess I’ll put feature B first there instead, while we wait.” That outside vendor goes in the WHEN wedge of the stakeholder map. They’re sort of distorting your priority away from value, so you need to visualize that.

Go ahead and brainstorm the stakeholders for each wedge. As a new Product Owner, you’ll probably need to ask others to figure out who these people are and what they do. So, you can ask around, and say, “Who are the people who inform what’s on our backlog? Who are the people that care about how we build what we build? Who are the people who represent dependencies one way or the other, and might affect the sequence of what we build?” and a stakeholder could appear on the map more than once. Some of them are in two places.

Now that you’ve done that, you can add another distinction to your stakeholder map. You do this by drawing a series of concentric circles, from the inside out, for the frequency on which you need to interact with that stakeholder. The inner circle is DAILY. Stakeholders go in this circle when new information emerges daily from them that will affect your team or from you, that will affect them. Moving out, the next is every Sprint—or SPRINTLY if you want to stick with adverbs. Stakeholders go there if things change every sprint. Then add more circles for MONTHLY, QUARTERLY, and YEARLY. Arrange your stakeholders on the right circle within their wedges.

Now, once you’ve done this, you can see who you need to talk with, about what, and how often. To set yourself up for success as a new Product Owner, get these interactions established. Some of them may be recurring meetings. Others may just be a reminder to you to send an email to that person at that time, about that topic.

Next move, once you’re got your stakeholder map sorted out, that I suggest for new Product Owners when you’re zooming out to the big picture is initial customer research. See if there are already customer profiles or personas you can review. If possible, arrange a few customer problem interviews. Your goal here is to understand the key customer segments for your product and the key jobs, pains, and gains for each of those segments. We spend a week or two on this in our ACSPO program; how do you do good customer interviews like this, how do you make sense of the results– there are also several books out there about this topic.A big part of the job of Product Owner is representing a range of customer perspectives, so you need to develop that understanding early before you get buried in feature requests and turn your team into a feature factory just taking orders.

Next, I suggest looking at vision. Vision is a picture of what the world looks like once your team has successfully done what they exist to do. Perhaps there’s already a compelling, vivid vision statement that you can adopt. But, honestly, it’s unlikely. We don’t see a lot of good ones in the wild. So, you may need to create one.

Based on what you’ve learned so far in your early research, write a draft vision statement. Vividly paint a picture in words of why the world will be better once your team is successful. In our CSPO workshop, we teach a rapid collaborative vision drafting technique. You could use that if you know it. Or you could just sit down and do some creative writing, and describe what the world looks like in the future.

Once you have that draft vision statement, test it with more experienced team members and stakeholders: ask them, “Does this describe what we’re doing? What’s interesting about this? What would you change or expand in here?” and use your feedback to refine your draft.

Finally, fill in the middle of the backlog between the vision and the top of the backlog that you’ve already refined. If you’re facing a big, complex problem, I recommend our Feature Mining technique for this to help your team focus on the core complexity of the problems you’re solving. If you’ve already resolved the core complexity, you may just need to analyze the variations to address and list and sequence the features from there. Jeff Patton’s story mapping technique can work really well for this kind of analysis.

After you’ve filled in the middle of the backlog, you’ll just transition into the regular steady-state, ongoing backlog refinement. Check out our PO Board episode for a way of structuring the backlog that supports that kind of sustainable continuous refinement.

Ok, that was a lot. A new Product Owner has a lot to do in the first months. So, to summarize:

Level up your expertise in both your new business domain and in general product management capabilities.

Sequence your early work by giving your team a sprint or two of good items to work on to buy breathing room for zooming out, then getting a handle on stakeholders, customers, vision, and the middle of the backlog.

Last, be patient with yourself. You’re not going to get everything right—this is a complex problem, and there’s always going to be too much to do: you can’t do it all sustainably—so prioritize your work and be willing to let the less important things fall off and be willing to ask for help.

If you found this episode useful, please like and share it and keep the questions coming! We love digging into tough topics, so send them our way. mailbag@humanizingwork.com. And if you need help with the Product Ownership capability in your organization, check out humanizingwork.com for training, coaching, and lots of free resources like our story splitting guide.

Last updated April 10, 2023

What do I focus on as a new Product Owner?