Year 3 as RevenueCat Head of Product
10 January 2024 ‧ 9 min read
I joined RevenueCat as Head of Product mid-2021, so 2023 was my third year in the job. The story so far was as follows:
The theme of 2021 was to take RevenueCat from MVP to robust product. I established a first iteration of a product strategy to align the organization on what to focus on (and more importantly, what not to focus on), and we shipped a bunch of things that fixed legacy problems, including Charts v2 and Projects.
2022 was the year of taking the engineering, product, and design (EPD) org from 1 to N. At the start of the year, I was the only product person, and all of engineering still worked as more or less one team. Over the course of the year, we built out seven different teams on the engineering side, and my team grew from myself plus one designer to three PMs, two designers, and a data scientist. This required additional processes, ways to communicate, and alignment mechanisms.
What happened in 2023
The RevenueCat EPD theme of 2023 was, in many ways, stabilization and optimization. We called it the the year of go-to-market, the year of shipping or also the year of efficiency. We had made the decision already in mid-2022 in the light of the changing business environment to not grow at all costs, and that continued in 2023. We did not add any net new teams over the course of the year on the EPD side, but rather filled out the gaps that we had.
If you want to read the story of a lot of the things that transpired this year in RevenueCat’s EPD org, I encourage you to read the post of CTO and Co-Founder Miguel – I will keep it a bit briefer, and instead focus on what I learned.
From my perspective, the year started off with a lot of energy – in January, we were shipping a lot of things that had been almost ready to ship in 2022. Then, however, things took a turn for the worse. We landed in a reliability crisis with several high-profile incidents and it became clear that the status quo was untenable and we needed to reprioritize our efforts to become rock-solid, quickly. This also meant that I spent much more time on reliability questions than I usually do – the questions I helped answer were about “if instead of going down, our system degrades gracefully, what kind of degradation is most acceptable to our customers”. Luckily, our investments immediately paid off as we were able to mitigate the impact of a major Apple outage just days after we had shipped RevenueCat Fortress.
We had also hit a wall in several other areas of the org and needed to pull ourselves up by our bootstraps – our support for Google’s new subscription model took much longer than originally anticipated to deliver, and some of the processes and tools that we had set up in our original team setup proved to hold us back more than they helped us.
We started hitting our stride in the second half of the year, shipping several high-profile features, starting with the aforementioned Google Subscription Model, over Paywalls and Targeting. We had made and are making deliberate changes to culture, processes, and team setup to facilitate this – more on that below.
We left the year with high spirits – wrapping up December with a week-long hackathon that yielded several shipped improvements and a few more that are close to shipping.
My lessons learned in 2023
Here are some of the lessons that I took away from 2023, in no particular order.
The right people in the right seats
In 2023, I gained more clarity on what makes for great product managers at RevenueCat. There is the age-old question “how technical do PMs need to be” – and it turns out, for RevenueCat, the answer is “quite a bit”. RevenueCat is a technical product, with large parts of the product focusing directly on engineers. Being able to reason through the developer experience is part of product managers’ jobs at RevenueCat, even if it is not their main responsibility.
That still doesn’t mean that PMs necessarily need an engineering degree, but that they need to have the technical chops to build up an understanding of the technical context, even if it is unfamiliar at first. (I had never designed REST APIs before RevenueCat, but with some research, it’s not rocket science.)
Balance between PM and Engineering
An interesting side effect of having PMs that have deep understanding of the more technical aspects of the product, though, was that we witnessed a bit of a slippery slope: PMs started solving more and more of the critical problems of projects before engineers started to work on the project. Often, input from Engineering was solicited in the process, but the ownership of the project stayed with the PM until it was deemed ready to implement. This was done with the best intentions of keeping engineers unblocked and not passing half-finished concepts over to engineering, but it had a very negative effect on the empowerment and ownership of engineers. Because they got used to having critical questions answered for them, and because they were lacking some of the context, they relied more and more on PMs to make all critical decisions. It was a bit of a vicious cycle, so we decided that we needed to pull back.
The change that we made was to make product management more strongly responsible only for customer value and business viability, engineering for technical feasibility and developer experience, and design for usability. Most of the time, in the earliest phases of a project, the ownership is still with the PM. The main difference is that once the most critical assumption becomes one of technical feasibility (for instance), the ownership passes over to Engineering (or design, if it’s about usability).
A good example of this approach (before we formalized it) was the Paywalls project. The project had big questions both about customer value (can we build something that’s valuable to customers) as well as technical feasibility (can we build it in a way that doesn’t take forever, scales across the platforms we support, etc.). The way that we approached this was that Dan, the PM responsible for the feature, and myself spend a couple of intense weeks collecting evidence of the customer needs and problems by scouring through tickets, interview and sales call notes, and conducting additional customer interviews. We then summarized the findings and handed the work over to the engineering team which spent a couple of weeks building out a proof-of-concept for an initial iteration of a product that could deliver against some of those identified needs. The PM played a supporting role during that time, helping answer questions about customer needs and providing input, but Engineering was decidedly in the driver’s seat.
Performance management and letting people go
Probably the toughest lesson learned this year, but an important one. I had to go through some performance management processes and also had to part ways with a few team members. I am, of course, far from an expert on the topic, but the main takeaways for myself from the experience this year were:
- I should act more quickly on anxieties – when something feels off, it probably needs action.
- I need to always share feedback quickly and frequently (duh)
- When having difficult conversations, preparation is the most important aspect for me – I felt that the preparation was much harder and mentally draining than the actual execution.
- There is surprisingly little content about the actual act of letting someone go. Maybe this is because it is hugely dependent on the HR processes of different organizations. Two pieces of advice that helped me, in the end: One is from Julie Zhou’s “Making of a Manager”: “When you decide to let someone go, do it respectfully and directly. Don’t open it up to discussion (it isn’t one), and don’t regard it as a failure on the part of your report. […] Be compassionate in examining the past, but focus on the future and don’t prolong the breakup. Help your report get on the best possible path toward the next chapter, and use the experience to become a better manager.” The other was from our CEO Jacob, and it was to say “Today, we are only going to talk about the logistics”.
Partnering as Engineering & Product leadership
One major change and lesson learned on the engineering side is that engineering leadership and management needs to be close to the content (product) that is being worked on – mainly being a steward of engineering processes and skills development was not effective for us at RevenueCat.
As a consequence, I now have a much closer partnership with our CTO and Co-Founder Miguel –and even changed my reporting line from our CEO Jacob to Miguel late in the year. I think this change was super positive. It has made Engineering care more about the product, and given me a more effective partner to work with through product strategy, team setup, and goal setting than ever before. While Jacob obviously has strong opinions on the product side as well, his main focus had become the go-to-market aspect, and collaborating with Miguel really helps get Product and Engineering in alignment.
More content, less process
More broadly speaking, over the course of this year we have dramatically simplified a lot of the processes, and it has been for the better. There were a lot of changes that we made, but here are some of the biggest ones.
We used to have a quarterly OKR process across the company, and it wasn’t really working well for a number of reasons. Some of the fundamental criticisms that I had about the approach are well summarized by Figma CPO Yuhki Yamashita in this interview:
What I really like about his summary is the phrase that “a commitment can be a why with many whats behind it, or a what with many whys behind it”, and that wasn’t really mapping well to OKRs, and in addition we spent a lot of cycles on the KRs that ended up not really mattering at all. In the last quarter, we moved away from OKRs to commitments (or “shipping and selling goals”, as we call them).
While reducing the process overhead, we conversely started talking more about content across all levels of the organization. One example here is how we review the roadmap and plan for each of the teams. We started out the year with having a monthly “30/60/90 plan review” between our VP of Engineering and myself and each of the teams. The 30/60/90 plan was owned by the Engineering Manager of each team and showed what the team was planning to deliver in 30, 60, and 90 days (with decreasing precision). However, updating the plan created additional overhead, and the discussions tended to focus more on whether the team had a solid plan than on the details of what the team was actually working on. Over the course of the year, we have evolved this to a monthly “roadmap & shipping review” with each of the teams. In addition to myself, both co-founders are participating, and instead of talking about the plan, we are talking about the actual content of the work and the decisions that the team is making. This provides more valuable feedback to the team while simultaneously keeping CEO and CTO more informed with what’s happening on the project.
Lastly, we finally moved to Linear from Jira, drastically removing the amount of process administration required to set up simple engineering workflows.
Sweating the (design) details
2023 was also the first full year that I had two designers reporting to me, so, for better or worse, I am also a design leader. Of course, I am not a designer by trade, but I started to work with the designers to sweat some of the details of our UI/UX a little bit more. RevenueCat is not a design oriented company – built by engineers, for engineers, a lot of the dashboard UI is mostly functional in nature. However, some of our concepts are already confusing, and as a team we’ve started pushing to make some of the entities more distinct. Without attempting to take credit for any of the work of our two amazing designers, I do think that we managed to ship some new UIs that are a far cry from the tables found elsewhere in the product, for example, the UI for targeting:
The power of deadlines
I didn’t really use to believe in deadlines. Asking Engineers for when they think they’ll be done, sure. Pushing to reduce scope to ship earlier, sure. But deadlines? They gave me the impression of death marches, not understanding the uncertainties of software development, waterfall planning, and so on.
I have changed my stance on this quite a bit this year. I now believe that a (self-imposed) deadline can be a catalyst for actually getting things out the door, and not falling into the trap of the last 10% of the project taking as much time as the first 90%. Setting a deadline can also be a forcing function for reconsidering scope cuts again and again – sometimes, if it turns out that one aspect of the project takes more effort than originally thought, in order to still hit the deadline, the team will come up with more creative solutions to reduce the scope – constraints breed creativity.
Complexifying vs. simplifying
This quote from Maggie Crowley really stuck in my head in the last couple of months of the year:
Some people, a broad generalization that I think comes up in things like when you're interviewing PMs for a job and you say things like are they a simplifier or are they complexifier? Do they make things complicated? And so some of it's a little bit of just who you are and how you think.
I’ve started to use this distinction a lot to think through both how people are acting (complexifying or simplifying), but also about how I and teams I am a part of are tackling a problem: are we adding or removing complexity?
Reaping the benefits of a remote organization
The last point isn’t so much a lesson learned as more of an achievement that I really enjoyed this year. I was finally able to make full use of being part of a remote company, and spend a couple of months with my family traveling through Asia and Australia. While I wouldn’t want to live the digital nomad life every day (especially not with two young children), for a couple of months, it was amazing, and I felt amazingly privileged to be able to do that.