Sales Enablement, Customer Success and the Feedback Loop

Sellers, partners and customer success teams carry your product to customers. Give them accurate claims, usable tools and a reliable path for customer evidence to shape product decisions.

Why this matters

Customers experience the product through sales explanations, partner deployments and onboarding. Inaccurate guidance becomes lost deals, delayed value and renewal risk.

Enterprise selling also serves a buying group. Gong’s analysis of 1.8 million opportunities found that 77% involved multiple buyer contacts, with 17 on average in strategic enterprise deals. This vendor data is correlational. Salesforce’s 2026 survey of 4,050 sales professionals found that sellers spent 40% of their time selling. Your kit needs to serve each buying role and remain usable between calls.

The field also supplies customer evidence. Collect requests, identify the underlying problems, decide and report the decision. These practices connect Go-to-market with the Customer dimension of your Product 360.

What the PM owes the field

Who owns what

Seismic defines sales enablement as using people, processes and technology to improve sales productivity and revenue. Content needs training, certification and findability to become useful enablement.

The Pragmatic Institute places sales alignment, tools, content and channel training in Programs, and win-loss analysis in Market, without assigning roles. This book recommends the split below: PM owns accuracy, product marketing owns packaging, enablement owns delivery, and sales and customer success own customer conversations.

In smaller companies the PM also covers much of product marketing’s column. The split still tells you which work to hand off when headcount arrives, and which work stays with you.

The sales enablement kit

This book recommends a standard kit for every product or major release. The contents are a synthesis, not any one author’s model:

Protect the four commonly missed PM-owned assets: ROI tool, roadmap guidance, known limits and escalation path. They help the field avoid poor-fit deals.

Discovery questions. Neil Rackham’s SPIN Selling (1988) draws on Huthwaite’s study of about 35,000 calls over 12 years. Its four question types are Situation (current facts), Problem (difficulties), Implication (consequences) and Need-payoff (the buyer’s value from a solution). PMs should help write the last two: they express why each persona would pay.

Matthew Dixon and Brent Adamson’s The Challenger Sale (2011) identified the Challenger as the highest-performing of five seller profiles in their research. Its useful PM implication is to supply insights from cross-customer patterns that an individual buyer cannot see.

Objections and battlecards. For each objection, record its meaning, a clarifying question, evidence-based response, escalation path and conditions under which it is valid. Acknowledge real limits before they become churn risks.

Klue’s Kimberly Mercer positions battlecards for late-stage shortlists. Frame points around buyer needs, specific competitors and the objections they plant. Crayon’s 2026 vendor survey associated weekly-or-faster intelligence sharing with reported revenue impact: 79%, versus 41% for monthly-or-slower sharing. The correlation supports testing a weekly feed, without proving causation.

The demo. The Great Demo! method starts with discovery, then shows the result before the path to it. Provide a stable environment, realistic data and a script. For AI, include a moment that demonstrates handling an error. Chapter 26 covers the method.

Pricing guidance and the ROI tool. Give the field list prices, discount bands, approvers, bundling rules and limits on promises. These include roadmap commitments, uncapped usage and fixed dates for unreleased features. Build ROI estimates from buyer inputs, sourced assumptions and conservative defaults. Chapter 15 covers pricing strategy.

The enablement cadence

Enablement decays. Products change, competitors ship and sellers forget. Tie the depth of enablement to the launch tier from Chapter 25, and run a standing cadence between launches.

Partner and channel enablement

Partner types need different enablement. An MSP runs customer IT under a service level agreement, usually for setup and monthly fees. A reseller takes a sales margin, a services partner implements and customizes, and a technology partner integrates. AWS uses distinct tracks for these roles. Segment your program accordingly.

MSP economics depend on serving many customers efficiently. Multi-tenant administration, per-customer billing and viable margins matter as much as training. Route every partner segment’s feedback into the direct field’s triage process.

Customer success as a product outcome

Desired Outcome

Lincoln Murphy defines customer success as achieving the customer’s Desired Outcome through the vendor relationship. His current formulation combines a Goal (objective, conditions and time frame) with an Appropriate Experience. Earlier, he called the first element the Required Outcome. Define it as a business result, such as fewer outages, rather than a functional activity such as dashboard use.

The Appropriate Experience depends on segment. A 5,000-person enterprise may need a named contact, joint plan and security review. A 30-person MSP customer may expect the provider to handle everything. Design onboarding, guidance and support accordingly.

The post-sale lifecycle

