station

S7 · Iterate

playbook/S7-iterate.md

S7 — Iterate (J14+)

Objectif : décider à J30 si le sprint a accouché d'une vraie startup (GO), d'une idée à pivoter (PIVOT), ou d'un mort-né (KILL). Pas de zombie SaaS.

Durée

Continu à partir de J14, avec un verdict structuré à J30 et un autre à J90.

Inputs

  • URL live + Stripe live (S5)
  • Posthog branché avec events (S5)
  • 100 emails envoyés + réponses reçues (S6)
  • Build-in-public posts publiés (S6)

Output (livrables verrouillés)

  • runs/{sprint}/weekly-retros/ — 1 MD par semaine (S14, S21, S28, etc.)
  • runs/{sprint}/J30-verdict.md — verdict structuré GO/PIVOT/KILL à 30 jours post-launch
  • Section s7_iterate dans startup.json enrichie hebdomadairement

Critères de verrouillage du verdict J30

Verdict GO si TOUS :

  • ≥ 5 utilisateurs payants (à n'importe quel prix > 0€/mo)
  • MRR ≥ 500€ (pas grand, mais réel et croissant)
  • Activation D1 ≥ 30% (% de signups qui font l'action core dans les 24h)
  • Rétention D7 ≥ 20% (% de signups encore actifs après 7 jours)
  • Au moins 1 testimonial inbound non-sollicité

Verdict PIVOT si :

  • Activation D1 < 15% (le produit ne livre pas la promesse) → revoir S4 spec
  • OU > 30% des conversations user signalent un pain différent que celui de S1
  • OU le ICP réel diverge clairement de l'ICP S1 (signaux : qui paie vs qui était ciblé)

Verdict KILL si TOUS :

  • MRR < 100€ à J30
  • < 50% des 100 prospects S6 ont ouvert l'email (taux d'ouverture cassé = sujet/cible cassés)
  • Aucune curiosité organique mesurable (Posthog refer none, pas de mentions externes)
  • Le pain S1 n'est pas confirmé en interviews (5 calls minimum)

Pas de "GO conditionnel". Le verdict est binaire et acté.

Process

Retros hebdomadaires (chaque vendredi soir, 1h)

Format weekly-retros/W{N}.md :

# Retro W{N} — {sprint_name}

## Numbers
- Signups : {X}
- Activation D1 : {Y%}
- MRR : {Z€}
- Churn : {%}
- Posthog events totaux : {N}

## Top 3 wins de la semaine
1. ...
2. ...
3. ...

## Top 3 problèmes de la semaine
1. ...
2. ...
3. ...

## What I learned about the user
{1 insight qualitatif issu de calls / messages / feedback}

## Next week ship list (max 3)
1. ...
2. ...
3. ...

## Burn-rate check
- Coût infra ce mois : {€}
- Coût agents/LLM : {€}
- Runway si MRR stagne : {mois}

J30 — Verdict structuré

Format J30-verdict.md :

# J30 Verdict — {sprint_name}

**Date** : {YYYY-MM-DD}
**Verdict** : GO | PIVOT | KILL

## Metrics réels vs targets

| Metric | Target | Réel | Status |
|--------|--------|------|--------|
| Paying users | ≥5 | ... | ✅/❌ |
| MRR | ≥500€ | ... | |
| Activation D1 | ≥30% | ... | |
| Retention D7 | ≥20% | ... | |
| Inbound testimonial | ≥1 | ... | |

## Le pain S1 a-t-il été confirmé ?
{5 interviews users, 1 ligne par interview, verdict global}

## L'ICP réel matche-t-il l'ICP S1 ?
{si divergent, qui paie réellement ?}

## Décision (binaire)
- GO → Sprint 2 prévu pour ajouter les features OUT_OF_SCOPE_v1 prioritaires
- PIVOT → Retour à S2 (positioning) ou S4 (spec) selon la cause racine
- KILL → Sunset propre (refund last 30j users, message gracieux, archiver le repo)

## Si KILL : qu'est-ce qu'on garde ?
- Code réutilisable identifié → re-canoniser dans `templates/saas-base/`
- Patterns prompts qui ont marché → enrichir le playbook
- Apprentissages méthodologie → enrichir post-mortem global

J90 — Snapshot growth

Si verdict GO à J30, à J90 :

  • MRR croît-il de ≥ 30% MoM ? Si oui → growth real, scale plan.
  • Sinon → re-stress test S1 + revoir spec S4.

Posthog dashboard canonique (à scaffolder UNE FOIS)

Liste d'events à tracker dans la template saas-base :

- $pageview (auto)
- signup (props: source, utm_*)
- activation (props: time_to_activation_sec)
- feature_1_used / feature_2_used / feature_3_used (per S4 spec)
- upgrade_clicked (props: from_page)
- upgrade_completed (props: plan, mrr_cents)
- churn_started (Stripe webhook → Posthog event)
- churn_completed
- contact_support

Dashboard pré-configuré : Funnel signup → activation → upgrade, retention D1/D7/D30, MRR over time, feature usage heatmap.

Prompt canonique (Analyst agent v1)

Tu es S7 Analyst d'Atelier. Tu run chaque vendredi soir (cron J+7, J+14, J+21, J+30, J+60, J+90).

À chaque run, tu :

1. Pull les chiffres depuis :
   - Stripe API (MRR, paying users, churn)
   - Posthog API (activation D1, retention D7, events)
   - Resend (delivery rates des emails outreach)

2. Écris `weekly-retros/W{N}.md` au format canonique (numbers + top 3 wins + top 3 problèmes + insights user + next ship list + burn-rate check).

3. À J30 et J90, écris un verdict structuré `J{N}-verdict.md` :
   - Compare metrics réels vs targets
   - Acte un verdict binaire (GO/PIVOT/KILL — pas de conditionnel)
   - Si KILL, identifie ce qu'on garde (code, prompts, apprentissages)

4. Mets à jour startup.json.s7_iterate.

Tu signales tout métrique anormale (chute > 30%, churn rate > 15%, delivery rate Resend < 90%) en Telegram immédiatement.

State input :
<input>
{startup_json_after_s6}
</input>

Anti-patterns

  • Reporter le verdict J30 "parce qu'on a une feature en cours" → non. J30 est J30. Une feature nouvelle n'invalide pas une métrique de 30 jours.
  • Pivoter sans 5 user interviews → "feel" n'est pas data. 5 calls minimum.
  • Garder un KILL en vie "au cas où" → coût caché énorme (hosting, support, distraction). Sunset propre.
  • Pas de Stripe webhook → Posthog mapping → churn invisible dans le dashboard. Câbler en S5 obligatoire.
  • Ajouter des features pendant S7 alors qu'on n'a pas validé S1 → reverse-engineering du market fit = mort lente.

Post-mortem global du sprint (à écrire à J30)

Format POSTMORTEM.md à la racine du run :

# Post-mortem — {sprint_name}

## Méthodologie
- Quel critère de verrouillage a été le plus dur à atteindre ?
- Où ai-je triché (passé une station sans satisfaire le verrou) ?
- Quel prompt a marché du premier coup ? (à canoniser dans le playbook)
- Quel agent humain a été le bottleneck (à automatiser en v1) ?

## Produit
- MRR à J30 : {€}
- 3 surprises positives
- 3 surprises négatives
- 1 décision de scope que je referais
- 1 décision de scope que je ne referais PAS

## Distribution
- Quelle source d'acquisition a vraiment marché ?
- Quel canal était sur-évalué ?
- Quel build-in-public post a généré le plus d'inbound ?

## Atelier (la méta)
- Quelles parties du playbook doivent évoluer ?
- Quelles parties auraient dû être automatisées dès le début ?
- Quel template manque (S5 saas-base, build-in-public, etc.) ?

Ce post-mortem nourrit la version suivante du playbook. C'est le mécanisme de compounding d'Atelier — chaque sprint rend les sprints suivants meilleurs.

Update startup.json (continuellement après S7)

{
  "current_station": "S7-iterating",  // ou "DONE" si KILL acté
  "s7_iterate": {
    "posthog_project_id": "...",
    "weekly_retros": [
      { "week": 1, "doc": "weekly-retros/W1.md", "mrr_eur": ..., "activation_d1_pct": ..., "retention_d7_pct": ..., "free_to_paid_pct": ... },
      ...
    ],
    "j30_verdict": "GO|PIVOT|KILL",
    "j30_doc": "J30-verdict.md",
    "j90_doc": "J90-verdict.md"
  }
}