Enterprise Pilot Program Template

30 days for simple products (single workflow, minimal integration). 60 days for complex products (multiple workflows, integrations, or organizational change required). Never exceed 90 days. If you need more than 90 days, you are piloting too broad a scope. Narrow the use case and extend later if the initial pilot succeeds.

10-25 users is the sweet spot. Fewer than 10 does not generate statistically meaningful adoption data. More than 25 creates onboarding and support overhead that distracts from evaluation. For products with network effects (collaboration tools), lean toward 20-25. For individual productivity tools, 10-15 is sufficient.

Charge for pilots when possible, even at a discount. Paying customers are invested customers. Free pilots attract tire-kickers who have no urgency to evaluate or decide. A common model: "The pilot is free. If you proceed to full deployment within 30 days of the evaluation meeting, the pilot period is credited toward your first year." This creates urgency without risk.

Diagnose the cause by week 2. Low adoption usually stems from one of three issues: the product does not fit the workflow (product problem), users were not trained adequately (execution problem), or users are too busy to evaluate (priority problem). For execution and priority problems, schedule 1:1 sessions with inactive users. For product problems, adjust the use case or acknowledge the gap. The [strategy guide](/strategy-guide) covers techniques for diagnosing product-market alignment issues.

Extension requests are usually buying signals wrapped in indecision. Ask: "What specific question would a 30-day extension answer that we cannot answer today?" If they have a legitimate gap (e.g., need to test with a second team), agree to a structured 30-day extension with its own success criteria. If they cannot articulate what would change, push for the evaluation meeting with the data you have. Perpetual pilots are worse than a clear no. ---