Gainsight, the customer success software company, describes four post-sale phases: onboarding and time to value; adoption and value realization; growth and expansion; and renewal and advocacy. Customer success teams run these phases. The product decides how hard each one is.

Onboarding and time to value. Ramli John and Wes Bush call the first value moment the “First Strike.” Map onboarding steps to it, then keep, delay or remove each step based on necessity and ease. Retain friction that builds customer ownership. Gainsight adds enterprise welcome, education, a joint kickoff plan, early success in 30 to 60 days and a formal handoff. Review at 30, 60 and 90 days. Carry the goals agreed during sales into onboarding.

Health scores. Gainsight groups inputs into usage against entitlement, feature adoption, sentiment, engagement, relationships and customer value. Product owns usage and adoption telemetry and should supply an account-level outcome measure. Track trends and validate scores against actual renewals, contractions and churn. Revise components when the score misses risk.

Business reviews. Murphy’s customer QBR model brings executives together around goals, delivered value, support, health, usage, roadmap obstacles and the next 90 days. The CSM owns it for the top customer segment. Keep tactical tickets elsewhere. The PM contributes a short roadmap discussion and two or three research questions. Chapter 29 covers internal reviews.

Expansion and renewal. Product creates expansion paths through usage, adjacent teams and higher-tier value. Renewal depends largely on whether customers reached their Desired Outcome. Ask CS for a health-based renewal risk view at least two quarters ahead. Feed every contraction and churn reason into product triage.

NRR and GRR are product metrics

Net revenue retention (NRR) and gross revenue retention (GRR) are usually reported by finance and owned by customer success. They’re also the cleanest summary of whether the product keeps delivering value after the sale. Gainsight states them this way:

• NRR = (starting recurring revenue + expansion − contraction − churn) ÷ starting recurring revenue × 100
• GRR = (starting recurring revenue − contraction − churn) ÷ starting recurring revenue × 100, which can never exceed 100%

For context, Gainsight, summarizing a KeyBanc Capital Markets and Sapphire Ventures survey, puts private B2B SaaS medians at about 101% NRR and 90% GRR. Treat that as a rough reference point, not a target.

GRR shows whether customers keep what they bought. NRR adds expansion, which can mask losses elsewhere. Decompose both by segment and cohort, then examine churn and contraction reasons and expansion triggers. Chapter 09 covers the deeper analysis.

The feedback loop

Inner loop and outer loop

Bain & Company’s Net Promoter System, developed from Fred Reichheld’s research, separates two loops. The inner loop gives customer feedback directly to front-line employees for follow-up. The outer loop addresses product, process and policy changes beyond their authority. A central team deduplicates and routes issues, while accountable teams investigate root causes and prioritize solutions.

Sellers, CSMs, support and partners close the inner loop. The PM and product operations run the outer loop, returning decisions to the field and customer.

Feature requests are solutions

Teresa Torres’s opportunity solution tree links an outcome to customer needs, solutions and assumption tests. Ask why a requested feature matters until you identify the need and several possible solutions. Requests often lack context, so use them to guide discovery interviews (Chapter 01).

Record a problem and attach requests as evidence, including customer, segment, revenue band and customer wording. Create a new record when the need differs. Count customers experiencing the problem alongside request volume.

Three disciplines make the outer loop trustworthy:

• Dedupe into problems. Forty requests for the same feature are one problem with forty pieces of evidence, plus whatever differently worded requests belong on the same record.
• Don’t let revenue-weighted counts decide alone. Weighting by account revenue is a useful input and a bad prioritizer: it favors the largest accounts’ preferred solutions over the segment you’re trying to grow, and rewards whoever logs the most.
• Close the loop twice. Tell the requester and the account team when a decision is made (including “not planned,” with the reason) and again when something ships. A field that hears back keeps sending good evidence. A field that hears nothing stops logging and starts escalating.

Win-loss analysis

Win-loss interviews ask buyers what drove a completed decision. Clozd recommends neutral interviewers, both wins and losses, interviews soon after close, about 25 to 30 per segment, and positive/negative driver tags. Share findings continuously. Its 2025 survey associated interviews within a month with more than twice the satisfaction with feedback depth. Treat this vendor finding as indicative: the sample size was unstated.

Customer advisory boards

A customer advisory board (CAB) brings senior customers into strategic decisions. The Farland Group recommends executive sponsorship, diverse accounts, tracked actions and periodic charter and membership reviews. Its format is one or two annual in-person meetings of one to one and a half days, with optional 60–90-minute virtual sessions. Recruit executives who can think beyond their accounts, maintain confidentiality and keep sessions pitch-free. Sales can nominate members but should not attend. Exclude prospects.

