Why I became a Technical PO

As a Senior- or Lead-Developer, you often receive some delegated tasks from the Product Owners you work with. As a consultant I went through PO's quite regularly, and I've had the opportunity to learn a lot about the different attitudes, methods and levels of mandate that a PO can have. Eventually I pivoted into a PO role myself. Here I want to answer some of the questions I keep getting since then.

Why put yourself forward as a Technical Product Owner?

Product Owners come in all shapes and sizes, but after a while you start recognizing certain types of Product:

The Scrum Guide very strictly says that there is "only one product", but that depends on how you define product in your organization. For a consumer or end-user "bol.com" can be a single product. But it would be very naive to think that all of bol.com could be developed under just one Product Owner without any type of delegation. So there you will likely find smaller products, like "search function" or "user settings". Their platform is massive, their products mostly consumer-facing.

At a far smaller scale, a company that supports your local library by setting up events will probably have three broadcast channels under one single Product Owner. Their UX budget will be far lower, but they will know all about their specific consumer.

A technical Product Owner often has a technical product. An example of this could be the pipelines that all other development-teams use for continuous delivery and deployment. Or that one "big data" solution that every team is communicating with but nobody knows how it works. Or even just a temporary three-month project to finally automate that one form everyone is bothered about. The challenges can range from needing prior knowledge about highly technical solutions to simply being able to speak technobabble with the intended consumer.

In many places where I was a consultant, my teams were highly dependant on these products and their teams, sometimes without even knowing who they were or what part of the office they were in. These internal services or solutions are not as flashy as big B2C products. It's not as straightforward to explain at a party just what the value is you're delivering. But this type of product is close to my heart and I love working on them.

But don't you miss being a developer?

The fact that these days I don't spend a lot of time in Visual Studio Code or going through Pull Requests doesn't make me any less of a developer. Being a dev is about a mindset. When I was hiring new team-members I always looked more for that mindset than for any set of hard skills. Tech changes every year. Knowing how to think in systems, how to detect the large impact a small change in code can have, that is what seniority in the developer role is all about. I still use these skills, but I use them when talking to stakeholders when they propose a change, or the understand a discussion in a refinement or Three Amigos session.

For me it was a small step towards becoming a Product Owner. I feel that any consultant has a higher change of success at a company when they come in and immediately:

• Learn the lay of the land
• Identify the principal stakeholders for the team
• Notice where things hurt the most
• Speak up when they see something that can be improved

These are things I always did as a developer, and I still do them today as a Product Owner.

So, how did you get there?

At a previous project, I was able to follow my PO in meetings, as a fly on the wall. We scheduled coffee-breaks so I could pick his brain on topics that we didn't immediately align on. This was a really valuable experience for me, as it provided me some insight into the considerations that had to be made in the Product Owner Role that I had not considered as a developer. I was already part of the Three Amigos sessions, and I asked to lead the Sprint Review and the discussion it generated whenever he was unable to.

To make sure that I had some more theory to inform my practice, I booked a digital PSPO course. I was very lucky to find an online course where everything was taken care of and the communication was crystal clear.

I've heard since that the online courses can be hit-or-miss. For my PSPO-Advanced training I went for in-person and that made a huge difference for me personally, as it just aligns better with my way of thinking. The best course/training/workshop is one with a group that is diverse in background and nationality, and I've been lucky on that account in both cases.

The last thing to do was to put myself out there. Initially, I thought I would be starting at the ground floor again, after putting in a lot of hours becoming a more senior developer throughout the years. This is partially true: some companies have a very rigid view and just look for years spent in the PO role on your resumé.

I've found that the more agile companies think more outside of the box: those years of experience as a developer can help you make an informed choice. The delegated tasks you performed and the communication skills you've honed are part of the PO role. It's just a numbers game: I do have to spend more time applying than before. But I fully expect that to be less of a problem after a couple of projects.