What makes us unique as Product Owners?
What defines and characterises each of us?
In the coming weeks, we will try to characterise how we are different as Product Owners in our organisation in order to highlight the quality of variety. By identifying our differences we can work better to support each other – something which is easy to overlook outside the traditional scrum team configuration.
Whatever your title, I’m sure you do your job differently than anyone else with that title.
What you focus on is the result of a combination of things: varying expectations (from boss, colleagues, self) or a preference for some specific tasks – probably those where you experience success more often.
Sometimes, you place your focus where you feel the need to improve.
Most important of all, you contribute where you feel your contribution is valuable. If there’s an unoccupied space that you think it would make sense for you to step into, you do it. You claim ownership of that space and do your best with it because you feel it’s the right thing to do at that time.
As a Product Owner in a truly agile organisation, you get to make a choice about where you want to place your focus at any given time and provide value to someone. One minute you are working within a development team and the next you are aligning with a customer, trying to make more sense of what value they are actually looking for. To build a useful network and gain more understanding of the product in full, you spend time in the server room with an admin installing hardware and deploying software.
The above tasks are all vastly different aspects of crafting software. All of those things need to be done to make it in our game, but nobody expects anyone to do all of it. That’s why we work in teams.
We are currently 5 Product Owners working with each our product. Some products have overlaps and collaborative opportunities. Others don’t. Regardless, we can use each other and our differences to become better at our jobs and create better products.
Working in a team doesn’t apply only to developers, testers and devops:
That is why we are trying to be a team of Product Owners.
In forming ourselves as a team, we have discovered that we have vastly different interests, skills, experience and focus, which we can use to help each other and deliver more value, faster. Just like a team.
To get an idea of how we complement each other, we are working with identifying what makes us unique as Product Owners; what defines and characterises each of us. In addition, it’s also an attempt to show that none of those unique qualities are better or worse than any other. Rather, it’s to encourage that everybody benefits from us working as a team.
The Visual Product Owner has an ability to put himself in the users’ place. He thinks visually and spends time generating ideas and designing an experience for the user. This makes it easier for him to communicate the value to the team.
He has a challenge: suggestions for implementation can easily be construed as dictating a solution to the team, so he has to ensure that the experience he designed in his mockups are perceived as suggestions from someone who cares intimately about the product.
He spends a lot of time producing social glue and listening to what the team says about priority and product. As a positive side-effect, he is included in the team to a great extent.
To ensure there’s no doubt about responsibilities, both he and the team sometimes address him explicitly as “PO” when a Product Owner decision or opinion is required. His personal opinion is not always the same as his professional Product Owner opinion, particularly when it comes to prioritisation.
When working on the backlog, he looks through what is in the top third-ish and make sure that each user story has a clear description of value using the syntax:
In order to <value>
As a <stakeholder>
I want <feature>
He looks only as far in time, as he can couple with events in “real life”, with the reasoning that: “If I don’t know what I am doing in my spare time 3 weeks hence, it’s likely to change anyway”. It’s the same with the product backlog. Things beyond the structured top of the backlog are constantly subject to change.
Epics are used as a tool for grouping. The groups can be prioritised and the priority of the epics help when working on the backlog. User stories from different epics can easily be worked on at the same time. The epics are more a tool for managing stakeholder expectations to when delivery of specific work is planned.
Next week, we’ll look at another flavour: The Inquirer.
Kickstart your new agile project using these 4 simple steps.
It will ensure alignment between stakeholders and project team at kickoff and help establish a foundation for an agile team working in an environment with open and honest communication.
Step 1: Preparation
Help stakeholders state their expectations for the project and team
Expectations from the stakeholders should be:
Strive for simple and positive statements that address expectations to deliveries, mandate for the team, the team attitude and collaboration with other parties.
Iterate until all stakeholders are aligned and committed to the expectations stated.
Step 2: Kick off meeting
Share stakeholder expectations with the project team
One of the stakeholders presents the expectations to the team. Allow ample room for questions and comments.
If this leads to confusion about the expectations, stop and revisit step 1.
The team coach or one of the team members makes sure expectations are noted for future reference.
When all team members have understood and acknowledged the expectations, proceed to step 3.
Step 3: Team building
Let the team meet and share
Do team building exercises.
Struggling to light fires in the rain and building bridges in your underwear: no. Figuring out how to work together in the workplace on workthings: yes.
It is important to share knowledge about competences and skills within the team in this step. Align expectations to relations, roles and working agreements within the team.
Use activities like Market of skills, Ability Spotting and other team coaching techniques based on systemic practice and appreciative inquiry.
Step 4: Team to action
Find team values and working agreements on how to meet the expectations
At this stage the team knows what is expected of them. The team members know each other and understand how they can support each other. Now it is time for the team to state how they envision to meet the expectations from the stakeholders.
Refer to the expectations stated in step 2. Explore past positive experiences in the team and help the team state a vision for their shared future, as they would like it to be when they meet the expectations. Let them use that vision to decide on actions, rules of engagement, working processes and so on.
Aim for the simple and operational. Build in reflection and feedback loops.