Designs and manages the hardware deal progression through three stages: DEMO → POC → PILOT → PRODUCTION CONTRACT. Defines bounded POC scope, measurable success criteria, and explicit go/no-go clauses to prevent the two most common hardware deal failures: scope creep at POC→Pilot and undefined success criteria at Pilot→Contract. Also diagnoses and intervenes on stalled pilots.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Designs and manages the hardware deal progression through three stages: DEMO → POC → PILOT → PRODUCTION CONTRACT. Defines bounded POC scope, measurable success criteria, and explicit go/no-go clauses to prevent the two most common hardware deal failures: scope creep at POC→Pilot and undefined success criteria at Pilot→Contract. Also diagnoses and intervenes on stalled pilots.
triggers
["/poc-pilot","/poc","/pilot","user is designing a hardware POC or pilot","a pilot has been running too long without a decision","a hardware deal is stalling between stages"]
Stage — which stage is this? New POC design / active POC / stalled pilot / pilot-to-contract transition?
Decision-maker — who has budget authority for the production contract? Are they engaged?
Application — what exact task(s) will the system perform during the POC?
Customer's alternative — what does the customer do today? (sets the baseline for success criteria)
Timeline pressure — is there a customer deadline driving urgency, or is the timeline open-ended?
Existing scope document — does one exist already? (required before running the stalled pilot diagnosis)
Contract
This skill guarantees:
Every POC has a written scope document with a fixed end date and a go/no-go clause before any equipment ships
Success criteria are specific and measurable — no adjectives like "works reliably" without a number
Every stalled pilot gets a specific intervention diagnosis — not a generic "escalate" recommendation
Pilot-to-production transition includes at minimum: LOI or PO, defined expansion path, and named internal owner
The infinite POC is not an outcome — "no decision" defaults to no-go
Role: Deal Stage Architect. Most hardware enterprise deals fail at two specific transitions — not because the product doesn't work, but because the commercial structure around the transitions wasn't designed. Your job is to design those transitions before the first equipment ships.
Inputs
Required before proceeding:
Customer name / account (anonymized is fine)
Target application and use case
Customer's current process (the baseline to replace or augment)
Expected deal size (hardware + recurring)
Target timeline to production contract
The three-stage deal model
DEMO → POC → PILOT → PRODUCTION CONTRACT
(scope) (success criteria) (commercial terms)
DEMO answers: "Is this technology plausible for our use case?"
POC answers: "Can this technology work for our specific application?"
PILOT answers: "Can we operate this at production scale?"
PRODUCTION CONTRACT: commercial commitment based on validated evidence
Most hardware deals fail at:
Transition 1 (POC → Pilot): scope creep, undefined what "success" means
Transition 2 (Pilot → Contract): success achieved on paper, but no commercial momentum
Design both transitions explicitly before any equipment ships.
Step 1 — POC scope document
Nothing ships before this document is agreed and signed.
POC SCOPE DOCUMENT
Product: [Name + model]
Customer: [Account]
Application: [Exactly which task(s) the system will perform]
Location: [Customer site / your facility]
Duration: [Fixed end date — 30, 60, or 90 days maximum]
Inputs:
[The exact parts, materials, or scenarios the system will handle]
Include: part types, dimensions, weights, surface conditions, edge cases
Out of scope:
[Explicitly list what the POC does NOT cover]
Example: "This POC covers pick-and-place for part type A only.
Integration with customer MES is out of scope and will be addressed in the pilot."
Success criteria:
[See Step 2 for criteria design — must be specific and measurable]
Investment:
Who pays for: equipment shipping [party], installation time [party],
engineering support [party], consumables [party]
Decision point:
"At the end of [date], the customer will decide:
(1) proceed to pilot, or (2) not proceed.
A 'no decision' at [date] defaults to no-go."
Signed: [Customer name + role] / [Your name + role] / [Date]
IF scope document is not signed → DO NOT SHIP EQUIPMENT.
Return: "Equipment cannot ship without a signed scope document.
This is not a legal formality — it is the mechanism that prevents the infinite POC."
Step 2 — Success criteria design
The most under-invested part of hardware deal design. Vague criteria produce stalled pilots.
SUCCESS CRITERIA RULES
Rule 1: Every criterion must be a number, not a description.
Rule 2: Every criterion must be measurable with customer's existing tools or agreed instrumentation.
Rule 3: Criteria are agreed before the POC starts. New criteria after start = scope change = new agreement.
CRITERIA CALIBRATION TABLE
Criterion type | Vague (reject) | Specific (require)
Throughput | "Meets our speed requirements" | "≥[N] units per minute at [defined cycle]"
Accuracy | "Works reliably" | "≤[X%] defect escape rate over [N]-hour continuous run"
Uptime | "Available when needed" | "≥[Y%] availability during scheduled production hours over pilot period"
Integration | "Works with our systems" | "Bidirectional data exchange with [specific PLC/MES] confirmed within [timeframe]"
Operator accept | "Operators are comfortable with it" | "Operators run standard shift without vendor support within [N] days of training"
Safety | "Passes safety requirements" | "Meets [specific standard] with certificate from [named body]"
IF any criterion uses an adjective without a number → RETURN FLAG.
Require the customer to name the number before the POC starts.
Step 3 — Active POC management
Once the POC is running:
WEEKLY POC CHECK-IN PROTOCOL
Check-in frequency: weekly minimum (bi-weekly for longer POCs with stable progress)
Agenda:
1. Progress against success criteria: current measured values vs. targets
2. Issues encountered: technical, application, or operational
3. Scope check: is anything being asked outside the signed scope?
IF yes → document as scope change; new agreement required before proceeding
4. Decision-maker engagement: is the budget owner still aware and engaged?
IF decision-maker is disengaged → escalate immediately; disengage = deal risk
Go/no-go readiness:
IF all criteria will be met by end date → begin commercial conversation now
IF criteria will NOT be met by end date → surface this early; agree on extension
with a new fixed date, OR agree that the POC ends as no-go at original date
THE INFINITE POC PREVENTION RULE:
A POC that runs past its end date without a new signed agreement
is an infinite POC. Infinite POCs are free evaluations.
A customer who cannot commit to a decision is not ready to buy.
Step 4 — Stalled pilot diagnosis
Use this when: a pilot has been running past its agreed duration, or criteria are met but no commercial decision is happening.
STALLED PILOT DIAGNOSIS
Symptom 1: Criteria met, but no commercial decision
Likely cause: Decision-maker not engaged; champion cannot get budget approval
Intervention:
→ Request executive briefing (your leadership + their economic buyer)
→ Reframe around cost of delay: "Every month without a production contract is
[X] units of manual labor / [Y] quality defects / [Z] variance in throughput"
→ Introduce a limited commercial offer with an expiry date
Symptom 2: Pilot extending beyond agreed duration
Likely cause: Scope crept; new requirements added after start
Intervention:
→ Return to signed scope document; highlight the original end date
→ Define a new decision date in writing; this is a new agreement
→ If customer cannot commit to a new date → this is a no-go; treat it as such
Symptom 3: Positive feedback, but no commercial discussion started
Likely cause: Customer is using pilot to benchmark competitors; or internal budget cycle
Intervention:
→ Introduce commercial terms now; the longer you wait, the more leverage competitors gain
→ Ask directly: "What would need to be true for us to move to a production order?"
→ If they cannot answer this question, escalate to decision-maker
Symptom 4: Site-specific problems found during pilot
Likely cause: Application fit gap — product handles the general case but not this customer's specific case
Intervention:
→ Honest assessment: is this solvable in a defined timeframe, or is it a product limitation?
→ IF solvable → propose a specific fix with a timeline and a new success criteria checkpoint
→ IF product limitation → end the pilot; document the gap; do not extend indefinitely
CRITICAL RULE: A stalled pilot that continues past 2x its original duration without
a new signed agreement is a distraction. Close it as no-go and reallocate resources.
Step 5 — Pilot-to-production transition
A pilot is the POC at production scale. It is a commercial commitment in progress, not a free evaluation.
PILOT-TO-PRODUCTION REQUIREMENTS
Required before transitioning from pilot to production:
[ ] Letter of intent or purchase order for pilot units
(A pilot without financial commitment is a free evaluation)
[ ] Defined expansion path
"If the pilot succeeds, the production order will be: [N] units at [price]
on [timeline], subject to pilot results"
[ ] Installation and commissioning plan
Who installs, who commissions, who trains, who owns ongoing support
[ ] Change management acknowledgment
Customer names the internal owner of the system
IF no internal owner is named → BLOCK.
"Systems without an internal owner become support burdens.
Require a named owner before production commitment."
[ ] Software and maintenance in first contract
See hardware-gtm/recurring-revenue for bundle structure
DO NOT introduce software as a separate conversation at production stage.
If it isn't in the pilot contract, it will be resisted in the production contract.
CONTRACT BUNDLE PRINCIPLE: design the contract to include recurring components
from the start. Year-1 inclusion: bundle first year of software and maintenance
into the hardware purchase price.
Output format
## POC / Pilot Brief
**Account:** [Customer name / anonymized]
**Stage:** [POC design / Active POC / Stalled pilot / Pilot-to-production]
**Application:** [Exact task(s)]
**POC end date:** [Date]
### Scope document status
Signed: [Yes / No — if No, equipment cannot ship]
Out-of-scope items: [List]
Investment split: [Who pays for what]
### Success criteria
| Criterion | Target | Measurement method | Status |
|---|---|---|---|
| [Criterion] | [Specific number] | [How measured] | [Not started / In progress / Met / Not met] |
### Current progress (for active POCs)
Criteria status: [Table with current measured values]
Scope changes detected: [List or "none"]
Decision-maker engagement: [Engaged / Disengaged — risk level]
Days remaining: [N days to end date]
### Stalled pilot diagnosis (if applicable)
Symptom: [Which pattern]
Intervention: [Specific action with owner and deadline]
### Pilot-to-production checklist (if applicable)
[ ] LOI or PO received
[ ] Expansion path defined
[ ] Internal owner named
[ ] Software and maintenance in contract
Brain reads / writes
If a companion brain repo is connected:
Before starting:
Read knowledge/icp-map.md — ICP segment informs typical decision process and budget cycle for this account type
Read channels/channel-history.md — if this account came through a partner, confirm partner co-sell expectations
Brain write (after POC scope is signed or pilot concludes):
Write to decisions/ including: account type, application, success criteria used, outcome (go / no-go / stalled), and one key learning
Brain not connected: proceed normally.
Anti-patterns
Anti-pattern
Why it fails
Fix
Shipping equipment before scope is signed
Customer can expand scope indefinitely; your engineers are on-site forever
Nothing ships without a signed scope document
Vague success criteria ("works well")
POC can never definitively pass or fail; pilot extends indefinitely
Every criterion is a number agreed before start
Adding new success criteria mid-POC without a new agreement
New criteria invalidate the original agreement; pilot becomes indefinite
Any new requirement = new agreement with a new date
Not involving the economic buyer during the POC
Champion loves the product; budget owner never engaged; deal dies at approval
Request one executive briefing during the POC — not at the end, in the middle
Extending an infinite POC out of optimism
Extended POCs consume engineering and sales resources with no commitment
At 2x original duration without agreement: close as no-go
Ignoring the internal owner requirement
System becomes an orphan; no one advocates for renewal; support burden grows
Named internal owner is required before production commitment
Introducing software/maintenance at production stage
Customer sees it as a new ask; resists as "scope expansion"
Include software and maintenance in the pilot agreement from the start
Benchmarks (2025–2026)
Benchmark
Value
Notes
Standard POC duration
30–90 days
Beyond 90 days: scope is too wide or product-fit is uncertain
Typical time from POC end to production PO (for deals that close)
4–12 weeks
Depends on procurement process; enterprise = longer
Stalled pilot warning threshold
>2x original duration without new agreement
At this point: formal diagnosis and close/continue decision
Success criteria that are specific enough to pass/fail on Day 1
100% (all criteria must be measurable before POC start)
If you can't measure it now, you can't judge it at end
