Technical Product Owner – A great title, a great job! Unfortunately, it’s difficult to live the role, to implement it in everyday work, and to come to terms with the fact that something will fall by the wayside, which is essential for a team…
What this job should be theoretically, what it is practical and if it is suitable for your company or your new challenge… are the questions I will answer in this article based on my personal 2 years‘ experience filling this role. I will list all the pros and cons and I will conclude this article with a recommendation on how it could be done better.
A Jack of all trades – That’s pretty much how I would describe the position of TPO (aka Technical Product Owner), after living it for almost 2 years in my last place of work. This was the internal description of my position, which was only a small part of my duties and responsibilities at my previous company. But this is a different topic for later.
What exactly is a (TPO) Technical Product Owner?
When I first heard about it, it was even before my time at ayfie. What I had imagined until then under this position was a classic Product Owner with technical experience. I won’t lie – that’s exactly what the position is. But Product Owner, in the classical sense of Scrum, is not to be confused with a Product Manager.
When I started at ayfie, I took on this position internally, for a total of 3 teams – 2 at the core product and one for a „green field“ side project.
- A Product Owner & Manager who sets the roadmap, knows the customer, has a vision of the product, is agile in responding to market changes, and writes epics and tickets that are critical to the work that the rest of the team does.
but also… - a technically affine person, preferably with a strong developer background, who can set technical requirements and make decisions when in doubt. He should not actively work on the code – he is rather the directing part.
A dream job for anyone who has an affinity for both worlds, or would like to acquire the other of the two. However, this position is still very young and not really widespread, which can and often does cause many misunderstandings.
As you can see above, the portfolio that you have to bring along as a TPO is very diverse and challenging, as you have complete control over the entire life cycle and development path of the product in your hands – which you have to handle very responsibly. Combining technical and product-related decisions to get the best out of the company, the team, and the product itself.
So the TPO acts uniformly on behalf of the product AND Engineering, although these two areas are pretty often antagonistic, even if the opposite should be the case, in an optimal world.
The unspoken third part of the role
An essential aspect of the role that is required in most cases is
- Disciplinary leader, with high emotional intelligence, who cares about the people, the team, and the humans behind these people. Whether this is done through one-on-ones or any other means is up to the TPO.
This area of responsibility, you surely know from other job descriptions. Engineering manager, team leader, disciplinary leader, etc.
Why unspoken? Well, because in most descriptions of TPO roles, it is left out, but in a team, it has to be filled out somehow. And since TPO’s do most of the administrative work in a team on their own, they may as well fill it in…
…. missing! xxx …
Hybrid roles
Since most companies would hardly hire anyone to work full-time with their employees (although it wouldn’t be that unglamorous…), hybrid positions such as Engineering Manager have emerged in the past. IT decision-makers on a team level, still programming themself, and besides, they are leading One-on-Ones and developing their co-workers.
Hiring a TPO is a commitment. The moment you do that, there is no room for a technical lead like an Engineering Manager. One, however, has to fill the disciplinary duties of a disciplinary leader – and this complicates the role of the TPO and makes it explode in terms of effort.
Here I also see the biggest problem. The wide scope of a TPO’s duties. But before we come to a proposal as to what one should consider when introducing such a role, I would like to briefly explain why a TPO is what every company actually wants to have – even if it doesn’t know it yet!
Why do product and technology (actually) bite each other?
In a „classic“ setup of an organizational structure, as it is currently taught and lived in most companies, there is a clear division between product and IT. This starts in the team and department and leads up to the VP level (depending on the size of the company) – a VP of Engineering and a VP of Product are definitely not uncommon at the moment. This is where decisions are consolidated, „discussed“ and then decided which way to go.
However, product and sales decisions are antagonistic to the wishes and needs of IT and vice versa – at least in most cases. An example of this is the technical blame that is built up for meeting deadlines and requirements that have been agreed upon – even if this means tinkering with the code. Building this blame is often a desire of the product since you can release features earlier; releasing the blame is more likely to be on Engineering, since it makes their lives harder.
(And this is exactly where I want to mention the word „actually“ in my paragraph title. Because actually, both parties have the same pain when making such a decision… it slows down further development enormously, because you always have to build around a hack as long as you don’t replace it with a clean solution).
Dysbalances in the decision making team endanger the company
When it comes to having the conversation just mentioned, it takes two parties (at whatever level) who should be equal in themselves to make the best decision for the case at hand. If there is an imbalance (in whatever direction) in the cooperation between the two parties because one party is stronger than the other in discussions, one party loses and the other wins. If you look at the snapshot, it is good, because you have (unintentionally) agreed on something and you move on.
But if you look at it as a whole, from the point of view of the company’s well-being, something has happened there that you don’t want to happen. One of the two parties, the orientation of the company, pushes in a certain direction. This can either lead to an exaggerated product-driven direction in development or an excessive technology-driven direction.
The Clash of Companies!
A meeting of employees of three completely different companies (organized by my former boss), which I was, fortunately, able to attend several years ago, opened my eyes and made it crystal clear to me what consequences this imbalance between product and IT has for the orientation of the company. People from three different companies met and discussed the current balance of power in their companies.
On the one hand, there were people from the middle management of a large Munich-based Fintech Company, where the company’s orientation was controlled purely by the product and sales. Working off technical debt was hardly approved, as product development stagnates and potentially a lot of money is lost. From a product point of view absolutely understandable and to be approved!
The second party were people from my former employer AutoScout24, where the balance of power was more on the side of IT, as the product department had suffered a few setbacks in the years before. There was hardly any technical fault, as the product department did not have the standing to demand this. IT could do what it wanted, it dictated the daily routine. From an IT point of view absolutely understandable and to be supported !
And this is where the hybrid role comes in …
So I stood there at the event and listened to both sides and agreed with both sides.
However, the advantages, but also the enormous disadvantages of such a situation, in which one party is „more powerful“ than the other, gave me a lot to think about, because you seldom get this so clearly shown in front of your eyes, as at such a meeting of different cultures.
But at the same time, with every minute that passed, I saw more and more the advantages of a role that has responsibility for both areas of a company or product, as was the case with me at the time.
Sometimes he is the product person, sometimes the IT manager. Sometimes he thinks from the perspective of the customer, sometimes from the perspective of the developer. Or he may be completely progressive: at the same time. But always… he thinks from the perspective of the company and not just through the glasses of one of the two parties.
Such an event as I have described above, I recommend to everyone who wants to see how companies think and act, which are inaccurate
I recommend an event such as the one I described above to anyone who wants to see how companies think and act that have unbalanced powers within the company – intentionally (as with company A) or unintentionally (as with AutoScout24).
My experience with the position
As I worked with AutoScout24 very much directly and indirectly with product, I felt up to the role. However, there were some things I was not aware of before that I had to feel and learn painfully!
From my own experience, I can say four things about it in retrospect:
- The position is pure schizophrenia
„This change is essential for the stability and maintainability of the code“, and at the same time … „We can’t let product development stagnate, the customer is getting on our backs“. Both from my mouth.
But also:
„Let’s hack it so that we can fix the bug in time for the next release and then we’ll do it nicely“, and at the same time … „I know we wanted to make it nice, but it won’t work, because we will lose 3 million Euros“. - It costs a lot of energy,
which we humans don’t have infinitely much of. To question, challenge and argue against oneself with a different pair of glasses is one of the most strenuous tasks I have had to perform in recent years. - For the company the best, for TPO not always.
If anyone can and will win in filling and defining such a position, then it is the company. The loser is always TPO, all things considered.
He will be both right and wrong with every decision he makes. A bit of defeat is always present in every decision. But a little bit of victory is also a little bit of victory, to be fair!
But primarily a victory for the company, than for yourself. - A TPO cannot and must not have disciplinary responsibility! The expertise that a TPO brings with it leaves no room for further skills and even more obligations and responsibilities. He should focus on the business, so that the jobs of the employees remain secure in the future. Business from a product perspective, but also business from an IT perspective.
Team leadership must come from a different source that has its strengths in exactly this area. But there are hardly any such explicit people manager positions.
… missing!! xxx … - The TPO needs a leader who listens to him.
Especially because of the points #1, #2 and #3 of this list, I consider it essential (!!) that the TPO has a leader (VP, CPO, CTO) who takes time for him, listens to him, helps him when he needs help and tries to eliminate the weak points of this position together with him, so that all parties involved benefit from this position.
… missing!! xxx …
My proposal is …
Start the experiment and implement the role of a TPO in your company. It is definitely worth it!
Whether you want to embody it yourself, or you wish someone else to do it in your company, it doesn’t matter. Create the space and structure to bring this position to life and you will go 100% with many learnings from this experiment. Some with the awareness that this position is what they have needed for years… and others with the knowledge that this position does not fit into the company structure.
However, you should think about the job before and put it in writing, otherwise it can lead to many misunderstandings. Here is a list of potential points that should be discussed and decided upon by everyone in such an agreement:
- What are the TPO’s responsibilities in your company
- What does NOT belong in his area of responsibility
- Who takes over the tasks that TPO does not have in its job description? (e.g. disciplinary management)
- Who does the TPO report to? To IT? To the product? To both?
- Who is the contact person who is there for TPO when they need him?
Conclusion
The role of TPO is wonderful. It brings together two major decision-makers and parties of a team/department in one person who makes decisions for the benefit of the company/team, all from one source.
Since the pressure and responsibility that weighs on this role is enormous, you have to be very precise in your role description, otherwise there will be an overload, which will be counterproductive and cause the opposite effect than what you had hoped for.
… missing !! xxx …