Top 5 tips for new product owners
If you get stuck on the practices, you lose sight of the principles.
Last week, I had the opportunity take the two day Certified Scrum — Product Owner training with LitheSpeed’s Arlen Bankston. Arlen’s experience with agile practices stretches over two decades, so he had quite a bit to share. And naturally I had a lot to ask.
Though I’ve never held the role, I’ve worked with several product owners over the years. Their participation, guidance, and support are instrumental to a product’s success. Sure, there are instances where product teams are self-sufficient and can largely exist without product owner direction, but that’s a post for another day.
Like many classes, Arlen had homework for us. At the end of Day 1, he asked us to come up with a tip for the product owner. We had just one rule. The tip had to be formatted similar to the values in the Agile Manifesto (think A over B).
I had trouble picking just one. We had discussed the product owner roles and responsibilities from many angles over the first day. That, coupled with years of daily product owner interactions, left me writing numerous tips off the top of my head. Through the chicken scratch, here’s what I gathered.
1 Translate over Transcribe: Being the conduit between business and the development team is tough work. Requirements intake from end-users can often lead to a long, tightly scoped wish list. One way to manage the competition between these requests is to identify similarities.
The next time you receive a backlog item from an end-user, ask why. Even better, have the user show you their current state of operations. This reveals the context to translate the need, draw similarities, and have conversations with other end-users to see if they would also benefit from the proposed backlog item.
2 Objectives over Requirements: Objectives eat requirements for breakfast. A product owner who sets an objective gives the team a healthy level of decision-making power.
Setting objectives is one way to motivate teams and help them reach their full potential. It has the ability to increase moral, decentralize decision-making, and improve the product. Most importantly, it causes the team members think about, discuss, and set their own requirements. Teams who can set their own requirements will build a simple and maintainable solutions. Why? It saves them time and energy.
The move from requirements to objectives doesn’t happen overnight. If the team has been built and optimized for development activities (not requirements elaboration), then there may be an initial hesitation to take on this new responsibility. As a product owner, your role is to embrace this change. Let the team know you are there to answer questions. Test the process out on a backlog item that has room for interpretation. Ask the team to come up with a set of requirements. If needed, set a limit for the total story points you’d like to invest in reaching the proposed objective.
3 We over Me: If you’ve ever attended a standup, you are familiar with their most common format. Each member answers the following:
- What did I do yesterday?
- What will I accomplish today?
- What are my blockers (if any)?
But isn’t that against the going against the grain of agile? We preach cross-functional, self-forming teams. But when it comes down to it, we talk about ourselves every day during standup. As a product owner, you have the ability to shift the conversation from “me” to “we.” During your next standup, ask the team to pull up their Kanban board. Then, ask them to only focus on items that moved to Done in the last day. After all, that is what the product owner wants to see.
Next, ask the team to focus on what items they anticipate move to Done today. And finally, ask what dependencies need to be managed in order to achieve daily committed items.
From this simple switch, the standup becomes less of a status pulse and more of a team huddle. The questions become:
- What did we move to Done yesterday?
- What do we anticipate moving to Done today?
- What dependencies exist and how will we manage them?
The “we” over “me” approach doesn’t stop there. Weave the word “we” into your vocabulary, emails, etc. to continue to build the strong team mentality.
4No over Yes: Saying no is both the hardest and the most useful thing a product owner can do. The backlog isn’t an infinite wish list. Treating it as such can undermine end-user engagement. It can also lead to an operational headache managing a list of hundreds of requests.
Agile is largely built on a pull system. Items are pulled (rather than pushed) along from conception to implementation. Having a push system for the backlog and a pull system for everything else naturally leads to disruption. Saying no is a way to combat this disruption.
During the CSPO class, there was an analogy made to the unorganized, cluttered kitchen drawer. You know the one. And you know how difficult it is to find something in that drawer. The same thing happens with a product backlog if everything that is desired ends up on the backlog. If everything ends up on the backlog, end-users will naturally ask “When will I get this?” Your time is better spent doing things other than answering these hypotheticals.
If no is too strong of a word, try “Not yet. Could you follow up with me next month if this is still a priority?” Most requests will fall by the wayside.
5Provide over Present & Present over Describe: Yes, I’ve taken the liberty of putting two tips together. There’s a bit of a tiered approach here. Stay with me.
Agile in a nutshell is all about building a product in an iterative, incremental manner. Building a product incrementally allows for feedback. And feedback help us steer the product toward success.
But the feedback that is received depends on how the product is provided, presented, and/or described.
- Provided — the user has the system in their hands, can test the system at their convenience
- Presented — the user sees a demo of the system, may or may not have ability to steer the demo in one direction or another
- Described — the user is told what new functionality has been added to the system
Imagine for a moment you are buying a car. You want to see it, right? And even better if you can test drive it! You don’t care so much if someone were to describe the dimensions, color, or air-to-fuel ratio in the carburetor. Imagine providing feedback on enhancements to a vehicle you didn’t test drive… it would feel quite strange.
The same can be said for product development. Providing a system to end-users at the end of a sprint, rather than conducting a demo or describing the new functionality, is one surefire way to get the right kind of feedback.
You can take this a step further by asking that the team incorporate visuals and mock-ups into their Definition of Ready (DoR). In fact, wireframes and lo-fi prototypes were the early bricks on which design thinking practices were built.
My call to action.
Bring these tips to your next retrospective. See which can be incorporated in the near-term. Make it happen and come back to let me know how it goes!