Use the CAB for category direction, acceptable autonomy and buying models. Keep roadmap voting in the ordinary feedback process.

How to apply it

Here’s a method for setting up enablement, customer success and the feedback loop for a product or a major release. Steps 1 to 6 happen before and around launch; steps 7 to 12 are the standing machinery you keep running.

Before launch: arm the field.

1. Agree the ownership split. Fill in the who-owns-what table with product marketing, enablement, and sales and CS leadership. Settle it in writing, so nobody discovers the gap on launch day.
2. Write the truth first. Before anyone drafts a slide, write the one-page positioning, the known limits and “do not sell into” list, and the roadmap guidance (what can be said, to whom, under what terms). Everything else in the kit is derived from these three.
3. Write the discovery guide per persona. For each persona in the Chapter 01 buying group, write a few Situation and Problem questions and, more carefully, the Implication and Need-payoff questions that encode why they’d pay. Test them on two friendly sellers first.
4. Build the objection handling guide and battlecards from evidence. Have your harness cluster objections from recent calls, win-loss interviews and lost-deal notes, then write the responses yourself. Mark the valid objections, and say what the seller should do instead of arguing.
5. Prepare the demo, the pricing guidance and the ROI tool. Lock a demo environment with realistic data and a reverse-chronology script. Write discount bands and approvals with your pricing lead. Build the ROI tool on the buyer’s inputs with conservative, sourced defaults.
6. Enable partners by segment. For each partner type you sell through, decide what they must know, sell, deploy and support, and what certification proves it. Give every partner segment a feedback channel into your triage process.

After launch: keep customers and listen.

7. Define each customer’s Desired Outcome at the handoff. Make the sales-to-CS handoff carry the customer’s goal in Murphy’s form (objective, conditions, time frame) and the agreed first-value milestone. If the deal closed without one, CS and the PM write it with the customer in the kickoff.
8. Straighten the onboarding path. Map every onboarding step to the first moment of value. Remove or delay steps that don’t lead there. Track time to first value per cohort and review cohorts at 30, 60 and 90 days.
9. Co-own the health score. Give customer success the telemetry they need: usage against entitlement, adoption of the features that predict retention and the customer’s outcome metric. Each quarter, check whether last quarter’s scores predicted renewals and contractions, and change the score if they didn’t.
10. Decompose retention every quarter. Ask for GRR and NRR by segment and cohort, churn and contraction reasons, and expansion by trigger. Bring the decomposition to your product review (Chapter 29) as a product finding, with the problems it points to.
11. Run the outer loop weekly. Hold a 30-minute triage with product ops: dedupe requests into problem records, link them to opportunities, send the unclear ones to the trio’s interview list, decide what you can and close the loop. Publish a monthly field update.
12. Run win-loss continuously and convene the advisory board. Interview wins and losses within a month of close. Hold the CAB once or twice a year on strategic questions, report back on what you did with its advice, and refresh membership yearly.

The AI lens

Enabling and supporting AI-powered products

AI products change what the field has to explain, what customer success has to measure and what “resolved” means.

• Sell the failure modes, not just the capability. A seller who implies an AI feature is always right creates a renewal problem the first time it’s wrong. The kit needs a plain-language section on how the product behaves when it’s wrong, what controls the customer has and what evidence it shows for its outputs. Zendesk’s CX Trends 2026 research reports that 95% of consumers expect an explanation for decisions made by AI, while 37% of organizations provide one. Those are consumer figures from a vendor, with no stated sample size, but enterprise security reviewers ask the same question in writing.
• The objection guide grows a trust section. Expect objections about data use, model training, autonomy, audit and regulation. Each needs a response written with the PM and, for regulatory questions, reviewed by legal (Chapter 33).
• Define “resolved” before you celebrate it. Some AI support and operations products are now priced and measured on outcomes, Beacon Agents among them. Intercom prices its Fin AI agent at $0.99 per outcome and counts two kinds of resolution among its outcomes: confirmed (the customer says it helped) and assumed (the customer leaves without asking for more help). A follow-up question or a request for a human doesn’t count, and a resolution is deducted if the customer comes back. Intercom also claims an average resolution rate of 76% across its customers. Klarna said in February 2024 that its AI assistant handled two-thirds of its customer service chats in its first month, the work of 700 full-time agents. Both are company claims. The lesson for a PM is about definitions: an “assumed” resolution may be a customer who gave up. Whatever your product’s outcome metric is, write its definition into the kit, the health score and the contract, and make sure CS can explain it to a customer.
• Health scores need AI-specific signals. Usage alone hides whether customers trust the output. For an AI feature, add a signal for acceptance (how often users act on the AI’s output) and for override or reversal. A customer whose usage is flat but whose acceptance rate is falling is losing trust, and that shows up at renewal.

