Product owners don’t need to be technical to be good – part 2

In part one, I wrote about the myth of existence and need of technical product owners. We left our hypothetical PO at a party answering few questions around his or her product.

As we saw, the product owner needs to own the product knowledge base. If you are a PO and you wouldn’t be able to answer any of the questions listed in part 1, you’d better fill the gap, as none of the answers would require a technical background or a subject matter expert whispering an answer in your ears.

There are even more detailed and specific aspects that PO needs to be aware of, and not for all of these they need to know the answer.

PO is then responsible to convey messages and interests from all other stakeholders and transform requirements, practices, concerns, improvements and expectations in a list of product backlog item (PBI) ready to be discussed and worked by the team. An expert become capable of frame the problems in a clear, concise, useful way.

Each PBI should have a description, a value, an estimate and an order. PBIs can be categorized as User Stories or Tasks or Spikes, Bug or other types according to what suits best organizational needs. And it is clear that if the PO has the responsibility of assigning a value and a priority to each item, there cannot be multiple POs –or stakeholders acting as PO- conflicting and disagreeing on what is the highest priority.

And for the same reason, PO must know the value, must know how much time is worth to spend to implement or fix each functionality, component or improvement. PO needs to know the cost, importance, and impact of an architectural decision. Will that decision increase maintainability? Will it introduce extra costs or important delays? Will time be well invested? Will the solution be reused? Will the learning curve make sense for the team? Can we use internal skills and already approved software in order to avoid waste of time and money? Will the waste –any type of waste- increase? Is the stakeholder that push for a particular expensive or risky solution behaving in the best interest of the business? How do we measure so? Did the PO understand, verify and agree? It’s his or her role to keep the correct balance around all these aspects and take responsibility for required decisions. Right or wrong these decisions will need to be respected or the PO wouldn’t be accountable for them. PO listens all the SMEs but PO is the ultimate responsible for the product.

A good PO would bring these responsibilities to the next level and get ready to address questions at the next launching party.
Whilst respecting the team and SME in taking decisions on how to fulfil the requirements and what technology to choose, a good PO could pose some basic questions and understand the value of the answers.

For example: does the software store information? What type of information is going to be stored? System information? Product information? User information? Personal, commercial, financial, sensitive? Are these data processed and stored in compliant and secure way? Can the system assure at any moment they are reliable and consistent? No need to know specific laws or technical details to imagine the importance of these questions.

After understanding what type of information will be in the system, why not asking how they will be organized?

Are they structured on unstructured? Are they files, images, videos, documents, record in a database? Relational or not? What is the consistency model: ACID, BASE? Is information persisted? Is it lost if the system resets or malfunctions? What are the legal or financial consequences? Is there a content management system? What are the inputs and the outputs of the system? Can data be imported or exported? Printed? If so, which format should be supported? How often the system be updated? How will the users be trained and educated to use the system for the correct intended purpose? How to spot misuse or abuse? Exploit and breaches?

What is the right balance between value and complexity when assessing features priorities? What are the must-haves and what are the nice-to-haves? How much will it cost? Is the software maintainable? Do we introduce innovative solutions or we keep supporting legacy code?

Although it will be on the team and some stakeholders to propose, provide and implement solutions, the PO will assess –with other parties- if it is economically acceptable or not.

Again, not technical skillset or detailed solution is expected from the PO. Only willingness to understand the full package of what it means taking ownership of a product.

If you are a product owner or a product manager, be aware that your work is not about receiving high-level epics and break them down into stories or tasks. If you were thinking that managing or tidying the backlog was what you had to offer and nothing more you have no more excuses to change your mind, take ownership of your role and improve.