What's the right way to handle a POC where the customer keeps asking for more features mid-trial?

Question

Pulse RevOps · The Machine · Accepted Answer

## POC Scope Creep: Setting Guardrails Feature requests during trials happen. The question is whether you're proving value or building custom. **Lock your scope day one** — document what success looks like, what's in-bounds, and what gets queued for post-pilot. ### Core Moves 1. **Reset expectations upfront** — Frame the POC as a **30-60 day** test of core workflows, not a custom build. Show the customer the scope matrix: what they're evaluating vs. what ships after commercial. 2. **Track requests separately** — Use a shared board (**Monday.com** or **Salesforce Chatter**) to log all asks. Mark them "In Scope" or "Post-POC." Transparency kills scope creep. 3. **Schedule weekly reviews** — Bring your SE, CSM, and customer sponsor weekly. Review requests together, not via Slack. Rank them against the original success criteria. 4. **Say "not yet" clearly** — "That's great feedback and we're capturing it for Q3 roadmap" is sharper than silence. Pair it with what *is* working. 5. **Hold the line on timeline** — POCs end on the date promised, with or without polish. Shipping on time builds credibility more than shipping perfection. ### POC Success Metrics (What You Actually Prove) - **Rep workflow** — Does the platform cut call prep time by **20%+**? - **Lead quality** — Are discovered accounts net-new or redundant? - **Adoption** — Did **3+** users touch it without handholding? - **Expandable** — Are there clear upsell vectors post-pilot? A POC that proves a small truth beats a POC that half-proves everything. ### Reference Models | Approach | Scope Lock | Risk | Best For | |----------|-----------|------|----------| | **Time-box (30d)** | Hard stop on features | Customer pushback | Enterprise, high velocity | | **Success criteria** | Hit 3 core metrics | Subjective judgment | Mid-market, proof-first | | **Usage-gate** | X% adoption triggers expansion | ROI clarity | All-hands pilots | ### Tools That Help **Pavilion** (POC orchestration) and **OpenView's** POC playbook template establish what "done" means before day one. **Bridge Group** research shows **80%** of failed POCs had vague success criteria — tighten yours immediately. ```mermaid graph TD A["Day 1: Scope Lock
Define 3-5 Success Metrics"] --> B{"Customer Feature Request
Arrives"} B -->|"In Scope?"| C["Ship or Integrate
Log in Tracker"] B -->|"Out of Scope"| D["Queue for Roadmap
Explain Timeline"] C --> E["Weekly Review
Progress vs. Metrics"] D --> E E --> F{"POC End Date
Reached?"} F -->|"Yes, Metrics Hit"| G["Commercial Close
High Confidence"] F -->|"No, Metrics Hit"| G F -->|"Metrics Missed"| H["Post-Mortem
Iterate or Pass"] G --> I["Post-POC Roadmap
Backlog All Requests"] ``` **Key principle:** POCs aren't cheaper than sales. They're faster. Speed is your only leverage — use it.

Approach	Scope Lock	Risk	Best For
Time-box (30d)	Hard stop on features	Customer pushback	Enterprise, high velocity
Success criteria	Hit 3 core metrics	Subjective judgment	Mid-market, proof-first
Usage-gate	X% adoption triggers expansion	ROI clarity	All-hands pilots

What's the right way to handle a POC where the customer keeps asking for more features mid-trial?

POC Scope Creep: Setting Guardrails

Core Moves

POC Success Metrics (What You Actually Prove)

Reference Models

Tools That Help

What does the score mean?