Onboarding Map Review

Crew Onboarding Map

The first-30-minutes plan for Crew, the AI dev-tool cost product path under research/crew/. A forward-looking target-state flow — Crew has no product yet — designed so every step drives toward one activation win: the Cross-Tool Reveal. It leads with the Platform Engineering Lead (primary) and carries the Startup CTO as a lighter self-serve track.

Status: review Date: 2026-06-26 Product path: research/crew/ Visual tier: visual

Pre-approval stop: the next action is review of this page. The flow below was confirmed in the in-conversation interview; this page is the structured approval record. Use the gates to approve, request edits, or flag concerns. Canonical markdown and downstream routing are withheld until a compiled response approves the page.

Proposed canonical outputs (written on approval): research/crew/onboarding-map.md and research/crew/onboarding-map-interview.md. Builds on the confirmed research/crew/journey-map.md and research/crew/lifecycle-metrics.md.

Summary

deliverable

Crew's onboarding has exactly one job: get a new account to the Cross-Tool Reveal — a per-developer or per-team cost fact spanning ≥2 tools that no single vendor dashboard can produce — in the first session, and under 5 minutes for the self-serve CTO. Everything else (team mapping, invites, sharing, chargeback) is deferred until after that aha.

The design philosophy is reveal-first, degrade gracefully, defer heavy setup:

Both personas self-serve, with an optional sales-assist path for larger orgs (security blocker, 2–6 week cycle). The single biggest failure mode — and the one with the strongest designed recovery — is no reveal in the first session.

Scope & Decisions

approval required

These decisions were confirmed in the interview and govern the whole onboarding map.

Scope

Crew only (research/crew/); both personas, Platform Lead primary / CTO secondary.

Mode

Forward-looking target-state — no product exists yet; this designs the ideal first 30 minutes.

First success

The Cross-Tool Reveal itself (the confirmed activation event). Deeper value is post-activation.

Coverage gap

Connect degrades gracefully: accept aggregate-only providers, show a coverage % meter, don't block.

Team mapping

Deferred — reveal first on raw connected data; mapping is an optional second step.

Invites

Solo through the reveal; invites & Finance sharing are share-triggered right after the aha.

Top drop-off

No reveal in first session — the activation-killer, gets the strongest recovery path.

Entry model

Self-serve for both personas, with an optional sales-assist path for larger orgs.

Approve the scope and onboarding philosophy as written?

Personas & Entry Points

deliverable
DimensionPlatform Eng Lead (primary)Startup CTO (secondary)
Trigger to arriveThe Attribution Gap — Finance asks for a cross-tool breakdown; budget shock; tool sprawlPersonal bill shock ($500–$2,000/mo); the $6,000 overnight runaway; investor question
Discovery channelPlatform Eng Slack, Rands, PlatformCon; Vantage / CloudZero / DX content; FinOps communityTwitter/X, YC Slack, Hacker News, Google comparison articles
Entry modelSelf-serve, with optional "talk to us" for larger orgs (security blocker)Pure self-serve, no sales touch
What they need firstCross-tool, team-level rollup answering "which team spent what?"Per-developer reveal in <5 min: "Developer A is $800/mo"
Decision speed2–6 weeks (champion + economic buyer + Finance + Security)1–3 days, CTO alone
Does NOT need at onboardingChargeback enforcement on day one (showback first)SSO, RBAC, compliance, chargeback

Signup & Setup Flow

deliverable

The shared path to activation. Steps 1–4 are the critical line to the reveal; step 5 onward is deferred, post-activation work.

  1. Sign up — email or SSO. Capture persona (platform_lead | cto) and company size with one optional question; never block on it. Fires account_created.
  2. Connect ≥1 billing provider — Claude Code / Cursor / Copilot / Devin·Windsurf. Per-provider OAuth or API key. Show expected granularity (per-seat | per-key | aggregate-only) during connect so expectations are set. Fires provider_connected.
  3. Coverage-aware ingest — pull and normalize billing; display a live attribution-coverage % meter as data lands. Aggregate-only providers count toward spend but are flagged as "team-level only." No team mapping yet. Fires attribution_coverage_sampled.
  4. Cross-Tool Reveal (ACTIVATION) — the first dashboard showing a per-developer/per-team cost fact spanning ≥2 tools. CTO target <5 min; Platform Lead within first session. Fires cross_tool_reveal_viewed with time_since_signup_sec, providers_count, attribution_coverage_pct.
  5. Share / invite (post-aha, optional) — share-triggered: the first export or "send to Finance" prompts teammate/Finance invites. Fires report_exported, teammate_invited.
  6. Team / cost-center mapping (deferred, optional) — auto-infer groupings from billing metadata (email domains, seat assignments), present a draft the lead confirms/edits. Unlocks team-segmented dashboards and showback.
  7. Alerts & ritual setup (deferred) — showback-first anomaly alerts and the monthly budget-review ritual; seeds retention. Chargeback is a later expansion step.

