It’s not easy being a Product Owner

At Digiterre, the Product Owner (PO) is outside the Development Team and is a member of the client team.

Generally, the PO is responsible for clearly expressing the requirements to a sufficient level of granularity for the development team, conveying these into a backlog, ordering these items in terms of business priority and then realising these in terms of business value from the work that the development team deliver.

Requirements – we usually talk about “gathering requirements” as if they are simply like ripe fruit scattered on the ground however in reality it’s more about “requirements elicitation” – teasing out what the PO (and ideally what the users) want, it can be more like fishing or hunting than strawberry picking! POs may often present their requirement as a solution rather than as a problem to solved, the old adage of Henry Ford suggests that if he had asked his users what they wanted, they would have simply asked for a faster horse…

This can be understood via active listening, asking questions (without having a solution in mind, using the 5 Whys for example (https://en.wikipedia.org/wiki/5_Whys), phrasing the problem in terms of wants and needs, guiding prioritisation (via MoSCoW analysis for example) and then finally identifying themes (epics) and scoping (phasing).

A common way of writing requirements is as User Stories, with an As a <type of user>, I want <some goal> so that <some reason> to express intention and then accompanying Acceptance Criteria to understand when a task is Done. Another way is to write in Gherkin syntax, (Given, When, Then) : (Given) some context, (When) some action is carried out, (Then) a particular set of observable consequences should result.

More mature requirements will also feature non-functional considerations, such as speed, responsiveness, availability and scalability, for example.

In whichever ways these requirements are locked down, the key is to present your understanding as clearly and as rapidly as possible. These can be via artefacts such as wireframes, mockups, prototypes or even logical architecture. Inspect and adapt. The quicker that’s done, the quicker it is to course correct and get an accurate understanding of what needs to be delivered.

Beyond requirements, the PO will also take part in ceremonies such as the Iteration Planning, the Review and make an appearance at standups. However what happens when the PO cannot (or does not) have the time or inclination to participate in these interactions? Well, one way is to assign a Proxy Product Owner inside the team. The PPO has the role of being team contact for all of the ceremonies and their responsibility is to be in sync with the Product Owner. They may do this via meeting with them when the PO is available and being a point of contact for questions from the development team as well as useful information back from the PO. They do not necessarily need to have all of the answers immediately, but only to facilitate getting these from the Product Owner.

Illustration credit: dilbert.com

There is a lot to Product Owner / Development Team dynamics and to the careful curation of requirements. Each of the paragraphs above can serve as a jumping off point for hours of conversation, however the key takeaway is that: requirements are hard and even though everyone loves the Development part of being a Development team, getting an understanding correct is a vital part of the software development lifecycle.  After all, people do not know what they want, they know what they do not want and they are usually quicker to mention that.