Year 4 as RevenueCat Head of Product
6 January 2025 ‧ 8 min read
I entered my fourth year as RevenueCat Head of Product in 2024, and in keeping with the tradition from the last couple of years (1, 2), I wanted to share some reflections on this year.
Going full IC PM mode
One of our most significant initiatives in 2024 was building our own web purchasing solution, complete with a web SDK and billing engine. This work began in late 2023 with an engineering-led technical proof of concept. While the team delivered an initial demo in December 2023 that showcased core functionality, it lacked clear direction and scope.
In January, I made the decision that I needed to step in and become the PM for that team near full time to clearly scope out an initial beta version we could launch by the end of the first quarter – which we did manage to do.
In fact, I didn’t just play the PM role, I even contributed quite a bit to the code base for the feature (on the frontend side), because I felt like this was what was necessary at that point in time to make sure that this new product started off on the right foot.
The power of deadlines redux
One of the themes in last year’s article was “deadlines might suck, but they work” and this year I saw the same thing happen again. The first of these deadlines was the ambition to launch RevenueCat Billing in Q1 (for which there was obviously no external pressure), and we had several additional internal deadlines that we set during the year.
I don’t think that all development should be deadline driven, in fact, probably most of it shouldn’t. Also, a team that has just delivered against a tight timeline should probably be given a little bit more slack afterwards – not to slack off at all, but to clean up some of the debt and fill in some of the gaps that inevitably get introduced when rushing towards a deadline.
I did also experience that beyond the sense of urgency, deadlines also do have a rewarding function. Especially if a deadline is challenging to hit, shipping just in the nick of time can give the whole team a sense of shared achievement.
You can just do things
One of the features that has long been on the RevenueCat backlog is LTV (customer lifetime value) prediction. In fact, we used to have an LTV prediction model in our experiments feature which was written by our CEO way back in the day, but the whole system was very unpredictable and hard to debug, so we killed it at some point, waiting for the right time to build a better replacement.
In the beginning of 2024, we were making plans for how to tackle the problem, and we decided that we needed to hire a second data scientist to do so, since the one data scientist on the team was always very busy with other things. Then began an endless debate about the ideal data scientist profile, with each team advocating for slightly different skills. At that point, I was the hiring manager for that role (since then, data science has moved to a dedicated data team). I found it hard to reconcile these differences because everyone had good points, but it felt like what we were getting to was the description of a unicorn candidate that would be impossible to hire.
This made me completely change the approach. Instead of starting the hiring process, I proposed that we would just do a six-week time-boxed MVP version of the LTV prediction with the people that we had. This meant we freed up the capacity of our data scientist and had him work more or less only on the model for six weeks (with some follow-up work for the engineering team to build the actual feature around the predictive model). This would then also help us determine what the right profile for someone to own this feature in the long term would be.
It turns out that this was absolutely the right decision in retrospect. Not only did we manage to build a reasonably well performing model in the six week time-box, but also did the hiring turn out to be much more difficult than we had anticipated. Even with the sharpened requirements after the time-boxed MVP, we still hadn’t managed to find the right person by the end of the year – so if we hadn’t done the MVP, we probably still wouldn’t have shipped any LTV prediction.
Speeding up team changes
We made two big sets of team changes in the engineering, product, and design (EPD) org in 2024. The first happened in the middle of the year and took us from 6 teams to 9; the second happened at the end of the year and reshuffled some teams, ending up with 10 teams.
The first change was definitely long overdue. After 18 months without changes to our team structure, features like Paywalls (built by a temporary project team) lacked a permanent owner.
In retrospect, I think we debated a bit too long before this first change. We had known for a while that we needed a proper home for the Paywalls product in particular. The second team change this year I think we tackled a bit more proactively, and with what I consider to be a good amount of deliberation – not completely shooting from the hip but also not too reluctant to rock the boat.
Scaling without process overhead
Almost doubling the number of teams also meant that some of our processes needed to adjust. In general, there is a tendency to add processes the more the team scales (after all, you can’t rely on everyone knowing everything that is potentially relevant to them anymore by accident, so you need to put in place mechanisms to align different teams). In 2023, one of the big focus areas and learnings was removing process in favor of content discussions, and we tried to stick with this this year.
However, some processes that worked with 6 teams stopped working with 9 or 10. One tangible example is that we used to have a planning meeting between EPD leadership and each of the teams each quarter, and that would have taken up too much time. In the last few quarters, we switched to asynchronous proposals with recorded video updates, followed by short Q&A sessions with Jacob (CEO), Miguel (CTO), and me. This was a more effective use of our time. However, it was also exhausting (15-minute meetings with each of the teams back to back), so we might readjust this process in 2025.
On a similar note, I overhauled the process by which we share roadmap updates from the product team to the broader organization. We shifted roadmap updates from infrequent, high-fidelity updates to more frequent, lightweight updates in Notion. We will see how this holds up.
Rebooting the product & design team rituals
On a similar note, I had pruned quite a few of the regular rituals on my team in 2023 – especially the joint product & design team meetings felt like they had become more of a status update discussion than anything else, with often no specific agenda items. After we had some great discussions in the team at our company offsite in May, I reinstated the meeting at a bi-weekly cadence, and added some regularly recurring discussion items. So far, I am liking this change – we have had quite a few good discussions in the new team meeting.
I think the most important point here is again to keep these expensive meetings with multiple participants focused more on content than on progress, and on interactivity instead of broadcasting – the latter can often happen much more effectively asynchronously.
Not waiting too long to hire
This has been the most painful lesson this year, and to some extent, it is the inverse of the above learning “you can just do things” and “going full IC PM mode”. After I spent some of the early parts of the year hacking through Gordian knots to help the teams ship RevenueCat Billing and LTV Prediction, I should have created more leverage for myself and my team more quickly. In particular, I would have needed to hire a dedicated PM and designer for the RevenueCat Billing team earlier than I managed to (both ended up starting in Q4).
There are multiple factors at play here. Firstly, going full IC mode obviously meant that I had less capacity to run a hiring process. Secondly, I prioritized my hires wrongly, starting to hire for a data scientist (the hiring process for this moved to a different team later in the year as part of the reorg, but it meant that I didn’t start hiring for a PM until much later). I also made the mistake of sequencing rather than parallelizing hiring processes.
In the second half of the year, I was able to speed up the hiring processes by doing two things: firstly, hiring for a PM role and a designer role in parallel, and secondly, leaning on some people from my team to conduct some of the early stage interviews – in the PM case, my most senior PM Dan is conducting the initial phone screen, in the designer case, my then-only designer Bárbara is conducting the portfolio review. In addition, I received some additional help from the recruiting side, which has further helped speed up the process. However, in particular on the design side, we were severely underresourced for the last few months, which increased the level of stress on the team unsustainably. It is one of the biggest takeaways from this year that I will attempt to not let this happen again – a lean organization is good, but not at the cost of bottlenecks or burnout. I’ll prioritize earlier hiring in the future.
Increasing our focus and ambition level
Last year, I wrote about how we moved away from OKRs toward quarterly “shipping” and “selling” goals. The challenge we faced with this list of shipping goals in the middle of this year is that it became longer and longer (since we wanted everyone to be able to relate to some point on this list), and therefore it didn’t really provide a lot of guidance in terms of what were the most important things we were working on. As a result, we often failed to meet the goals by the end of the quarter. Now, it is understood that when setting ambitious goals, you will not always hit all of them. However, in our case it seemed that we failed to hit the goals more often than we hit them – it seemed they had simply stopped mattering.
Therefore, in Q4, and driven mostly by Jacob, we reduced the number of goals to 4, and then reinforced that these were things that were more important than any other work that was happening. This really helped improve the focus and redeploy our capacity in a way that made sure that these most important initiatives got pushed forward with all the force we could muster.
This doesn’t mean that we didn’t also do other things; on the contrary, I feel like we did and shipped more things in Q4 than ever before. However, it also meant that we didn’t end up in a state where for all of our really important bets, we didn’t get to where we wanted by the end of the quarter. Overall, this was a great and necessary change, and we will stick with this approach for the foreseeable future.
Attending a couple of conferences
This year, I also managed to attend a couple of conferences (both in Berlin), which was a lot of fun. (My only previous conference appearance representing RevenueCat was in 2021, but it was COVID times and I only gave a remote talk).
The two conferences also could not have been more different: One was Droidcon / Fluttercon, which was massive with 2000+ attendees in a big conference center, most attendees being engineers. As a general mobile developer event, there were of course some RevenueCat customers there, but we spent a lot more time at the booth explaining what RevenueCat does and how it helps developers (make more money).
The other one was App Promotion Summit, where I also gave a talk. Much smaller, and focused on marketers and growth people, and hosted at the swanky Adlon hotel. The discussions we had here were very different – much more about “how do I actually make more money”, “how do I use RevenueCat to achieve this use case that I have”, and “what do you see other apps typically do”.
Overall, this was a very valuable experience, and I hope to repeat this next year. (One event that I didn’t manage to attend this year but very much have on the list for next year is our own conference, RevenueCat App Growth Annual.)