My Product Leadership Reflections on 2022

Some things I learned last year

It’s been a while since I wrote a year-in-review post — five years, after my first full year as a product manager at Yammer. 2022 was not my first full year as Head of Product, but it was momentous for me in my role at RevenueCat. I went from managing one person at the beginning of the year to six at the end, which is more people than I have managed before.

Here are some of my takeaways from this year:

1. Preparation helps have tough conversations
2. Product team dynamics can be tricky the get right
3. There’s a balance to strike between belonging to functional and cross-functional teams
4. One person does not make a team, but two people do
5. Getting planning processes right takes multiple iterations, every single time
6. Too much work-in-progress is a velocity killer
7. I didn’t manage to write as much as I wanted

More details on each in the following.

Preparation helps have tough conversations

I had to have a couple of tough conversations this year in which I had to deliver critical feedback. I think in the end, these conversations all went well and had the intended effect of getting the person to address the feedback. Having these conversations was still hard, though.

What helped me was very thorough preparation. I wrote out the entirety of the feedback in detail first, ensuring that I had all the points I wanted to make, all the situations I wanted to describe, all the expectations I wanted to lay out, and the storyline tying everything together all lined up.

Especially in the cases where parts of the feedback I needed to deliver was based on what I had heard from third parties, it made it clearer where I didn’t have sufficient information yet to be really clear in my delivery.

The other aspect that I think made the conversations successful is to come at them with the attitude of wanting to support the person and make them successful. While the communication of expectations needs to be super clear and unambiguous, I was able to provide my support for thinking through the feedback and working on the challenges in any way that I can.

Product team dynamics can be tricky the get right

This year, at RevenueCat we went from one big engineering team to five different product / engineering teams. This entailed hiring three product managers and three engineering managers, people changing reporting lines, etc.

While I think that by the end of the year, the teams are all operating quite well, it was definitely not a super smooth road to get there. For one thing, org changes always affect people more than I expect. The uncertainty and changes in relationships that people have to navigate causes friction and a period of readjustment. This is made even more difficult when filling vacant key positions takes some time.

In addition, some of the teams evolved different sub-cultures and saw very different personalities having to find ways to collaborate effectively. This caused quite a lot of friction and needed time until it had sorted itself out. While this is of course to be expected (the whole forming / storming / norming / performing idea), I wasn’t ready for the attention it took from me to help sort it out.

In the future, I think I will pay more attention to potential issues like that earlier in the process in order to be able to support and/or prevent issues from escalating too far.

There’s a balance to strike between belonging to functional and cross-functional teams

Many modern product development organizations have a kind of matrix organization, where people report to a functional manager (e.g., engineering manager, Head of Product) but work mostly on cross-functional product teams between engineering, product management, and design. This creates a bit of tension as to what the primary “team” is, and how much time and energy to spend aligning with the functional vs. cross-functional teams.

In our current setup at RevenueCat, we lean a lot more strongly on the cross-functional side. On the product and design team, we have very few functional touchpoints with the whole functional team. Partly this is due to our remote and asynchronous setup which makes group meetings hard to schedule and also in general undesirable. Large parts of functional alignment happen in 1:1 conversations (between myself as Head of Product and the PMs and designers on my team, but also in 1:1s between PM and design peers).

I don’t know that the current setup is optimal, and I think it will require more fine-tuning going forward.

One person does not make a team, but two people do

The jump from one person of a function to two is a much bigger jump than from two to three; perhaps even than from zero to one. As soon as there are two people, you have to be more deliberate about how you do things. Before the second product manager (in addition to me) started, I spent a lot of time writing down the ideal product process, making implicit knowledge explicit. This also serves as a great opportunity to revisit opportunities to improve processes or make them more consistent. The same thing happened when the second designer joined the team.

In addition, when I managed a single designer, it didn’t feel really like managing a separate team — there was only a single person with a different functional specialization. As soon as the second designer joined, I needed to pay much more attention not just to how the individual designer interfaces with the rest of organization, but also how design as a function / team does.

Getting planning processes right takes multiple iterations, every single time

I have by now gone through 4 introductions of quarterly (OKR) planning processes, and every single time it’s taken several iterations to get into a somewhat steady state. At RevenueCat, for 2022 we set up more formalized annual goals for the first time in December 2021. By May, we realized that the annual goals were too inflexible and implemented quarterly OKRs for Q3. We have now just gone through the third iteration and are only now starting to find a rhythm. Some of the key challenges we faced especially in Engineering, Product, and Design were:

• How to have enough lead time to allow alignment at the various levels and defining initiatives: we are now at roughly six weeks which seems to work relatively well
• How to ensure alignment both within the engineering and product/design reporting chains as well as between the functions at various levels: we are now having cross-level and cross-functional alignment meetings early and then multiple times throughout the process
• How to define OKRs in a way that leaves room for the teams to best decide how they will deliver on them, especially for teams that are working on multi-quarter projects: this one is very much a work in progress still. It always seems easy and straight forward in theory but in practice it’s much harder to define outcomes in a way that strikes the right balance between specificity and empowerment, and that are also within the realm of control of the product team.

Too much work-in-progress is a velocity killer

This one isn’t really news, but this year was the first time I really witnessed how too much work in progress can slow the entire team down. I wrote an entire post about the topic so I won’t rehash it here, but going forward I will definitely pay more attention to the early warning signs of high WIP.

I didn’t manage to write as much as I wanted

I had the goal of writing at least a post a month, and I very much failed at it halfway through the year. I got really busy with work afterwards, and also it can be hard to find enough time to reflect and write up meta observations down in the trenches of day to day product work. I did, however, give some product management talks, including a virtual session at mtpcon, which was a lot of fun.

I will see if next year I can keep up a more regular posting schedule. I sure don’t expect to be less busy.

I hope you found this article useful. If you did, feel free to follow me on Twitter where I share thoughts and articles on product management and leadership.