FDE Adoption and Value

Move from “the POC ran” to a testable conclusion about who will keep using it, what value it creates, and whether further investment is justified.

Required input

Read the POC Run and Validation Report from fde-poc-runner and revisit the frozen success criteria in the POC Engagement Charter.

Identify real users, actual tasks, run evidence, the baseline or its gap, business owners, and available data. When data is unavailable, mark the claim as unvalidated. Do not convert positive opinions into value.

Use references/adoption-input-guide.md to separate technical outcomes, task behavior, sustained adoption, and business outcomes.

Method

1. Separate use from value: State who used the solution for which task, whether behavior changed, and whether outcomes improved. Demo count is not adoption.
2. Build traceable metrics: Connect every value claim to a definition, baseline, target, data source, collection frequency, and owner. Mark it as customer-confirmed, FDE-inferred, or unvalidated.
3. Find adoption resistance: Analyze workflow integration, trust, training, permissions, incentives, support, and change-management risk.
4. Recommend the next investment: Define evidence-based conditions to continue, scale, correct, pause, or stop. Do not treat correlation as causation or promise unvalidated ROI.
5. Handoff productization candidates: Send repeated customer needs, effective implementation patterns, and standardization opportunities to fde-playbook-productizer.

See references/adoption-rules.md for adoption diagnosis, rollout segmentation, feedback, and support; see references/value-measurement.md for metric trees, baselines, attribution, and ROI rules.

When the engagement requires enablement, support, customer takeover, FDE exit, or production-operations handoff, read references/enablement-and-handover.md. Validate knowledge transfer with independent tasks and failure drills, not attendance counts.

Execution sequence

1. Freeze target users, eligibility, adoption events, and the measurement window.
2. Recover business and task baselines from the charter and historical workflow.
3. Build a technical → task → adoption → business → risk metric tree.
4. Segment users by role, scenario, frequency, experience, and risk.
5. Observe drop-off across awareness, access, first success, repeat use, and workflow dependence.
6. Interview users who adopt, refuse, or stop; distinguish value, capability, trust, workflow, and incentive issues.
7. Calculate full incremental cost and label value as customer-confirmed, FDE-inferred, or unvalidated.
8. Design training, support, permissions, governance, and stop conditions for the next cohort.
9. Decide to scale, correct, pause, or stop.
10. Handoff repeated cross-scenario patterns and their evidence to Productization.

Measurement windows

Use short windows for first success and longer windows for repeat adoption and business outcomes. When observation is too short, report leading indicators rather than long-term value. Include seasonality, business volume, staffing, and simultaneous policy changes in attribution limits.

Use-value conflicts

• High use, low value: check novelty use, duplicated work, or distorted incentives.
• Low use, high value: check entry points, permissions, training, trust, and misalignment between beneficiary and burden bearer.
• High technical quality, low task success: return to PRD, architecture, or Skill Design.
• Strong expert results only: segment and validate ordinary users before generalizing.

Output

Use references/adoption-value-plan.md to produce the Adoption and Value Review Package.

Boundary

Do not replace contract pricing, financial audit, or the customer’s final procurement decision. Produce reliable adoption and value evidence for those decisions.

Quality gates

• Record technical metrics, user tasks, adoption behavior, and business outcomes in separate layers.
• Give every metric a definition, baseline, target, data source, window, and owner.
• Separate customer-confirmed, FDE-inferred, and unvalidated claims; do not present correlation as causation.
• Define the denominator, target population, and active-use event for adoption rates.
• Record refusal, workarounds, manual correction, support requests, and negative effects.
• Include population, workflow, enablement, support, permission, and governance conditions in any scale recommendation.
• Include operations, human review, integration, support, and risk cost in ROI.
• Recommend stopping when value evidence is absent; do not scale because of sunk cost.

Score with references/adoption-quality-rubric.md. See references/adoption-worked-example.md for a complete example and references/adoption-field-handbook.md for detailed metrics, adoption interviews, and scale cadence.

See references/public-sources.md for public methodological sources.