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:
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 https://agile.dzone.com/articles/product-owner-responsibilities)
That was surprising because when I first thought what a PO means to me, the sentence that he owns the product didn’t come to my mind. I strongly believe the whole team owns the product: 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 Product Owner 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.
The theory also says there is a single product owner per product. 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’ll keep discovering details about it. In this case, a focused product owner is one who is 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.
Such situations require for a responsive product owner who involves the whole team into the decision making process. Communication and collaboration with the development team are important characteristics of a good product owner. He has to know very well the product, but that alone won’t help unless the product vision reaches the team effectively.
A good product owner is understood and understands the technical people. 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.
Another aspect of understanding the technical team is the understanding of software development. A Product Owner needs to know that software requires careful maintenance to allow for easy changes. Refactoring, unit tests, automated 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.
I see the PO more as a team member, 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 product owner was close to the team from story creation to release. This helped maximize the work not done when developers don’t fully understand the details.
So far I have discovered from experience that a good product owner matches the following criteria:
- Has the best knowledge of the product
- Effectively shares his product knowledge with the team
- Is a team member
- Constantly collaborates and communicates with the team
- Finds answers to the teams questions
- Gets his hands dirty doing early testing of the features still under development
- Is flexible regarding product backlog changes
- Agrees to technical tasks
- Constantly gives his, the users’ and the clients’ feedback to the team, good or bad
What is your opinion? Let me know in the comments!
