Pilot ≠ POC: Prove the Fix, Not the Feature — Test the approach, not "does it run"; goal is decision, not demo.

TL;DR: Test the approach, not "does it run"; goal is decision, not demo.

The problem (why now)

When a team says "let's do a POC," what they often mean is "show me it runs." That's not the job. The job is to prove the fix to an urgent & important problem in buyer language and connect it back to a stated priority. If the problem isn't urgent and important, the rest of the story doesn't matter; the business case is supposed to prove value against the buyer's priority and timeline, not float on vague goodness. Lead with the recognized symptom, connect the dots to the priority, and anchor the whole thing in a single-page executive summary that says: if the analysis holds, we should act. Numbers first. Names of stakeholders consulted. Pricing as a range. Keep it short because decision-makers read the summary, evaluators read the detail.

Start where the buyer is. List symptoms they already recognize as urgent & important, and show how those symptoms connect to a root cause you can fix. That bridge is your credibility. It's not enough to claim a fix; you need measurable symptoms, a clear "connect the dots" path, and language the buyer already uses to describe the pain.

The POV (how the system works)

The POV is simple: Symptoms → Root Cause → Fix. No product nouns. Build a structured version of your point of view so anyone can follow it in the order buyers think: do we have a problem, what's causing it, and how do we fix it, independent of any vendor. Operationalize what you know that others don't, and label the sections so your team (and the buyer) can reuse them consistently.

For root cause, list possible causes for each major symptom, estimate prevalence, tag anything outside your remit, and go a couple levels deeper by asking "why" again. Decide whether the conclusion is self-evident or needs proof, and identify what customer data would support the analysis. This is how you avoid mistaking correlation for causation.

For the fix, describe what "fixed" looks like, what changes must happen, who's impacted, the risks and barriers, and how you'll mitigate them. Share enough detail that a competent team with unlimited time & budget could fix the problem. Visuals help the buyer connect the dots across multiple causes and outcomes.

The three options

Every problem has exactly three options: Do Nothing, DIY, or find a Vendor. The fix is the same—what changes must occur—only the who/when/how differ. Be explicit. For each, describe who does what work, who is impacted, and the realistic timeline with major milestones.

DIY needs an honest accounting: design time, in-house expertise, people pulled off their day jobs, the other teams you'll need, and all the ways things can go wrong—with the ongoing costs at 3, 6, and 12 months. Don't forget onboarding, documentation, keeping dependencies up to date, upgrades, triage, and feature requests. Capture it so the buyer can decide rationally.

Call out the spreadsheet and "we'll just build it" failure modes. POCs are easy; production is hard. Security, user management, upgrades, and dependency management all pile on once you move past a spike. That last 80% is tough, and the opportunity cost is real. Put it in the spreadsheet.

Do Nothing is also explicit: it equals the cost of the impact you quantified. Your model should make that clear.

The model (show your work)

Quantify with Canary and Impact. Your Canary metric is the direct indicator that separates those with the problem from those without—be careful with causation. Your Impact metric is the high-level symptom that improves if you fix the root cause. Connect the "what if" insight to data and show the math: how improving the Canary moves the Impact. Encourage buyers to replace placeholders with their own numbers.

Then configure the financial model to compare the three options:

Inputs: FTE costs and the cost of the problem from your Impact math.

Time factors: development + implementation durations (time counts against benefit).

Risk factors: the percent chance the approach will fix the problem (100% means nothing can go wrong).

Benefit: Impact × Risk.

Costs: everything required for the fix, including cost of change.

Net Outcome: Benefit − Cost.

Calculate for two windows: a near window (1–2 quarters) and over time (12–18 months).

Expose assumptions in plain language with units. For example: "Build time = 8 weeks @ 2 FTEs; adoption ramp = 90 days to steady state; risk of DIY success = 50%; risk of vendor success = 80%." Ask the buyer to sign off on risk percentages because they swing the outcome.

Proof / pilot (if needed)

A pilot isn't "show it runs." It's a test-tube to validate the approach—prove the fix. Design it around four questions:

What is the approach? Write down the change the buyer will see after buying your solution—the "what fixed looks like" you already defined.

What might go wrong? The risk list must come from the buyer. User rollout, integrations, data migration, continuity of results—assume "does the software work" is not the real risk. For each risk, add guardrails.

Shortest time to learn? You're not proving the whole value prop to the nth degree—only enough to show it's safer than Do Nothing or DIY.

How will we know? Define observable change and/or whose "thumbs up" counts when hard numbers aren't available. Get it in writing to avoid the goalposts moving.

That's the test-tube design. Then run it real smooth: pick two teams—one stellar (to show potential) and one average (to prove everyday usability). Secure an executive sponsor, calendar all check-ins across the pilot, and test against the agreed criteria at every touch. Push against happy ears; reward candor; use smaller groups so people actually talk. Goal: decision, not demo.

Success criteria include: the specific Canary improvement observed (unit + timeframe), the buyer-perceived risk mitigations that held, and the executive's explicit "go/no-go" authority with a decision date on the calendar. The artifact is a short addendum to your business case recording the change observed, guardrails used, and the decision.

Implementation & change

Implementation is the same storyline you laid out in the three options, now with owners, milestones, adoption, and dependencies written down to avoid shelfware. Spell out who does what work, who is impacted, and the realistic timeline with major milestones. Include the extra "cost of change" and the check-ins cadence that made the pilot effective, then reduce the frequency once training, peer pressure, and real investment create momentum.

Carry the momentum through Thank God I Gave You Money Day—the moment the buyer sees first value post-go-live—then execute the expansion you bookmarked in the Mutual Action Plan. Don't wait a year; remind the core team that the pilot only proved your root-cause knowledge and guardrails; the bigger value is next.

What good looks like (checklist)

• Symptoms are measurable and recognizable as urgent & important; the "connect the dots" to root cause is clear.
• Root cause analysis lists alternatives, estimates prevalence, and notes where proof is needed.
• Fix is described without product nouns, with metrics for "happening vs. fixed," risks, mitigations, and who is impacted.
• Three options (Do Nothing, DIY, Vendor) are explicit with owners, work required, and realistic milestones.
• Model shows your work: Canary → Impact → Value; Benefit = Impact × Risk; Net = Benefit − Cost; calculated for 1–2 quarters and 12–18 months with buyer-signed risk percentages.
• Pilot is a test-tube: observable change, buyer-perceived risks with guardrails, shortest time to learn, success criteria, decision maker, and decision date. Goal: decision, not demo.
• Implementation plan written down (owners, adoption, dependencies), with cost of change included and a path to expansion post-TGIGYMD.
• Business case is concise with an exec summary that ties priority → problem → proof → value → milestones, supported by one killer chart.

CTA

If the problem is urgent & important and the fix is clear, let's design the smallest possible test-tube pilot that proves the approach, not the feature, and set a calendar decision date. We'll document the observable change (Canary movement in units over time), the guardrails against buyer-named risks, and success criteria that a real decision-maker will use to say "go" or "no." Goal: decision, not demo.