Pirate metrics AARRR for product managers

Kevin Lee
By
Kevin Lee
Kevin Lee
Kevin Lee
Kevin is a Co-Founder of ProductHQ. He has worked as a VC at Pear Ventures where he invested in and partnered with…
More About Kevin →
×

Pirate metrics, often written as AARRR, is a framework I use to discuss how people move from first finding a product to receiving ongoing value and contributing to sustainable revenue. The letters stand for acquisition, activation, retention, referral, and revenue. The framework is memorable, but the real work is defining the customer behavior and product value behind each stage.

I do not treat AARRR as a universal funnel or a scorecard where every product must improve every letter at once. A self-serve tool, an enterprise platform, and a community product may have different journeys and different meanings for activation or referral. I use the framework to connect a growth question to a customer experience, then choose measures that help the team learn.

Start with the customer journey

I define the journey before choosing events. Acquisition is how a person or account becomes aware of and reaches the product through a relevant channel. Activation is the first meaningful experience of value, not merely an account creation or button click. Retention is the behavior that shows the product remains useful over an appropriate interval. Referral is a voluntary recommendation or invitation that brings relevant people into the product. Revenue is the exchange that supports the business model, such as a purchase, expansion, renewal, or another verified commercial outcome.

These definitions are hypotheses until I connect them to real use. I write the job the customer is trying to complete and the moment that indicates progress. For a collaboration product, activation may involve completing a shared workflow with a colleague. For a reporting product, it might be answering a recurring business question. The exact event matters less than whether it represents meaningful value for the intended segment.

I also map where the stages overlap. A referral can be part of acquisition, and a paid conversion can occur before a customer has formed a retention habit. A linear diagram helps explain the model, but customer behavior is not obligated to follow my labels.

Acquisition: reach the right people

I measure acquisition by source and audience, not just by traffic volume. I want to know which channels bring people who have the problem, can use the product, and are eligible for the offer. A campaign that produces many visits but little qualified exploration may look efficient while consuming the team’s attention.

When acquisition is weak, I ask whether the issue is reach, message, trust, targeting, or the product’s relevance. Changing a headline cannot fix an offer that does not solve the audience’s problem. The metric should lead me to a question, not directly to a favorite growth tactic.

Activation: deliver an early outcome

Activation is where I look for evidence that a new user experienced the product’s promised value. I avoid defining it as “completed onboarding” unless onboarding completion itself is the outcome. A checklist can be useful, but it is not proof that the user’s problem was solved.

I choose an activation behavior that is close enough to the value moment to be influenced by product work. Then I inspect who activates, how long it takes, what blocks progress, and whether the behavior predicts a useful next step. I segment by use case, acquisition source, device, role, and other meaningful context rather than hiding different experiences inside one average.

I am careful not to optimize activation by removing information or creating a forced click. A higher event rate can be a worse customer experience if people are rushed through a step they do not understand. I pair the measure with qualitative evidence, task success, and signals of confidence.

Retention: understand continuing value

Retention asks whether customers return to or continue using the product in a way that makes sense for the problem. I define the interval from the use case. A daily workflow, a monthly reporting task, and an occasional compliance process should not share an arbitrary return expectation.

I distinguish retention from mere logins. A person can open a product repeatedly without accomplishing anything, while another may use it less often because the product efficiently solves an infrequent job. I examine the value-producing behavior, renewal or continued commitment, support themes, and reasons people stop.

Retention analysis is also a chance to find broken promises. If customers activate but do not return, the issue may be weak ongoing value, poor reliability, missing collaboration, confusing reminders, or an audience-product mismatch. I avoid assuming that a messaging campaign is the answer before understanding the cause.

Referral: make advocacy meaningful

I use referral to mean a customer action that credibly introduces another relevant person or account, not every social share or copied link. I define the behavior and its intended recipient. An invitation that creates an account but no useful engagement is not the same as a recommendation that leads to a successful customer outcome.

Revenue: connect value and economics

Revenue measures the commercial exchange, but I do not treat it as the only proof of product success. I define whether I am examining first purchase, conversion, expansion, renewal, or another business outcome, and I connect it to the segment and offer. A single blended revenue rate can hide different packaging, sales, and retention realities.

I compare commercial behavior with customer value and delivery cost. If a growth tactic increases short-term purchases while causing cancellations or support burden, the AARRR view should make that tradeoff visible. I also separate revenue reporting from promises: a metric can describe what happened without guaranteeing that the next experiment will reproduce it.

Build a learning loop

I put the stages into a simple table with the customer behavior, event definition, owner, segment, data source, and decision the metric supports. For each measure, I write what I would do if it moves up or down. If no decision follows, the measure may be interesting but is not yet useful for the team.

I validate instrumentation before interpreting a trend. I check identity, event timing, duplicate events, missing devices or channels, consent, and changes in the product that alter the event definition. I annotate releases and campaigns so a chart has context. I avoid invented benchmarks and compare against a clearly defined baseline or cohort when that is appropriate.

Common mistakes

The first mistake is treating AARRR as a race to maximize a funnel percentage. That encourages shallow events, aggressive prompts, and local optimization. The second is choosing one metric per letter without explaining the customer value it represents. A dashboard can be tidy and still be misleading.

I also avoid forcing every product into the same order, counting referrals without considering quality, and using revenue to excuse harm to customers. AARRR is a map for questions, not a replacement for judgment, research, or responsible measurement.

A practical starting exercise

I choose one customer segment and write the journey from first relevant contact to repeated value and commercial commitment. I define one candidate behavior for each AARRR stage, test the definitions against real examples, and identify the biggest uncertainty. Then I instrument or inspect only what can answer the next product question.

Pirate metrics works for me when it connects growth language to customer value. The memorable acronym is useful because it helps teams start the conversation. The discipline is in defining each behavior honestly, checking the data, and changing the product based on what the journey teaches us.

Next step

Build stronger product analytics, growth, and decision-making skills in the Product Manager Certification. Subscribe to the Product HQ newsletter for practical frameworks and career-ready product lessons.

Kevin Lee
Kevin Lee
Kevin is a Co-Founder of ProductHQ. He has worked as a VC at Pear Ventures where he invested in and partnered with early-stage founders on product & growth to help them build the foundations of category-defining companies. He has worked as a Product Manager at AltSchool (backed by Andreessen Horowitz, Founders Fund, First Round Capital, Mark Zuckerberg, John Doerr and other exceptional investors). Previously, he was a Senior Product Manager at Kabam (acquired by NetMarble and Fox for a combined $1bn+), where he worked on products through all lifecycles in San Francisco, Vancouver, and Beijing and helped grow one of the company’s products to become the third largest revenue generating product in the company portfolio. In a former life, he worked in Technology Investment Banking at Merrill Lynch. He is also the author / co-author on 10+ gaming patents.