{"id":1400,"date":"2019-07-30T09:06:00","date_gmt":"2019-07-30T09:06:00","guid":{"rendered":"https:\/\/digiterrebestg.wpengine.com\/?p=1400"},"modified":"2024-05-30T10:05:24","modified_gmt":"2024-05-30T10:05:24","slug":"its-not-easy-being-a-product-owner","status":"publish","type":"post","link":"https:\/\/www.digiterre.com\/us\/2019\/07\/30\/its-not-easy-being-a-product-owner\/","title":{"rendered":"It’s not easy being a Product Owner"},"content":{"rendered":"
\n
\n

It’s not easy being a Product Owner<\/h1>\n\n

Requirements are hard. No one is born knowing how to write wonderfully detailed requirements or knowing how to be the perfect Product Owner (though you can probably think of many contenders for those who definitely wouldn\u2019t win that award).<\/p>\n \n <\/div>\n<\/section>\n\n\n

\n
\n

At Digiterre, the Product Owner (PO) is outside the Development Team and is a member of the client team.<\/p>\n\n\n\n

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 realizing these in terms of business value from the work that the development team deliver.<\/p>\n\n\n\n

Requirements \u2013 we usually talk about \u201cgathering requirements\u201d as if they are simply like ripe fruit scattered on the ground however in reality it\u2019s more about \u201crequirements elicitation<\/em>\u201d \u2013 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<\/em> 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\u2026<\/p>\n\n\n\n

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<\/a>), phrasing the problem in terms of wants and needs, guiding prioritization (via MoSCoW analysis for example) and then finally identifying themes (epics) and scoping (phasing).<\/p>\n\n\n\n

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><\/em> to express intention and then accompanying Acceptance Criteria to understand when a task is Done<\/em>. 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.<\/em><\/p>\n\n\n\n

More mature requirements will also feature non-functional considerations, such as speed, responsiveness, availability and scalability, for example.<\/p>\n\n\n\n

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\u2019s done, the quicker it is to course correct and get an accurate understanding of what needs to be delivered.<\/p>\n\n\n\n

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<\/em> Product Owner inside<\/em> 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<\/em> 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.<\/p>\n\n\n\n

Illustration credit: dilbert.com<\/em><\/p>\n\n\n\n

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

\n
\n

About the Author<\/h3>\n
\n \n \"\"
\n

Digiterre<\/h4>\n\n \n \n <\/div> \n <\/div>\n
\n Date: 30\/07\/19<\/strong><\/span>\n Category: People Blog<\/strong><\/span>\n <\/div>\n <\/div>\n<\/section>\n\n\n
\n
\n
\n \"\"<\/a>\n\n
\n \n

Digiterre Opens in D\u00fcsseldorf: Strengthening Our Presence in Germany\u2019s Energy Market<\/h4>\n <\/a>\n
\n

Date: 03\/06\/25<\/strong><\/p>\n

By: Laurence Pisani<\/strong><\/p>\n <\/div>\n <\/div>\n <\/article>\n\n

\n \"\"<\/a>\n\n
\n \n

Modernizing C++ in Tier 1 Banks: Balancing Performance and Progress<\/h4>\n <\/a>\n
\n

Date: 21\/05\/25<\/strong><\/p>\n

By: Digiterre<\/strong><\/p>\n <\/div>\n <\/div>\n <\/article>\n\n

\n \"\"<\/a>\n\n
\n \n

Legacy Threat: Cybersecurity Lessons from Retail Attacks\u00a0<\/h4>\n <\/a>\n
\n

Date: 07\/05\/25<\/strong><\/p>\n

By: Digiterre<\/strong><\/p>\n <\/div>\n <\/div>\n <\/article>\n\n

\n \"\"<\/a>\n\n
\n \n

Data Under Pressure: Rethinking Data Management in a Volatile, Tariff-Driven Market\u00a0<\/h4>\n <\/a>\n
\n

Date: 30\/04\/25<\/strong><\/p>\n

By: Laurence Pisani<\/strong><\/p>\n <\/div>\n <\/div>\n <\/article>\n\n \n <\/div>\n

\n

Follow Us<\/h3>\n

Get the latest news and stay up to date<\/p>\n