[Growth Epic] Increase user adoption through faster activation, focused positioning, and sharing loops

[jimmykane]

Summary

Create and execute a measurable product-led growth program for Quantified Self.

The product already has substantial capability across Garmin, Suunto, COROS, Wahoo, manual FIT/GPX/TCX imports, training analysis, workout comparison, benchmark reports, routes, sleep, the built-in Assistant, and read-only MCP access. The main opportunity is therefore not simply adding more features. It is:

1. communicating one clear reason to use the product;
2. reducing time to first value;
3. letting prospective users experience value before sharing private data;
4. creating privacy-safe outputs that users and reviewers naturally share;
5. retaining activated users with useful recurring insights; and
6. measuring the full acquisition-to-retention funnel.

This issue is the growth epic and implementation checklist. Existing feature issues should remain the source of truth for their detailed implementation.

Product hypothesis

Quantified Self should initially focus its acquisition message on:

Serious endurance athletes who use multiple watches or services, are changing device brands, or want a private, vendor-neutral home for their training history.

Proposed primary promise:

All your training data. One private home.
Connect Garmin, Suunto, COROS or Wahoo—or upload FIT/GPX files. Understand your training, compare devices and ask questions grounded in your own history.

Proposed secondary acquisition wedge:

Compare sports watches with evidence, not screenshots.

The Assistant and MCP access remain important differentiators, but should be introduced after a visitor understands the core data-hub and analysis value.

Goals

• Increase qualified visitor-to-account conversion.
• Increase the percentage of new accounts reaching first value.
• Reduce median time from account creation to first useful result.
• Improve day-7 and day-30 retention for activated users.
• Generate organic acquisition from useful shared reports and comparison tools.
• Learn which provider, workflow, and plan changes have the largest measurable demand.
• Keep privacy, data ownership, evidence quality, and user control central to every growth mechanism.

Non-goals

• Building a social feed, likes, follower graph, or engagement-for-engagement's-sake mechanics.
• Making medical claims or presenting training context as diagnosis or prescription.
• Publishing private activities, routes, coordinates, health data, or account details by default.
• Adding providers based only on intuition without measuring demand.
• Presenting self-hosting as turnkey until a genuinely supported deployment path exists.
• Replacing deterministic metrics with model-generated numbers.
• Redesigning every existing feature before validating the acquisition and activation funnel.

North-star and funnel metrics

Record a baseline before rollout, then define targets after at least two representative weeks of data.

North-star metric

Weekly Activated Athletes (WAA): unique users who receive or upload eligible data and complete at least one high-value action during the same week.

High-value actions include:

• opening Training after eligible data is available;
• completing a workout/file comparison;
• viewing or saving a benchmark report;
• receiving a grounded Assistant answer;
• exporting an activity or report;
• viewing a weekly digest;
• completing a supported cross-service workflow.

Activation definitions by entry path

Entry path	Activation event
Training hub	First activity imported/uploaded and Training opened
File comparison	Two compatible files accepted and comparison result viewed
Device benchmark	Benchmark report generated or viewed
Assistant	First grounded answer completed from account data
Provider sync	Provider connected and first eligible data successfully imported
Migration	Archive import completed and imported history viewed

Funnel events

Instrument only consented, non-sensitive metadata. Never send file names, route coordinates, activity titles, account emails, raw health values, provider tokens, prompts, or report contents.

• Landing page viewed by source/campaign.
• Primary and secondary CTA selected.
• Demo/sample dashboard opened.
• Login/signup method started and completed.
• Onboarding intent selected.
• Onboarding completed or abandoned by step.
• First upload started/succeeded/failed by file type and safe error category.
• First provider connection started/succeeded/failed by provider and safe error category.
• First eligible data available.
• First high-value action completed.
• Time to first value calculated.
• Share created/opened and referred signup attributed without exposing private content.
• Weekly digest opened and deep link used.
• Free-to-paid checkout started/completed.
• Day-1, day-7 and day-30 retention reported by activation path.

Workstream 1: Focused positioning and public-site conversion

