Be a Product Owner or Tech Lead, but not both
Just recently I was put into a role that, 2 years ago, I would have told you I never wanted: Product Owner.
I’ve always been a software engineer. I started my career by being an overachieving developer who wanted to learn as much as he could and make awesome things. I went on to be a full fledged software engineer, lead developer, architect, and then technical lead all in the space of just a few years. This wasn’t really because I was a very good developer, it was more because I was ambitious and took a personal interest in making the products I worked on as awesome as I could.
Around a year ago, though, I realized that I was no longer satisfied in making improvements to the products that other people were driving and responsible for. I wanted to be the one driving that product, driving those improvements, and creating a vision to work toward. When I expressed this interest to my boss, he looked at me and said:
Sounds like you want to be a product owner
What?! Me? A product owner? No chance. I’m the guy who gets work done… not the guy who creates work for other people to do and then sits around and watches it get done (or not). Joking aside, my view of what a product owner actually does on a day to day basis wasn’t particularly flattering, and I have worked with some excellent product owners.
The more I thought about it though, the more I realized that this kind of transition presented an opportunity that I did want: the ability to be responsible for a product. The sole source of priority and planning for a product. One that I could create a vision for and go about helping a team execute it. We were in a unique position as a company where there was a product that needed a full time product owner, so the timing worked out in my favor for this opportunity. I accepted.
There was one catch though: I was needed as the technical lead for this team as well, because we are a small company in the process of trying to hire more talent. Until that gap could be filled, I couldn’t really stop developing. At the time, I was A-OK with this. I love developing and I’d still be able to do work and not just write stories or manage a backlog. Perfect.
Bring it On
The very first week of the job a startling reality hit me: I had almost absolute responsibility over my product. A product owner is not supposed to be the one doing the work. They’re supposed to enable their team to do work. Instead, here I was with the ability to:
- Define a product vision
- Scope the features of the vision
- Define how it should be done technically
- Help it get done, technically
- Review the work done afterwards
- Give it the official P.O. stamp of approval afterwards
Sweet gig for a go-getter. Dream up an idea, scope it, do it. In fact, you even have have a team to help you do it. At first, I could go with that no problem.
The second week into having this role though, I realized something: being a product owner, a good product owner was a full time job. Not just a full time job, but one that could take up as much time as you want it to. At last I started understanding what product owners actually do. I was the guy doing it. Yes, I had to write stories, but the significance of those stories took on a deeper meaning — I was helping my team to waste as little time as possible while they made amazing things.
A key here is that in this role transition, the metrics for success were no longer based on being an individual contributor. A product owner is measured by the success of their product, not on how many stories they can write, how well their backlog is organized, or how well they can pitch a vision.
I didn’t get to make amazing things any more, but I did get the satisfaction of knowing that I was enabling those things to be built. That was awesome. Not only that, but I realized that I was the source of truth for my product. There are always stakeholders outside of your immediate development team that have a vested interest in your product: marketing, sales, support, etc. They all have day-to-day activities that rely on your product, which means that someone needs to understand where they all fit in when creating new features or solving problems. You don’t want your developers spending their time on that, they have enough hard problems to solve.
Additional Responsibilities
Facilitating the communication between all the various stakeholders for a product is a tremendous task. It requires constant over-communication about priorities, team progress, customer needs, and a host of other factors. It became clear to me that this was literally my job, to ensure that everyone who had a vested interest in my product was represented properly. Whew, that’s a lot of people. It also requires dedicated time.
The more I became aware of these responsibilities, the less I was enamored with the idea of having complete control over my product, and the more I wanted to be able to hand off the actual work associated with that product to someone else. It’s too much for any one individual to do well. And I was on the hook for all of it.
Features weren’t prioritized correctly? That’s on the PO.
Delays in the development of features or bug fixes weren’t communicated properly? That’s on the PO.
A feature wasn’t architected properly? That’s on the technical lead.
The technical scope of a feature wasn’t estimated properly? That’s on the technical lead.
In other words. It’s all on me. For an ambitious person loving a challenge, that can be electrifying. In reality though, when you realize that both roles require the full attention of an individual to be done well, it becomes terrifying.
In short, I also learned that there was no way I could do both jobs well. I had enough trouble doing one of those jobs well, and I was brand new to being a PO, which means I had a lot of failing to do before I started to do it well.
A Grand Vision
Just recently I had the opportunity to pitch a vision to upper management about the direction of the product as it pertains to the market we’re in. They loved it. They were excited and motivated by the direction, the possibilities, and the scale of what I pitched. I was excited coming out of the meeting because that was the type of interaction I had been hoping for over the past few months.
Then as I drove home I realized that every expectation I had just set in that meeting was now on me to fulfill. Opportunities are awesome, but they also have to be executed on. In my role there was a single person who would be held responsible for the success or failure of making that vision a reality, and it was also the person who recognized around how much effort it would take.
Welcome to the world of a PO. Make sure you have a strong team you can rely on, because your success will be entirely contingent on how well you can motivate them and empower them to make an awesome product.
