Power User

What is Power User?

A power user is someone who sits in the top bucket of a product's engagement histogram, the small slice of your base that opens the product almost every day and gets more value out of it than anyone else.

The clearest public treatment of this comes from Andrew Chen's Power User Curve, later republished with Li Jin at Andreessen Horowitz. The idea is simple: instead of collapsing engagement into one ratio like DAU/MAU, you plot a histogram of how many days each user was active over a period, often 30 days (L30) or 7 days (L7) for products with a weekly cycle like B2B SaaS. When that histogram forms a "smile," with a large cluster at the low end and another cluster of daily users at the high end, you have a real power-user segment. The a16z republish notes that the 30-day version, L30, was coined by the Facebook growth team, which is why the term shows up across so much of consumer growth writing.

Power users are not the same as early adopters. Early adopters are defined by timing, they tried your product before most people did, often because they were willing to tolerate rough edges to get an advantage. Power users are defined by ongoing behavior. Someone can sign up in your fifth year and still become your most intense user by month two. Some early adopters churn out entirely and never appear in a power-user histogram at all. Treating the two groups as one is a common way founders overweight the wrong feedback.

Why it matters for product-market fit

Produck's loop runs Listen, Diagnose, Decide, Ship, and power users are disproportionately useful at every stage of it, for a specific reason each time, not because they are simply "better" users.

In Listen, power users generate more raw feedback per person, because they touch more of the product more often. In Diagnose, they surface edge cases sooner, because heavy use finds the seams that light use never reaches. And because they've built a mental model of how the product should behave, their complaints tend to name the exact broken step instead of a vague "this feels off."

That specificity is exactly what a founder needs when deciding what to build next, which is the argument we make in The PMF stack is broken: most teams don't lack feedback, they lack a way to tell which feedback is load-bearing. Power users are one of the fastest filters for that. If your five most engaged accounts all hit the same wall, that wall belongs at the top of Decide, ahead of anything a single one-time visitor mentioned.

The catch is retention. A power-user curve is a snapshot, and a healthy one this month can hollow out next month if you ship for your loudest users and ignore why casual users never came back for a second week. Power-user feedback should sharpen your roadmap, not replace your retention numbers as the definition of success. Watching whether power users convert into durable activation further down the funnel, rather than just watching how loud they are today, is what keeps this signal honest.

When it works, and when it doesn't

It works when:

• Your power-user segment is large enough to matter, not two people in a Slack channel who happen to reply fast
• You can trace a specific complaint back to a specific workflow, not a general sentiment score
• You're using power users to prioritize among already-validated problems, not to invent net-new ones
• You keep tracking casual and lapsed users alongside them, so the curve doesn't quietly become your whole picture

It falls short when:

• You let a handful of loud accounts set the roadmap for a market that looks nothing like them
• You mistake a power user for a proxy of what a brand-new user needs on day one

How to apply it

1. Pull a 30-day (or 7-day, if your product runs on a weekly cycle) activity histogram and find your top bucket. That's your power-user segment for this period.
2. Pull the feedback and support tickets from just that segment for the last month. Read them in one sitting.
3. Group the complaints by the workflow they touch, not by how they were phrased. Three people describing the same broken step in three different ways is one problem, not three.
4. Cross-check each grouped problem against your retention data. Does fixing it plausibly move a metric bigger than this one segment's happiness?
5. Rank the surviving problems into Decide, and ship the top one before adding anything new to the backlog.
6. Re-pull the histogram a month later. If the same accounts are still in the top bucket and new accounts are joining it, the fix worked. If the top bucket just got smaller, go back to Listen.