Product Goal-Setting: How Scrum Masters can onboard a new or beginner Product Owner

Why do we have daily meetings? Why do I need to be involved with the team every day? Why can’t I just give you the requirements document and concentrate on other tasks?

This blog is part of Module 2 of the Coach your Product Onwer v2.0 video course.

The Anti-Patterns When A Product Owner Is New To The Team, The Product And To Scrum

These are just some of the questions that Product Owners that are new to Scrum will ask. But sometimes we need to onboard Product Owners that are new to Scrum, new to the Product and new to the team. That’s not an easy task.

The Product Owner may not have any technical knowledge of the product or the understanding of the business the product supports. When a Product Owner is new to the team, and the collaboration habits have not yet developed. For example, he may be tempted to just go away and write all the User Stories in isolation or with a Business Analyst, and never involve the team. Which later leads to the “tell the team what to do, and disappear” anti-pattern. In Module 1 of the “Coach your Product Owner course v2.0” we described how to deal with the absent or overly busy PO. In this module we focus our attention on the Product Owner that is new to the team, the product and possibly even to Scrum.

For such Product Owners there are some common anti-patterns. Product Owners that are new to the team, don’t yet have a set of collaboration practices they go through with the team. That is natural, and our role as Scrum Masters, is to help PO and team develop those practices.

Another common anti-pattern, the command-and-control Product Owner, may be caused by a previous experience in a waterfall project where the Product Manager is expected to tell the team what to do and the team act as order takers. Product Owners with this type of background will try to resolve uncertainty with top-down orders, instead of involving the team in understanding the problem, and ultimately come up with creative solutions to those problems.

Some Product Owners new to Scrum and the team may not have the mental availability (stress, too many meetings, too many stakeholders to manage) or the willingness to learn a new way of working. Every team is different, and helping the PO learn a new collaborative approach is a key part of successfully onboarding a new Product Owner.

A final anti-pattern is that of the overwhelmed Product Owner. Such situations lead to the Product Owner wanting to do things on their own, perhaps to respond quickly to a stakeholder request, or to complete the User Stories ahead of Sprint Planning. But working alone has many negative side-effects. After all, Product Ownership in software development is a collective sport, not an individual sport. In Module 1 we defined some tools and techniques to help Product Owners that are feeling overwhelmed. To avoid this anti-pattern, we focus on one specific problem: how to onboard a Product Owner that is new to the team and the Product. In the complete course module which will be available at launch, we will also cover tools and techniques to answer the following challenges:

• How to onboard a Product Owner who does not have the facilitation skills to collaborate with the team, and wants to work alone?
• How to  onboard a Product Owner that has little or no experience with Scrum, and we need to coach “on the job”?

How To Onboard A Product Owner That Is New To The Product And The Team?

When a Product Owner is assigned to work with a new team and a new product, they have two steep learning curves to climb: the team, with its habits, ceremonies, conventions, expectations, conflicts, etc.; and the product itself. In some cases the Product Owner will also be new to the business (when recruited, for example).

Product Owners that have a deep business insight, may (and usually do) lack the technical understanding that the team might have experienced in a previous Product Owner. This fact will make the communication harder, and increase the misunderstandings between team and Product Owner.

When a Product Owner is new to the product, he will also be likely to take “orders from above”, with little understanding of how those decisions affect the business or the technology of the product. In such cases it will seem to the team (and the Scrum Master) that the Product Owner is little else than a “broken telephone”, passing on decisions that are made without any team involvement.

In these cases, the Scrum Master may be tempted to focus on the team-PO collaboration, with the aim to make that collaboration work smoothly with fewer conflicts and more information sharing. However, asking the Product Owner to be more involved with the team has other consequences. For example, the Product Owner may not be able to learn the product quickly enough for the collaboration with the team to be productive. Asking the Product Owner to “lead” the collaboration with the team from day one, even with Scrum Master help, prevents him from learning the Product well enough to be able to make coherent prioritization decisions, maintain or improve the product success in the market, or even learn the technology that some teams will expect the Product Owner to know.

Instead, the Product Owner should use their first days or weeks reviewing and redefining the most important goal for the product. Product Owners that work on defining the product goal will more quickly learn who the critical stakeholders are, the main characteristics of the market they are trying to serve, and quickly feel comfortable making decisions the team needs to progress in their work.

Without a goal, the Product Owner will be lost as to what to base the prioritization decisions on, and what technology trade-offs are important to make.

Finally, a clear product goal will help the team make decisions on their own (e.g. technology decisions) and free up time for the Product Owner to focus on learning the many other things they need to be aware of.

But defining a product goal isn’t always easy, and usually takes a long time to settle on. How do we help the Product Owner define a product goal on day one of his new assignment?

Defining A Product Goal: A Process And Tool To Support A Quick Goal Setting Session

The first task for us is to agree which are the critical stakeholders to involve in setting the goal. If the product is mature, the list of stakeholders is likely to be available, and the process to define critical stakeholders will be simple. However, sometimes the product is also in its early stages and it is harder to define the stakeholders. To help in that scenario, I’ve prepared a list of questions to help you review and agree on a list of critical stakeholders with the Product Owner. Go through these questions to help the Product Owner define who to involve in the goal setting for the product.

