Imagine that you are Product Owner for a Sodoku application: you would probably be able to describe the game’s rules to your development team and to provide as condition of success, a resolved puzzle and the corresponding valid starting grid. But it would be more difficult to specify a starting point without the reference of a resolved puzzle. To achieve this, you would probably resort to several experiments to discover valid starting puzzles. And that is without considering designing puzzles with multiple difficulties: how would you know if it is going to be difficult to solve if you do not know the solution and the necessary steps to get there?
That is somewhat how I feel in my new role as Product Owner…
I am newly the Product Owner of an interactive product meant to make online teaching of Lean approaches more relevant. I have a lot of experience teaching these approaches and I have the privilege of working with Christian Bélisle, an experienced programmer who has knowledge in video game development.
I approached my role as Product Owner the usual way: by making development requests through writing a backlog. However, I quickly realized that even if creating teaching material is easy for me, and even if Christian is able to program the Lean exercises, it is difficult to know the dysfunctional start configurations without making experiments.
So we started some sort of ping-pong game: I describe the settings of my experiments and he programs them. But it is inefficient because:
- Christian has to wait for me when I am thinking about the experiments’ settings.
- Without the result of the experiments, it is difficult for me to continue writing the training material.
- We do not know how many attempts will be necessary to find satisfactory settings.
Since I am a former Java programmer, I now want to code my experiments on my side in order to break our ineffective exchange dynamics. And that bothers me because I am convinced that normally, a Product Owner should not be coding.
Why is it a bad idea for a Product Owner to code?
Without being an absolute rule, we generally prefer Product Owners who have a business background rather than a technical one, because:
- They understand the value of the product to be built, as well as the clients/users’ needs.
- They embody the users’ reality.
- They have the information and authority to make decisions more autonomously.
- They have a network of contacts to find missing information, to confirm their hypotheses and to present the results.
We can therefore deduce that a candidate who knows about product development and marketing, as well as an understanding of the clientele and the competition, would have everything needed to do a good job.
“In simple terms, the product owner sits in the driver’s seat, deciding what should be done and when the software should be shipped. The team decides how much work they can take on in a sprint and how the work is carried out.”
So the team expects the client to express a business need that have to be answered and not to be overly involved in making technical choices, except when they can impact the product’s success.
Worse, technical expertise could become a dysfunction within a Scrum team:
“It could be disastrous if they had worked as a programmer 15 years ago and pretended that their understanding of technical tradeoffs remained perfectly relevant today. I’ve worked with product owners who had stopped programming 15 years earlier and couldn’t understand why something that was easy to do on a Green Screen application took longer to do with Enterprise Java. This led in some cases to fights over cost estimates. It might help to know what’s feasible, but if they work with programmers that they can trust, then that becomes less of an issue.”
J.B. Rainsberger’s post, No, a Product Owner doesn’t need programming skill
So what can I do?
Here are a few options that come to mind to improve the dynamics between Christian and me:
- Coding: I am lucky, I know how to code, at least with Java. And I am not the only one, many Product Owners are excellent with Excel or Access. As long as the programming is for specifying the need rather than developing the software solution, it respects the Product Owner’s role. Christian could even value receiving specifications in the form of an executable unit testing, not just in textual format.
- Writing automated acceptance testing: With platforms like SpecsFlow, Cucumber or Selenium, it would be possible for me to write the settings of my experiments and run them directly on Christian’s code. This would reduce programming costs because I could test Christian’s logic engine without asking him to update the final solution’s interface. In addition, these tests would serve as specifications for Christian, and this would probably reduce the feedback cycles between us.
- Using a console: Automated acceptance testing can be daunting for a less technical Product Owner. If Christian developed a console to interact with his code, without using the final solution’s interface, then I could conduct my tests independently and I would reduce the development effort for Christian. On the other hand, I should continue to specify in text format.
And what would YOU recommend?
You may have experienced similar situations as developer or Product Owner. How have you dealt with the situation?
Further readings
- http://blog.jbrains.ca/permalink/no-a-product-owner-doesnt-need-programming-skill#
- https://www.scrumallianorg/agile-resources/7-skills-you-need-to-be-a-great-product-owner
- https://www.mountaingoatsoftware.com/agile/scrum/roles/product-owner
- https://www.romanpichler.com/blog/product-owners-and-technical-skills/
- http://agilemodeling.com/essays/businessAnalysts.htm