Doing the work with AI

The field already works with AI. Salesforce’s 2026 State of Sales survey found that 54% of sellers had used AI agents, nearly nine in ten planned to by 2027, and 51% of sales leaders using AI said disconnected systems were slowing them down. Crayon’s 2026 survey found 80% of competitive intelligence teams using AI to generate compete content. Both are surveys run by companies that sell into these teams, so read them as direction rather than precise measures. The direction has three consequences for the PM.

The seller’s AI assistant reads your kit. Publish structured, dated documents with owners in an accessible location. Keep pricing rules, approved claims and known limits explicit so pre-call briefings can retrieve them.

Call and ticket analysis. Connect the harness to CRM, recordings, support and telemetry through approved connectors, including Model Context Protocol (MCP) servers. Ask which objections appeared, in which segments, with which deal outcomes. Require source excerpts and review a sample before accepting clusters. Chapter 19 covers access and verification.

Draft with AI, own with a human. A harness can draft battlecards, field updates, problem merges and win-loss tags. Assign a human checker to each. Transcripts can repeat false competitor claims, and similar wording can conceal different problems.

The Beacon case: arming the field for Beacon Agents

The ownership split. Filling in the table with product marketing, enablement and the sales and CS leaders reveals one gap: nobody owns the known-limits list or roadmap guidance, and sellers have been improvising both. You take them.

The truth first. Your known-limits list has three entries the field had been glossing over. Beacon Agents acts only with human approval except for low-risk actions the customer allowlists. Diagnose depends on the connectors a customer has enabled, so a customer with no deploy or change-ticket connector gets weaker root causes. And the per-resolved-incident price applies only to Beacon Agents; the platform fee per environment remains.

Discovery questions per persona. You write Implication and Need-payoff questions for each persona in the buying group:

The objection guide. The top objection in the last quarter’s call recordings is “your agent will make things worse in production.” You write the response around the controls (approval gate, allowlisted autonomy, per-action audit logs) and you tell sellers to bring up the hallucinated root cause that led a customer to roll back the wrong service before the buyer does, then explain what changed in evals and in the approval flow (Chapter 31). Hiding it would fail the first reference call. Two other objections get entries: “our observability vendor already has AIOps,” answered with Beacon’s tool-agnostic connectors and cited evidence, and “per-resolved-incident pricing is unpredictable,” answered with the caps and bands in the pricing guidance. A fourth, “where is your EU AI Act documentation?”, is routed to Sam’s pack, owned by legal.

The battlecards. The first is against the main alternative, humans plus runbooks plus chat. The second is against AIOps features bundled into large observability platforms, written from the buyer’s need (tool-agnostic diagnosis across every system they run).

The ROI tool. Marcus’s ROI tool takes his own incident count, current MTTR and on-call cost, and shows Beacon’s effect as a range the customer sets, labeled as an assumption. It contains no benchmark gains. You had a draft with a “typical 40% MTTR reduction” line in it from a marketing slide; you deleted it because nobody could source it.

The MSP plan. For Leo’s segment, the partner enablement plan adds a technical certification for deploying connectors across many customer tenants, a sandbox tenant, and margin math under per-resolved-incident pricing. Two product gaps surface: the multi-tenant view doesn’t roll up resolved-incident counts per customer, and partners can’t set per-customer allowlists in bulk. Both go into triage as problem records with partner evidence attached.

Onboarding and health. You rewrite the onboarding plan around a Desired Outcome stated in Murphy’s form, for example: “Reduce P1 MTTR by an agreed amount within 90 days, while keeping change approval with the on-call lead.” The First Strike is the first incident in which the on-call responder accepts Beacon’s root cause. Sam’s security review becomes a prerequisite scheduled in week one rather than a surprise in week four. With customer success, you add diagnosis acceptance rate, weekly active responders and incidents resolved with Beacon’s help per account (the North Star at account level) to the health score, and agree to check the score against the next two quarters of renewals.

Retention. You ask for GRR alongside the 118% NRR, by segment. Two mechanisms go on the watch list: the Beacon Classic sunset (Chapter 30) is a GRR risk if migrations stall, and per-resolved-incident pricing moves NRR only as far as Beacon actually resolves incidents.