• Rewrite the homepage above the fold around the single private training-data-home promise.
• Use one primary CTA: Try a sample dashboard.
• Use one secondary CTA: Connect my device or Start free.
• Add a concise three-step “How it works” section:
  1. connect a provider or upload files;
  2. centralize and preserve source context;
  3. analyze, compare, export, or ask grounded questions.
• Add real product screenshots for Training, activity calendar, comparison, benchmark report, and Assistant.
• Add a 60–90 second product walkthrough.
• Add honest social proof: user quotes, supported-provider facts, open-source activity, and evidence-based examples.
• Explain the free-plan boundary clearly before registration.
• Replace broad claims such as “100% Data Ownership” with verifiable details covering export, deletion, retention, AI processing, sharing, and location controls.
• Ensure public pricing, login context, feature pages, guides, and release notes have meaningful prerendered/server-rendered content and metadata instead of a crawler-only “Please enable JavaScript” response.
• Add appropriate canonical tags, Open Graph cards, sitemap entries, structured FAQ data, and descriptive page titles.
• Add campaign/source attribution to public CTAs using privacy-safe parameters.

Acceptance criteria

• A first-time visitor can explain the product, target user, supported inputs, free starting point, and privacy model after reading the first screen and “How it works”.
• The primary homepage action leads to immediate product value rather than an undifferentiated feature catalogue.
• Critical acquisition pages expose meaningful crawlable content.
• Public pages meet existing responsive, accessibility, metadata, and test requirements.

Workstream 2: Instant, privacy-safe product experience

Sample dashboard

• Create a clearly labelled, read-only demo using synthetic or explicitly licensed/redacted sample data.
• Include enough history for Training, readiness/load context, an activity detail, maps where safe, and an example grounded Assistant result.
• Prevent demo users from mutating, exporting as another user, connecting providers, or reaching private production records.
• Add contextual “Use my data” CTAs at moments of demonstrated value.
• Reset demo state deterministically between sessions.
• Document sample-data provenance and ensure no real user's private health or location data is included.

No-account comparison entry

• Let visitors select compatible FIT/GPX/TCX files and preview a useful comparison before account creation where security and operating costs permit.
• Prefer local/browser parsing for the anonymous preview when technically viable.
• Clearly disclose whether selected files leave the device.
• Require an account only for durable saving, private cloud processing, sharing, or account-level history.
• Provide safe size, type, count, decompression, parser, and abuse limits.
• Delete temporary server-side data promptly when server processing is unavoidable.
• Add a first-party sample comparison for visitors without files.

Acceptance criteria

• A visitor can experience a meaningful result without connecting a health account.
• Anonymous/sample activity is isolated from authenticated production data.
• Privacy disclosures accurately match the data path.
• Successful demo/preview sessions have a clear, contextual continuation into signup.
• Abuse, cost, accessibility, responsive behavior, and failure states are tested.

Workstream 3: Goal-based onboarding and faster activation

The current legal-consent and plan steps remain required, but onboarding should also identify and complete the user's intended job.

• Ask one intent question:
  • Centralize my devices/services
  • Analyze my training
  • Compare watches or sensors
  • Import/migrate my history
  • Ask questions about my data
• Optionally capture primary sport and current provider without making either mandatory.
• Route each intent to a focused first-run checklist.
• Keep the checklist to the minimum actions required for first value.
• Preserve progress across refresh, magic-link continuation, OAuth redirect, and device changes where safe.
• Show a useful processing/progress state during history imports.
• Celebrate a concrete outcome, not merely account creation.
• Delay advanced dashboard customization and unrelated feature education until after activation.
• Provide sample/demo data when the user cannot immediately connect or upload.
• Add a visible route to support when connection/import fails.

Intent-specific first value

Intent	First-run path
Centralize	Choose provider → connect → import first eligible data → open unified history
Analyze	Upload/connect → open Training → highlight one understandable insight
Compare	Select two files/activities → view aligned comparison → optionally save report
Migrate	Select archive/source → preview → import → review counts and duplicates
Ask	Add eligible data or use sample → run a suggested grounded question → inspect evidence

Acceptance criteria

• Every intent has one deterministic success state and one recovery path.
• Median time to first value can be measured.
• Users are not forced to configure an empty dashboard before seeing value.
• Onboarding abandonment is measurable by step without collecting sensitive content.
• Existing auth, consent, account linking, subscription restoration, and redirect behavior remain intact.

