Product Ownership (2)

Continuing on my earlier post about Product Ownership, I wanted to dig in a bit more in maybe the most obvious of the items on my list.

"A deep understanding of the problem".

The product owner is the main point of contact for all stakeholders. In most projects these are a set of very different profiles, ranging from high-tech to no-tech and from senior VP of directors to working class heroes. In order for your product owner to communicate well with all those parties he needs to be able to give the executive summary of a project, but also to have detailed discussions about problem areas.

Imagine the following scenario. A simple project (if there is such a thing) to develop a piece of data displaying software to track impact of press releases. Your main 3 stakeholders are a senior marketing executive sponsoring the project, some junior on the marketing force who will be mostly working with the tool but hasn't got any skills beyond viewing a form in access, and a data analyst who is used to slicing and dicing data with custom scripts and queries.

In order for your product owner to be able to effectively communicate with all these people he needs to be able to give the executive summary, work with the junior in understanding his requirements and translating these into backlog items and, lastly, working with a data guru who thinks in hooking custom scripts and plugs to that output and cares about APIs that should be in there.

These are, in my opinion, 3 completely different approaches to be taken. Perhaps the executive summary could be winged with less understanding of the problem, but that would definitely harm the credibility of the project. Working with the junior may require mostly listening and trying to slot his requirements in a timeframe that would suit him best at any given time. The last one will delve deep into the technical aspects. Some of these requests are better taken up with the developers, but the product owner should at all times be a first point of contact in order to shield the development team from deviating from sprint tasks by outside requests.

In order to do all this, there is no way the product owner will get away with having a high level overview of what the product is supposed to be. He will need to filter out requirements, talk stories through with developers, give regular feedback to his stakeholders and really be just as involved as the development team in order to reach the goals of this sprint.

Since the product owner is equally committed and involved, and will stay involved during the entire project, replacing him is something that would add the same amount of troubles and overhead as replacing anybody in the team. The problem with replacing a product owner is that he is a first point of contact and the "external" interface. Meaning that he doesn't have a lot of margin to slip up. Any slip up, miscommunication or doubt in understanding the project may (and usually will) result in confusion, angry stakeholders, a mess as to who is the actual product owner. And especially that last part is concerning. One of the most difficult tasks to handle, speaking from experience, is having a lot of channels that are all directly talking to the development team and setting their requirements. The development should focus on development of whatever is needed. It's not up to them to make decisions about what is a priority to the business. And doing so requires a strong product owner, who understands the problem at large.