Revenue-weight feature requests

Rank feature requests by account value, usage pain, and renewal risk so product and GTM teams can prioritize with context.

Updated · published

markdown for agents →

difficulty intermediate · time to value 5 minutes · execution on demand
#analytics #revenue #product #roadmap #customer-success #expansion

Start from this 

Rank feature requests by requesting accounts, ARR or plan value, renewal risk, usage pain, and whether the feature blocks expansion.

Why this matters

Raw feature-request counts overweight noisy accounts and underweight strategic customers. Revenue weighting gives product a better signal without turning the roadmap into a sales queue.

What you get

  • Feature requests ranked by account value
  • Request count by customer segment
  • Expansion or renewal context for each request
  • A short list of roadmap items to investigate

Walk through it

You

Which feature requests matter most commercially?

Agent

I’ll group request events by request key and weight them by account value and customer health.

Endpoint: POST /v1/projects/:project_id/analytics/query
Exact shape: /v1/openapi.json?path=%2Fv1%2Fprojects%2F%7Bproject_id%7D%2Fanalytics%2Fquery&method=post
Custom HogQL goes in the OpenAPI-defined `query` field.
Concept fields:
  query: "SELECT properties.request_key AS request, count(DISTINCT properties.account_id) AS accounts, sum(toFloat(properties.opportunity_value)) AS opportunity_value FROM events WHERE event IN ('feature_requested','expansion_opportunity_created') AND timestamp > now() - INTERVAL 180 DAY GROUP BY request ORDER BY opportunity_value DESC, accounts DESC LIMIT 25"

The output

The agent returns a ranked roadmap input, not an automatic roadmap. It should include request volume, revenue context, customer risk, and the next discovery question.

Setting it up

Emit feature request events from support, sales, feedback forms, or CRM sync. Use a normalized request key so the same request is not split across wording variants.

Variations

  • “Show requests from renewing accounts only.”
  • “Which requests block expansion?”
  • “Compare revenue-weighted requests to usage pain.”

Related workflows

ops 10 minutes

Review account-health evidence before outreach

Combine verified account usage, revenue context, and support-friction signals into a review queue without pretending a universal score proves churn or intent.

growth 10 minutes

What behaviors predict an account will upgrade?

Compare upgraders vs flat users from last quarter. Find the pre-upgrade behaviors that most strongly predict expansion.

growth 5 minutes

How fast was the new feature picked up?

Track time-to-first-use for a newly launched feature, split by trial vs paying user. The 2-week post-launch reality check.

Adapt this workflow in your own agent.

Ask your agent to map the starter prompt to your saved signal map, live events, and the current HTTP API before answering.

Agentry gives coding agents production context from errors, product analytics, and deploys through one HTTP API. Fetch and read https://agentry.sh/install.md completely, then install Agentry's full first-time telemetry baseline in this repository. I authorize device-code login, saving the owner key only to ~/.agentry/credentials.json, creating one Agentry project for this repository, and read-only inspection of shipped source plus hidden CI/provider configuration. Deeply analyze the product's business logic and complete value flow before choosing telemetry. Save the complete source-backed plan and show me its exact contents and hash. Until I explicitly approve that plan or request a replacement, do not edit app/CI source, place runtime/CI credentials, commit, exercise product traffic, start proof, push, or deploy. After approval, I authorize only the reviewed targets: place the required scoped browser/server/CI credentials through the established environment or secret mechanism, preserve existing telemetry, implement and test the baseline, commit it, push that reviewed commit when the shipped CI/provider path requires it, exercise safe proof paths with test/non-customer data, and perform one deployment through the reviewed shipped CI/provider path. Ask first if proof would charge money, contact a third party, change real customer data, or require new external access. After the plan is saved, immediately before every onboarding state-changing POST, GET current onboarding state, perform only its single returned next_action, then read state again; do not batch or infer later stages. Continue until status is verified, installation_complete is true, and next_action is null. Keep all secrets, source snapshots, proof markers, and scratch files outside the repository.

+ Full access
5.5 Extra High
  1. 1. Open your repo in Codex, Claude Code, Cursor etc.
  2. 2. Paste the install prompt.
  3. 3. Your agent reads the install doc and shows you an implementation plan for approval.
← all workflows