Evidence that Medicare shoppers are actively looking for a better way to choose coverage.
D.1
Sizing the target audience
Why: We need to know how many members actually face the coverage-choice problem each year.
Criteria: Segment counts: new-to-Medicare, switching AEP, dual-eligible, caregivers.
Evidence: Market sizing memo with sources (CMS enrollment data, internal book).
Risk if skipped: Building for an audience that is too small to justify the investment.
D.2
Current-behavior signal
Why: If the problem is real, members are already coping with it somehow.
Criteria: Data on Plan Finder abandonment, agent call reasons, search queries, complaints.
Evidence: Behavioral analysis brief.
Risk if skipped: Solving a problem that members don't actually experience.
D.3
Stated interest in an AI-guided experience
Why: Willingness to use AI for a high-stakes health decision is not a given.
Criteria: Survey with target segments; opt-in intent for AI-guided shopping.
Evidence: Survey report with sample size, methodology, and demographics.
Risk if skipped: Overestimating AI acceptance in a 65+ audience.
Proof that today's shopping experience actually fails members in specific, describable ways.
U.1
Named jobs-to-be-done
Why: Vague pain points don't drive product decisions.
Criteria: 5-10 JTBD statements per segment with quotes.
Evidence: JTBD document from qualitative research.
Risk if skipped: Building a generic experience that helps no one particularly well.
U.2
Failure modes of the status quo
Why: The AI has to be measurably better than what members do today.
Criteria: Documented breakdowns: overwhelm, wrong plan, missed drugs, missed providers.
Evidence: Failure-mode inventory tied to interview evidence.
Risk if skipped: Parity with the status quo — not enough reason to switch.
U.3
Caregiver-specific need
Why: Caregivers often drive the decision but the current tools ignore them.
Criteria: Interviews with adult children / spouses making decisions on behalf.
Evidence: Caregiver research summary.
Risk if skipped: A member-only design that breaks when a caregiver is involved.
Are members comfortable letting a Crinkle Health AI recommend and enroll them?
T.1
Brand permission to guide
Why: Members must believe the brand is neutral enough to trust the recommendation.
Criteria: Brand-perception study; trust ratings vs. competitors and neutral brokers.
Evidence: Brand research report.
Risk if skipped: Members read the recommendation as a sales pitch and disengage.
T.2
Transparency + override expectations
Why: Members need to see 'why this plan' and be able to disagree.
Criteria: Concept tests showing rationale UI and override flow.
Evidence: Usability study with pass/fail thresholds.
Risk if skipped: Perceived coercion; formal complaints; regulator attention.
T.3
Comfort with AI-assisted enrollment
Why: Recommending is different from submitting an enrollment on their behalf.
Criteria: Willingness metrics for each step: chat → compare → enroll → e-sign.
Evidence: Willingness study with drop-off analysis.
Risk if skipped: Members happy to chat but unwilling to actually enroll through the AI.
The AI has to be usable by the members most likely to need it — not just the digitally fluent.
A.1
Assistive-tech scenario testing
Why: Screen readers, high-contrast, and voice input are baseline needs, not edge cases.
Criteria: Task-based tests with members using assistive tech.
Evidence: Accessibility usability report.
Risk if skipped: Excluding the highest-need segments; ADA exposure.
A.2
Plain-language comprehension
Why: Medicare vocabulary is a barrier before the AI even starts.
Criteria: Comprehension checks at target reading grade (≤ 8th).
Evidence: Readability + comprehension study.
Risk if skipped: Members nod along, don't understand, and disengage silently.
A.3
Low-bandwidth / low-device viability
Why: Many members are on older phones or shared devices.
Criteria: Testing on representative devices and network conditions.
Evidence: Device / bandwidth test log.
Risk if skipped: Experience only works for well-resourced members.
Structured tests that prove the specific concept — not just the abstract idea — resonates.
C.1
Concept test with target segments
Why: The idea might poll well in the abstract and fail on the specific execution.
Criteria: Prototype walkthrough with per-segment reaction, intent, and objections.
Evidence: Concept-test report with quotes and quant intent scores.
Risk if skipped: A concept that tests well only with early adopters.
C.2
Preference vs. current alternatives
Why: Compare to Plan Finder, calling a broker, and calling a family member.
Criteria: Head-to-head preference study.
Evidence: Preference study with statistical significance.
Risk if skipped: Preferred in isolation, ignored when other options exist.
C.3
Willingness to recommend to a caregiver / peer
Why: Word-of-mouth is a leading indicator of trust in this population.
Criteria: NPS or equivalent from concept testers.
Evidence: NPS + verbatims from concept test.
Risk if skipped: Members use it once and never talk about it.
Once a lightweight prototype exists, keep listening to real members.
S.1
Live prototype telemetry
Why: Behavioral signal beats stated intent.
Criteria: Engagement, completion, hand-raise-for-agent, and drop-off events.
Evidence: Telemetry dashboard.
Risk if skipped: Trusting survey data that behavior contradicts.
S.2
Qualitative feedback loop
Why: Numbers tell you what; interviews tell you why.
Criteria: Recurring interviews with users and abandoners.
Evidence: Rolling research log.
Risk if skipped: Optimizing metrics without understanding the driver.
S.3
Go / no-go criteria to enter Feasibility
Why: Desirability has to end in a decision, not a vibe.
Criteria: Written thresholds for demand, trust, comprehension, and preference.
Evidence: Go/no-go memo signed by Product + Research.
Risk if skipped: Slipping into Feasibility work before the core assumption is proven.
Exit to Feasibility
Once these items are validated (or explicitly accepted as risk) for a given project, the program moves into the Feasibility & Viability rubric — where we use NIST AI RMF (Govern → Map → Measure → Manage) to prove we can actually build and safely operate what members said they wanted.