The feedback loop. You replace the spreadsheet with a weekly outer loop. The first triage finds about 40 requests across accounts for “auto-rollback without approval.” Asking why, account by account, collapses them into one problem record: slow approvals at 3 a.m. extend incidents (Dana’s problem). There are at least three ways to address it: approvals from the on-call engineer’s phone, a broader default allowlist, and time-boxed auto-approval for specific actions. The trio adds the problem to the opportunity solution tree and three requesting customers to the interview list. Every requester and account team hears within a week what’s being explored and when they’ll get a decision.

The advisory board. You draft a CAB charter for ten to twelve senior operations leaders, meeting twice a year with virtual sessions between, with one seat for an MSP. The first agenda has two questions: how far customers will let an agent act without a human, and how they want to buy autonomy. There’s no roadmap walkthrough.

Product 360 artifacts

# Sales enablement kit · [Product or release] · v[n] · [Date]

**PM owner:** [name]   **PMM owner:** [name]   **Enablement owner:** [name]   **Launch tier:** 1 / 2 / 3   **Next review:** [date]

## 1. One-page positioning (PMM with PM)
- For: [segment and persona]
- Problem: [in the customer's words]
- What they use today: [main alternative, including "do nothing"]
- Why we win: [two or three differentiators, each with proof]
- Proof: [reference customers, data, analyst or certification evidence]

## 2. Pitch narrative (PMM)
Problem → what changed in the world → what we do → proof → next step. Link: [deck]

## 3. Discovery guide (PM with sales)
| Persona | Situation | Problem | Implication | Need-payoff |
|---|---|---|---|---|
| | | | | |

## 4. Objection handling guide
Link: [objection guide]

## 5. Competitive battlecards
| Competitor or alternative | Card | Owner | Last updated |
|---|---|---|---|
| | | | |

## 6. Demo
- Environment: [link, data set, reset procedure]
- Script: [link] (reverse chronology: outcome first)
- Failure-mode moment (AI products): [what we show when the product is wrong]

## 7. Pricing and packaging guidance (PM with pricing)
| Item | List | Discount band | Approver |
|---|---|---|---|
| | | | |
Never promise: [custom roadmap dates, uncapped usage, unreleased features, other]

## 8. ROI or business value tool (PM)
- Buyer inputs: [list]
- Assumptions, each with source: [list]
- Default posture: conservative

## 9. Roadmap guidance (PM)
| Item | Can say publicly | Can say under NDA | Do not discuss |
|---|---|---|---|
| | | | |
Every roadmap statement carries the line: "This is not a commitment."

## 10. Known limits and "do not sell into"
| Limit or poor-fit customer | Why | What to do instead |
|---|---|---|
| | | |

## 11. FAQ and escalation
- FAQ: [link]
- Escalation to PM: [channel], response within [one business day]

## Enablement plan
| Audience | Format | Certification | Date | Owner |
|---|---|---|---|---|
| Sellers | | | | |
| Sales engineers | | | | |
| Customer success | | | | |
| Partners | | | | |

## Health of the kit
Usage by asset, field feedback, and the date each asset was last checked by the PM for accuracy.

# Objection handling guide · [Product] · [Date]

**Owner:** [PM]   **Reviewed by:** [PMM, legal for regulatory items]   **Sources:** [call recordings, win-loss, lost-deal notes, date range]

## Objection classes
Price or value · Trust and risk (security, AI safety, data use) · Integration · "We can build it" · Timing · Incumbent is good enough · Regulatory

## Entries (one per objection)

### [Objection, verbatim as buyers say it]
- **Class:**
- **Who says it:** [persona]
- **How often heard:** [count and period, with source]
- **What it usually means:** [the underlying concern]
- **Clarifying question:** [ask before answering]
- **Response:** [two to four sentences]
- **Proof:** [customer evidence, demo moment, document]
- **When to escalate to the PM:** [condition]
- **When the objection is valid:** [condition, and what the seller should do instead, including walking away]
- **Last updated:** [date]

## Retired objections
| Objection | Retired on | Why (product change, market change) |
|---|---|---|
| | | |

# Battlecard · [Us] vs [competitor or alternative] · [Date]

**Owner:** [PMM]   **PM reviewer:** [name]   **Refresh trigger:** competitor release, win-loss pattern, or every [n] weeks

## The competitor in one line
[Who they are and who they sell to]

## When we meet them
[Segments, deal stages, personas involved]

## Where they win
- [Be honest. Sellers trust cards that admit this.]

## Where we win (framed from the buyer's need)
- [Need] → [how we meet it] → [proof]

## Landmines to set (discovery questions that expose their gap)
1.
2.

## Traps they set, and responses
| What their sellers say about us | Response | Proof |
|---|---|---|
| | | |

## Pricing posture
[How they price, how we respond, what we never do]

## Win-loss evidence
[Recent wins and losses against them, with decision drivers]

# Partner enablement plan · [Product] · [Period]

**PM owner:** [name]   **Partner team owner:** [name]

## Partner segments
| Segment | Their business model | Their job with our product | Target number of partners |
|---|---|---|---|
| Reseller | | | |
| Managed service provider | | | |
| Services partner | | | |
| Technology partner | | | |

## What each segment must be able to do
| Segment | Know | Sell | Deploy | Support |
|---|---|---|---|---|
| | | | | |

## Product requirements for partners
[Multi-tenant views, per-customer billing, bulk configuration, APIs, partner pricing, deal registration. Link each gap to a problem record.]

## Content and training
| Segment | Assets | Format | Certification level | Owner |
|---|---|---|---|---|
| | | | | |

## Demo and trial environments
[Sandbox tenants, data, reset rules]

## Commercial summary
[Margin or discount structure, deal registration, co-sell rules. Link to the contract owner.]

## Feedback channel
Partners log problems through [channel] into the same weekly triage as the direct field. Response standard: [days].

## Metrics
| Metric | Baseline | Target | Review cadence |
|---|---|---|---|
| Certified partners by segment | | | |
| Partner-sourced pipeline | | | |
| Time to first partner deal | | | |
| Health of partner-managed customers | | | |

# Onboarding plan · [Customer] · [Start date]

**CSM:** [name]   **Customer lead:** [name]   **Executive sponsor (customer):** [name]   **Product contact:** [PM or SE]

## Desired Outcome
- Goal: [objective] under [conditions] by [time frame]
- Appropriate experience for this segment: [touch model, communication, self-serve vs guided]

## First value
- First-value moment: [the event that proves value]
- Target date: [date]

## Handoff from sales
- Goals agreed in the deal:
- Promises made (check against roadmap guidance):
- Buying-group members and their concerns:
- Risks flagged by sales:

## Prerequisites
| Item | Owner | Due | Status |
|---|---|---|---|
| Security review | | | |
| Connectors and permissions | | | |
| Data access | | | |
| Admin and user provisioning | | | |

## Plan
| Week | Milestone | Customer owner | Our owner | Status |
|---|---|---|---|---|
| 1 | Kickoff, joint plan agreed | | | |
| 2 | | | | |
| 3 | | | | |
| 4 | | | | |

## Checkpoints
| Day | What we review | Signals | Decision |
|---|---|---|---|
| 30 | | | |
| 60 | | | |
| 90 | Formal onboarding review | | Handoff to steady state? |

## Exit criteria
[The conditions that move the customer from onboarding to steady state]

## Risks and mitigations
| Risk | Likelihood | Mitigation | Owner |
|---|---|---|---|
| | | | |

# Feature request intake and triage policy · [Product or portfolio] · v[n]

**Owner:** [PM]   **Operated by:** [product ops]   **Effective:** [date]

## Principle
We record problems, not solutions. Every request becomes evidence on a problem record.

## Intake channels
CRM field · CS platform · Support escalations · Partner portal · Customer advisory board · Win-loss findings · AI call and ticket summaries (with links to the source)

## Required fields
| Field | Notes |
|---|---|
| Customer and segment | |
| Revenue band | |
| Requested by (role and persona) | |
| The problem, in the customer's words | Not the proposed feature |
| Current workaround | |
| Impact | Time, money, risk, blocked deal or renewal |
| Evidence link | Call, ticket, email |
| Account team contact | Who receives the answer |

## Dedupe rule
Search existing problem records first. If the problem exists, attach the new customer as evidence. If not, create a problem record with status "needs discovery."

## Linking
Every problem record links to an opportunity on the product's opportunity solution tree, or is marked "outside current outcomes."

## Statuses
New · Needs discovery · Linked to opportunity · Planned · Not planned (with reason) · Shipped

## Cadence
- Weekly triage, 30 minutes: PM and product ops
- Monthly field update: top problems, decisions and what shipped

## Service levels
- Acknowledge to requester: within [5] business days
- Decision or "needs discovery" status: within [n] weeks
- Close the loop at decision and at ship, to the requester and account team

## Rules
- Revenue-weighted counts are an input, never the sole prioritizer.
- No roadmap commitments in deals without PM sign-off, recorded on the problem record.
- "Not planned" answers include the reason and what the customer can do instead.

## Health metrics
Share of requests linked to a problem · Median time to acknowledge · Share of requesters who received a decision · Share of shipped items announced back to requesters

# Customer advisory board charter · [Product or company] · [Year]

**Executive sponsor:** [name, ideally the CEO or GM]   **Program owner:** [name]   **PM lead:** [name]

## Purpose
[The strategic questions this board exists to advise on]

## Goals for this year
1.
2.
3.

## Membership
- Size: [number]
- Selection criteria: senior decision makers from strategic accounts who can advise beyond their own account; a diverse mix of segments, regions and use cases; [partner seat, if applicable]
- Not eligible: prospects, outside thought leaders
- Term: [length], with a graceful exit for members who no longer fit

## Member value
[What members get: influence on direction, peer exchange, early insight]

## Recruitment and onboarding
[Who nominates (sales and CS), who approves, how members are briefed]

## Rules of engagement
Pitch-free · Confidential · Open dialogue · Compliant with legal and ethical rules · Sales nominates but does not attend

## Meetings
- In person: [1 to 2] times a year, [1 to 1.5] days
- Virtual: [frequency], 60 to 90 minutes
- Agenda principle: strategic questions first; no roadmap walkthrough without a question attached

## Member expectations
[Attendance, preparation, candor]

## Reporting back
After each meeting: a read-out to members within [n] weeks, documented insights, actions with owners and due dates, and candid updates on what we did not do and why.

## Annual review
Revisit charter, content, format and membership every year.

Prompts

Goal: Replace anecdotes about "what customers push back on" with evidence from real calls.
Paste in (or connect the harness to): call recordings or transcripts and CRM opportunity outcomes for [product] over the last [90] days. This is customer data: use only an approved tool, and strip personal details where possible.

From these calls for [product], find every objection a buyer raised about the product, price, risk, integration, timing or a competitor.

1. Cluster the objections into no more than 12 groups. Name each group in the buyer's words.
2. For each group give: how many calls it appeared in, which personas raised it, which segments, and the share of those opportunities that were later lost.
3. Quote two short excerpts per group, with call ID and timestamp.
4. Flag groups that appear only in one segment or only with one competitor.
5. Map each group to the current objection handling guide (pasted below): covered, partly covered or missing.

Limit the output to objection evidence and coverage gaps. Count each call once per group.

[current objection guide]

Check the output: open three of the cited calls and confirm the excerpts. Check the "lost" share against the CRM yourself. Treat any group with fewer than five calls as a lead, not a finding.

Goal: Get a first draft of a battlecard that a PMM and PM can correct, rather than a blank page.
Paste in: win-loss interview notes and call excerpts mentioning [competitor or alternative], our positioning page and known limits. Use an approved tool for customer data.

Draft a battlecard for [product] against [competitor or alternative] using only the material provided.

Sections: the competitor in one line; when we meet them; where they win (be honest); where we win, framed from the buyer's need, each with a proof point from the material; two or three landmine discovery questions; the claims their sellers make about us, with responses; pricing posture; and recent win-loss evidence.

Rules:
- Cite the source for every claim about the competitor. If the material doesn't support a claim, leave it out.
- Mark any competitor claim about us that our known limits show is true, and suggest how to acknowledge it.
- No feature grids.

[material]

Check the output: delete any competitor fact without a source, because transcripts repeat rumors. Have a seller who has lost to this competitor read it before it ships.

Goal: Give sellers Implication and Need-payoff questions for each persona, not just situation questions.
Paste in: the persona set (with job stories and anxieties), the product hypothesis and the known limits.

For each persona below, write SPIN discovery questions for [product]:
- 2 Situation questions (facts about today; keep them few, buyers tire of them)
- 3 Problem questions (difficulties and dissatisfaction)
- 3 Implication questions (what the problem costs or causes, in the persona's terms)
- 2 Need-payoff questions (invite the buyer to state the value of solving it in their own words)

Then, for each persona, say which answer would suggest this customer is a poor fit, based on the known limits.

Rules: ask about the buyer's experience and outcomes in the persona's vocabulary. Keep the discussion independent of our product and features.

[personas]
[hypothesis]
[known limits]

Check the output: try the Implication questions on a friendly seller. If they can't imagine asking one aloud, rewrite it. Make sure the poor-fit signals match the "do not sell into" list.

Goal: Find out if the customer health score is a leading indicator or decoration.
Paste in (or connect to): health scores by account at the start of each of the last [four] quarters, and renewal, contraction and churn outcomes for the same accounts. Use an approved tool; account data is confidential.

For [product], compare each account's health score at the start of a quarter with what happened at its next renewal.

1. How did renewal, contraction and churn rates differ across health score bands?
2. How many churned or contracted accounts were rated healthy two quarters before? List them with their score components.
3. Which score components moved before the bad outcomes, and which didn't move at all?
4. Which components seem to carry no information about outcomes?
5. Are there segments where the score works and segments where it doesn't?

Report counts alongside every percentage. Say where the sample is too small to conclude anything.

Check the output: pick three "healthy but churned" accounts and ask their CSMs what actually happened. If the reasons aren't in the score, propose a component that would have caught them, and test it next quarter.

Goal: Turn NRR and GRR from a finance number into problems the product team can act on.
Paste in (or connect to): recurring revenue by account for the last [four] quarters, with expansion, contraction and churn amounts, segment, cohort and any recorded churn or contraction reasons. Use an approved tool for financial data.

For [product]:
1. Compute GRR and NRR for each quarter, overall and by segment and cohort. State the formulas you used.
2. Break contraction and churn into reasons, using the recorded reasons and, where missing, the last 90 days of CS notes. Mark inferred reasons as inferred.
3. Break expansion into triggers: more seats, more environments, higher tier, more usage, new product.
4. Name the three findings that most look like product problems (value, fit, onboarding, missing capability) rather than commercial ones, with the accounts and evidence behind each.

Don't round away small segments; list them separately.

Check the output: reconcile the overall NRR with the figure finance reports. If they differ, find out why before sharing anything. Read the notes behind each inferred reason.

Goal: Turn a pile of requests into a short list of problems with evidence.
Paste in: new feature requests from the last [period] (with customer, segment, revenue band and the requester's words) and the current list of problem records. Remove personal details if your tool isn't approved for them.

For [product], take each new request and do one of three things:
1. Merge it into an existing problem record, explaining why it's the same problem.
2. Propose a new problem record, written as a customer need with no solution in it.
3. Mark it "unclear," with the question someone should ask the customer.

For each new or updated problem record, list: the customers attached, segments, revenue bands, the strongest verbatim quote, and at least two different ways the problem could be solved.

Rules: merge only when the evidence supports the same underlying need. Keep requests for the same feature separate when their reasons differ.

[requests]
[problem records]

Check the output: review every proposed merge yourself before accepting it. Any problem record with only one way to solve it is probably still a solution; rewrite it.

Goal: Keep the field informed every month without spending a day writing it.
Paste in: release notes for the month, the triage log (decisions and status changes), the top objections and the roadmap guidance.

Draft a field update for sellers, sales engineers, CSMs and partners of [product], under 500 words, with these sections: what shipped and who it helps; what's coming that you can talk about (use only items marked shareable in the roadmap guidance, and include "not a commitment"); top problems we heard and what we decided about each; known issues and workarounds; one objection and its updated response.

Write for a seller reading on a phone between calls. Plain language, no internal code names.

Check the output: confirm every roadmap item against the roadmap guidance. Remove anything that reads like a date commitment. Make sure every "we decided" item has also been sent to the original requesters.

Anti-patterns

Checklist

• The ownership split between PM, product marketing, enablement, sales and CS is written down, and the PM owns the truth of every asset.
• The sales enablement kit has all eleven components, each with an owner and a last-checked date.
• Every persona in the buying group has Implication and Need-payoff discovery questions.
• The objection guide is built from real calls and marks valid objections; battlecards cite sources and refresh on a trigger.
• The ROI tool uses the buyer’s inputs with sourced, conservative assumptions, and roadmap guidance carries “not a commitment.”
• Each partner segment has a plan covering know, sell, deploy and support, plus a feedback channel into triage.
• Every new customer has a Desired Outcome and a first-value milestone, with time to first value reviewed by cohort at 30, 60 and 90 days.
• The health score includes product telemetry and an outcome metric, and has been checked against renewals.
• GRR and NRR are decomposed by segment, cohort, reason and trigger every quarter, and the findings reach the product review.
• Feature requests are deduped into problem records linked to opportunities, triaged weekly, with the loop closed at decision and at ship.
• Win-loss interviews run continuously, soon after close, for wins and losses.
• The customer advisory board has a charter, a strategic agenda and a report-back for every meeting.
• For AI products, the kit explains failure modes and controls, and the outcome metric (“resolved,” “accepted”) is defined the same way in the kit, the health score and the contract.
• AI-generated field analysis links to its source calls and tickets, and runs only in approved tools.