Customer Obsession
15 August 2025 ‧ 4 min read
Customer obsession is one of our values at RevenueCat, and should be at the heart of any product manager's job not just at RevenueCat but everywhere. In this article, I want to share a few thoughts on what exactly it means to be customer obsessed.
Customer obsession means that we keep talking to customers, and that we never believe that we know better.
The number one way of being customer obsessed is, of course, talking to customers. The best way to do this is to do customer and user research—trying as best as you can to talk to as many customers as possible. Talking to at least one customer a week is a totally attainable goal. (Unless you are in an organization that blocks PMs from talking to customers—I feel for you.)
Of course, not all "talking" needs to be face-to-face conversations. Other ways are reading (or even better responding to) support tickets, engaging with customers on social media, attending to or watching recordings of sales calls, talking to people at conferences, etc.
One of the things I often say is "nothing shatters your world view like talking to customers". No matter how good your intuition is for what the average customer wants from your product, the reality is that there is always a very broad range of customer types, use cases, etc. Only continuously engaging with customers will give you an appreciation for that breadth.
Humans are pattern matching machines.
Humans are very good at pattern matching, recognizing something that happens a few times and realizing that it has a meaning. I am personally not a fan of keeping long backlogs of everything you've ever heard from customers. Instead, I like to rely on the pattern matching capabilities of product managers on my team—if something comes up again and again, it is probably something we should act on.
Sometimes, this can be random, like when 3 prospects in a row ask for an integration with an esoteric third party tool. So you shouldn't only act on patterns. Other times, however, this is the best way of detecting trends and emerging needs—since you don't just churn through a backlog, you can be more reactive to what is important to customers now. And the things that would rise to the top of the backlog will come up again and again over time anyway.
Customer input should inform our mental model.
Customer obsession doesn't mean blindly building everything that customers ask for. Sometimes it means not building it at all ("faster horses"). Instead, product team members should build up their own mental model of customers and their problems and needs. Every subsequent interaction with customers then evolves that mental model. When it is time to actually build something, use the mental model to determine how to best meet customers' needs. Of course, you should still validate that—a mental model is only a model and has flaws.
Shipping quickly is customer obsession.
Related to the previous point, shipping quickly and iteratively is another core tenet of customer obsession (and also RevenueCat's second value, "Always Be Shipping"). No matter how well you understand customers, no matter how good your mental model is, no matter how well you have validated a product idea before shipping it, you can only really tell how customers are going to use your product once they actually have it in their hands.
The following thing has happened enough times for me to consider it a fundamental product development truth: the team has a goal to ship something by a certain date, and has determined a scope of all the must-haves to ship by that date. Inevitably, some complication comes up which means shipping the agreed-upon scope by the target date is no longer feasible. Instead of pushing out the date, the team decides to cut scope. Begrudgingly, some of the must-haves get demoted to nice-to-haves, even though the team doubts the usefulness of the feature without those must-haves.
Fast forward to when the feature ships. Customers start using it and see that the feature is incomplete and flawed—but the funny thing is, what they request to be built next isn't the former must-have, it is something different. This might be despite customers having said that they needed the must-have when they were testing early prototypes. In truth, nobody can really predict how they will use a product or feature once they actually have access to it.
This has happened enough times for me to say that the main reason to ship something that has the smallest possible scope is not only to validate the hypothesis that whatever we are building is valuable to begin with, but also to determine the roadmap order.
The goal is customer adoption and impact.
The goal of (almost) all product work should be building features that are valuable to customers. There is no such thing as a perfectly designed or perfectly engineered product if it doesn't see customer adoption and customer value. Customer value itself can sometimes be hard to measure, but adoption and engagement is often a good enough proxy.
Of course, companies also exist to make money, so business goals matter as well, but fundamentally I believe that value needs to be created before it can be extracted. If you build a valuable product that customers love, then chances are that you will be able to make money from it. The reverse is not true.
Fix small issues that bug customers.
A smaller thing that reflects customer obsession is fixing small issues that bug customers. The small bugs, paper cuts, UX challenges. If someone complains about something on social media or in a support ticket, if an engineer can hop on it and fix it quickly and you can then respond to the disappointed customer, it immediately turns a doubter into a supporter. At RevenueCat, we pride ourselves on being responsive like that. This is something that is hard to manufacture, it requires everyone in the company truly caring about it (it is very hard to do be responsive when it requires a PM to write a ticket, an EM to review it, the team to groom it, and it then be prioritized in a sprint).
Of course, this only works if the team is set up for it, and if everyone agrees for this to be a priority.
Consider the impact of your work.
One last aspect is a customer centric mindset. What this means is always looking at our actions as teams and individuals from the customer perspective. This can be both positive (how might what I am doing be improving our customers' lives) and negative (how might what I am doing unintentionally make our customers' lives worse). This applies to everything we do as a team—features we ship, of course, but also our business model, how we talk to customers, how we deal with issues such as outages or bugs, etc. Think about your actions from the customers' perspective—how will they perceive your actions? Of course, this requires having a good mental model of your customers—see above.