Transcription
Hello everyone, we are back with another interview-related question and answer series. Today, we are focusing on the role of a Product Owner, if I'm not mistaken. I believe the roles of Product Owner and Scrum Master overlap quite a bit, as we discuss processes, Scrum, and delivery methods.
Let's dive in. We have a volunteer who is willing to share her questions. Would you like to give a brief introduction before we start?
Hi Saket! I have around 15 years of experience, with the last 10 years spent as a Technical Product Owner. I'm looking to re-enter the workforce after a career break, and I have a list of questions I’d like to review with you to get the best answers.
Let's get started!
Sure! The first question I have is: How would you handle requirement changes mid-Sprint? In a different way, how do you handle scope creep? They are both related, and I want to know the best approach to answer this.
We need to answer this differently for the Scrum Master role and the Product Owner role.
As a Scrum Master, you might need to convince the Product Owner not to make frequent changes. As a Product Owner, you need to understand that some stakeholders might request changes, and you should explain that these changes can be counterproductive for the team.
You also need to prepare your team to accommodate changes when necessary.
You can start by saying that you usually see resistance from your team when changes are introduced during the Sprint. This is understandable because we have spent time discussing requirements and doing fine-grained planning. If something changes, it can derail the short-term plan we prepared, which is why people react negatively.
I also show flexibility and remind my team that Scrum encourages us to remain flexible throughout the Sprint. User stories can evolve, and acceptance criteria can be added at any point during the Sprint. I educate my team about this and remind them that it’s okay to make changes as long as we don’t deviate from the Sprint goal.
We usually write the Sprint goal in a way that allows for some flexibility. If we can accommodate a change without altering the Sprint goal, we proceed. If the change impacts the Sprint goal, I keep it as a next Sprint objective. I work with stakeholders to avoid committing to changes mid-Sprint, explaining that we will do backlog refinement and planning for the next iteration next week.
By default, I follow this approach, but there may be situations where I need to make a call. In those cases, we might miss our Sprint goal, but we make those decisions collaboratively. I want to ensure that such events don’t happen frequently because they create rework.
Sometimes, we may need to replan, as Scrum allows the Product Owner to cancel the Sprint and start again. However, we generally try to avoid such events. Occasionally, we may need to do a full replanning of the Sprint, but we aim to minimize that.
In some cases, requirements change, and we don’t want to continue working on something that is no longer needed. I start by explaining that this can lead to rework. I acknowledge that there are situations where we need to adapt, and I understand that Scrum allows us to do this according to the Sprint goals.
We write the Sprint goal in a way that allows for fine-tuning as we progress. I reiterate that user stories are negotiable, and we can add acceptance criteria as long as it doesn’t change the Sprint goal. That’s how we balance the answer.
Thank you!
The same goes for scope creep. The terms "scope creep" or "gold plating" are not very relevant in our agile way of working. They were more relevant in predictive methodologies. If someone asks, you can explain that in a predictive approach, we wanted to ensure that once we agreed on the scope, we wouldn’t deviate from it.
Uncontrolled expansion of scope, if done by the team, is called gold plating; if done by stakeholders, it’s called scope creep. However, in agile, we follow complete transparency. Decisions are made during backlog refinement, and we continuously conduct iteration reviews while working together.
Uncontrolled changes in requirements are not going to happen. We can say that we change priorities and directions for the betterment of our project objectives, but these changes happen transparently and in consultation with key stakeholders. The Product Owner represents these stakeholders, and I ensure that my understanding of requirements aligns with theirs.
We have a clear working agreement, and if stakeholders can’t attend iteration reviews, I show them demos to keep them informed about our progress. As soon as a user story is completed, I work with stakeholders to show them what we’ve done and what we plan to do. This helps manage alignment.
That’s the goal: alignment through continuous interaction. As a Product Owner, I frequently align with the development team, reminding them not to work on unnecessary tasks. I look at things on a story-by-story basis, and as soon as a story is completed, I engage with stakeholders to ensure we’re not working on anything unnecessary.
Okay, thank you!
Moving on to the next question: Let’s say you need to design a login page for a website. Can you come up with a user story?
The challenge here is that while we want to start with new users, a lot of technical work needs to be done first, like database changes and API updates. How do you handle this? If I just say, "As a user, I want to enter my account details so that I can access the website," that’s one kind of user story. But internally, tasks like database table creation and API work become too big to handle in one Sprint.
What do you do?
In simple terms, a user story should be user-oriented and provide stakeholder value. It should be created by people who understand the requirements and be small enough to be completed within one Sprint.
The focus on user value is relevant for end users, but it should also be achievable within the two-week Sprint duration. This is more about the Scrum team’s issue than the stakeholders’ issue, as they may not fully appreciate this.
As a Product Owner, I need to start by acknowledging that we need to understand the requirements. Sometimes, stakeholders may present a large requirement, like the entire login page. I appreciate their input and will capture it, but I also understand that developing a large requirement all at once delays feedback.
If we take one to one and a half months to complete it, we won’t know which parts are working, and we won’t be able to make adjustments or conduct incremental reviews. In agile, it’s recommended to break down requirements into smaller pieces that can be completed in two weeks to facilitate incremental feedback.
I show my understanding of this utility. Then I say, how do we move forward? We may have technical readiness work, which we sometimes call enablers in SAFe or technical stories in general. It’s not necessary to always start with a user story; we may need to do foundational work.
In the first Sprint, we might focus on foundational work along with some user stories. We need to assess the context. If my organization has reusable components for a login page, we can leverage those.
Each application typically has a login page, so it could be a one- or two-day job. If it’s a new technology or a new team, we need to understand the technology we’re using.
Once we have clarity on the technology, we can focus on the requirements. We should consider various user personas, such as registered users, frequent visitors, mobile users, users logging in with mobile numbers and OTPs, users logging in with Google IDs, and users entering incorrect credentials.
All these scenarios can be user stories for the login page. Ultimately, everything comes together to create the login page.
Thank you!
Next question: What is the most important part of a Product Owner's job?
From a Scrum perspective, product backlog management is the most important aspect. You need to ensure that the product backlog is well understood.
If you’re speaking to someone who appreciates theory, you can say that maintaining a healthy product backlog is a primary responsibility of a Product Owner. A healthy product backlog can be defined using the acronym DEEP: Detailed, Appropriately Estimated, Emergent, and Prioritized.
I need to ensure that the product backlog items are appropriately detailed. Items at the top should be well refined, while items at the bottom may be defined at a high level. We need to involve the right people in prioritization, considering risk, timelines, estimation, and dependencies during refinement.
For this purpose, I work closely with my development team to ensure that items are ready as we approach the next planning session. I discuss stakeholder alignment, business value delivery, and the overall success of the Product Owner, which is to ensure the product succeeds.
My accountability is to produce business outcomes from the product. I achieve this by putting the right things into the product backlog and prioritizing them correctly so that my development team can deliver the right requirements to meet business objectives.
Is it also good to mention that the product vision needs to be conveyed to the development team? They should be on the same page and aligned with the vision, right?
Yes, you can mention that. You can say that I ensure my stakeholders and development team members clearly understand the outcomes, and their efforts are aligned toward those outcomes.
I do this by communicating our goals and ensuring the product backlog reflects the direction toward that alignment. If the interviewer is willing to listen more, you can elaborate on how you continuously communicate the product vision, ensuring team members have a clear understanding of user personas.
I participate in backlog refinement to ensure they have a fine-grained understanding of user stories in advance. I work with them daily to verify and validate user stories, provide feedback, and ensure stakeholder participation in iteration reviews.
I also work one-on-one with stakeholders to provide as much detail as possible. You start with the overall understanding of business outcomes and work with the respective teams and stakeholders to achieve those outcomes through the product backlog.
Okay, so the main point is maintaining a good product backlog.
Yes, that’s an instrument you use to perform your job. Your job is to produce business results. The company is investing money, and they should see a return on that investment.
To achieve that, the instrument you use is product backlog refinement, explanation, prioritization, and ensuring alignment between stakeholders and team members.
Thank you!
This question is somewhat related but worded differently: Can you talk about a typical day in a Product Owner's life and how you distribute your time across various activities?
You can create some patterns for yourself, which can help. This question aims to understand if the person has real experience in product ownership. It’s open-ended, and your response reflects your beliefs about the role and your experience.
You can mention special days, like iteration planning meetings, Sprint planning meetings, backlog refinement meetings, and iteration review meetings.
You can prepare answers for what you do on days filled with iteration planning meetings, backlog refinement meetings, or iteration reviews.
For instance, during an iteration review, you may need to create minutes of the meeting and capture stakeholder feedback. In an iteration planning meeting, you prepare the draft iteration goal, identify tentative user stories, and explain the business priorities and objectives of those user stories.
Once the iteration planning is over, you communicate with stakeholders about which stories were planned and which were postponed.
On non-iteration planning or non-critical days, you might work on understanding user story dependencies, analyzing customer feedback, or checking metrics related to product usage.
You may also conduct market research to analyze competitor products and identify which features are performing well or poorly.
You might spend time negotiating with multiple stakeholders who have different priorities, conducting one-on-one meetings to show completed work, or clarifying user stories and acceptance criteria with team members.
All these activities can be tailored to fit your project description. You can mention specific people you collaborate with, as the interviewer may want to know who you work with and why.
So, you can highlight the distribution of your time between external and internal activities.
Yes, that’s a good point. You need to create a bucket for external and internal activities. This helps demonstrate whether you are more externally or internally focused.
Some Product Owners may spend more time on external work, while others may focus more on internal tasks. You should clarify your focus based on your project description.
Sure, that makes sense.
Next question: If during a Sprint demo, the development was done according to the user stories, but the stakeholders are not very happy, would you consider that Sprint successful or not?
In my role, we always had user stories signed off by stakeholders, along with any UX wireframes. So, how should we answer this? If stakeholders are not happy during the demo, should we consider that Sprint a success?
We can say that, depending on the context, we need to define success or failure criteria for the Sprint. Usually, success or failure is based on whether we met the Sprint goal.
Even if we meet the Sprint goal, some stakeholders may still be unhappy. Conversely, if we only meet 50% of the Sprint goals, some stakeholders may be very happy.
As a Product Owner, I would consider it a failure if stakeholders are not satisfied. The team may define success based on the Sprint goal, but my role is primarily about alignment and managing stakeholder expectations.
I should proactively work with stakeholders to understand their needs and expectations. If there’s misalignment, it’s a significant retrospective point for me as a Product Owner.
Success or failure can have political reasons and metrics involved, but if stakeholder satisfaction is lacking, we need to explore and address that issue.
We can use a simple yes/no voting method to gauge stakeholder satisfaction at the end of a Sprint. If the majority say yes, we consider it a success. If they say no, we listen to their feedback and determine if it matters.
If stakeholders say we met the goal but are still unhappy, we can call it a success based on the Sprint goal being met.
If this happens, it’s essential to understand the underlying reasons for their dissatisfaction. Only by knowing the reasons can we resolve the issue.
In previous cases, we started having regular interactions with stakeholders during the week. I began sending video clips as user stories were completed, and I spent more time understanding their domain and problems.
This often happened in the initial stages when my mindset and the stakeholders’ mindset were not aligned. I engaged in self-learning to ensure alignment.
Sometimes, we realized stakeholders were comparing our product to others, like Instagram, while we were working on workforce management. We needed to educate them about the differences between these applications.
It could involve me educating stakeholders or learning from them to establish a common mindset. We also sought more continuous interactions, both synchronous and asynchronous, to enhance collaboration and alignment.
Thank you!
Another question: What metrics or KPIs do you feel are important for a Product Owner to track?
Typically, a Product Owner focuses on outcomes and predictability.
Starting from our previous conversation, the key accountability of a Product Owner is to meet business objectives. Therefore, I need to track some business outcome-related metrics.
If the product is not yet live, these could be survey-based feedback metrics. At the end of an iteration, we can survey stakeholders to check their satisfaction levels.
If the product is live, we can analyze factual data, such as customer engagement levels, time spent on the application, number of purchases, and conversion rates.
Another type of metric focuses on predictability. This includes how well we can predict the roadmap, release plans, and milestone goals. As a Product Owner, I’m responsible for identifying the release scope and working with the team to forecast at the release level.
This builds trust with stakeholders. If I can predict upcoming milestones and meet them consistently, we can track deviations from our commitments.
If we commit to a release and don’t meet it, that’s a critical metric to monitor. We should assess our progress toward commitments and how we manage any variances.
Yes, so both business and team-level metrics are important.
Correct, but the work-level metrics should focus on meeting business objectives and commitments rather than velocity, defects, or story points delivered. Those metrics are more relevant for Scrum Masters and teams.
My focus is on whether I’m meeting commitments to stakeholders. If there are deviations, I work with the team to address them. My effectiveness is judged based on producing desired results, so outcomes and predictability are key metrics for a Product Owner.
Thank you!
Next question: Can you tell me about a project that worked well or one that did not? What’s a good framework to answer these questions as a Product Owner?
It’s tricky to discuss failures or projects that didn’t work well. If you say you’ve never experienced failure, it may indicate a lack of experience or openness.
When discussing failure, it should include a mistake, a reason, and show that the mistake was somewhat beyond your control. You should also highlight what you learned and how you plan to improve in the future.
The failure story should represent learning. Provide context, discuss false assumptions or changes that led to the failure, and explain how you plan to do things differently moving forward.
When discussing a successful project, focus less on "I did this" and more on how collaboration, engagement, and the environment contributed to the result.
You can say that the project succeeded due to collaborative backlog reviews, frequent deliveries, and open stakeholders. Your role was to facilitate alignment and integration.
Highlight that the team was motivated to see the project succeed in the market, and you ensured they were aware of the project’s success.
Okay, that makes sense.
Another question: How would you prioritize the product backlog if all items are high priority?
I was asked this question in an interview, and I started by saying I would talk to stakeholders to determine which item is higher priority. However, the interviewer insisted that all items are high priority.
In that case, the MoSCoW method may not apply.
You can use MoSCoW for high-level categorization. For example, if you have 100 product backlog items, you can categorize them into must-have, should-have, could-have, and won’t-have.
However, when targeting the next Sprint, if all items are must-haves, we need to understand the overall context. If all ten features must go live together, then everything is a must-have.
If stakeholders insist that we need all ten features to go live, we need to focus on technical priorities, risk mitigation, and our capacity limitations.
If we can’t do all ten in one Sprint, we need to identify risky items that can help us discover and create a better product. We may also consider the technical sequence to deliver things faster.
If business priorities are the same, we focus on technical and risk priorities, as we cannot do everything at once.
Is it acceptable to say that when there are many unknowns, we should tackle those first to allow more time for addressing them?
Yes, you can mention that. You can also say that you conduct user story mapping workshops with stakeholders to identify the skeleton of the product.
This helps us understand that while all items are important, we can prioritize based on technical and risk factors.
We understand that business releases will only happen when everything is completed, but we still need to prioritize effectively.
Sure!
Next question: What would you do if a specific project is failing or if it won’t meet deadlines?
This question seems more suited for a project manager.
You can say that if there’s a release goal and technical challenges arise, we may not meet the release goal, which could have significant costs.
In such cases, collaboration is key. There’s no one-size-fits-all solution, but you can share examples from your experience.
For instance, in a previous project, we faced challenges, and through open conversations, we found common ground.
If you say you’ll do open conversations but the people aren’t willing to collaborate, it can lead to confusion. You can say that in some cases, we could negotiate, but if nothing works, we prepare for the possibility of failure.
We explore flexibility in scope, timelines, or resources. These flexibilities often emerge when people communicate openly. My role as a Product Owner is to facilitate open communication.
Lastly, how do you approach building a product roadmap?
Building a product roadmap is challenging as it aligns with the organization’s strategy and requires projecting investments.
It starts with understanding the organization’s strategy—whether it’s about exploiting opportunities or resolving problems.
I need clarity from my portfolio group and strategic group about what they want to achieve. After understanding the strategy, we discuss candidate directions and assess market size and business cases.
We need a high-level understanding of why we’re doing it, how much it will cost, and what expectations we can have in the future.
Based on strategic alignment and business cases, we can set checkpoints or milestones for the roadmap. The roadmap should direct us toward achieving the product vision, which aligns with the strategy.
We consider market events, such as elections or competitor launches, and internal factors like team capacity.
It’s not just about having a team of ten people and saying we can do something in three months. We need to merge market-driven and capacity-driven approaches.
We forecast how many user stories we can complete with our team and set milestones accordingly.
Once we propose the roadmap, we seek buy-in and keep updating it. It’s not frozen; we adapt it based on market events and internal parameters.
The roadmap is closely tied to strategy, vision, and business cases, and it evolves as we learn more.
That’s more advanced management or product ownership, closely related to portfolio understanding and business direction.
Sure! Those were the questions I had. I have one more: What constitutes a good quality user story?
You can use the INVEST criteria: Independent, Negotiable, Valuable, Estimable, Small, and Testable.
But be clear to bring ideas and examples from your project. While INVEST is a good guideline, not all user stories need to meet that level of detail initially.
You will refine them as you move forward in your backlog refinement process.
Okay, that makes sense.
Thank you so much! It was nice talking to you.
Thank you! Bye for now!