tidaldb/.sdlc/features/p0-target-segment-recruitment/spec.md

p0-target-segment-recruitment: Target Segment & Recruitment

Problem Statement

P0 ("Beachhead Validation") must answer whether a personal briefing feed drives repeat use. That question is only answerable if the people in the study are the people the product is for. There is currently no screening bar, no recruitment funnel, and no cohort record -- so the pilot could be staffed with contacts, developers, or passive scrollers and produce a retention number that means nothing.

Open questions this feature closes:

1. Which of the two beachhead personas (docs/personal-briefing-beachhead.md §2) are in scope, and what disqualifies a candidate?
2. How many candidates must enter the funnel to land a 20-50 person pilot cohort (ROADMAP P0 AC-1)?
3. What may the outreach promise, given the prototype is concierge-operated with manual source QA (§10 Phase A)?
4. What consent is required before behavioral instrumentation and recorded interviews?
5. What is stored per participant, where, and under what identifier?

Goals

1. Screening bar -- explicit qualify/disqualify criteria derived from persona jobs-to-be-done (§3) and the adoption-killing failure modes (§6.3).
2. Sized funnel -- named stages with a stop condition that lands the cohort inside the 20-50 range and survives pilot attrition.
3. Honest outreach artifact -- states the real commitment, promises nothing the prototype cannot deliver, and does not prime the interview outcome.
4. Consent and data handling -- one consent record per participant covering instrumentation, recording, retention, and deletion.
5. De-identified cohort record -- git-tracked roster keyed by an opaque participant_id, with no personal identity anywhere in the repo.
6. Segment balance -- a cohort that is not a single persona or a single role bucket.

Non-Goals

• Running the daily briefing or the pilot itself -- p0-concierge-pilot-loop.
• Interview coding, retention analysis, and the GO/NO-GO decision -- p0-validation-readout.
• Any engine, app, or instrumentation implementation (consumed, not built, here); Phase B scale recruitment (200-500 users, §10 Phase B) and paid acquisition channels.

Functional Requirements

FR-1: Persona Scope and Screening Criteria

In scope: the primary persona "information-overloaded decision maker" (§2), narrowed per §10 Phase A to strategy / product / analyst / operations / media / investing / policy roles; and the secondary persona "curious consumer with intent". Both classes are in scope because ROADMAP P0 AC-1 names knowledge workers and high-intent consumers.

Qualify -- all must hold, each recorded as a roster field:

• Q1 Consumes content to make decisions rather than for entertainment (primary), or follows multiple topic domains with stated intent (secondary) -- §2.
• Q2 Uses at least one incumbent baseline daily: feeds (X, LinkedIn, YouTube, Reddit, news apps), newsletters, podcasts, or a general AI assistant. Without an incumbent, the §6.2 question "why not just use my current feeds?" has no comparison.
• Q3 Commits to a daily session across the 2-week pilot and to at least one feedback action (more/less/hide/mute/save) per session -- ROADMAP P0 AC-3.
• Q4 Willing to complete onboarding inputs: 5-10 interests, depth, hard excludes, time budget -- §5.1.
• Q5 Willing to be interviewed at the end of each pilot week, recorded -- §10 Phase A.3.
• Q6 Accepts daily briefing delivery cadence -- guards §6.3 "too many notifications".

Disqualify -- any one excludes:

• D1 Works on tidalDB, or is a personal/professional contact of the pilot operator. Return driven by social obligation is not a retention signal.
• D2 Evaluating as a developer or buyer rather than as a reader -- §8.3.1 makes a developer platform an explicit beachhead non-goal.
• D3 Unavailable for use on two of the first three pilot days. D2 retention (AC-5) and the §6.3 failure mode "feed still noisy after 2 days" both require day-2 exposure.
• D4 Declines instrumentation or interview-recording consent.
• D5 Duplicate of an already-enrolled person reached via a second channel.

FR-2: Recruitment Funnel Stages and Sizing

Stages, in order: sourced -> contacted -> responded -> screened -> qualified -> consented -> enrolled. Each transition is recorded with a UTC date on the participant record; each exit records the stage and a reason code (D1-D5, no_response, declined, unreachable).

Per-stage conversion targets are TBD (owner: product) -- neither the beachhead doc nor the ROADMAP supplies a prior-art rate, and an invented rate would misplan sourced volume. The funnel is instead sized backwards from the ROADMAP range: enroll 50 (top of the 20-50 range) so the cohort can lose up to 30 participants over the 2-week pilot and still hold the >= 20 floor. sourced volume is re-planned once the measured contacted -> enrolled rate exists.

Stop condition: enrolled == 50, or the recruitment window closes with enrolled >= 20 and FR-6 balance satisfied. Below 20, recruitment continues and the pilot does not start.

FR-3: Outreach Artifact Requirements

One versioned script per channel. Must state: this is a concierge-operated prototype with manual source QA (§10 Phase A.2); 2-week duration; a daily session scoped to the chosen 5/10/20 minute time budget (§5.1); that behavioral instrumentation is active; that two interviews will be recorded; compensation terms (TBD (owner: product)); withdrawal at any time; and the deletion right.

Must NOT promise: accuracy, coverage or completeness, source breadth, freshness guarantees, or replacement of any named incumbent feed. Must not cite "first useful briefing in under 3 minutes" -- that is a P2 self-serve onboarding target (§6.2, ROADMAP P2), not a P0 concierge target. Must not describe surfaces absent from the prototype (cohort view, time-budget mode) as present.

