The Gatherer mainly focuses on gathering as much information/feedback from stakeholders as he can. This helps him build a direction for the product for a specific period of time. Although he gets new requirements, features and requests, he strives to keep the direction steady and aligns new requirements to it. Together with the team, he prioritizes the backlog consequently. This helps him ensure that the direction is clear to the team.
The Gatherer keeps a personal log for all the possible long-term features that could be implemented in the product. He notes everything down regardless of whether the come from from customers, or by comparing with other similar products in the market. As soon as one of these features is barely considered valid for implementation, adds them to the product backlog and discussed it with the team.
He insists on frequent grooming sessions; they keep everyone in the team informed and mentally prepared for the forthcoming tasks. Moreover, grooming sessions keep the backlog clean and optimised, since most of the old issues would have been already solved and need to be deleted or rephrased.
The Gatherer always tries to keep the team involved. At the regular meetings with customers, he usually summarises the notes and shares them with the team. Likewise, he tends to convey the feedback from stakeholders (positive or negative) about the development process, the quality of deliverables, and their expectation to the product and the team.
As a Product Owner, he believes in the role as responsible for defining the product path. That is of course after analysing requirements, business needs and use cases. He has established a strong relationship with the customers, based on mutual trust and sending a clear signal that he takes product ownership seriously.
This post concludes the series about different flavours of a Product Owner.
If you look up “complete ownership”, there’s likely to be a picture of this Product Owner. He identifies with the task at hand to an extent that it requires the most stern-hearted 1940’s British nanny to not be won over to his team. If he believes in something, there’s no doubt that he will run in front to get to the finish line. He has a knack for formulating visions and goals which are both ambitious and attractive.
His greatest strength is also a challenge: his own buy-in means he has to work hard to get a similar sense of ownership in the people he works with. He manages this by being really well prepared for any conversation where he suspects it might be necessary to defend a decision or align expectations.
The Buy-in has a knack for selling. He’s not the traditional salesman with well-honed skills of persuasion, but rather he makes a choice. A very conscious choice to trust his own buy-in. A choice to believe in his buy-in and an admirable ability to accept that it is necessary to thoroughly understand those who don’t share his devotion before he is ever able to enjoy their support.
The moment he feels even the most subtle signals of agreement, he sets all sails and his unwavering enthusiasm becomes apparent.
When structuring the backlog, there’s calculated strategy involved. In his case, it’s the communication strategy which prevails. If he can successfully communicate his reasoning for priorities, he feels that the prioritisation is right. This forces him to consider both his customers and his peers and he must make an effort to understand their expectations and perspectives in his work.
In the next post, we’ll look at The Confident PO.
This is the second installment of the series about flavours of a product owner.
He does so because it helps him get closer to defining the value that a user story or an epic represents. He understands that users often create their own detailed mental model of a system, which is somewhat removed from the implemented model. Both the questions he asks and the answers he gets, help him discover the users mental model, and translate that to value described in user stories and epics.
To do this, he plays the “Why?”-game.
When a user tries to communicate what he wants by describing his mental model of the implementation, this POs most common response is asking why the user feels he needs the feature and asking for clarification on what the user hopes to achieve.
By asking, he is be able to identify the use case behind the request, and perhaps more importantly, the real value that the user is looking for.
With a clear idea of the required value, he can author user stories which focus on the desired value.
He can use this to communicate with the team without having to discuss implementation.
This empowers the team to design the implementation and deliver the required value with as few constraints as possible.
During the course of development, the team naturally encounters areas which require additional business input and decisions. The Inquirer makes an effort to return the teams questions and will aim to use their very extensive knowledge and understanding to return to the core value of a given user story. Does the team feel that one or another decision will contribute to delivering the value?
Is there any chance that this PO will also deliberately end a conversation with a question?
Next week we meet The Buy-in.
tl;dr Make sure to talk about why you do the work you do and what the value of said work is.
Historically, we have had several teams working on separate components (stand alone products at the time) for one of our products. The choice of organising in component teams was natural evolution of people’s interests, how we group in the offices and how the separate products grew, before turning into components for a whole product. It might even be a related to Conways Law.
Now, as these components are merging into one single product, several pains are now manifesting.
The obvious pitfalls with component teams, like communication on related work and integration testing was handled as best as we could. To minimise the impact of these pitfalls, we tried to coordinate between teams so that related Stories were being worked on at the same time; Hopefully minimizing how much we impede each other and our turnaround time on issues found. Unfortunately, this approach took control of the work to be done away from the teams, and still duplicate work and uncertainty about responsibilities was prevalent.
Previously, much of the work being done has been described with a focus on the functionality (the what) and technical solution (the how) and more often than not, the value (the why) provided would slide into the background. We would all sorta – kinda know why, but our conversations tended to be more about the how. This approach has worked well with component teams, as the tasks describing changes to the components were technical by nature – with focus being on the what and how. But this does not invite discussions about the why.
We would like to increase visibility of the value we deliver and foster discussions about the why. An important step in doing so, is actually talking about the value of the work we do. When we talk value, we talk about it in the broadest sense. We ask questions about the kind of value a given Story adds or subtracts. Does it add value for the user? How about the customer? Could the perceived user value could be achieved in another way? How about the strategic value? Does that influence the customer value? All valid questions and the conversations stemming from these is what we want to have more of.
The introduction of the value-driven Stories did not happen overnight, but it has been a gradual shift in how we talk about the work we do. An interesting side-effect of the value-driven Stories is that it became natural to talk about Stories across the product without being specific about each component. So how did that work with our setup of component teams? The flow for a value-driven Story ended up looking something like this:
“But wait”, the observant reader objects, “is a component story then really a value-driven Story?”. No, no it is not. The component Stories are more like technical tasks.
I’ve touched on some of the pains we were experiencing with component teams. Given these pains, we had known for some time that feature teams would be an interesting change. But the final push came from the move towards value-driven Stories. In the above model, the conversations about value were happening between all of the involved people when discussing the product as a whole. But as the component stories were about the what and how, the conversation died in the day-to-day work for the teams.
So we started a journey towards feature teams. For us, feature teams mean that all teams are able to commit to a Story from the backlog and handle work responsibly across all components. We have only taken our first steps on this journey and there are still lots of quirks in how we organize around the feature-driven Stories. We have already had the first wins, like the teams aligning on various agreements around the whole product, such as quality and Definition of Done. It has also fostered communication between teams, as each team has limited knowledge about the other components.
But most importantly, we are now having conversations about why we are working on a Story, and what the value is, on a daily basis. That, I think, is a success.