30 Questions to ask a Product Owner
30 Questions to ask a Product Owner
Scrum Master's first 1:1 meeting with the Product Owner
👋 Hello, I’m Vibhor, and welcome to the 🌟 free monthly edition 🌟 of my weekly Q&A Series powered by Winning Strategy. Every week, I answer one reader question and publish 2 posts about Agile Products, Role-Based Skills, and anything else that you need answered about your Career Growth. You can send me your questions here.
On to this week’s question!
Q: Hi Vibhor! Thank you for taking the time to share your knowledge and expertise. I would love your assistance in providing tips on how to start with a new team. Specifically, what questions should I ask the Product Owner? I somehow learned that the last SM left due to excessive workload and pressure. He also gave me a long list of issues with the team. I am overwhelmed. It seems I have a mountain of a task in front of me. How should I approach this?
Thank you for the question.
What you have described is one of the main reasons why most Scrum Masters struggle to form a meaningful connection with their new team. They let other’s opinions cloud their judgment.
I am not saying that you shouldn’t meet the old members of the team. In fact, that is a really good idea. But don’t treat that meeting as an alternative to your own initial analysis.
When you meet someone who has worked with your team before, then instead of asking what doesn’t work, ask what works with the team. You can ask questions like:
Who is the most influential team member?
What’s the influential person’s personality type (driver, analytical, amiable or expressive)
What’s their attitude towards being part of an Agile team?
Who is always skeptical?
Who listens?
Also, ask, “What makes you think that?” after each of the above questions.
This advice can serve as a starting point for your interactions during your first 30-60-90 days with your new team.
It will help you:
create a list of questions for a 1:1 with each individual team member
formulate a 30-60-90 day plan and strategy, and
approach your team with the right mindset
If you haven’t yet, check out the post linked below for a handy framework to create your own 30-60-90 day plan.
First 30-60-90 days as a Scrum Master
Today’s post talks about your first 1:1 with the team’s Product Owner. You’ll learn:
What’s the right mindset for the meeting?
What topics to inquire about?
What questions to ask?
What not to ask?
Let’s get started.
Get into the right mindset
Before you meet your Product Owner (for the first time), it is important that you get into the right mindset.
Don’t go to the meeting thinking that the Product owner is obligated to tell you everything that’s needed to help you fix all of the team’s problems. As a Scrum Master, it is your job to find out what the team needs to succeed, and this meeting is one of many that will help you discover those needs.
Your first meeting with the Product Owner or any other team member has two primary objectives:
gather information, and
establish trust
The first objective (gather information), helps you learn about:
your team,
the product they are working on, and
what success looks like
The second objective (establishing trust) is needed so that the Product Owner can trust you with the team's internal matters. Without this, you will not be welcomed.
So, don't go to the meeting with the preconceived notion that there are problems within the team that need to be solved.
Go to the meeting with an open mind.
Be a “learner.”
Ask questions and listen.
What topics to inquire about?
This depends on whom you are meeting and what their role is within the team.
Product Owner is one of the most important roles within an Agile team. Their primary responsibility is to:
discover problems to be solved
analyze those problems to be the right ones
collect the ones that turn out to be right in a backlog, and
prioritize them in a logical order
They then empower the team to find the right solution.
For this to happen, they need to have a deep understanding about:
the end user and their problems
the product that will solve those problems
the stakeholders and their needs
the business value that will fulfil those needs
the team and their requirements for success, and finally
the metrics that will measure that success
So, the information that you want to gather from the Product Owner will be mostly about:
the product vision
the existing product backlog
the stakeholders and their dynamics
the team and its interactions, and
the success metrics
Let’s discuss these in detail.
Product Vision
This is the “imaginary future state” that everyone is working towards.
Knowing about this will help you keep your team focused on the big picture.
I like to divide “Product Vision” into 4 sub-categories as follows:
grand vision
target audience
long-term goals, and
roadmap (if available)
To get this information from the Product Owner, ask the following questions:
Q1: What problem does the product solve, and why is it important?
Q2: Who are the primary users? What are their pain points and core needs?
Q3: What are the high-level objectives and milestones?
Q4: Is there an established roadmap outlining key features, releases, and a general timelineAnswers to the above questions are enough to guide you on how to:
use the process to help your team solve problems
customize the process as needed
prepare the right training for the team
facilitate the discussions in the right direction
help your team pivot when necessary, and
gain your team’s commitment to the common goal
Product Backlog
This is the prioritized list of end-user problems the team is trying to solve.
Knowing about this will help you keep your team focused on delivering value incrementally.
I like to divide the "Product Backlog" into yet another 4 sub-categories:
backlog structure
prioritization techniques
refinement
user stories
To get this information from the Product Owner, ask the following questions:
Q5: How is the backlog organized and prioritized? Are there different levels (themes, epics, etc.)? How are items defined and estimated?
Q6: What factors are considered (customer value, business goals, dependencies, etc.) to prioritize the backlog items?
Q7: How frequently is the backlog refined?
Q8: What's your expectation for user story readiness before Sprint Planning?
Q9: What's the Definition of Done? Does it need to be refined or revisited?Answers to the above questions will help you discover:
potential issue
training gaps
coaching requirements, and
mentoring needs
Note: You are just gathering data. So, DO NOT offer any suggestions in this meeting.
Stakeholder Dynamics
Understanding this will help you make sense of how the “development efforts” align with the “business expectations.” You will know why the Product Owner makes certain decisions that go against the grain of the defined Scrum process.
This knowledge will help you customize the process when necessary.
I like to divide "Stakeholder Dynamics" into 3 sub-categories:
key stakeholders
feedback loops
decision making
To get this information from the Product Owner, ask the following questions:
Q10: Who are the key stakeholders you interact with regularly?
Q11: How do you typically engage with them, and what are their main concerns and expectations?
Q12: How do you collect their feedback? How do you use this feedback in decision making?
Q13: How do you make the final decisions on priority?Answers to these questions will help you:
relate to the decisions made by the Product Owner
understand when to enforce the process and when to let go
support the business with Agility
understand how the business makes money, and
how to help the team resolve certain impediments
The Team
The information you gathered above will help you guide your team towards greater productivity, as expected by the business.
Now, it is time to understand the team itself. Here's a breakdown of important things a Scrum Master should understand from the Product Owner's perspective about the team:
past challenges
wins and strengths
skills
cross-functionality
collaboration
team norms
feedback process
communication style
availability
conflict resolution
To get this information, ask the following questions:
Q14: Are there any recurring obstacles (technical debt, unclear requirements, etc.) that the team repeatedly face? What was done in the past to resolve these impediments?
Q15: What are the team's core strengths? Name some of the past successes?
Q16: Does the team have the right mix of skills to deliver product increments? Are there potential skill gaps that you are aware of?
Q17: Is the team cross-functional, or are there strong dependencies on specific individuals?
Q18: How does the team work together? Are they highly collaborative or more independent?
Q19: Are there unspoken expectations, preferences, or ways of working within the team that I should be aware of?
Q20: How does the team give and receive feedback?
Q21: How accessible are you for team's questions and clarifications? Are there specific hours or channels (eg. email) preferred?
Q22: How you approach conflicts within the team or with external stakeholders?The answers to these questions will help you understand:
the team's background
organizational factors that affect their work, and
their “known” challenges
Note Again: Do not offer any suggestions or quick resolution to these challenges. You are here to gather information. Resisting your urge to appear smart at this point will help build the necessary trust and credibility.
Success Metrics
This is how the Product Owner measures:
team’s progress in the right direction, and
product’s health
The Success Metrics, therefore, are a mix of metrics that reflect both:
the effectiveness of the process, and
customer’s satisfaction
When asking questions, I divide "Success Metrics" into 2 sub-categories:
PO’s definition of success.
KPIs
You can get this information by asking the following 3 questions:
Q23: How do you define a successful delivery?
Q24: How do you help the team balance qualitative and quantitative factors?
Q25: What KPIs do you track to evaluate product and team performance?The answer to these questions will help you in the following manner:
You will understand PO's vision for success
You can align your process strategy with product goals
You can facilitate discussions around impediments that impact these metrics
You can suggest improvements to the team's workflow
You can identify if the PO's definition of success and the team's understanding of it align or not
Example:
Let’s say the PO mentions that successful delivery is primarily measured by hitting a certain number of story points in a Sprint. You know that velocity is highly prioritized.
Then, as a Scrum Master, you can later plan to:
help the team find ways to improve predictability and estimation, and/or
remind the PO that velocity alone may not be the best reflection of value delivery
Expectation from your role
After gathering all the information about the team, the product and the success, you can ask the Product Owner about what they expect from you as a Scrum Master.
This is important to:
make sure that they have a clear understanding of your role, and to
clarify any misunderstandings or confusion related to your role right away
To do this properly, ask the following questions:
Q26: Given your experience, what a Scrum Master can do to support the Product Owner and the team?
Q27: How would you like us to work together? Daily updates, specific meetings – what works best for you?
Q28: Any specific situations where my involvement and support would be most helpful?
Q29: Do you have any current concerns about team's performance or the process where you'd like me to focus my initial efforts?Closing
Before you end the discussion with the Product Owner, make sure you give them an opportunity to ask questions.
You can say something like:
Q30: Before we wrap up, do you have any questions for me? This could be about my background, my approach to Scrum, or anything else on your mind."Important: Also, don’t forget to inform them about your 30-60-90 day plan so they know about your observation period and are not alarmed by your initial inaction.
Things to avoid in the first meeting
I have seen numerous Scrum Masters make the mistake of immediately challenging the Product Owner's way of working.
This will damage your relationship before it is built.
To make a positive kickoff, here are a few things you should avoid in the first meeting with a Product Owner:
Criticize how things are done
Give a Scrum/Agile lesson
Make promises you can't guarantee
Asking, "What was wrong with the last Scrum Master?" This sounds negative and will not help you.
Asking super detailed questions about how the team builds the product. Talk to the team directly about this.
Asking "What if..." questions about a problem that has not happened yet. Focus on what's happening now.
Asking questions that show you didn't do your homework. If the PO sent you information beforehand, don't ask them to repeat it.
This isn't about being overly cautious. It's about establishing trust and starting your work on the right foot. As your relationship develops, you can be more direct and offer suggestions!
Further Reading
This is it 🙏
If you have any questions (related to this topic), don’t forget to use the comments section to ask the community. I will try my best to get you an answer.
🙋🏻♂️ Your Questions!
If you want me to answer your questions in this newsletter, please send them my way using this link - Send me your questions.
If you find this newsletter valuable, consider sharing it with friends or subscribing if you haven’t already.
Till next week!
Sincerely,
Vibhor 👋
P.S. Let me know what you think! Is this useful? What could be better? I promise you won’t hurt my feelings. This is an experiment, and I need feedback. You can reply to this email to send your message directly to my inbox.
“I share things I wish I knew in the starting years of my career in the corporate world"
Hello VIbhor. Thanks for wonderful Article. I have started my Journey as Product Owner 1.5 yrs back. Recently I have moved to Healthcare product within my organization. Can you please help me with similar article for POs? Like 30-60 days plan. What to do when u join new team . Which questions to ask As a New PO likewise. Thanks a bunch.