Must NOT prime the outcome: the script may not use the phrases "less noise", "more useful", or "saves time". Those are exactly the claims p0-validation-readout tests in interviews (ROADMAP P0 AC-4); seeding them in outreach invalidates the finding.

FR-4: Consent and Data Handling

A consent record is obtained before enrolled, covering: (a) behavioral instrumentation -- session opens, item impressions, opens, every feedback action, and D2 retention counters; (b) interview audio recording and transcription; (c) retention period and deletion on request (§6.2 "Is my data private?"). Withdrawal removes the participant from subsequent analysis and deletes recordings; already-aggregated de-identified counters are retained, and the consent text says so.

Signed forms, recordings, and contact details live in an out-of-repo operator store. Git-tracked artifacts hold only consent: true, the UTC date, and the consent script version.

FR-5: Cohort Record and Participant Identity

A git-tracked, de-identified roster at docs/planning/p0/cohort-roster.md, one row per candidate: participant_id (opaque, stable, assigned at screened, e.g. P0-017), persona class (primary|secondary), role/domain bucket, incumbent baselines (Q2), declared interest domains, time budget, recruitment channel, per-stage transition dates, consent flag and date, exit stage and reason if not enrolled.

No name, email, employer, handle, or any other personal identity appears in any git-tracked artifact. The participant_id -> person mapping exists only in the operator store. Every downstream instrumentation event, interview transcript, and readout table keys on participant_id.

FR-6: Segment Balance Requirements

Both persona classes are non-empty at enrollment (AC-1 names both). The primary persona is the majority, per §10 Phase A "target one segment"; the secondary-persona floor and the exact split are TBD (owner: product), and must be fixed in the roster header before the funnel opens, never adjusted to match results. No single role/domain bucket may account for the entire cohort. Declared interest domains must span at least two of the §2 topic areas (career, health, finance, AI, hobbies) so the §6.3 "one source dominates" failure mode is observable across differing interests. Balance is checked at enrolled == 20 and again at window close; on violation, recruitment continues in the deficient segment only.

FR-7: Exit Criteria and Handoff

Hand off to p0-concierge-pilot-loop only when all hold: (1) enrolled is within 20-50 and FR-6 is satisfied; (2) every enrolled participant has a participant_id and a consent record; (3) every enrolled participant has submitted onboarding inputs (interests, excludes, time budget) so day-0 briefing generation is unblocked; (4) every enrolled participant has a recorded pre-pilot baseline-feed answer; (5) the instrumentation dry-run has passed. The handoff artifact is the frozen roster plus the version-pinned screening and consent scripts.

Non-Functional Requirements

• NFR-1: No personal identity in any git-tracked artifact; the roster is safe for anyone with repo access to read.
• NFR-2: Screening criteria, balance targets, and the funnel stop condition are frozen before the first contacted event. Later changes are versioned with a written rationale, never applied silently mid-funnel.
• NFR-3: Recruitment channel is recorded per participant so channel bias is measurable in p0-validation-readout.
• NFR-4: The roster is plain markdown -- no tooling, database, or schema required to read or edit it.

Test Strategy

Cohort quality is not automatable; each check below is a human review whose written result is appended to the roster.

• Screening audit -- a reviewer other than the recruiter re-scores every enrolled participant against Q1-Q6 and D1-D5 using roster fields alone. Full census, not a sample: at 20-50 participants sampling has no justification. Any enrollment not defensible from recorded fields is corrected or removed before the pilot starts.
• Duplicate and ineligible detection -- roster checked for duplicate participant_id, same person across channels (operator-store cross-check), and any row that satisfies a disqualifier.
• Instrumentation dry-run -- with at least one enrolled participant (or the operator using a reserved participant_id), complete one full daily briefing session and confirm the pipeline records session start, impressions, and each of more/less/hide/mute/save, and that the pg1-instrumented-metrics /diagnostics JSON endpoint reflects those writes. Recruitment does not close until this passes -- instrumentation is verified before the cohort is committed, because the §6.3 failure mode "feedback actions appear ignored" is indistinguishable from lost telemetry after the fact.
• Pre-pilot baseline control -- before day 0, each participant answers in their own words what they use today and how much time it costs. Recorded verbatim, keyed by participant_id. This is the control against which p0-validation-readout codes the AC-4 "less noise / more useful / saves time" claims; asked pre-pilot so it cannot be contaminated by exposure.
• Pre-registration -- screening criteria, segment split, funnel stop condition, and the D2 retention threshold (TBD (owner: product); ROADMAP AC-5 states only "agreed threshold") are written down and frozen before outreach begins.

Dependencies

• docs/personal-briefing-beachhead.md -- §2 personas, §3 jobs-to-be-done, §6.1-6.3 pressure test and failure modes, §10 Phase A.
• docs/planning/ROADMAP.md P0 acceptance criteria -- cohort size 20-50, feedback-action rate, D2 retention threshold.
• pg1-instrumented-metrics -- /diagnostics JSON endpoint and feedback-action counters exercised by the instrumentation dry-run.
• Downstream: p0-concierge-pilot-loop consumes the enrolled pilot cohort, the frozen roster, and the pre-pilot baseline answers; it cannot start until FR-7 is met.
• Downstream: p0-validation-readout consumes the baseline answers and the persona/channel fields as controls for the GO/NO-GO decision, reached via p0-concierge-pilot-loop.