In 2019, I wrote about how a product owner succeeds in their work with the help of the development team. I gave a talk about this in an event in spring 2021, and in this blog post, I’ve gathered the tips I gave in my talk on how the development team can help their PO to succeed.
In my talk, I claimed that development teams often expect too much from their product owner and can easily feel disappointed in the PO’s work. In order for the PO to be able to succeed, the development team plays a key role. It’s the development team’s job to set up goal-scoring opportunities for the PO, so that the whole team can reach the project’s goals together.
Perhaps our expectation of a 100% dedicated PO with a firm grasp of agile product development is simply too much – at least until all digital development is thought of as product development that takes professional PO’s to facilitate it.
At Vincit, one of our defaults is that the client names a product owner within their own team. Our project lead and the PO on the client side form a pair that works towards our shared goals. It often takes a coaching approach before the product owner’s effort matches the team’s expectations and enables success. It’s also vital for anyone taking on the PO role in a development project to evaluate how well they can answer the development team’s needs. The load of other tasks and responsibilities, previous know-how and the passion to learn a new role are essential aspects to consider.
When a new product owner and development team start working together, everyone has plenty to learn. My tips list below isn’t all-encompassing, but these are some of the things that I’ve come to face in my own everyday work. Feel free to drop a comment on LinkedIn or Vincit’s social channels if your toolbox contains other good ways to help product owners.
1. Before you can help, get your own act together
Before a team can ask for a PO to help or coach them, they must first clarify their own ways of working. How should the team work and how do they want to work?
What kind of methods are suitable for this particular project? What does ”ready” mean in this project? When can the team start working? How do we track progress towards common goals? What does agile development mean for us in practice in this project? Why do we do these things and how do we develop our own work?
Sometimes, for some reason or other, teams choose not to give these things a thorough think. In this case, a good enough solution could be to ”pick a recipe out of the cookbook”, (e.g. Scrum) and stick with it. It’s worth remembering, though, that a noodle soup is a long way away from a nine-course dinner. There is no ”right recipe” or one-size-fits-all solution, and as the team gathers experience, everything needs to be adjusted according to the project’s needs.
2. Work on empathy and find the product owner’s win conditions
”We need user stories, write us some user stories!”
It’s easy for a team to make demands to the PO, but do development teams actually truly understand their product owner?
If a development team is committed to helping their product owner succeed, the team will find out about the PO’s other responsibilities, goals, contents of their work week, hobbies and other essential win conditions. What factors enable success?
It’s worthwhile for the team to develop empathy towards the product owner. After that, their demands are likely to be more appropriate and will more likely get the desired response.
Imagine this: what if you changed jobs with your product owner for a week? What would you learn about each other?
3. Answer expectations by crystallizing roles and responsibilities
Especially in a bigger project, it’s a good idea to openly write down people’s roles and responsibilities. The good old RACI matrix can be a valuable tool to help widen narrow bottlenecks and improve information flow.
Once roles and responsibilities have been clarified, everyone knows what is expected of them and what they should expect from others.
The article PM and UX Have Markedly Different Views of Their Job Responsibilities presents an interesting example on presumptions about other people’s roles. The article dives into a 372-reply survey about how differently product management and UX design see each other’s tasks and responsibilities. If roles are not clarified, the team’s work is based on assumptions, and before long, they can end up cleaning up big a mess.
4. Create a timetable that fits into the PO’s space-time continuum
Get together and make a timetable that is realistic enough to fit into the PO’s space-time continuum. A full day of sprint reviews and planning every 2 weeks can be a deadly demand for a PO.
If it’s impossible for the PO to commit to set sprint sprint meetings and cycles because of, say, client meetings, are Scrum cycles the best way of working for the team? Would a Kanban style flow model with short weekly goal meetings and mini retros be more suitable?
However the team decides to work, on top of repeating rituals such as demos, retros, design and backlog checkups the team must reserve enough time together for mining and chewing information and clarifying specs. It’s worthwhile to mark down time for the topics of information gathering and processing sessions somewhere in the near future. This way, the team always has development work that advances the project’s goals.
5. Build a product owner team
If, despite scheduling and reorganizing other possible responsibilities, the PO doesn’t have enough time to dedicate to the project, it’s time to get help.
A product owner is an institution.
”Institutions are constructions and mechanisms of social order and collaboration that guide the behavior of two or more individuals.” Source: https://fi.wikipedia.org/wiki/Instituutio
So, a product owner can have ”minions” that form a team together. At the end of the day, the PO is responsible for maximizing the value production of the development investment. Some PO tasks can be delegated, but this requires the product owner team to agree on common rules and practices for smooth information flow.
For example, if the PO doesn’t have the time or the skills for evaluating user story acceptance criteria, collecting user or customer feedback or concepting new features, which of these tasks can be delegated to the team? In this situation, UX designers are worth their weight in gold to the PO’s in gathering specs, validating and communicating to the team – they definitely are a resource to be utilized.
If the PO doesn’t have the time to clarify, crystallize and communicate, it makes sense to smartly delegate and focus on making decisions, digging up answers and removing obstacles. This way, the team can continue their development work despite the PO’s challenging situation.
6. Allow the product owner to focus on storytelling
From time to time, we see situations where the PO talks and the team eagerly listens and discusses the matter at hand.
However, nobody’s taking notes, drafting a user story or listing acceptance criteria. For many of us, simultaneous talking and writing can be really challenging, resulting in one more item on the PO’s to-do list for the evening.
All of us can write, though! Maximize the usefulness of the PO’s time and let them focus on storytelling.
There are other ways to make communication easier between the PO and the development team, for example:
- speak a language that the PO can understand
- create a common business lingo
- explain and list the strengths and weaknesses of each solution proposal
- draft illustrations to support conversation and memory
7. Clear your development backlog with a Story Map
Once the team and the PO have clarified project goals together by e.g. crystallizing vision, KPI’s and development road map into a presentation (which the PO uses for internal sales in their organization), it’s time to roll up the sleeves and tackle the development backlog.
However, time tends to stretch and swell up the backlog, making it even practically impossible to refine and manage it.
”I don’t understand these stories, what do they relate to? I can’t find anything here. Where’s that ticket from last week?”
When you walk deep enough into the forest, it’s easy to lose the forest for the trees. But like a professional forester, a PO and a development team have access to different tools that help evaluate their site. My absolute favorite is User Story Mapping, a tool that brings the stories back to the user’s context and clarifies the order in which development should be done. Here are a few links:
- Mapping User Stories in Agile
- User Story Mapping with Jeff Patton
- Story Mapping in UX Knowledge Base Sketch
Image © Krisztina Szerovay — www.uxknowledgebase.com
8. Offer help outside your own territory
Sometimes you might end up facing a situation where you need to figure out how you can help the PO outside your own professional turf. Can you reinvent yourself, step out of the limits of your role and out of your comfort zone for the common good?
If you decide to do this, immediately put a notification on your calendar for a ”sanity check” in, say, a month or two. Are the things that you’ve done to help the PO something you want to continue with? Is this sidetrack taking you towards your calling or away from it?
Often we tend to do things that we can succeed at and that make us feel good, but in the long run, they can take more than they give. Check out my colleague Juha Riipi’s blog post about the mysterious meaningfulness of work and take some time to really think about your calling, especially if you’re feeling sidetracked.
It could always be that being a product owner is your true calling. However, it is not a role you want to end up in without being aware of the complexities and challenges that come with it!
+1: Play with an open hand and build trust
The common ground and a good working buzz between the team and the product owner can only be found if everything, including the challenges of the project are discussed openly.
However, at the beginning of the project, the trust and feeling of personal psychological safety that are necessary for these conversations might not yet exist. Building trust by exposing your own vulnerabilities at the beginning of a development project may feel too bold – even inappropriate.
In time, cooperation will create trust, but schedules often force us to just take a leap into the unknown.
The team will help keep the PO’s head above water – or they will drown as well.