Workstream 4: Shareable reports and organic acquisition

Build on #503 rather than duplicating its permission and share-link implementation.

• Define privacy-safe share modes for event comparisons and benchmark reports.
• Require an explicit preview and confirmation before publishing.
• Default precise locations, start/end points, route geometry, user identity, private notes, source files, provider identifiers, and sensitive health fields to hidden.
• Let the owner revoke a link and see its current visibility state.
• Generate a useful social preview card from approved, non-sensitive summary data.
• Add clear attribution and a contextual CTA: Compare your own recordings.
• Support reviewer-ready reports with methodology, reference/test roles, alignment details, metrics, limitations, device/firmware fields, and export.
• Track aggregate share creation, opens, and referred activation without creating a public activity feed.
• Add expiry as an optional owner control.
• Test access control, revocation, guessing resistance, caching, crawler previews, and deleted-account/event behavior.

Acceptance criteria

• Nothing becomes public without a deliberate owner action.
• The owner sees exactly what an unauthenticated visitor will see before publishing.
• Revocation takes effect reliably.
• Shared reports remain useful without leaking hidden fields.
• A referred visitor can enter the matching comparison workflow.

Workstream 5: Retention and lifecycle communication

Build the underlying deterministic digest payload/narrative through #412 and add delivery/activation work here.

• Replace the generic welcome-only sequence with intent-aware lifecycle messages.
• Immediate message: continue the selected first-run workflow.
• Day 1: surface the first available useful result or recovery step.
• Day 3: introduce one relevant feature based on intent and completed actions.
• Day 7: deliver a useful weekly summary when sufficient data exists.
• Add an in-product weekly digest with deterministic metrics, evidence, missing-data states, and deep links.
• Make email digests explicitly opt-in and easy to disable.
• Suppress empty, misleading, duplicated, or stale digests.
• Avoid medical claims and distinguish facts, estimates, and interpretations.
• Add reactivation messaging only when there is a real new result, completed import, connection problem, or meaningful product change.
• Rate-limit all lifecycle communications and respect deletion, marketing consent, and transactional-email boundaries.

Acceptance criteria

• Every message has a specific user benefit and relevant continuation action.
• Users without sufficient data receive setup help rather than invented insights.
• Unsubscribe/consent settings work consistently.
• Delivery, opens, deep-link use, activation and retention can be evaluated with privacy-safe aggregates.

Workstream 6: Migration and provider-demand discovery

• Build or improve a migration wizard for supported bulk exports/archives.
• Preview accepted/rejected records, duplicates, source attribution, estimated processing, and limits before committing an import.
• Provide resumable or safely retryable processing for large imports.
• Preserve original files and provider provenance where permitted.
• Produce a final reconciliation report: discovered, imported, duplicate, skipped, failed.
• Add a “Missing your provider?” demand form.
• Offer a controlled list such as Strava, Polar, Apple Health, Health Connect, Oura, WHOOP, Fitbit, and Other.
• Record provider demand, intended workflow, platform, willingness to beta test, and paid/free intent without collecting credentials.
• Prioritize the next integration using qualified demand, strategic fit, API availability, operating cost, data quality, and maintenance burden.
• Do not promise an integration date before API access and feasibility are confirmed.

Workstream 7: Pricing and packaging experiments

Run one controlled experiment at a time after baseline funnel instrumentation is trustworthy.

Potential hypotheses:

• Basic becomes more compelling if it includes one connected provider with bounded history/sync.
• A simpler Free + Pro structure reduces decision friction.
• A no-card Pro trial converts better when it begins at first provider connection rather than at account creation.
• Free comparison remains the acquisition tool while saving, expanded history, automation, or advanced reports provide upgrade moments.

Experiment requirements:

• Define hypothesis, eligible cohort, primary metric, guardrails, duration, and stopping rule in advance.
• Preserve existing subscribers' contractual entitlements.
• Avoid dark patterns, surprise charges, misleading urgency, or obscured cancellation.
• Measure activation and retention, not checkout conversion alone.
• Include support load, infrastructure cost, provider API limits, refunds, and churn as guardrails.

