{"id":607,"date":"2020-10-28T22:43:00","date_gmt":"2020-10-28T22:43:00","guid":{"rendered":"https:\/\/www.danieledavi.com\/blog\/?p=607"},"modified":"2021-02-23T21:58:10","modified_gmt":"2021-02-23T21:58:10","slug":"product-owners-dont-need-to-be-technical-to-be-good","status":"publish","type":"post","link":"https:\/\/www.danieledavi.com\/blog\/2020\/10\/product-owners-dont-need-to-be-technical-to-be-good\/","title":{"rendered":"Product owners don’t need to be technical to be good – part 1"},"content":{"rendered":"\n

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. <\/p>\n\n\n\n

I am talking about the myth of the existence and the need of a technical PO.<\/p><\/blockquote><\/figure>\n\n\n\n

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. <\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Spoiler: you don\u2019t need to be technical to make the right questions around your product. Framing the problem and have a 360\u00b0 view of a product don\u2019t require technical abilities. Don\u2019t 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.<\/p>\n\n\n\n

You may have experienced sometimes teams making some questions and the PO saying \u201cwell that’s up to you, that’s a technical decision\u201d.
Whilst finding solutions and creating product increment is team\u2019s 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\u2019t need to be expert in any of these, yet they should own the entire product and these areas aren\u2019t excluded.<\/p>\n\n\n\n

Imagine for instance a PO saying \u201cI’m not a legal expert, so whether my product should fulfil data protection laws and requirements is not my responsibility\u201d. 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.<\/p>\n\n\n\n

POs don\u2019t 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\u2019t require you to be a global black belt in any particular subject.<\/p>\n\n\n\n

PO negotiates, synthetizes, prioritizes, and owns all of these different overlapping areas of their product. All stakeholders help and support him or her.<\/p><\/blockquote><\/figure>\n\n\n\n

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:<\/p>\n\n\n\n

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\u2019s 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\u2019s the ROI? Did you work on accessibility? What\u2019s next? What\u2019s in your roadmap? What license do you use? What\u2019s the pricing model? What is the support model? What are the SLA and the SLI?<\/p>\n\n\n\n

The party may be over or just started, it depends on your ability to answer these questions.<\/p>\n\n\n\n

Read part 2 to know more about it.<\/p>\n","protected":false},"excerpt":{"rendered":"

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.
\nI am talking about the myth of the existence and the need of a technical PO.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[263,325],"tags":[252,271,253],"aioseo_notices":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p90hsv-9N","jetpack-related-posts":[{"id":609,"url":"https:\/\/www.danieledavi.com\/blog\/2020\/10\/product-owners-dont-need-to-be-technical-to-be-good-part-2\/","url_meta":{"origin":607,"position":0},"title":"Product owners don’t need to be technical to be good – part 2","author":"Daniele Dav\u00ec","date":"October 28, 2020","format":false,"excerpt":"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\u2026","rel":"","context":"In "Agile"","block_context":{"text":"Agile","link":"https:\/\/www.danieledavi.com\/blog\/category\/agile-2\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":616,"url":"https:\/\/www.danieledavi.com\/blog\/2020\/11\/envision-imagine-anticipate-the-future-of-your-product\/","url_meta":{"origin":607,"position":1},"title":"Envision, imagine, anticipate the future of your product","author":"Daniele Dav\u00ec","date":"November 6, 2020","format":false,"excerpt":"Today, I would like to write about another important set of attitudes and abilities that a good product owner (PO) should possess. As mentioned in the article I previously posted, PO doesn't need to be technical to deepen his or her view and understanding of the role. Having a wider\u2026","rel":"","context":"In "Agile"","block_context":{"text":"Agile","link":"https:\/\/www.danieledavi.com\/blog\/category\/agile-2\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":555,"url":"https:\/\/www.danieledavi.com\/blog\/2020\/07\/is-your-team-doing-scrum\/","url_meta":{"origin":607,"position":2},"title":"Is your team doing Scrum?","author":"Daniele Dav\u00ec","date":"July 26, 2020","format":false,"excerpt":"There many tools and checklists to verify wether your team is doing Scrum and how good (or or bad or ugly) is implementing it. If you are a Scrum Master, self-assessing the following statements from 1 (strongly disagree) to 5 (strongly agree) can help you to make a reality check\u2026","rel":"","context":"In "Agile"","block_context":{"text":"Agile","link":"https:\/\/www.danieledavi.com\/blog\/category\/agile-2\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":673,"url":"https:\/\/www.danieledavi.com\/blog\/2020\/02\/spikes-102\/","url_meta":{"origin":607,"position":3},"title":"Spikes 102","author":"Daniele Dav\u00ec","date":"February 11, 2020","format":false,"excerpt":"In my previous article \"Spike 101\" I introduced the concept of Spike and it's general use in Agile. In that article we saw that: Spikes are investigation activities -e.g: research, design, investigation, exploration, prototyping- to gain the knowledge to solve a problem.\u00a0As Scrum doesn\u2019t prescribe any particular type for Backlog\u2026","rel":"","context":"In "Agile"","block_context":{"text":"Agile","link":"https:\/\/www.danieledavi.com\/blog\/category\/agile-2\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":671,"url":"https:\/\/www.danieledavi.com\/blog\/2020\/02\/spikes-101\/","url_meta":{"origin":607,"position":4},"title":"Spikes 101","author":"Daniele Dav\u00ec","date":"February 10, 2020","format":false,"excerpt":"Scrum is often described as a very prescriptive framework despite this is not the case. Take for example the various type of backlog items that we are used to deal with in our favourite backlog visualisation tool. Some work with Epics and User Stories only, others use a mix of\u2026","rel":"","context":"In "Agile"","block_context":{"text":"Agile","link":"https:\/\/www.danieledavi.com\/blog\/category\/agile-2\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":791,"url":"https:\/\/www.danieledavi.com\/blog\/2021\/03\/changes-are-welcome\/","url_meta":{"origin":607,"position":5},"title":"Changes are Welcome","author":"Daniele Dav\u00ec","date":"March 10, 2021","format":false,"excerpt":"There are different levels of understanding\u00a0Agile.The first one is where you care about rules. You take every best practice, guide, book, training suggestion and you make a strict process out of context and without interpreting the reality. That's not Agile. That's you using Agile to cover your need of implementing\u2026","rel":"","context":"In "Agile"","block_context":{"text":"Agile","link":"https:\/\/www.danieledavi.com\/blog\/category\/agile-2\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"amp_validity":null,"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/www.danieledavi.com\/blog\/wp-json\/wp\/v2\/posts\/607"}],"collection":[{"href":"https:\/\/www.danieledavi.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.danieledavi.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.danieledavi.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.danieledavi.com\/blog\/wp-json\/wp\/v2\/comments?post=607"}],"version-history":[{"count":3,"href":"https:\/\/www.danieledavi.com\/blog\/wp-json\/wp\/v2\/posts\/607\/revisions"}],"predecessor-version":[{"id":615,"href":"https:\/\/www.danieledavi.com\/blog\/wp-json\/wp\/v2\/posts\/607\/revisions\/615"}],"wp:attachment":[{"href":"https:\/\/www.danieledavi.com\/blog\/wp-json\/wp\/v2\/media?parent=607"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.danieledavi.com\/blog\/wp-json\/wp\/v2\/categories?post=607"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.danieledavi.com\/blog\/wp-json\/wp\/v2\/tags?post=607"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}