Product ownership – a developer’s thoughts

Patterns and anti-patterns of product ownership

As a developer, I am very interested in the patterns and anti-patterns in product ownership that I have encountered in my professional career. Organizing the roadmap, making sure it is transparent, clarifying backlog items with the SCRUM team, finding out what the end user requires, these are some of the responsibilities you’ve probably heard about concerning product ownership. They are important, but in this article, I would like to show you different PO’s behaviors and their impact on our SCRUM teams. Because correctly understanding and applying SCRUM rules may help you with some problems, we are not robots, so a good awareness of one’s behavior and the impact can help a lot not just in a SCRUM team, but in all human interactions.

I am a developer. Over the years, I also became interested in psychology and human behavior. The best place I had the opportunity to practice my so-called hobby was at work within the teams I was part of. My favorite area of practice was conflict and stress management. I loved trying to “fix” the occasional “brawl” between two team members, mediating expectations towards the team, helping them handle tight and stressful deadlines healthily, or coaching people through their evaluation process.

As you can imagine, I’ve had quite some hiccups along the way, and I’m still learning. However, I did identify one topic which has a significant impact on team productivity and their stress level: how the Product Owner positions him (or herself) towards the team or more simply put, his attitude. Sadly, people tend to concentrate more on the task at hand and less on how emotions and human relations impact both their work and wellbeing. And this can mean the difference between good and beyond expectation results.

After having been in many teams, some patterns and antipatterns have started to emerge. I decided to give them names so that it is easier to relate to them. The characters I have created are the Salesman, Agile Actor, Autocratic Client, Wire, and Team Player. Let’s go through each persona and look at the advantages, disadvantages, and risks of each one.

The Salesman

In my experience, it is one of the most common characters or patterns I have encountered. Many of the Product Owners at TSS that I have worked with are also in charge of going to tenders, making client presentations with new addons, and so forth.

An obvious disadvantage is that this PO will miss some scrum events since he’ll be on the road or meeting with customers. But a major advantage of the Salesman is his vast amount of knowledge! The Salesman PO has a very clear perspective on how the end-users mind works and what the big selling points are. He can have an exceptional synergy with the team in terms of product requirements and implementation, planning, and brainstorming for improvements.

The risk here is focusing more on the sales part and less on that synergy. Here is an example I’ve experienced myself, which spiraled out of control.

It started with our PO selling something and setting a delivery date before discussing it in detail with the team. We did our best in refining and estimating everything that was promised. There were a lot of unknowns, and we had to cross out some of the features from the very beginning simply because there was not enough time. And as the months passed, ‘must-haves’ turned into ‘nice to have,’ putting a lot of pressure on our PO and the team. Usually, when you pressure a dev team into delivering, you run the risk of them not closing sprints as they try to overachieve. In this case, that was precisely what happened. Our PO became unhappy with the team. The team felt unappreciated for all the hard work they put in trying to make the most of a difficult situation. As a result, there were many arguments between the team and the PO, and also between team members themselves. This unhealthy atmosphere reduced productivity and made the team more prone to cutting corners so they could deliver faster. The overall mood in such a team is quite bleak; there is a lack of trust among team members and between the team and the Product Owner.

The lesson here is that nothing should be promised without having a proper estimation first. Since the Salesman PO has a say in both selling and SCRUM, he is the perfect liaison between the team and the customer. If he plays both ends well, he can make that double-edged blade swing in whichever direction he wants.

The Agile Actor

This pattern refers to those situations when the SCRUM Team receives a very hard deadline requiring a lot of effort (e.g., an urgent legislation change). I called it The Agile Actor because this pattern only pretends to do Agile. What I mean is that the team will still be doing refinements and planning, but it doesn’t matter if some estimations change or some unexpected situations show up, the deadline stays the same. A Product Owner in this situation can’t do much about the deliverable, but he can directly influence the team’s attitude and, as such, their productivity. The more he pushes and enters the panic mode himself, the more it will impact the team negatively.

It’s essential in this scenario for the PO to assume the role of the captain of the ship. Developers can be quite capricious when it comes to being presented a ‘fait accompli.’ I can’t stress enough how important it is for the Product Owner in this situation to show empathy towards the team and be open about the challenges while promoting understanding and focus on solutions instead of blame. It can help to find someone influential within the team whom he can chat with periodically, planning things together, and gaining insight into the team’s state of mind. In the end, it can go both ways; however, having the right attitude will greatly increase the Agile Actor’s chances of success.