• Who funds the product development? (usually an executive, department, or customer)
• Who is responsible for the success of the product beyond the Product Owner? (usually a customer, a Product Manager or head of Product Management, sales director, product line head, or an executive)
• Who will have to support the product when it is on the market? (usually a support engineer/department, pre-sales engineers, sales director, key developers)
• Who is responsible for staffing the product development team? (usually a manager, director or executive)
• Which departments need to directly contribute to the product development? (usually quality assurance, user testing, user experience, alpha/beta customers or their representatives)
• Who will sell the product once it is available? (usually business development, sales department, marketing)

After creating the list of potential stakeholders it is time to consider a few more questions. Before scheduling the session, we should consider the maximum and the minimum number of participants so that the session is both insightful and productive. Too many people in that session and it will become a “talk show” with too few decisions being made. Too few people in that session and there will not be enough ideas being shared, with a high probability of missing some critical insights. When preparing this kind of session I prefer to aim for 4-5 stakeholders in the room plus the facilitator. More than 5 stakeholders will make the conversation facilitation harder, as it takes longer to get everybody to express their views, and disagreements are slower to resolve. However, 3 or fewer stakeholders in the room may lead to quick, but incorrect decisions because of the lack of different perspectives.

My bias is to have a key developer/team member, Product Owner, Product Manager (or head of Product Management), a Salesperson and the executive responsible for the product in the room. When these roles overlap I will add (as needed), line managers, customer support representative, business development, marketing. Note that your experience within your organization is key! Focus on getting people that can make real decisions (which will not be easily changed later by other stakeholders), and enough diverse perspectives to avoid large blind-spots.

Once the list of stakeholders is clear, it is time to prepare the session.

In my experience, the first time you run this session it will easily take 1h30m to 1h45m. Therefore it is best to start with a 2h timeslot to ensure that the conversation is not rushed.

The template that I use to facilitate this session is the modified Elevator Pitch from Geoffrey Moore’s Crossing the Chasm book. However, the most important tool in the product goal-setting session is not the template, it is the conversation that we will facilitate between the stakeholders! The back-and-forth conversation is what ensures the commitment to the decisions made, that new ideas are generated, and that we don’t overlook anything critical.

Here’s the template (if possible, I always use post-its and a whiteboard when facilitating the session):

The process I follow when discussing the product goal has two phases.

First, we start by generating several options for each of the clauses in the template (for, who struggle with, the, etc. ). I call this first step “Brainstorming”. In brainstorming, I aim to have at least 5-7 ideas for each clause before going to the next. However, it is ok to generate 3 ideas (for example) and then come back to that clause at a later point in the conversation to ensure that we reach a minimum of 5 ideas. In the course video we explore some more facilitation tips. Ensure that you spend about two-thirds of the session time in this phase, or about 1h20m-1h30m.

The second phase of the session (which I call “Crystallization”) is about reaching an agreement on the product goal and define some of the possible metrics to measure our goal. In this phase I ask the stakeholders to select only 1 (maybe 2 if I’m feeling generous) post-its for each of the clauses. For example, we may have 5 different customer segments/personas in the “For” clause, but we really want to focus on 1 customer only! (max 2). We go through each clause and eliminate all but one idea through a consensus-based conversation, or – if necessary – using dot voting. Finally, I ask the stakeholders to list possible metrics for us to measure how we are achieving this goal. In the video course, we explore some tips on how to help stakeholders reach a consensus and generate actionable metrics (as opposed to vanity metrics) for the goal.

At the end of the goal-setting session, I read the resulting template out loud for the participants and ensure that all agree explicitly to the goal we just defined.

In this session of about 2 hours, the Product Owner has been exposed to many of the dynamics that he will have to face regularly as part of his new role. Therefore, it is important to take some time with the PO and explore what he observed from the session. Additionally, the goal-setting session generates many decisions, which will make the Product Owner’s job easy and, most importantly, give the Product Owner the mandate to make their own decisions based on what was discussed and agreed!

Here’s one incredibly useful tip that I learned from these sessions. If you have a remote/distributed team, record this session on video (with permission, of course), and make the video available to the team. The conversations that happen during the session are incredibly insightful and will help the team feel involved, and understand much better the product they are developing.

How To Use The Product Goal, And Next Steps

Product Owners that are new to the product need to climb a steep learning curve right from the start. If the Product Owner skips that step, he will not be able to answer questions from the team. This, in turn, will make the team feel lost, and not able to deliver on the expectations due to misunderstandings, slow decision making, contradicting priorities, etc.

Once the goal is defined it is time to share it with the team. Together with the Product Owner decide how to communicate and make the goal available to the team. It can be done in a meeting, or as a preparation step before defining the Product Vision (see our FREE video course on how to Prepare a Product Vision). Ensure that the team has the time to ask all the clarifying questions they have, and explicitly agree that the goal is clear to them.

Now that the product goal is defined, and the Product Owner has taken a massive step in the product learning curve, it is time to focus on the other critical aspects: how to collaborate with the team, and how to learn and take advantage of Scrum and Agile in his role. Those are topics we cover in module 2 of our “Coach your Product Owner course v2.0”, which this blog is part of.