Being a product owner isn’t easy. In addition to coordinating with every group of stakeholders and prioritizing the entire backlog, this person is considered the “single, wringable neck” who will take the fall if a product doesn’t succeed. Yikes! To be effective in the midst of this stress, there are a few things product owners need to know. That’s why we’ve boiled our list down to five items that will increase your likelihood of success, and keep you off the chopping block.
comic c/o implementingscrum.com
1. Trust is Key
In the early stages of a new project, there may be number of product backlog items that will be difficult to understand for product owners who lack significant development experience… and that’s okay. Product owners: Don’t be afraid to rely on your team to explain key items, so you can properly prioritize them. Your ability to make effective backlog decisions is dependent on a good relationship with the Scrum Master and at least one (or preferably all) of the developers, so allow them to guide you through any esoteric work a sprint requires.
But remember, trust needs to be a two-way street. If the team feels comfortable enough to suggest changes you may not have thought of (refactoring comes to mind), then your product will benefit from their specialized perspective. More often than not, their technical changes will accelerate feature development, create more reliable code, boost long-term performance, and make development easier in the long run- so take the time to listen! Your team’s feedback can be a valuable addition to the final product, but their input will quickly disappear if you don’t take the time to earn team trust.
2. Your Job is to Serve the Team
The ultimate goal of development is to ship great software on time. That’s why you’re there, that’s why the team is there, and in a roundabout way, that’s even why the Scrum Master is there. But despite this clear mission, the Scrum team can often be their own worst enemy along the way. While this issue isn’t something product owners can fully prevent, it’s definitely something you don’t want to contribute to.
Imagine a scenario where your team is working on various aspects of the product, and one by one start seeking product owner feedback. As the requests and daily tasks accumulate, it begins to take you a day or so to respond. That’s not so bad, right?
Unfortunately, if your team has 14-day iterations, then one lost development day means seven percent of the sprint has been wasted due to this delayed turnaround time. Needless to say, that’s not ideal. Although the product owner’s job is to act as a single, dedicated source of stakeholder feedback, their primary focus has to be releasing high-quality software by deadline!
To adopt this mindset, the product owner and Scrum Master may want to adopt a “customer service” mentality when the Scrum team requests feedback. A good customer service department’s number one goal is to shrink response times from hours to minutes if possible. With that ideal in mind, make yourself available to the Scrum team in-person whenever possible, and help them get comfortable walking into your workspace with questions at any time.
3. User Insights are Essential
Q: What do developers know really, really well?
A: How to make software.
Q: What do developers probably know less about?
A: How to operate a warehouse, file insurance paperwork or anything else your stakeholders plan to use your software for.
Ideally, the product owner you bring on will already be equipped with industry expertise and domain knowledge, but that’s not always the case. If you’re a product owner who regularly works with new fields or comes from within the development team, nothing is more important than the time you spend understanding a product’s end users.
That means it’s essential for product owners to get inside the head of people who will ultimately use the product and:
- Reach out to users and find out what they like/don’t like about the product experience.
- Observe the habits of frequent users and take note of their unique operating actions and workarounds.
- Become an active part of the user community online to hear how people talk about the product to their peers.
When taking your findings into account, the backlog items you deem important may have to take a backseat to capabilities the customer base values. Though this can be difficult, creating a balance between what you know a product needs and what the users value, is an art all product owners must master.
4. The Team Occasionally Fails
Though the team might be ultra productive one sprint, you’ll quickly discover that this doesn’t necessarily predetermine success during the next. These fluctuations are neither good nor bad, but it does show that software development (at the team level) can be incredibly unpredictable. Despite these inconsistencies, as a product owner you’ve got to hone in on the team’s true workload, so you can plan effective sprints.
So how do we do this? Well one easy way is to think of it like this:
If the team delivers the first sprint with an actual velocity of 90 hours, and the second sprint with 110, what’s the average? Comparing velocity sprint-over-sprint will help you determine your team’s sprint capacity, and make adjustments as they start to work more cohesively.
With this information in mind, you should still note that a sprint’s success or failure isn’t as important to the product owner as the team’s ability to deliver product value. Don’t sweat the details too much and exercise the trust we talked about earlier. If the team occasionally fails because they’re trying new techniques, setting ambitious goals, and looking to improve every sprint, you will still be trending toward a faster, more efficient development process over the length of an entire release.
5. You are Not a Project Manager
Although your neck on the line as a product owner, you should not set the team’s schedule, worry about how they allocate work, or plan the sprint backlog. When it comes to the Scrum team, your only job is to set their priorities and provide valuable feedback. That’s it. If you attempt to control aspects of development past these levels, then frustration and unhappy teammates are bound to follow.
Here’s why: Planning the day-to-day details of development by individual task or backlog item is a complicated, in-depth exercise. Only team developers understand the full technical details of their work (because they’re the ones doing it), and have the experience to consider task-based dependencies, individual schedules, sick days, vacation time, etc. They’re also the best people to hammer out these specificities because they have a better grasp of each teammate’s strengths and weaknesses than any project manager, Scrum Master or product owner.
While it can be hard to let go, these intricacies have been giving project managers headaches for decades as they used the waterfall method. Letting the team oversee their own task execution plan will save time and make everyone’s life easier.
Takeaways
A strong product owner can be the secret sauce that separates great software development teams that amaze customers, from mediocre groups that simply push out releases. To ensure you’re being the most effective product owner possible, remember:
- Trust: Don’t be afraid to rely on your team to explain key items, so you can properly prioritize them.
- Serve: Adopt a “customer service” mentality, make yourself available in-person whenever possible, and be open to questions.
- Understand: Strike a balance between the features you know a product needs, and the capabilities users value.
- Relax: Don’t worry if the team occasionally fails as they try new techniques, set ambitious goals, and look to improve every sprint in creative ways.
- Let Go: Allowing the Scrum team oversee their own task-execution will save time and make everyone’s life easier.
Leave a Reply