Product Owner: Expectations vs. reality!
World of Digits / Explore
What is a Product Owner? What is its role and what are the tasks associated with its position? All these questions have already been the subject of numerous articles on the web.
It is therefore easy to get a quick idea of what the role of a PO (yes, let’s call him by his pet name) is. However, the job of the PO is much larger and more inclusive than what you may read. It changes and differs according to the structures and even the entities within the same company.
Does the role of the Product Owner seen through the framework of a specific project respect the different theoretical precepts of the Agile method and the different definitions of this position? Antoine and Divya are both Product Owners at World of Digits. And they can already give you a (Norman) answer: it depends 😊. That’s what Agile is all about.
As well as all the organisations that set up this project methodology or that think of implementing it. Trained more or less on common bases, the POs are not very similar in the end. They are constantly adapting, learning and renewing themselves. It’s almost schizophrenic. And this is true regardless of their training, background or professional experience.
At WORLD OF DIGITS, we assume that it’s necessary to master the theoretical methodological framework that governs them all: The Agile manifeste, and to pass the certifications or training courses that result from it.
The Product Owner knows that he will also have to lead or take part in Daily Meetings, Backlog Grooming, Sprints Planning, budgeting, retrospectives and write US…
He knows that he’ll have to manage all this according to the project and the way the team operates: in-house skills or TMA operation, Kanban project or Sprint project…
To conclude, it’s difficult to define very precisely the profile and the field of intervention of the PO, which varies according to the organisation.
We invite you to discover World of Digits’ vision of the Product Owner’s role through the different professional experiences of Divya and Antoine within our firm. Enjoy your reading!
ENGIE, Société Générale, Accor Hotels, AXA, SNCF, and Crédit du Nord. These are the different clients where we had the opportunity to learn and practice the role of the PO. Six different structures for as many differences in the vision of the role of the PO!
First, let’s start with the name of the job. Depending on the structure, the role of the PO can be called various things: Business Analyst (BA) or Proxy Product Owner (PPO). Furthermore, it is important to look at the role’s remit rather than its name. Theoretical definitions of the role of the PPO will state that he is the “right-hand man” of the PO or more commonly called “assistant project manager”. But this depends on the tasks assigned to them and the role of the PO they are working with.
Antoine: “I had the opportunity to work as a BA and as a PO for AXA France. Both on major and critical projects. As a BA, my area of intervention was not very far from the PO’s one. I led the main workshops and rituals of the Agile method (with the Scrum team, with the business or with other stakeholders).
I was doing the “classic” tasks of a PO. The difference was in two aspects. The first was reporting. The progress of the projects was reported directly to the PO, who was responsible for participating in the steering committees and sharing the information with the various sponsors. The second differentiating aspect was the budget management of the Scrum team in direct link with the Product Manager.
At the SNCF and the “Factory”, in the position I currently hold to look after the sncf.com website, the PO is, this time, the Business Owner. In this organisation, I adopt the name of “PPO” according to some and PO for others. I oversee the whole project management and sprint delivery cycle.
The phase of scoping the needs and defining the new functionalities is the responsibility of the “Business Unit PO”. This structure is totally different in another SNCF entity where I was involved as the PO of the INOUI TGV Chatbot.
The scope of intervention of a PO is therefore variable depending on the structure, an entity or even a team. Whether PO, BA or PPO, he or she remains the sole guarantor of the quality of the product delivered and the intermediary of all the project’s stakeholders. And there are many of them.
Besides, the PO must collaborate with all the skills of an Agile project, such as UX/UI Designer, developer, tester, Scrum Master, Business Owner, Product Manager. Each of these visions will help the need to mature and evolve. At Wolrd of Digits, we are convinced that the success of the PO depends on this interdisciplinary approach. He is the only one who has a 360-degree view on the different facets of the product. From marketing to design, including the ergonomics of the product and technical issues, he is the only cross-functional player.
To carry out the scoping, delivery and RUN phases, the PO leads and participates in several Agile rituals. Most of these rituals are now well known. We no longer need to present the Daily Meetings (or DSM), the Weekly Meetings, the Backlog Refinement (or Backlog Grooming), the Story Mapping, the Sprints Planning, the Ciphers (or Poker Ciphers), the “demos”, the retrospectives and so on 😊. Of course, the PO attends all these ceremonies and leads many of them. They all have a certain importance but do not apply to all projects. Their format may also differ between organisations.
“As the PO of ENGIE’s mobile application ” particuliers “, I had the opportunity to apprehend the wide range of Agile rituals that are available to us. Sprint Planning, Retrospective, Sprint Review, Poker Chiffrage, Daily or even the ceremony that the business and the other stakeholders particularly expect: the demonstration. They all have their own interests and require more or less time to prepare. My objective was to combine a high-quality organisation of these rituals with the management of my US writing time.
At ENGIE, one ritual seemed to me to be essential: the “Refinement Backlog”. This workshop of “grooming” in the hand of the PO, allows to present the US which will be embarked in the next sprint. The aim is not necessarily to encrypt / macro-encrypt the functionalities presented but to communicate with the DevTeam to best respond to the value of the product and the business needs. We debate, we break down, we raise the technical risks, and we go back to the DOD if necessary, to refine the US as much as possible. Practice has taught me that taking the time to groom means saving time for the rest of the agile process.
Another ritual whose approach is very interesting, and structuring is the preparation of “PI plannings”. On my mission, they take place every three months and require good preparation by the Scrum Team. This involves poker figures and the collection of as many UX/UI elements as possible.
Developing products in SaFe agility has taught me to anticipate hazards and adherences as early as possible in the program increment. At ACCOR, as a World of Digits consultant, I had the opportunity to work on the Premium and Eco-middle brands (Pullman, Ibis, Mercure hotels…) of the ALL site with three POs.
We had ad-hoc ceremonies between POs to prioritise our tickets in collaboration with the PPOs, whose profile was purely technical, but also to clean up the backlog or to review incident reports. A particular context requires particular tools!
Within Crédit du Nord, some projects are in full Agile and others are halfway between the V cycle and Agile. At Wolrd of Digits, we have been able to adapt the ceremonies to teleworking, using collaborative tools such as Miro or Klaxoon, which work well for participative remote meetings. ”
Many of these rituals, beyond project management, help the PO in the implementation of what represents the nerve centre of his work: The Users Stories (US). For those who are not familiar with them, US are the functional and written transcription of the business need. They respect a set of important theoretical rules. Amongst them, a US must be independent of minimal size, quantifiable, testable and must have a real customer focus.
The PO must never lose sight of the end user. He must take a pragmatic approach and test his product by putting himself in the shoes of the user. This “test and learn” approach enables him to guarantee the maximised value of the product.
This is achieved by implementing regular developments, measuring the impact with the help of KPIs and, above all, readjusting the product if necessary.
It cannot be repeated often enough, but the PO is the guarantor of the project and the quality that results from it. The importance given to the US is therefore crucial. A quality US will save time and avoid the need to go back and forth during the delivery phase. This will limit the number of anomalies and accelerate the “Time to Market” (time to production).
“Whatever my missions or the nature of my project, the US remains the heart of my activity. Through Story Mapping or a simple and explicit definition of needs, I try to make them as clear and self-supporting as possible. This saves me a lot of unnecessary back and forth in Grooming or costing.
The quality of the product or functionality delivered is all the better for it. In most of the companies I have worked with, I have been used to working with the JIRA tool. Whether in Kanban or in Sprints, JIRA allows me to give a transverse visibility on my activity and to see briefly the progress of the scoping phase, development, testing … depending on the structure of the team and the project.
I rely a lot on the vision of each member of the Scrum Team to feed my US. Sometimes well in advance of a Grooming or a UX / UI workshop. This allows me to smooth the transitions of the US in the columns of my Kanban and increase the Lead Time (or velocity) of the team. When I read a US, I want someone completely outside the project to be able to understand it without explanation. This method, in my opinion, ensures the quality of everyone’s work. “
To have access to a variety of missions, in companies that are committed to developing innovative products for their customers.
I did a first mission at Belfius (banking sector), a second one at STIB (mobility) and finally, I am now on mission at bpost.
I mainly work on mobile application and web platform development projects.
The main role of a Product Owner is to create (digital) products that will have the most value for their target audience, and in their market. By creating mobile applications or new features, our goal is to make our customers’ lives easier by providing them with useful and easy-to-use services, while fulfilling the objectives set by the company (customer acquisition/retention, increase of revenue, …).
The responsibilities can be very different from one project to another. The PO, as guarantor of the product, is often involved in other projects (marketing, panel management, PR, …) to guarantee the sustainability of the product.
In general, as a PO: I have to …
… establish the product strategy with the different stakeholders.
… define the different personas and the customer journey’s of the product
… coordinate the design of the future product or functionality.
…coordinate product development with the DM and the development team.
… make sure that the testing is done, and that the required criteria are met.
…ensure that the product is well received by the customers, and collect their feedback on the product, to constantly improve it.
Some yes, some no … Working as a PO in large structures has its advantages (more budget for developments, more visibility, …) but also disadvantages. Large organisations have difficulty being as agile as they would like to be. When many digital products have to be developed and maintained at the same time, development times can be very long, and the necessary reactivity to co-create tomorrow’s functionalities with our clients is totally lost.
As you will have understood, defining the role of the Product Owner is a complex task. So much so that it depends on a context, a mission, and a team. Assets and certainties are often called into question and the PO must constantly renew himself. We advise you to really see the PO as a conductor. A filter.
A privileged interlocutor. He takes on a lot of responsibility and must react quickly to the various hazards that a project may encounter. He must prioritize, justify himself and make himself heard. All definitions of the position of PO are good to take. They will provide you with theoretical elements on how to understand this position. But the reality can sometimes differ. Whatever your experiences. What is a PO? Finally, everyone has its own definition 😊Joins us as a PO
Written by Divya, Antoine and Laura
Read this article
Working smarter, not harder, is possible for your developers and designers thanks to the right collaboration tool.Read this article
Many UX designers are familiar with the problem of a creative block. But how do you make the most of this moment of low?Read this article
Read this article