Product teams need asymptote registers

A product can have product-market fit and still be moving toward product-market unfit. That sentence feels wrong only if fit is treated as a permanent badge. In practice, fit is often local: one segment, one use case, one channel, one moment in the market. The first curve proves that something works. It does not prove that the same product shape will carry the next curve.

That is why product teams need asymptote registers. An asymptote register is a simple operating artifact for suspected growth ceilings. It turns a vague plateau into a named hypothesis, with the affected segment, evidence, false fix to avoid, owner, next experiment, and decision rule. The goal is not to sound more scientific. The goal is to stop confusing execution noise with a structural ceiling.

Eugene Wei describes the problem clearly in his essay on invisible asymptotes: many products grow quickly until they hit a hidden limit in the product, market, or match between the two. The dangerous part is that the ceiling is often invisible while the team is still inside the old success story.

The plateau is not always an execution problem

When a growth metric stalls, the default reaction is usually operational. Improve onboarding. Add lifecycle emails. Ship the long-requested feature. Discount the annual plan. Launch another campaign. These moves can be useful, but they also let the team avoid a harder question: what if the next segment does not want the product you already built?

A plateau after early fit can mean at least three different things. The product may still be valuable, but the acquisition channel is saturated. The product may be strong for early adopters, but too complex, risky, expensive, or narrow for the next audience. Or the market may have changed around the product while the roadmap kept optimizing the original promise.

Those are different problems. They require different decisions. A channel ceiling asks for distribution work. A segment ceiling asks for positioning, packaging, or product shape changes. A market ceiling may ask for a strategic choice about where not to compete. If every plateau is treated as a conversion problem, the team will keep sanding the same surface while the real constraint sits underneath.

This is where an asymptote register differs from a dashboard. A dashboard shows the curve. The register asks why the curve may be bending. A dashboard says expansion conversion is down. The register says: our current collaboration workflow may be useful for founder-led teams, but too ungoverned for departments with compliance review. That second sentence is a decision-making sentence.

The same discipline appears in good product strategy work. A team that uses choice maps instead of priority stacks is already admitting that growth comes from trade-offs, not from doing everything. An asymptote register applies that logic to stalled metrics.

What belongs in an asymptote register?

The register should be boring enough to use every week. If it becomes a strategy deck, it will be abandoned. A useful entry has seven fields.

First, write the ceiling hypothesis. Be specific. Not “activation is bad,” but “solo users understand value, but managers do not invite teams because the product lacks a safe handoff model.” Second, name the affected segment. This prevents the team from averaging together users who have different jobs, budgets, fears, and switching costs.

Third, collect evidence. Use retention curves, qualitative interviews, funnel breakpoints, sales notes, support tickets, lost-deal reasons, and usage traces. The point is not to demand perfect proof. It is to stop relying on anecdotes that confirm the roadmap already in motion.

Fourth, write the false fix to avoid. This field is the most uncomfortable and the most useful. If the suspected ceiling is trust from larger teams, the false fix may be “shorter onboarding.” If the suspected ceiling is lack of buyer urgency, the false fix may be “more feature depth.” If the suspected ceiling is wrong segment selection, the false fix may be “more paid acquisition against the same audience.”

Fifth, assign a decision owner. Not a project owner, a decision owner. Someone must be responsible for saying whether the ceiling is real enough to change the plan. Sixth, define the next experiment. It can be a concierge workflow, a fake-door test, a sales discovery sprint, a pricing probe, a prototype, or a narrow launch for a different segment. Seventh, write the decision rule before the test begins.

This last field connects the register to the discipline of kill criteria for product bets. If the team decides after seeing the data, the loudest narrative often wins. If the decision rule is written before the test, the team has a better chance of learning instead of defending.

How do you test product-market unfit?

Product-market unfit is not a moral failure. It is a diagnostic label for a mismatch between what the product offers and what a segment needs to adopt, keep using, and expand. Testing it requires more than asking users whether they like the product.

Start by separating love from reach. A small group may love the product deeply while the next group fails to care at all. That is not a contradiction. It is the shape of many early products. The right question is not “do users like us?” but “which users reach durable value, and which users hit friction that our current product cannot absorb?”

Then separate feature gaps from adoption gaps. A feature request from a target segment may be a real clue, but it may also be a polite way to say that the product does not fit the buyer’s workflow. If a team says, “we need approvals,” the literal feature may be approvals. The deeper issue may be that the product is moving from an individual tool to an organizational system of record. That is a different product shape.

A good test narrows the uncertainty. For example, if the hypothesis is that managers need visibility before inviting teams, do not spend a quarter rebuilding administration. Run a managed pilot where the team manually provides weekly visibility reports. If invites increase and retention improves, the product has learned something about the ceiling. If nothing changes, the old explanation was probably too convenient.

The register also protects discovery from becoming theater. In discovery interviews with decision logs, the important move is to connect what was heard to what the team will change. The asymptote register does the same for growth diagnosis: every interview, metric, and experiment should either strengthen, weaken, or replace a ceiling hypothesis.

When should the strategy change?

A single weak experiment should not rewrite the company. But repeated evidence of the same ceiling should force a strategic choice. The team can deepen the current segment, reshape the product for the next segment, change the business model, change distribution, or explicitly stop chasing that curve.

The worst option is pretending the choice does not exist. That is how teams build bloated products. Each quarter adds another feature for the next promised segment, while the core experience becomes harder for the segment that already loved it. The product becomes a museum of unresolved asymptotes.

A practical review cadence helps. Once a month, pick one stalled metric and ask: what ceiling are we assuming, what evidence has changed, what false fix are we still tempted to ship, and what decision is now overdue? Keep the register short. Close old entries. Archive disproven hypotheses. Promote confirmed ceilings into strategy work.

The register is not pessimistic. It is a way to preserve ambition by refusing vague optimism. A team that names ceilings can choose which ones to attack. A team that refuses to name them keeps mistaking motion for progress.

This week, audit one stalled metric. Write one asymptote register entry. Include the ceiling hypothesis, segment, evidence, false fix, owner, next experiment, and decision rule. If the entry feels politically awkward, that is probably the first sign it belongs in the register.