April 26th, 2016 by Christian Hauschild

This is the third installment of our series of blogposts about different ways to be a PO. For the previous posts see here for part 1 and here for part 2.

The Buy-in pwns

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.

Don’t do it if you can’t sell it

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.

You really have to talk to someone about this

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.

Now hiring in Dubai! - Read more

Posted in develop software, process Tagged with: , , , ,

April 19th, 2016 by Christian Hauschild

This is the second installment of the series about flavours of a product owner.

The Inquirer asks a lot of questions.

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.

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.

Talking to the team

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.

Now hiring in Dubai! - Read more

Posted in process Tagged with: , , , ,

May 13th, 2015 by Christian Hauschild

Asking questions is a “free for all” – at least where I work. Even further, it’s expected that you ask questions. Not because you yourself need answers but because everyone needs the answers – even the people who try to provide them.

Agile testing is one of the most explicitly pronounced mindsets for asking questions and a primary practice is asking questions early and often. It helps clarify the value in the work we are setting out to do and puts perspective and reason behind our choices.

Simply asking: “why?”, is possibly the most powerful tool you can use to gain clarity of purpose and value.

Developers are good at this. They continuously need to align with their surroundings to ensure that they share an understanding of the value they are supposed to deliver and can meet or exceed the expectations to what they produce. The implementation should on all levels reflect the value described in the user story/epic/feature, and developers know that asking “why?” helps them make that happen.

Product owners can also use this tool. Some use it a lot with clients. They know that the developers are going to present a wave of intelligent questions centered on “why”, so to be sure that a user story description already contains many of the answers, a product owner spends considerable time asking the client in turn.

That’s outward facing, the way many product owners are used to working. With more focus on asking inwards, a product owner can get much better at prioritising a backlog containing a potpourri of value from any conceivable direction.

An example is technical user stories. It’s generally accepted that these are necessary and there’s nothing to do about that. I would argue that if a product owner practices the why game with the team, technical user stories can be both non-technical and in turn make it much easier for the product owner to prioritise them. Everyone wins:

“Uhh, technical user stories. We need those!”, says developer.
“Yeah, it’s prioritised.”, says product owner.
“But…”, continues the developer “it’s right at the bottom?”.
The product owner clarifies: “Like I said, it’s prioritised. It’s more important to deliver customer value than do gold-plating of an implementation.”
Offended, the developer argues: “You just don’t understand it. It has nothing to do with gold-plating. It’s clearly value.”
“Why?”, says product owner.

Granted, the product owner probably knows that there’s user value there. He just can’t articulate it because he relates to the business side. The developer hasn’t yet discovered the user value because he needs someone to ask him “why?”.

Two colleagues, literally on the same team – searching for the same but from opposite directions, can meet where the value is, but simply asking “why?”. Everyone wins.

Now hiring in Dubai! - Read more

Posted in process Tagged with: ,