Feature Request Template for B2B Products
B2B feature requests are fundamentally different from consumer feature requests because they come attached to specific accounts, specific revenue numbers, and specific competitive situations. A single request from a $200K ARR account at risk of churning is not the same signal as 50 votes on a public Canny board. B2B PMs must be able to evaluate requests along multiple dimensions simultaneously: the revenue at risk, the pattern across accounts, the competitive pressure, and the strategic fit with the product direction.
This template standardizes the information required for every B2B feature request so that PMs can make consistent prioritization decisions without spending 30 minutes excavating context from multiple Slack conversations, Salesforce records, and CSM emails. It is designed for B2B SaaS companies where individual accounts represent meaningful ARR and where sales and customer success teams surface feature requests as part of their regular workflow.
Why B2B feature request management requires a different process
The fundamental challenge in B2B feature request management is signal quality. Most requests arrive through the loudest channels — the largest account, the most persistent CSM, the most recent deal. Without a structured process, product roadmaps gradually drift toward serving the needs of the noisiest accounts rather than the most common needs across the customer base.
The antidote is systematic aggregation. A request from one $300K account is interesting. The same request from 20 accounts representing $4M in ARR is a roadmap priority. The same request from 20 accounts plus 15 prospects that represent $8M in blocked pipeline is an emergency. Structured templates make aggregation possible — when every request has the same fields, you can run a spreadsheet or a CRM query to identify patterns that would otherwise be invisible.
The other critical failure mode is commitment management. In the pressure of a deal, sales sometimes implies (or explicitly promises) a feature timeline that has not been reviewed by product. The customer then expects that feature. If the feature is not on the roadmap, the PM is put in the impossible position of either delivering on a promise they did not make or watching a deal fall through. Clear templates that include what has been committed — and by whom — prevent this situation from escalating.
Template sections
5 sections covering the complete feature request workflow.
Request description and feature context
Start with a clear description of what the customer is asking for, written in product terms rather than customer-service language. Include a link to the original source (Intercom ticket, Slack message, support email) for context. Then translate the customer's request into a problem statement: what problem are they trying to solve, rather than the specific solution they proposed?
Feature request: Bulk user deprovisioning Customer request (verbatim): "We need to be able to remove all users from a specific department when they leave the company. Right now we have to do it one by one and it takes our admin 2 hours." Problem statement: Enterprise customers with 50+ users cannot efficiently manage user lifecycle events (employee offboarding, role changes, team reorganizations). The current one-at-a-time deprovisioning flow takes disproportionate admin time for large accounts. Original source: [Intercom ticket #12847] from Acme Corp admin, 2025-03-14
Tips
- Always include the verbatim customer quote — it captures emotional context that a reworded description loses
- Translate the feature request into a problem statement — the customer asks for a solution; your job is to identify the underlying problem that might be solved better
- Link to the original source so the PM and engineers can read the full context if needed
Account context and revenue
Capture the full revenue picture of the requesting account: current ARR, plan tier, account health, tenure, contract renewal date, and CSM owner. For prospects, include deal stage and pipeline value. This context determines how much weight to give the request from a pure revenue standpoint — before considering strategic fit.
Requesting account: Acme Corp - ARR: $180,000 (enterprise plan) - Account health: Yellow — 2 support escalations in the last 60 days - Tenure: 3 years (up for renewal in 4 months) - CSM owner: Sarah Chen - Contract renewal risk: HIGH — CSM rates renewal likelihood at 60% without this feature - Contact: Marcus Webb (VP Operations) — primary stakeholder
Tips
- Always include the renewal date and renewal risk rating from the CSM — these turn an ARR number into an urgency signal
- Health score context matters: a yellow or red account requesting a feature is at churn risk; a green account requesting a feature is asking for a growth enabler
- For prospects: include deal stage and the sales rep who owns the deal — they are the person with the most context on how critical the feature is to closing
Aggregate demand analysis
The most important analysis for a B2B feature request is the aggregate demand: how many accounts and prospects are asking for the same thing, and what is the total ARR and pipeline represented? One vocal account is noise. Ten accounts representing $5M ARR is a signal. Run this analysis before presenting the request to the product team — it determines whether this is a tactical customer service issue or a strategic roadmap priority.
Aggregate demand analysis: - Total accounts requesting bulk deprovisioning: 23 accounts - ARR represented: $2.8M (23% of total ARR) - Plan distribution: Enterprise (18 accounts), Mid-market (5 accounts) - Pipeline blocked: 12 prospects in active evaluation have flagged this requirement; estimated pipeline value: $1.4M - Trend: First request appeared 8 months ago; frequency has increased — now averaging 3 new requests per month - Source breakdown: 14 via support tickets, 6 via CSM feedback, 3 via sales discovery calls
Tips
- Maintain a feature request tracker (CRM custom field, Airtable, or dedicated tool like ProductBoard) that makes aggregation possible — this analysis cannot be done from memory or scattered Slack messages
- Show the trend in request volume over time — increasing frequency is a more compelling signal than a high absolute count
- Weight requests by ARR, not by account count — one $500K account requesting a feature may be more strategically important than five $10K accounts
Competitive context and market pressure
Document whether competitors offer this feature and how it affects competitive evaluations. Competitive context is a forcing function — if the feature is table stakes and competitors have had it for two years, the calculus is different than if it is a novel capability that would create differentiation.
Competitive analysis: - Competitor A (primary competitor): Has bulk deprovisioning via CSV upload. No API access. - Competitor B: Has bulk deprovisioning via SCIM provisioning integration. Full API. - Competitor C: No bulk deprovisioning. Competitive pressure: This feature is table stakes in enterprise evaluations against Competitor A and B. Sales reports losing 3 of the last 8 enterprise competitive deals partly due to this gap (others were pricing and security features). Lost deal analysis: [Link to 3 deal post-mortems where this was mentioned]
Tips
- Do not overstate competitive pressure — if your win rate is still strong in deals where this comes up, note it honestly
- Distinguish between "competitors have this" (parity requirement) and "this would differentiate us" (strategic investment)
- Include links to competitor documentation or feature pages — it makes the competitive claim verifiable and avoids the game of telephone where competitive claims grow in each retelling
Sales commitments and customer expectations
Document what has been committed by sales or CS to the customer — and verify it with the account owner. Commitments made without PM review are a governance problem; they should be surfaced immediately and clarified with the customer rather than silently accepted as product roadmap constraints. The template creates a paper trail that supports productive conversations about commitment management.
Commitments made: - CSM Sarah Chen mentioned to Acme Corp "we are aware of this request and it is on our roadmap" in a QBR on 2025-02-15. [Slack message: link] - No specific timeline was committed. - Sales rep James Park included "bulk user management Q3 2025" in a proposal summary for prospect Globex Corp. [Proposal email: link] PM assessment: The CSM's statement that it is "on our roadmap" is currently inaccurate. Recommend: Sarah acknowledges to Acme that the timeline is under evaluation, not committed. James needs to be informed that Q3 is not confirmed — the Globex proposal language should be corrected.
Tips
- All commitments should be documented with a source (Slack message link, email excerpt, CRM note) — verbal commitments without documentation cannot be verified or disputed
- The PM's job is not to honor every commitment sales makes but to clarify the actual commitment status and communicate the product position accurately
- Create a shared protocol with sales leadership: any feature commitment with a specific date requires PM sign-off before it is communicated to a prospect or customer
Copy-paste template
## B2B Feature Request **ID:** [FR-XXX] | **Date:** [Date] | **Submitted by:** [Name / Role] **Priority recommendation:** [Critical / High / Medium / Low] --- ### Feature Description **Customer request (verbatim):** "[Exact quote from the customer]" **Problem statement:** [Translate the request into the underlying problem — 1–2 sentences] **Proposed solution scope:** [High-level description of what building this would entail] **Original source:** [Link to Intercom ticket / Slack message / CRM note / support email] --- ### Primary Account Context | Field | Value | |---|---| | Account name | [Company name] | | ARR | [$X] | | Plan tier | [Starter / Growth / Enterprise] | | Account health | [Green / Yellow / Red] | | Renewal date | [Date] | | Renewal risk | [Low / Medium / High — CSM assessment] | | CSM owner | [Name] | | Primary contact | [Name, Title] | | Existing customer or prospect | [Existing customer / Active prospect — deal stage] | --- ### Aggregate Demand | Metric | Value | |---|---| | Total accounts requesting this | [N accounts] | | ARR represented | [$X (Y% of total ARR)] | | Pipeline blocked (prospects) | [$X across N deals] | | Total revenue impact | [$X ARR + $Y pipeline = $Z total] | | Request volume trend | [Increasing / Stable / Declining] | | Most recent requests | [Date of most recent 3 requests] | **Source breakdown:** [How requests are coming in: support tickets / CSM / sales discovery / NPS verbatim] --- ### Competitive Context | Competitor | Has this feature? | Implementation quality | Notes | |---|---|---|---| | [Competitor A] | [Yes / No / Partial] | [Full / Basic] | [Notes] | | [Competitor B] | [Yes / No / Partial] | [Full / Basic] | [Notes] | **Lost deals where this was a factor:** [N deals — link to post-mortems if available] **Competitive assessment:** [Differentiator / Parity requirement / Not currently competitive pressure] --- ### Sales Commitments and Expectations | Who | What was committed | When | Source | |---|---|---|---| | [Name, Role] | "[Exact language used]" | [Date] | [Link to evidence] | **Commitment risk:** [No commitment / Soft commitment — "on our radar" / Hard commitment with timeline] **Recommended action:** [No action needed / Clarify with CSM before next customer touch / Correct proposal language immediately] --- ### PM Assessment **Strategic fit:** [Strong / Moderate / Weak — one sentence rationale] **Build vs. buy vs. workaround:** [Build natively / Partner / Workaround: describe] **Effort estimate (rough):** [Small (1 sprint) / Medium (1 quarter) / Large (multi-quarter)] **Recommendation:** [Add to roadmap Q[X] / Defer / Decline — with reasoning]
Frequently asked questions
Generate instead of filling in templates
Connect your tools, and Vantage generates the content using real product data. Free to start.
Free to start. No credit card required.