Workstream 8: Distribution and open-source discoverability

• Produce reusable public benchmark reports with a small group of sports-watch reviewers.
• Recruit approximately 10 relevant smaller reviewers/coaches/testers for an initial program.
• Publish evidence-led content rather than generic release announcements.
• Initial content topics:
  • Garmin vs COROS/Suunto/Wahoo recordings on the same route
  • Comparing heart-rate sensors from FIT files
  • Centralizing training history while switching watch brands
  • Importing or sending activities between supported providers
  • Asking grounded questions about training, sleep and readiness
  • Detecting GPS/sensor artifacts in device tests
• Add a repeatable release process with screenshots, concise user-facing notes, upgrade/compatibility information, and matching website/social updates.
• Keep the website version, GitHub releases, and product release notes aligned.
• Improve repository topics to reflect the current product: Garmin, Suunto, COROS, Wahoo, FIT files, training analysis, fitness data, sports analytics, and MCP.
• Add a README product screenshot or short GIF near the top.
• Add CONTRIBUTING.md, issue forms/templates, PR template, Discussions, and curated good first issue/help wanted tasks.
• Make clear that the hosted app is the easy starting path and self-hosting remains advanced until a supported turnkey workflow exists.

Suggested delivery plan

Phase 0 — Baseline and research (weeks 1–2)

• Build the funnel dashboard and validate event semantics.
• Record at least two representative weeks of baseline data.
• Interview approximately 10 activated and 10 abandoned/inactive users.
• Review support email, issue, and connection-failure themes.
• Select the initial positioning and one activation path to optimize first.

Phase 1 — Conversion foundation (weeks 2–4)

• Ship homepage positioning and public-page rendering/metadata improvements.
• Add real screenshots, walkthrough, privacy proof, and plan clarity.
• Align releases/version messaging.
• Ship the sample dashboard entry point.

Phase 2 — Activation (weeks 4–8)

• Ship goal-based onboarding.
• Ship the no-account/sample comparison path.
• Add intent-aware lifecycle messages.
• Measure time to first value and fix the largest observed failure point.

Phase 3 — Growth loops and retention (weeks 8–12)

• Ship privacy-safe shared benchmark/comparison reports via Re-implement the sharing capability for event and comparisons #503.
• Ship the first weekly digest via AI Insights: Weekly/Monthly Digest Narrative #412.
• Publish initial reviewer reports and workflow guides.
• Run one pricing/package experiment.
• Choose the next provider investigation from measured demand.

Epic-level acceptance criteria

• A documented baseline exists for acquisition, activation, time to first value, retention, sharing, and conversion.
• Homepage and public pages communicate one primary promise and expose meaningful crawlable content.
• Visitors can experience a safe sample or comparison result before connecting private health data.
• New users select an intent and reach a measurable first-value state.
• Shared reports are explicit, previewable, revocable, privacy-safe, and attributable.
• Weekly lifecycle value exists for users with sufficient data.
• Provider priorities are informed by qualified demand.
• At least one controlled pricing/packaging experiment is completed.
• Day-7 activation-path retention and median time to first value improve from baseline without worsening privacy, support, reliability, cost, or churn guardrails.
• Documentation, tests, accessibility, analytics consent, security review, rollout and rollback notes accompany each shipped workstream.

Related issues

• Re-implement the sharing capability for event and comparisons #503 — Re-implement sharing for events and comparisons
• AI Insights: Weekly/Monthly Digest Narrative #412 — Weekly/monthly digest narrative
• AI Insights – Interpretation & Guidance Roadmap #406 — AI Insights interpretation and guidance roadmap
• feat(garmin): support for optional health, workout, and course synchronization #333 — Optional Garmin health, workout, and course synchronization

Open decisions

• Which acquisition wedge should be primary for the first experiment: private multi-provider training hub or device/file comparison?
• Should sample mode cover the full dashboard, Training only, or comparison first?
• Can anonymous comparison be performed entirely in the browser?
• Which fields are permitted in public benchmark reports?
• What event qualifies as activation for commercial reporting?
• Should Basic include one provider, or should packaging simplify to Free + Pro?
• Which lifecycle messages are transactional versus marketing under the applicable consent model?