Time-to-Value Budget

visual

An illustrative target allocation of the CTO's <5-minute (300-second) self-serve path to the reveal — a design budget, not measured data. It shows where the flow can and cannot afford friction: the connect step is the largest, riskiest slice.

Target time budget to first reveal (CTO <5 min path)

Activation Path

approval required

Activation is a single, sharp event: cross_tool_reveal_viewed. The path and its guardrails:

The activation chain

Single-provider guardrail

If a user connects only one provider, there is no cross-tool reveal. The flow surfaces a "add a second provider to unlock the cross-tool view" nudge rather than showing a single-vendor dashboard that any vendor already provides.

Approve the activation definition and its guardrails?

First Success

deliverable

First success = the Cross-Tool Reveal. Onboarding is "done" the moment the user sees their first cross-tool per-developer/per-team fact. This deliberately stops short of "answered the CFO" or "shared with Finance" — those are conversion/retention milestones, not the onboarding bar.

Why stop here: the reveal is the first irreversible value moment (journey-map Critical Moments #1/#2) and the confirmed activation metric. Setting first success deeper would conflate onboarding with conversion and hide onboarding drop-off behind slower buying cycles — especially the Platform Lead's 2–6 week cycle.

Post-success momentum (not required for activation, but the immediate next nudges): add a second provider if not already; export/share the reveal; for the Platform Lead, map teams to unlock segmented dashboards.

Drop-Offs & Recovery

approval required

Three onboarding failure modes, ordered by priority. "No reveal in first session" gets the strongest designed recovery.

Drop-offPriorityDetection signalRecovery path
No reveal in first session1 (highest)provider_connected with no cross_tool_reveal_viewed in session; thin or aggregate-only dataWalk to a guaranteed team/aggregate-level reveal; prompt a second provider; offer CSV upload; follow-up email with "your reveal is ready" once enough data lands
Connect failure2OAuth/API auth fails; provider unsupported; provider_connected with connect_status=failedInline retry; CSV/export upload fallback; provider-status guidance; "we'll email you when this provider is supported"
Single-provider stall3Exactly one provider_connected, no second within sessionPersistent "add a second provider to unlock the cross-tool view" nudge; list the user's likely other tools
Approve the drop-off priority and recovery paths?

Instrumentation Needs

deliverable

Onboarding reuses the confirmed lifecycle-metrics event inventory; no new canonical events are introduced. The onboarding-specific funnel and signals:

SignalBuilt from (confirmed events)Why it matters
Onboarding funnel (signup → connect → reveal)account_createdprovider_connectedcross_tool_reveal_viewedThe core activation funnel; locates the drop-off step
Time-to-first-revealcross_tool_reveal_viewed.time_since_signup_secThe headline onboarding metric; CTO <5 min target
Providers-connected distributionprovider_connected count per accountSingle-provider stall detection; cross-tool wedge health
Attribution coverage at first revealcross_tool_reveal_viewed.attribution_coverage_pct, attribution_coverage_sampledWas the reveal real? Gates activation quality
Connect success rateprovider_connected.connect_status, granularityConnect-failure drop-off; per-provider API reality
Post-activation momentumreport_exported, teammate_invitedShare-triggered expansion into multiplayer

Product Gaps

open
GapWhy It MattersResolution Path
No product or analytics layer existsThe entire flow is a target-state designBuild the connect + ingest + dashboard MVP; this map is the flow seed
Per-provider billing-API granularity unvalidatedDetermines whether step 2→4 can produce a per-developer reveal at allTechnical spike per provider (Claude Code, Cursor, Copilot, Devin/Windsurf)
Aggregate-only degradation UX undefinedThe graceful-degrade promise needs a real coverage-meter + team-level reveal designUX variation pass on the coverage-aware ingest + reveal screens
Team auto-infer heuristic unprovenDeferred mapping relies on inferring teams from billing metadataValidate email-domain / seat-assignment grouping against real billing exports
Second-provider nudge timingToo early annoys; too late loses the cross-tool ahaDesign + later A/B once instrumented

Next Steps

routing

Routing is proposed; it activates only after this page is approved.

  1. /conversion-map research/crew — the activation→paid / team-rollout path that begins right where onboarding's first success ends.
  2. /metrics research/crew — commit firm onboarding-funnel targets (time-to-reveal, activation rate, connect success) left as BASELINE NEEDED in lifecycle-metrics.
  3. Per-provider billing-API granularity spike before the connect step can be specced.
Approve the artifact destinations and file changes?

Files on approval: research/crew/onboarding-map.md, research/crew/onboarding-map-interview.md, this alignment page (→ confirmed), the central alignment/index.html, and a last_touched bump in research/.progress.yaml.

Which downstream route should follow approval?

Compile Responses

Answer one or more gates, or select section feedback, then compile YAML. A complete response with every required gate answered and no unresolved negative feedback can be pasted back to the agent to approve this page and write the canonical artifacts.