{"id":12077,"date":"2014-03-17T09:46:56","date_gmt":"2014-03-17T07:46:56","guid":{"rendered":"http:\/\/mozaicworks.com\/?p=6443"},"modified":"2022-02-01T18:28:50","modified_gmt":"2022-02-01T16:28:50","slug":"a-developer-about-product-owner","status":"publish","type":"post","link":"https:\/\/mozaicworks.com\/blog\/a-developer-about-product-owner","title":{"rendered":"A developer about Product Owner"},"content":{"rendered":"

I developed software products for about 5 years and collaborated with Product Owners (PO) during this time. I will share in the following my perspective as a developer about this role and about working together with POs. I was surprised when I first read about the definition of a product owner, after working for a while in this environment:<\/p>\n

The product owner is the person who owns the product on behalf of the company. The individual is responsible for the success of the product, and has to be empowered to make the necessary decisions. His artifacts are: product vision, product backlog, release burndown, product roadmap. (from\u00a0https:\/\/agile.dzone.com\/articles\/product-owner-responsibilities<\/a>)<\/p><\/blockquote>\n

That was surprising because when I first thought what a PO means to me, the sentence that\u00a0he owns the product<\/em>\u00a0didn\u2019t come to my mind. I strongly believe\u00a0the whole team owns the\u00a0product<\/strong>: the development team together with the product owner and the business people or clients. After all, a developer takes ownership of a story in an agile environment. The\u00a0Product Owner\u00a0<\/a>owns the product in the sense that he is responsible for certain decisions at product level, but he cannot do it without sharing the product with the rest of the team.<\/p>\n

The theory also says there is\u00a0a single product owner per product<\/em>. I found this to be challenging in reality. One PO is indeed enough for a small product. For a complex product, with many modules, one product owner per module could be more efficient. Each PO would focus on the best direction for his part of the product while communicating and collaborating intensively with other product owners and the development team. We know that no story is perfect and that we\u2019ll keep discovering details about it. In this case, a focused product owner is one who\u00a0is available to answer questions coming up during the sprint. They can also make hard decisions faster. Even after starting the implementation, we often discover the story is more complex than expected and it cannot be done in one sprint.<\/p>\n

Such situations require for a responsive product owner who involves the whole team into the decision making process<\/strong>.\u00a0Communication and collaboration with the development team<\/strong>\u00a0are important characteristics of a good product owner. He has to know very well the product, but that alone won\u2019t help unless the product vision reaches the team effectively.<\/p>\n

A good product owner is\u00a0understood and understands the technical people<\/strong>. He knows that some stories are too big for one sprint and is able to split them in minimum deliverable features. This splitting is usually done better together with the team.<\/p>\n

Another aspect of understanding the technical team is the\u00a0understanding of software development<\/strong>. A\u00a0Product Owner<\/a>\u00a0needs to know that\u00a0software requires careful maintenance to allow for easy changes<\/strong>.\u00a0Refactoring<\/a>,\u00a0unit tests<\/a>,\u00a0automated acceptance tests, frameworks upgrades and other things that are not directly linked with features have important consequences for the future of the product. Knowing that and trusting the skills of the team, the product owner allows technical tasks in the product backlog.<\/p>\n

\"Team\"<\/a><\/p>\n

I see the PO more as a\u00a0team member<\/strong>, rather than a product development leader. I once had to extend a tool in a very short time while not having complete and clear stories. We had to decide to deliver the fastest thing possible. The tester, the product owner and myself joined forces. I did incremental implementation in the sense that once a small feature was stable on the development environment, I would go straight to the product owner for the initial feedback. Once we agreed on it, I went forward with the implementation. When the whole story reached the test environment, the tester only had to take a quick look before accepting the story. Our mini-team worked smoothly and had lots of fun while delivering fast. It worked because the\u00a0product owner was close to the team from story creation to release<\/strong>. This helped maximize the work not done when developers don\u2019t fully understand the details.<\/p>\n

So far I have discovered from experience that a good product owner matches the following criteria:<\/p>\n