POs should write explicit questions with decisions to structure the conversations around new features

This is the second article in a series on how the best Product Owners manage to get on top of their refinement process. The insights come from interviews and close collaboration with ~150 product owners from across tech.

A Product Owner is responsible for the 3Cs, Card – Conversation – Confirmation.

Most POs share the Card (story ticket in Jira) and the Confirmation (written acceptance criteria and/or attached reference designs) with their developers.

In an ideal world, the developers should also have been part of the Conversation, or at least the PO should have shared it with them, as that would provide them with relevant context, empowering them to make sound judgment calls and removing the PO as a bottleneck.

But oftentimes the developers have not been part of the whole Conversation. And in sharing it with the developers, the PO faces the problem that the Conversation does not naturally occur in a format that is easily digestible. The discussion that lead up to a decision is instead often spread out across many emails, chat threads, and meeting notes – if it is at all written down.

As long as this is the case, it is not feasible to share the Conversation, as it could take hours for a developer to go through it all, and even then, it might not be possible to extract sufficient context.

That is why many POs only share the Card and the Confirmation with their developers.

But the best POs make an effort to have a condensed representation of the state of the Conversation. In its most simple form, this is something that all POs should do. They should have one place for notes relating to each story, a shared living document or maybe an area on a wall.

Some POs attempt doing this by writing neat documents with formatted text in full paragraphs. But it is unnecessarily hard and time-consuming to try to capture the discussion and formulate the rationale for why a decision was made in that way. The result of this tends to be long and complicated sentences containing “based on”, “having considered”, “on the other hand”. This is a wholly unnecessary effort, as these sentences are not only hard to write, but also hard to read.

We believe that POs should instead use a bullet outlining tool, to structure the conversations around new features, and simply write down questions as bullets, with options as sub-bullets, and pros/cons below that. That way they can get maximum speed and simplicity by formatting neither text nor grammar.

Once they have that structure, they should be vigilant to continually capture and add whatever questions are raised that is related to that feature and also fill in different discussed options, pros, and cons – and of course decisions made. These should be added, not as full sentences and paragraphs, but as concise and to-the-point bullet points.

This way is not only faster to write, but putting the Conversation in this format also makes it much easier for the developer to digest.

The format is also easy to digest for the stakeholders, and so allows the PO to assign and follow up on specific input, (LATER: not to mention, it will also save the PO a lot of time in the end).

Delibr is an outlining tool for product owners that helps them handle the conversation around new features.

It aims to help POs bring structure and cohesion to a conversation that is often disjointed and split across email/chat/meetings by explicitly capturing questions with decisions.