Year 5 as RevenueCat Head of Product
31 December 2025 ‧ 10 min read
I am now in my fifth year as Head of Product at RevenueCat, and like in the last years, I wanted to share a few things I learned and took away from this year.
A growing team
My team doubled in size this year—I ended last year with 5 people on my team, and I am ending this year with 10, another one already hired, and two open positions. I started the year with a big hiring spree to play catch-up with engineering team growth and fill some painful gaps, especially on the design side. I then took a bit of a hiring break in the spring. In the summer, we made the conscious decision as a company to accelerate our headcount growth—we call it RC Maxxing. Therefore, I’ve been in hiring mode ever since.
As a company and as the product and design team, we’ve been through phases of rapid growth before—after all, when I joined, my team was just myself and one designer. However, I feel that this year my role evolved more dramatically than it did before, and that I had to stretch and learn quite a bit (and made my fair share of mistakes in the process).
Evolving structure and delegation
With a team of 10 (and growing), this was the year that I needed to start putting a substructure in place in my team. In the product management team, I now have two GPM roles—very senior product managers who are also managing a few more junior product managers. I made this change relatively late in the year, so I wouldn’t say that I have completely adjusted to this new reality of—at least partly—managing managers, but at least it has already provided me with more leverage.
There are also more topics that I have delegated (or let team members run with voluntarily) that I would have felt the need to own in the past. Among other things, folks on my team have driven forward new product analytics and research tooling and an overhauled product feedback process. I’ve also delegated key steps in both the PM and design hiring process to team members that I used to do (or at least participate in) in the past.
More delegation and an additional management layer has meant though that at times I felt less informed and on top of everything that is going on in my team than I used to be. To some extent, that is of course inevitable—you can’t keep the same amount of context in your head for a team of twice the size. However, there were times where I felt like I was caught flat footed by some development and had to scramble to keep up. I still need to hone my ability to suss out where my attention is most needed across a bigger team.
In some instances, being more removed from some of the day to day work of the team has also made me become more impatient. When I was looking at the difficulties and obstacles that need to be overcome every day, it was easier to understand why sometimes things are taking longer. The more removed from that I have become, the more I sometimes have the feeling that we should be making progress more quickly. I don’t know if that’s a good thing or a bad thing.
RevenueCat’s Design Ascension
One of our strategic focus areas for this year was “RevenueCat’s Design Ascension”: putting more emphasis on both the user experience and visual aspects of our products. We had big plans for this, including additional polish for a number of consumer facing aspects of our product, as well as a redesign of our dashboard. To achieve all of this, we grew our design capacity quite a bit. In November of 2024, there was only one designer on the team, and by May of 2025, there were four designers (and a UX/UI engineer reporting into engineering).
For me, this also meant that I found myself as an accidental design leader (without any design background myself). I think that I have reasonably good understanding of user experience and a lot of context in our product and our customers’ needs, so giving feedback and guidance to the individual designers on my team was not something I struggled with. However, a working design team needs much more than that, including common design fundamentals, guidelines, principles, etc. None of these are things that I had experience setting up.
With a lot of help by the individual designers on the team, I think we managed decently well to address some of the most glaring issues. However, it became clear to me (perhaps later than it should have) that I need additional support and leverage, so I decided to hire a manager for the design team (who will start early next year).
Coordination & shipping the org chart
Another challenge that is increasing with the number of teams is the coordination that is required to ship a cohesive product experience. The risk is “shipping the org chart”, also known as Conway’s Law:
Organizations designing systems will inevitably create designs mirroring their own communication structures.
In other words, according to Conway’s law, you will notice the organizational setup of the company that built a product in the user experience of the product. This can never be completely avoided. The best way of addressing this is setting up the organization in a way that mirrors what you want the product experience to look like (also known as Inverse Conway Maneuver). However, that only goes so far. We have needed to take additional measures, such as setting up goals across teams or forming temporary teams to build good experiences across the areas of responsibilities.
Much more still needs to be done. Our features are still often isolated from one another and not very well integrated. We have laid some foundations and started some initiatives for tighter integration of our features and functionalities, but we are not there yet (and frankly, I wish we had gotten closer to a well-integrated set of features this year).
Maintaining focus
Last year, I wrote about streamlining our goal setting, moving from wanting to have a goal for every team to a tighter set 3-4 company wide shipping goals (also known as “ship-or-dies”). This setup still served us reasonably well in the beginning of the year, but over time, we began slipping and not delivering even this tighter set of goals.
In the last quarter, we tightened the focus even more, and ended up with a single goal (which we did manage to hit). We will see what we will do next year.
There is a lot to unpack here, and I don’t think we fully appreciate the entirety of why we started slipping in terms of meeting our goals. However, I think one aspect is that there were a few teams who ended up having one of these goals every quarter, which has multiple drawbacks: firstly, it means that the team is constantly under more pressure than is sustainable in the long term. In addition, it means that the team might have taken on some technical and product debt initially to meet the first goals, and that debt then slows them down later on (if they don’t have a quarter with more slack that they can use to pay down some of the debt).
It’s a constant challenge that we haven’t figured out as a leadership team. We will keep iterating.
Engaging a bigger team
As a last point on the topic of team growth, there are a few things that I started doing this year in order to keep a bigger team engaged. I mentioned last year that I had rebooted some of the team rituals, and they saw a bit of an evolution this year. We held the first product & design offsite in Berlin in February, which was very good—we had a bunch of new team members, so getting to know others in person was great for connection and morale. We also got to have deeper conversations about the longer term evolution of the product, as well as drilling down into some medium term challenges, both of which we usually don’t find the time for in the day to day.
Outside of the offsite, in our regular remote working environment, I also experimented a bit with formats for workshops and collaboration. What I found particularly promising was breaking the group into small breakout teams of 2-3 and then tackling parts of a broader problem before reconvening to discuss what each team had come up with. In a team of 10, group discussions otherwise become very lengthy and don’t give everyone time to participate a lot. I will continue experimenting with this kind of format going forward.
Points of pride
Here are a few things that the team achieved this year that I am particularly proud of. Of course, there are many more things—in fact, just thinking about where we were at the beginning of the year vs. where we are now makes my head spin.
Dashboard redesign
In Q2, we redesigned the overall layout and navigation of the RevenueCat web dashboard. The design team had been thinking about and proposing versions of this redesign literally for years. Our old navigation structure with four navigation items across the top was not scalable (we literally could not add top-level items due to lack of space) and it was also really super inconsistent (in some areas you selected the project first, in some areas second, and in some it was just an optional filter).
I am particularly proud of this project for a few reasons:
- We did our homework. As mentioned, this project had been an idea for a couple of years, and had undergone a number of rounds of usability testing already. When we decided that 2025 was going to be the year of RevenueCat’s Design Ascension, we knew that this project was going to be a major pillar. However, we avoided the temptation of jumping straight in but took Q1 to make sure that we resolved the open questions.
- We didn’t boil the ocean. A redesign has a lot of surface area since it literally touches every single page. We found a way to implement the redesign in which we changed some styles to the main containers of the pages, but beyond that, we mostly moved existing pages into the new layout without completely redesigning every single page. This meant that we were able to deliver the redesign really quickly from an engineering perspective.
- This was a team effort. There were many people involved in this project, including everyone on the design team. Without everyone’s contributions, we could not have shipped this so quickly.
- The response was overwhelmingly positive. A redesign is always a bit of a dangerous project—people have established workflows and have gotten used to achieving results in a certain way, and a redesign breaks those workflows. As such, we were fully prepared for some amount of negative feedback. What the feedback actually showed, though, was that the vast majority of customers preferred the new design (which in turn is a proof point that we successfully did our homework).
Moving fast on Epic v Apple
In May, a US court ruled in the Epic v Apple case that Apple must not forbid linking out to web purchases in apps selling digital goods. The team at RevenueCat immediately scrambled to support developers to experiment with this new way to monetize their apps as easily as possible.
We had our annual company offsite the week after that decision, which meant that the offsite turned into a massive hackathon, with multiple teams working on different aspects of the experience. It was amazing to see the energy and dedication across the team.
The situation was also a vindication of some strategic investments we had made over the preceding two years, especially in our Paywalls and Web Billing products.
A team of builders
At some point this year, I made it my secret, not-so-secret goal to enable everyone on my team to ship code. Thanks to AI assisted development, we are now in a world where not knowing how to code is not an insurmountable obstacle to that.
Of course, I am not claiming that you can write production grade backend code for a system like RevenueCat without understanding what that code does. That's also not the goal. In fact, one of the goals we have with product managers and designers shipping code is increasing their understanding of the code base.
PMs and designers have shipped some small features independently, and have unblocked themselves from relying on engineers for every small change. A good example is when the design team decided to remove one variant of our buttons. In the past, this would have meant that the designers would have gone through all screens, made a list of where an outdated button needs to be replaced with a different variants, created a ticket out of that, waited for an engineer to pick it up, fielded the inevitable questions, QA’ed the change and possibly iterated with the engineer, etc. Now, the designers made a PR that everyone contributed to and were able to ship the change quickly, which meant lower lead time and less total time spent.
We are still finding the right balance on how much “vibe contribution” makes sense. Especially more complex changes that aren't fully understood by the vibe coding contributor can put a strain on code review, and some features like that are easy to get to an “almost working” stage but hard to get over the finish line without proper engineering involvement. However, as the tools and our knowledge how to best employ them improve, I am certain that product managers and designers will ship more and more complex changes independently.
In the end, product managers and designers at RevenueCat are product builders, not stakeholder wranglers and pixel pushers. Whatever we can do to ship quality software that delivers value quickly, we do.
Starting the journey of becoming a multi-product company
Perhaps the most important and exciting aspect of this year’s work was that we started on the journey of becoming a multi-product company. I wouldn’t really call this an “achievement”, yet, since we are in the very early stages of this journey, but we’ve made some good first steps: we have some customers for our fintech product Daily Payouts which pays out proceeds from App Store purchases immediately (rather than the 30-60 days later that Apple pays). We also have a couple of customers who are using RevenueCat only for paywall experimentation, not for the full platform. We are also making progress on being able to support ad monetization in addition to in-app purchases.
All of these endeavors are in their infancy, and they will require a lot more work, attention, and intention next year and beyond in order to become meaningful contributors to our growth. Still, it is very exciting that we are going down this path.
A personal note
One thing is more on my mind at the end of this year than ever before, and that’s health. I am, by most standards, in quite good health. However, I had a couple of experiences this year that made me more keenly aware of how fragile my health is and how when health is not a given, everything else ceases to matter. On New Year’s Day 2025, I felt a sudden pain in my abdomen that quickly became so debilitating that I could do nothing but lie down. I could not even pick up my phone to text my wife that I needed help. Eventually, my kids found me and told my wife: “Mum, I think Papa is not okay!” My wife called an ambulance, the EMTs gave me a shot of a painkiller and rushed me to the ER. Already on the way to the ER, the pain started subsiding as quickly as it had come. I later found out that it was a kidney stone that had gotten stuck, and when it got dislodged again, the pain was immediately gone. Scary, but luckily no lasting damage.
Then, in the fall, I got really sick with the flu. Luckily no hospital involved, but I was in bed for two full weeks and had a fever for almost four weeks. Even when I was able to finally get up out of bed, I was so exhausted all the time that I could barely walk up a flight of stairs without wheezing and being completely out of breath. The doctors ran a bunch of tests, but in the end basically told me there’s not much they can do other than treat the symptoms and wait for the viral infection to pass.
Luckily, by now, I am completely back on track again. However, these experiences this year have made me ever more thankful for my health.
So here is to a hopefully healthy and successful 2026!