The Autocratic Client

This category is a complete antipattern. You have a client who has assigned a Product Owner from its own ranks to oversee a development team from the partner. However, in this antipattern, the Product Owner doesn’t integrate and become part of the team, focusing on creating the desired results. He remains entirely on the side of the client, isolating himself from the developers who are part of the partner’s team.

This Client – Partner relationship within the SCRUM team can cause a lot of problems if any side abuses it. By the Autocratic Client, I’m referring to a difficult client (I’m sure you’ve had some yourselves), who demands, always knows your business better than you do, needs to have all details explained and who rarely admits to a mistake. They simply expect things to move along without any glitches or hiccups as they pay for the service. They constantly remind you and use that as leverage. The Autocratic Client starts to threaten when you hit a bump in the road, like “we may need to close the project,” or “we may need to shrink the team,” “I am very disappointed in you.” They rarely give good grades to the team at the sprint retrospective, and usually, their grades are not even related to the team’s dedication or commitment. The Autocratic Client works blame-driven rather than result-driven.

The mantra to fix this antipattern is quite simple. The PO may be an employee of the client, but he is more than that. He is part of the SCRUM Team, which succeeds or fails together. Overall it is a client-partner relationship between the two companies, focusing on getting the results. But a PO who acts as an autocratic client towards the team is going to be treated as such.

I’ve observed some very toxic behaviors in the dev team, as a response to an Autocratic Client. Firstly, it breaks trust, so when things get bumpy, the developers will have the tendency to withhold the full extent of the damage since “we don’t want to upset the client.” Secondly, the team will be reluctant to go the extra mile when the going gets tough and will be very strict with scope increases. The team behaves this way because they don’t identify with the PO’s challenges and see him as an outsider who complains and makes demands. They don’t feel recognized as part of the entire team trying to accomplish the envisioned results, and they may form a tight bond among themselves. It is normal human behavior to rally with your allies against the common threat. The Product Owner should be part of the team, not against it.

The Wire

The context is that a PO may have many other responsibilities besides product ownership, or maybe he has to care for multiple teams at the same time. It’s physically impossible to attend all the scrum meetings and be there with the team for all things. So, he becomes a proxy, or as I like to call it, The Wire. The PO just conveys the required information as clearly as possible and does periodic checkups. This works when the team is very experienced and knows both the product and the end-user well. They can deal with this situation if they know the deadlines, the consequences, the opportunities, and the scope, and how flexible the scope is. Of course, The Wire PO still needs to attend the sprint retrospective and be available for questions in case some things come up. This situation can work if there is a dedicated requirements analyst added to the team. Then the RA will pick up some of the PO’s responsibilities so he can focus on other things.

The Team Player

As the name suggests, this is the holy grail of product ownership, and it’s also the direct opposite of “The Autocratic Client.” Even SCRUM best practices state that you are part of the team. The best Product Owner is a full member of the team, except that he has other responsibilities. His retrospective grades count just as much as any other team member’s. He is always transparent with everything concerning the roadmap, the challenges that he faces, and the pressure he sometimes gets from his customers or managers. The Team Player is never just disappointed in the team and proactively looks for things he can improve. He collaborates with the other team members to make the best offer for the customer. The Scrum Team decides everything together.

A Team Player PO makes sure he meets with the team at least twice a year if he is remote. It’s essential to get together for some meetings and some beers. He also plans on-site meetings between the dev team and the end-users so they can better understand how the users actually interact with the product they are building. Add some leadership skills to the mix and you are looking at a SCRUM Dream Team! I know it’s easier said than done. Just know that it all starts with your own mindset.

There you have it! You will probably identify with parts of multiple categories, and that’s ok. POs also have to maneuver in the latitude that their function and company give them. The purpose of this article was for you as a PO to see how you may impact the team and what you can do to get the best out of it. This is just a short breakdown, so I’d love to have more detailed chats on the subject and share ideas with you. In the long run, I’d like to write a more detailed guide on the Product Owner – team relation, and I’ll need your help to do so! Just send me an email at alexandru.mihordea @ tss-yonder.com.

By Alex Mihordea, Front End Developer / Tech Lead