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

Today I want to write about the product owner (PO) or product manager (PM) role and not to provide a definition or list responsibilities but address a specific myth.

This is an expression used not only by POs themselves but also by teams, business analysts, architects and other stakeholders. Any of them, have different views and different reasons to bring up the mythological figure of a technical PO. 

Some POs may even use these as a justification to avoid taking ownership of matters they are not passionate of, they think they are not responsible for, they are not sure about. Rather than improving in their role broadening their knowledge of various aspects around a product, it is easier to say that some topics are too technical for them.

Spoiler: you don’t need to be technical to make the right questions around your product. Framing the problem and have a 360° view of a product don’t require technical abilities. Don’t even require understanding technical solution founded by team. Still it requires understanding the value of the implemented solutions and the impact that technical decisions have on the overall business.

You may have experienced sometimes teams making some questions and the PO saying “well that’s up to you, that’s a technical decision”.
Whilst finding solutions and creating product increment is team’s responsibility, having the awareness of their value and consequences for the product is still undoubtedly among the PO responsibilities and no technical skills are required for that. Any product will have different characteristics afferent to different areas. POs don’t need to be expert in any of these, yet they should own the entire product and these areas aren’t excluded.

Imagine for instance a PO saying “I’m not a legal expert, so whether my product should fulfil data protection laws and requirements is not my responsibility”. That would be a very narrow, perhaps even a dangerous view.
On the other hand you may have subject matter expert such as business analyst, security engineer, architects, UX experts, delivery managers whose work would impact the product, whose decisions will effect the product release timeline, costs, future decisions. PO needs to talk with all of them, understand their perspective, the costs and business values that their proposals add to the product. These stakeholders need as well to understand and respect the PO role, cooperate with PO to achieve the necessary clarity of business and non-business requirements, functional and non-functional acceptance criteria.
This is valid not only for the technical characteristics of a product but also for the legal requirements, sales proposition expectations, marketing and branding policies and requirements, financial expectations, licensing model, price strategy.

POs don’t need to understand technical jargon for each specific part of these areas. Understanding10-20% of their plain language should be able to transform any requirement in something useful for the team and understandable from an end-user or an external auditor perspective. Framing the problem that your product should solve doesn’t require you to be a global black belt in any particular subject.

Any PO should be able to address high-level questions from whoever is going to pay for the product or has an interest in it. If you are a successful PO, imagine yourself at a Version 1 launching party, surrounded by different background stakeholders asking questions like:

What problem does the product solve? Why are you better than your competitors? Who are they? Is the product secure? How can you prove it? Is it compliant with any international or industry standard? Does it comply with the law and in which countries? Where are the data stored? Which quality framework do you use? Are tests automated? How mature and fast is your continuous delivery process? If a bug is found are you able to release a fix in few hours? Is your product innovative? What’s the tech stack? Do you use any well-known framework or innovative library or tool? Who are your technical partners? Is it multi-tenant? Is it customizable? What is the architectural model? How does it scale? How do you manage updates? Do you send notifications to the users? Are updates all mandatory or optional? Is it possible to run A/B test or have features flag? Who is the typical user? What are the demography and geography attribute of their profiles? Did you run any UX test? What are the supported browsers or devices? For how long will you support obsolete software or device? What is the support lifecycle model? How many languages does it support? How long it would take to support a new language? How much would it cost? What’s the ROI? Did you work on accessibility? What’s next? What’s in your roadmap? What license do you use? What’s the pricing model? What is the support model? What are the SLA and the SLI?

The party may be over or just started, it depends on your ability to answer these questions.

Read part 2 to know more about it.