Feature Adoption Prompt: Usage Data to a Recommendation

You shipped the feature. Three weeks later someone asks the real question: is anyone using it? The dashboard shows an adoption rate, a funnel, and a few cohort lines, and now you're staring at numbers trying to turn them into a decision. That gap — from metrics to a defensible next step — is exactly where a good feature adoption prompt earns its place.

Search this query and you'll find a wall of metrics articles. They define breadth, depth, and time-to-adopt, list five things to measure, and end on a "Book a demo" button for an analytics platform. Useful background. None of them hand you a prompt that reads your numbers and tells you what to do next.

This post does. The prompt structure, the output contract that turns a funnel into a recommendation, and the one rule that stops the model from suggesting a tooltip for every problem.

Why "analyze my adoption data" produces nothing useful

Paste a usage dump into ChatGPT and ask it to analyze adoption, and you get a confident summary that restates your own numbers back at you. Adoption is 34%. Drop-off is highest at step two. Cohorts vary. Thanks — you knew that. The model summarized; it didn't decide.

The deeper problem is arithmetic. Language models are unreliable at computing rates and funnels from raw event data. Hand a model 40,000 rows and ask for the adoption rate and it'll often hallucinate a clean-looking percentage that's just wrong. So don't. Compute the numbers in your analytics tool, hand the model a small table of computed metrics, and ask it to do the part it's actually good at: interpretation and judgment.

Here's the stance worth defending: the model should never see raw events. Feed it the adoption rate, the per-step funnel drop-offs, and the cohort splits as a clean table. It reasons well over a dozen numbers and badly over a hundred thousand. Match the job to the strength.

What you can do with a feature adoption prompt

• Convert a computed adoption rate and funnel into a ranked list of likely blockers
• Compare cohorts (by plan, signup week, or persona) and name which segment is stuck and where
• Tie each blocker to the exact metric that proves it, so the analysis is auditable
• Produce one concrete next-step recommendation, not a menu of ten
• Flag the "high adoption, high support volume" pattern that means users are struggling, not thriving
• Draft the adoption section of a product review or QBR in the team's voice

Anatomy of the prompt

The prompt is a role, a table of computed metrics, and an output contract that forces interpretation into a fixed shape. Computed numbers go in. Judgment comes out.

Variables
  {{feature_name}}     → the shipped feature under review
  {{adoption_metrics}} → computed: adoption rate, funnel step drop-offs
  {{cohort_breakdown}} → adoption by segment (plan, signup week, persona)
  {{target}}           → optional: the adoption rate you were aiming for

Prompt
  Role: product analyst reviewing adoption of a shipped feature.
  Task: interpret the computed metrics below. Do not recompute them.
        Identify blockers, rank them, and recommend exactly one next step.
        Every blocker must cite the metric that proves it.

Output contract
  ## Adoption summary   (rate vs target, one sentence)
  ## Blockers           (ranked; each: blocker · the metric proving it · cohort)
  ## Recommendation     (one next step · expected effect · the metric to watch)
  ## What to ignore      (a tempting-but-wrong reading the data does NOT support)

The ## What to ignore section is the quiet hero. It makes the model argue against an obvious-but-wrong conclusion, which surfaces the assumption a busy reader would otherwise run with.

Step-by-step usage

1. Compute the metrics first

In your analytics tool, pull the adoption rate (eligible users who adopted ÷ total eligible), the drop-off at each funnel step, and the same numbers split by cohort. If 40 of 100 eligible users use the feature, that's 40% — compute it there, not in the prompt. Drop the results into {{adoption_metrics}} and {{cohort_breakdown}} as small tables.

2. State the target

Fill {{target}} with the rate you were aiming for, even if it was a gut number. "34% against a 50% target" reads completely differently from "34%." Without a target the model grades on a curve it invents.

3. Run it model-aware

GPT-4o reasons cleanly over a compact metrics table and is happy to commit to a single recommendation when the contract demands one. Claude is more cautious and will hedge unless you tell it to pick exactly one next step — useful, because the hedge is honest, but you have to force the decision. Gemini will sometimes try to recompute the numbers you handed it; add an explicit "do not recompute, interpret only" line for it.

4. Post-process

Check the cited metric on every blocker. The blocker should name a number that's actually in your input. If the model cites a metric you didn't provide, it invented it — tighten the "cite the metric that proves it" rule and rerun.

5. Iterate

Run the second pass with the recommendation removed and ask: "What's the strongest argument against shipping this recommendation?" The counter-argument is often where the real risk lives.

Prompt-craft patterns that hold

Number-anchored actions. Every recommendation traces to a number. No anchoring metric, no recommendation. This is what kills the generic "add a tooltip, send an email, run a webinar" reflex.

Format each action as: blocker → metric that proves it → proposed change
→ metric that would confirm the change worked. Omit any action with no
anchoring metric.

One recommendation, not ten. Listicle-style "10 ways to improve adoption" output is worse than useless — it offloads the decision back to you.

Recommend exactly ONE next step. If two are close, pick the one with
the cheapest test and say why.

Name the wrong reading. Force the model to state the seductive misinterpretation. High adoption plus a spike in support tickets isn't success; it's users fighting the feature. The feature adoption analysis pack ships this as a fixed section so it's never skipped.

Variables you'll set

Getting started

1. Compute adoption rate, funnel drop-offs, and cohort splits in your analytics tool.
2. Drop them into {{adoption_metrics}} and {{cohort_breakdown}} as small tables.
3. Set {{target}} so the model grades against your goal, not its own.
4. Paste the role, the "interpret, don't recompute" rule, and the output contract last.
5. Run it on GPT-4o, which commits to a single recommendation cleanly.
6. Verify every cited metric exists in your input.
7. For the contract and the wrong-reading section already wired, use the Feature Adoption Analysis pack.

Adoption analysis usually feeds two other jobs. If the numbers say the feature missed, the product roadmap prioritization prompt decides whether it's worth a second swing, and an A/B test prompt can frame the experiment that proves the fix.

A caveat worth stating plainly. The model interprets; it doesn't know your business. A 20% adoption rate might be a triumph for a niche power-user feature and a disaster for a core flow, and only you know which. Treat the recommendation as a sharp first draft, pin the model version when an analysis feeds a real decision, and re-read the cited metrics before anyone acts. For the requirements that follow a fix, the Product Requirements pack picks it up, and the PRD prompt frames the rebuild.