Using your Product Management skills to elevate your Leadership

The idea for this article came to me, when I talked with someone at APP (Association of Product Professionals). While discussing what I do in leadership, she said “it seems to me that you took your product management skills and applied them to leadership”. I didn’t even think about it like that but I guess that’s what I did. So let’s get into it.

What makes a good leader? And how do you become one? Well, I don’t know. Just like in product management, you will never stop learning. You will need to fail to succeed and you will need to craft hypotheses and validate them to reach your goal. I want to share with you what I learned when I got my first leadership role and how I formed a team of this group of individuals that still keeps in touch, even when most of us aren’t at that company anymore.

My first leadership role

The first time I took over responsibility for a team was a rather unique setting. I got promoted to lead the team. It consisted of software engineers, product managers and SEO managers. We came from a rather chaotic past. When I joined the company, there was no product management. The team was an internal agency and its purpose was to execute on what others in the company wanted. Regardless of who wanted it, why they wanted it or what the purpose was. I was hired as Product Owner for a couple of B2C online products. One of three Product Owners (we were all responsible for all products and it was somehow expected that we figure out how to work together) in a team that was complemented with four developers. The developers were instructed to do what the Product Owner wanted and the Product Owner did what others (like marketing, sales and so on) “needed”. Sometimes someone ordered us to do something and a few weeks later someone else ordered us to roll it back because they liked it better the other way. The only and most important KPI was Page Impressions and features weren’t measured. Management only wanted to know if Page Impressions as a whole were increasing.

Everyone in Product should know by now the amount of challenges this construct comes with. Well, the reason I got promoted was because I did product management. I only wrote a user story, if the goal was clear, we had some kind of transparent measurement in place, did an A/B-Test on it (if possible) and measured the outcome. With this approach, we broke through year over year stagnant metrics and thus improved revenue. Now, I was tasked with bringing that approach to all products.

The challenges

Now, I had to build a team out of individuals. Engineers thought Product was their superior, Product thought they had to obey other business departments, those business departments thought they were owners of partials of the product, Product wasn’t part of any retrospective so that “the engineers could talk openly”, engineers were overwriting the code of peers accidentally on a daily basis… I could go on like that for hours. So, what did I do?

Discovery Phase

Like any good PM, I needed to get a grip on the problem space. Only the problem space wasn’t some pain points of customers. It was the pains of my team members and stakeholders within the company. I observed and analysed all the big and little problems that were happening. I challenged my findings with my team members individually to hear their opinion on the topic. I did that for about two month. Just analysing, validating findings, generating ideas, and challenging parts of the solution. I know many “Your first 90 days of …” tell you to move faster. The cost of breaking something because I still didn’t understand it fully, was too high. And keep in mind. It was my first leadership gig.

Crafting a vision

Before I changed something, I had to know where I wanted to go. What is the ideal state of my team (from today’s point of view)? Many leaders will tell you their goal is to become obsolete. I think this is a buzz-word (or sentence) by now. What does it really mean? Think about it. There are teams that provide zero outcome. They just react to whatever happens. They may not need a leader. Well, maybe to approve their vacation days. I think everyone knows a team that is better, when their boss is on vacation. So, challenge accomplished? I don’t think so.

I had to dig deeper.

Inspired by Christina Wodkte, I formulated the vision of building a self-sufficient team. A team that, when given a product vision, finds a way to execute on that vision and build products customers love to use, without my input. A team that is able to correct processes and directions, when necessary on their own. Selfish as I am, I still wanted to be the one providing the vision, though.

Full Transparency

After I thought I’ve seen, heard and understood enough and knew where I wanted to go, I invited everyone to a team meeting and told about my findings. We didn’t discuss solutions. Just talking about our problems. This was the kick-start of an agile team developing process. This was a crucial step. We had many of such meetings with leaders that came before me ( and we had quite a few of them). Everyone of them already had a solution. So, the whole discussion part felt like a farce. They didn’t really want to know what we thought. They just needed some build up to present their great idea. I didn’t want to do that. I wanted to kick-off a process where we talked about problems and find solutions together. Therefore, it was an open ended meeting. No solution. Just a long list with problems we all gathered. You may think that people left the meeting feeling down because of all the challenges ahead. Yes, they were a bit down. On the other hand, they started openly talking about everything that was wrong. And this is what I wanted. Full transparency.

Roadmapping the shit out of team developing

What I did afterwards was to synthesize this long list into themes and prioritize them. One theme for example was “Expectations”. This bucket entailed every problem with the root cause of uncertainty in roles, goals and so on. This was the first thing I wanted to tackle, as it was the one I could easily solve. But there were others like “Communication”, “Processes”, “Focus”, “Agile Development”, and more. Every theme got a quarter-long slot in my roadmap. I wanted to focus on one theme at a time, moderating a process, where we tackle it together and simultaneously implement a process where once we tackled a problem, we optimized that theme in retrospectives together. The roadmap was a living document. When I saw the need for change, I adapted the prioritization.

Solving one problem at a time

When “Agile Development” was up next, I prepared for it. I read everything I could about that topic. I spend two weeks of vacation days on agile. After that I formulated a plan on how to solve it and presented it to the team. The presentation wasn’t a solution presentation. It was more of a suggestion. It entailed things like: “Getting a trainer for a few days”, “Hiring an Agile Coach”, “Taking time out of day to day business to look at processes and optimize them”. It was more of an epic than a task presentation. Leaving the rest open for further discovery. I think this is crucial because I wanted the team to own the solution, so they had to be involved in every step and participate in finding the way. Just like you would involve customers in your product development process. But you need some starting point. That’s why I prepared something.

End Notes

I think, if you free yourself from forcing typical management advice and just adapt your skills as a product manager to leadership, it can really help you. Don’t think you know it all. Learn and adapt. Listen to your customers (your team members). Of course, I inform myself about good leadership practices and talk to other leaders. But foremost I am still a Product Manager. Nowadays, my products are processes and workflows within my team. And my team members are my customers. I work to solve their pain points. And this is my foremost goal. Therefore, I don’t look ad leadership advice as given. I see it more like a feature I saw somewhere else. Interesting, but now I have to figure out, if it’s relevant for my customers and solves their problems. I might have to adopt it. I might have to leave it for another time. I might even have to leave it be.