Why do I want to start coding again since I became Product Ower?

By Mathieu Boisvert

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.

bad idea

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

Other Stories You Might Be Interested In

Explore and Innovate Within Our Laboratory | Done Technologies

Journal of an Intern

Hi, I am Marc André, intern at Done; or should I say member of the team. I am presently doing an internship at the Done Technologies  in Laval. It has already been a month and half since I started my adventure here and what an adventure it has been until now! What’s Done? It’s a...
Custom Software Development | Done Technologies

5 tips to develop custom software with a small budget

The decision to use existing software or to invest in the development of custom software is still subject of much debate. Using existing software that already has some basic features may seem tempting, but we often forget to compare it to the benefits of developing custom software. For more than 17 years, Done Techno has...
Our Success Projects | Done Technologies

Did you know that your technology may be outdated?

Are you overwhelmed with internal requests? Is your IT support team overwhelmed? Are you still able to deliver to your customers? Are your employees frustrated?  Very often, these situations are related to tools that are no longer adequate or to aging technology that no longer meets the changing needs of the company. Our team at Done advises...