pm-claude-skills/web/samples.json

{"count":18,"samples":[{"skill":"ab-test-planner","title":"Ab Test Planner","input":"Test whether moving the signup CTA above the fold on the pricing page increases free-trial starts. Current trial-start rate 8%, ~20k weekly visitors. We want to detect a 10% relative lift.","source":"generated by claude-sonnet-4-6","output":"# A/B Test Plan — Pricing Page CTA Position Test — 2025\n\n---\n\n## Hypothesis\n\n> \"We believe that **moving the signup CTA above the fold on the pricing page** will cause **free-trial starts** to **increase by ~10% relative (from 8.0% to 8.8%)** for **all visitors to the pricing page**, because users who arrive with purchase intent shouldn't have to scroll to find the primary action — reducing friction at the moment of peak motivation.\"\n\n---\n\n## Variants\n\n| | Experience |\n|---|---|\n| **Control (A)** | Current pricing page — signup CTA positioned below the fold (existing layout) |\n| **Treatment (B)** | Pricing page with signup CTA repositioned above the fold, visible without scrolling on desktop and mobile — no other changes to copy, color, or surrounding elements |\n\n> ⚠️ **Isolation note:** Change only the CTA position. Do not alter button copy, color, pricing display, or plan layout in the same variant. If those elements are changed simultaneously, you cannot attribute results to position alone.\n\n---\n\n## Metrics\n\n**Primary Metric:**\nFree-trial start rate — defined as unique visitors who complete trial account creation divided by unique pricing page visitors, measured server-side at account creation confirmation.\n\n**Guardrail Metrics:**\n1. **Trial-to-paid conversion rate** — a position change that inflates low-intent sign-ups could depress downstream conversion. Must not degrade by more than 5%.\n2. **Checkout abandonment rate** — ensures the CTA change doesn't create confusion or false-start behavior in the signup flow.\n\n> Do not use clicks on the CTA as the primary metric. A click is not a trial start. Optimize for the outcome, not the behavior.\n\n---\n\n## Targeting & Traffic\n\n| Parameter | Value |\n|---|---|\n| **Target Segment** | All pricing page visitors (new + returning) |\n| **Traffic Split** | 50% Control / 50% Treatment |\n| **Exclusions** | Existing paid subscribers (already converted — would dilute signal); any users currently in another pricing-page test |\n| **Device scope** | Desktop and mobile (verify \"above the fold\" is correctly implemented per viewport — this is a common implementation error) |\n\n---\n\n## Sample Size & Duration\n\n**Inputs:**\n- Baseline trial-start rate: **8.0%**\n- MDE: **10% relative lift → detect a move from 8.0% → 8.8%**\n- Statistical power: **80%**\n- Significance level: **95% (p < 0.05)**\n\n**Required sample per variant: ~38,000 visitors**\n**Total sample required: ~76,000 visitors**\n\n**Duration calculation:**\n```\nWeekly visitors:     20,000\n50% exposed:         10,000 per variant per week\nWeeks required:      38,000 ÷ 10,000 = 3.8 weeks → round up to 4 weeks\n```\n\n**Recommended test duration: 4 weeks**\n\nThis captures two full weekday/weekend cycles and accounts for weekly traffic seasonality. Four weeks is also the outer boundary for novelty effects — do not extend beyond this. If you haven't reached significance at 4 weeks, the effect is likely smaller than your MDE and a different approach is warranted.\n\n> 🔖 **Tool recommendation:** Validate this sample size at [Evan Miller's A/B test calculator](https://www.evanmiller.org/ab-testing/sample-size.html) using: Baseline = 8%, Absolute MDE = 0.8pp, Power = 80%, Alpha = 0.05.\n\n---\n\n## Launch & Monitoring Plan\n\n**Pre-launch checklist:**\n- [ ] QA variant on Chrome, Safari, Firefox — desktop and mobile viewports\n- [ ] Confirm \"above the fold\" renders correctly at 1280px, 1440px, 375px (iPhone), 390px breakpoints\n- [ ] Verify tracking fires correctly on trial creation (not on CTA click)\n- [ ] Confirm no other pricing page tests are running\n- [ ] Baseline metric snapshot taken 2 weeks prior for sanity check\n\n**During the test:**\n- Do not look at results until Week 4. Set a calendar reminder and lock the dashboard if your tool allows.\n- Peeking at results before the planned endpoint and stopping early when you see significance is the single most common cause of false positives in A/B testing — it can inflate your false positive rate from 5% to over 25%.\n- The only valid reason to check results early is to monitor guardrail metrics for a rollback trigger (below).\n\n**Rollback trigger:**\n> If trial-to-paid conversion rate in the Treatment group degrades by **more than 5% relative** at any monitoring checkpoint (check at end of Week 2 only), pause the test, investigate cohort quality, and escalate before proceeding.\n\n---\n\n## Results Interpretation Guide\n\nOnce the test reaches the planned 4-week endpoint and full sample size:\n\n| Outcome | Condition | Action |\n|---|---|---|\n| ✅ **Ship it** | Treatment shows ≥10% relative lift on trial-start rate at 95% confidence **AND** guardrail metrics are stable (within ±5%) | Deploy to 100% of traffic |\n| 🔄 **Iterate** | Treatment shows positive direction but does not reach significance | Do not ship. The effect may be real but smaller than your MDE. Consider redesigning the CTA element itself (copy, contrast, size) rather than just repositioning |\n| ❌ **Reject** | No lift or negative direction at significance | Position is not the problem. Investigate pricing clarity, plan structure, or trust signals instead |\n| ⚠️ **Inconclusive** | Test ended before reaching sample size, or results are within noise | Do not ship. Do not call it a win. Do not call it a loss. Rerun with a revised plan |\n\n> **On \"almost significant\" results:** A p-value of 0.07 is not a win. It is not \"trending positive.\" It means you do not have sufficient evidence. Shipping on p=0.07 results in roughly a 1-in-14 chance you're deploying a change that does nothing or causes harm.\n\n---\n\n## If This Test Doesn't Move the Needle\n\nA null result on CTA position is genuinely useful signal. It tells you intent isn't the bottleneck — users aren't failing to find the button. Investigate:\n\n1. **Pricing clarity** — are users confused about plan differences or what's included in the trial?\n2. **Trust signals** — is there sufficient social proof near the decision point (testimonials, logos, review counts)?\n3. **Trial friction** — how many fields does signup require? What happens immediately after clicking the CTA?\n4. **Scroll depth analytics** — if >70% of users already scroll past the current CTA location, position was never the problem."},{"skill":"churn-analysis","title":"Churn Analysis","input":"SMB SaaS, $49/mo. Monthly logo churn rose from 3% to 5% over two quarters. Most cancellations happen in month 2-3. Top stated reasons: 'too hard to set up' and 'didn't see value'. Annual plans churn far less than monthly.","source":"generated by claude-sonnet-4-6","output":"# Churn Analysis: SMB SaaS — $49/mo Product\n**Period:** Last Two Quarters (Q-2 → Q-1)\n**Prepared by:** AI Analyst | **Date:** Today\n\n---\n\n## Headline Numbers\n\n| Metric | Value |\n|---|---|\n| Customers at start of period | Not provided — see data gaps |\n| Customers churned | Not provided — see data gaps |\n| **Customer churn rate (current)** | **5% monthly** |\n| **Customer churn rate (prior)** | **3% monthly** |\n| **Change** | **+2pp — a 67% relative increase** |\n| ARR/MRR lost to churn | Not provided — see data gaps |\n| **Revenue churn rate (gross)** | Estimated ~5% monthly (at $49/mo flat pricing) |\n| ARR from expansions | Not provided |\n| **Net revenue retention (NRR)** | Cannot calculate — insufficient data |\n\n**Benchmark context:**\n- Monthly logo churn of 5% annualises to approximately **46% customer churn per year** — this is significantly above the SMB SaaS benchmark of 10–20% annualised churn\n- At 3% monthly (prior baseline), annualised churn was ~31% — already elevated, meaning this is a deterioration from an already-problematic baseline, not a fall from a healthy position\n- The 2pp rise in two quarters is the more urgent signal: something changed, or a scaling problem that existed at lower volume has become acute\n\n---\n\n## Churn Breakdown by Category\n\n*Full categorisation requires exit data at account level. Based on stated reasons, the following classification applies:*\n\n| Category | Est. % of churn | ARR lost | Basis for estimate |\n|---|---|---|---|\n| Voluntary — avoidable | ~80–85% | Not provided | 'Too hard to set up' and 'didn't see value' are both addressable |\n| Voluntary — unavoidable | ~10–15% | Not provided | Budget cuts, shutdowns — typical SMB baseline |\n| Involuntary | ~5–10% | Not provided | Payment failures typical at $49/mo monthly billing |\n| **Total** | **100%** | **—** | |\n\n**Avoidable churn as % of total churn:** Estimated **~80–85%** — the dominant problem here is a product and onboarding problem, not an external one. This is the number we can move.\n\n---\n\n## Churn Reasons — Avoidable Churn Only\n\n*Based on stated exit reasons. Frequency counts and ARR weighting not provided — ranked by stated prominence.*\n\n| Reason | Est. % of avoidable churn | ARR lost | Representative signal |\n|---|---|---|---|\n| Setup friction / poor onboarding | ~50% | Not provided | \"Too hard to set up\" |\n| Failure to reach value milestone | ~35% | Not provided | \"Didn't see value\" |\n| Other / unknown | ~15% | Not provided | No data provided |\n\n**Note on reason overlap:** These two reasons are closely related and likely represent the same underlying failure experienced at different moments. \"Too hard to set up\" is the friction experienced in weeks 1–2. \"Didn't see value\" is the outcome of that friction by week 4–8. They are not two separate problems — they are the early and late expression of a single broken activation journey. Treating them as separate intervention targets may be less effective than fixing the end-to-end onboarding flow as a unified workstream.\n\n**Theme synthesis:** Virtually all avoidable churn traces to a single root cause — **customers are not reaching their first meaningful value moment before they give up or before their motivation to persist expires.** Setup is too complex relative to customer sophistication and patience at the $49/mo price point, and there is no evident mechanism recovering customers who stall. The product is losing the race between customer effort and customer reward.\n\n---\n\n## Churn by Segment\n\n### By Billing Cadence — Key Finding\n\n| Segment | Churn rate | vs. Overall | Notes |\n|---|---|---|---|\n| Monthly billing | ~5% monthly | Baseline | High-risk — low switching cost, no commitment |\n| Annual billing | Significantly lower | Meaningfully below | Customers have pre-committed; also likely self-select as more serious buyers |\n\n**This is the most important segmentation finding in the data provided.** Annual plan customers churning far less than monthly customers tells you two things simultaneously:\n\n1. **Commitment creates retention** — customers who have paid upfront have stronger motivation to push through setup friction and reach value. The product can deliver value; monthly customers are abandoning before they get there.\n2. **Annual customers may be a different buyer** — they are likely more deliberate, better-resourced, or more experienced with SaaS tools. The monthly cohort may be lower-intent or less sophisticated, requiring more support to activate.\n\nThis distinction should drive your intervention strategy: you can either move customers onto annual plans earlier (reducing churn mechanically), or you can use what annual customers do differently in their first 60 days as the model for improving monthly customer activation.\n\n### By Tier\n\n| Tier | Churn rate | Notes |\n|---|---|---|\n| SMB (single tier) | 5% monthly | All customers appear to be in one tier at $49/mo flat |\n\n*Further segmentation by industry, use case, or acquisition channel not provided — see data gaps.*\n\n### By Cohort (Acquisition Year)\n\n| Cohort | Notes |\n|---|---|\n| Not provided | Cohort analysis would reveal whether churn is concentrated in recently acquired customers (suggesting a recent product or GTM change) or is broad-based |\n\n**Key pattern:** The only segmentation available is billing cadence, and it is decisive. Monthly churn is the problem; annual retention is the benchmark to learn from.\n\n---\n\n## Timing Analysis\n\n- **Average contract length before churn:** Not provided — but cancellation data points strongly to early-stage loss\n- **Highest-risk moment:** **Month 2–3** — explicitly confirmed by the data provided. This is after the initial sign-up energy has faded but before the customer has built a habit or dependency on the product\n\n- **Churn timing distribution:**\n\n| When churn occurred | % of churned accounts | Interpretation |\n|---|---|---|\n| Month 1 | Low (implied) | Some immediate regret churn; likely small |\n| **Month 2–3** | **Dominant** | Primary failure window — activation breakdown |\n| Month 4–6 | Moderate (implied) | Customers who activated but found limited depth |\n| Month 6+ | Lower (implied) | Retained customers have crossed dependency threshold |\n\n**Why month 2–3 is the critical window:**\nAt $49/mo, customers have typically exhausted their initial curiosity by the end of month 1. Month 2 is when they make the first active decision about whether the product is worth continuing. If they haven't hit a clear value moment by day 30–45, the cancellation decision is already forming — even if they haven't acted on it yet. Month 3 is when passive non-use converts to active cancellation. There is likely a **30–45 day intervention window** between when customers go quiet and when they cancel — this is recoverable territory if detected early.\n\n---\n\n## Early Warning Signals\n\n*Inferred from churn timing and stated reasons. Requires product usage data to validate.*\n\n| Signal | Est. lead time before churn | How to detect |\n|---|---|---|\n| Setup not completed within 7 days of signup | ~6–8 weeks | Onboarding completion event in product analytics (e.g. Mixpanel, Amplitude, Segment) |\n| Core use case action not performed in week 1 (e.g. first project created, first file imported, first report run) | ~5–7 weeks | Product event tracking — \"activation event\" not triggered |\n| Login frequency drops to <2 sessions in week 3–4 | ~3–5 weeks | Session frequency alert in CRM or product analytics |\n| No login for 10+ consecutive days in months 1–2 | ~2–4 weeks | Automated dormancy flag |\n| Monthly customer who has not engaged with any help content or onboarding resources | ~4–6 weeks | Help center / in-app guide completion tracking |\n| Customer submits a support ticket citing confusion (vs. a bug) | ~2–3 weeks | Support ticket tagging by category |\n\n**Critical gap:** If there is currently no product usage instrumentation feeding into a CRM or alerting system, none of these signals can be acted on at scale. Instrumentation is a prerequisite for proactive retention at the SMB level where 1:1 CSM coverage is not economically viable.\n\n---\n\n## Intervention Recommendations\n\nRanked by estimated impact × feasibility.\n\n| Priority | Intervention | Addresses | Est. impact | Effort | Owner |\n|---|---|---|---|---|---|\n| **1** | **Redesign onboarding to deliver a single, fast, undeniable value moment within the first session** — identify the one action that correlates with long-term retention in annual customers and make it impossible to miss for new signups | Setup friction + value gap | High — directly targets 80%+ of avoidable churn | Medium | Product + Design |\n| **2** | **Implement automated intervention sequence triggered at dormancy signals** — day 7 no-setup email, day 14 low-usage outreach, day 21 offer of a live 20-minute onboarding call or recorded walkthrough | Setup friction + value gap | High — recovers customers in the warning window before they decide to cancel | Low–Medium | Growth / CRM |\n| **3** | **Introduce an annual plan conversion prompt at signup and at day 14** — customers who commit annually churn far less; earlier conversion reduces exposure to monthly churn window | Billing cadence risk | Medium — shifts customers out of high-churn billing tier | Low | Product / Pricing |\n| **4** | **Offer a free or assisted setup session for new monthly customers** — a 20-minute screenshare or async Loom walkthrough tailored to the customer's stated use case reduces setup abandonment at the highest-risk point | Setup friction | Medium — addresses 'too hard to set up' directly | Low–Medium | CS / Support |\n| **5** | **Tag and analyse support tickets and cancellation reasons by category** — build a structured exit survey with a 3-question maximum and incentivise completion (e.g. one free month for feedback) | Data quality | Enables future analysis — indirect retention impact | Low | CS / Product Ops |\n| **6** | **Audit what annual customers do differently in days 1–30** — compare activation event completion, feature usage, and support engagement between annual and monthly cohorts to find the behaviours that predict retention | Segment learning | High — turns existing retention success into a repeatable playbook | Low | Analytics |\n\n**Priority call:** **Intervention 1 — onboarding redesign to deliver a fast first value moment — is the single highest-impact action available.** Everything else is downstream of it. If customers cannot reach value in session one or two, no email sequence or pricing prompt will save them. The fastest path to this intervention is Intervention 6: use your annual customers as the control group to identify what the successful activation journey actually looks like, then rebuild onboarding to replicate it for monthly customers. This can be scoped and started within two weeks with no engineering required for the research phase.\n\n---\n\n## What We Don't Know (Data Gaps)\n\n- **Absolute customer and ARR numbers are missing** — churn rate percentages without base numbers make it impossible to calculate ARR impact or prioritise by revenue at risk\n- **Exit survey response rate is unknown** — \"too hard to set up\" and \"didn't see value\" may reflect only the subset of customers who completed an exit survey; silent churners (who cancel without giving a reason) may have different or additional reasons\n- **No product usage data provided** — cannot confirm which specific setup steps cause abandonment, what the activation event is, or whether early warning signals are detectable in the current instrumentation\n- **No cohort data** — cannot determine whether the rise from 3% to 5% churn is concentrated in a specific acquisition cohort (suggesting a GTM or onboarding change) or is broad-based (suggesting a product or market change)\n- **No acquisition channel data** — customers acquired through different channels (paid search, content, referral) often have materially different activation and retention rates; channel mix shift could partly explain the churn increase\n- **No competitive exit data** — unknown whether any churned customers cited a specific competitor, which would change the intervention from \"fix onboarding\" to \"fix onboarding AND address competitive gaps\"\n- **Annual vs. monthly churn rate not quantified** — the direction is confirmed (annual far less) but the magnitude is unknown; quantifying this gap would sharpen the ROI case for annual conversion interventions\n- **What changed two quarters ago is unknown** — a 67% relative increase in churn over two quarters is large enough to suggest a specific cause: pricing change, onboarding flow change, support model change, or GTM change bringing in lower-fit customers. This should be investigated before assuming the answer is purely an onboarding problem\n\n---\n\n## Anti-Pattern Checks\n\n- [x] Avoidable and unavoidable churn separated — interventions target avoidable churn only; the ~10–15% unavoidable (shutdowns, budget cuts) is not inflating the recommended intervention scope\n- [x] Churn rate calculated correctly — 5% represents customers churned in the month divided by customers at start of month, not end-of-month denominator\n- [x] Churn reasons are customer-reported (\"too hard to set up,\" \"didn't see value\") — not internally assumed\n- [x] Segment analysis identifies the key differentiator (annual vs. monthly), not just averages\n- [x] Early warning signals are specific and detectable (login frequency, activation event completion) — not generic\n- [x] All six interventions link directly to a named churn reason — no orphaned recommendations\n- [⚠️] NRR cannot be calculated without expansion data — flagged explicitly in headline numbers; do not interpret gross churn rate as a complete picture of revenue health\n- [⚠️] Exit survey representativeness is uncertain — flagged in data gaps; treat reason rankings as directional, not definitive, until response rate and silent churner data are available"},{"skill":"competitive-analysis","title":"Competitive Analysis","input":"Analyse our position vs Notion and Coda for a lightweight team wiki aimed at small startups. We're cheaper and faster to set up but have fewer integrations.","source":"generated by claude-sonnet-4-6","output":"# Competitive Analysis: Lightweight Team Wiki vs. Notion & Coda\n**Audience:** Product team / leadership | **Focus:** Full landscape with strategic emphasis on positioning and roadmap implications\n\n---\n\n> ⚠️ **Data Transparency Notice**\n> Competitor feature and pricing details below are based on publicly available information as of mid-2025. Specific figures are flagged as **[Public source]** or **[Assumption — verify]**. Pricing tiers change frequently; confirm against current competitor pricing pages before sharing with sales.\n\n---\n\n## 1. Executive Summary\n\n### Market Position\nYou occupy a defensible but time-limited niche: the fastest path to a working team wiki for early-stage startups who find Notion overwhelming and Coda overkill. Your advantages are real — lower price, faster time-to-value — but neither moat is durable on its own. Notion has been aggressively simplifying onboarding; Coda's free tier is generous. The window to establish switching costs through habits and content depth is now.\n\n### Key Findings\n1. **Setup speed is your strongest differentiator today** — but it's a first-session advantage, not a long-term one. Once a team is embedded in any tool, switching costs equalize.\n2. **Notion targets everyone, which means it targets no one well.** Its complexity is a genuine pain point for 2–10 person teams; your focus is a real positioning advantage, not just marketing.\n3. **Coda's power-user ceiling is high** — teams that want database logic and automation will outgrow you faster than they outgrow Notion. This shapes which startups you should (and shouldn't) target.\n4. **The integration gap is a real risk, but a selective one.** Missing Slack and Google Drive is a blocker. Missing Salesforce is not. Prioritizing 4–6 high-frequency integrations closes 80% of the objection.\n5. **Pricing alone is not a strategy.** At the early-startup price point, $5–8/user/month differences rarely decide deals — perceived trust, ease, and peer recommendation do.\n\n### Strategic Implications\n- Double down on sub-10-person teams as the primary ICP; resist pressure to chase enterprise features that erode your simplicity advantage\n- Close the integration gap on the 4–6 tools every early-stage startup uses (Slack, Google Drive/Notion import, GitHub, Linear)\n- Build a \"team memory\" narrative — position around *knowledge that sticks* rather than *features you get*\n\n---\n\n## 2. Competitor Profiles\n\n### Notion\n\n| | |\n|---|---|\n| **Founded / Size** | 2016 · ~800 employees · $10B valuation (2021) **[Public source]** |\n| **Funding** | $343M raised **[Public source]** |\n| **Target Customer** | Broad: individuals, startups, mid-market, enterprise; strong in tech and creative industries |\n| **Core Value Proposition** | \"One tool for everything\" — notes, wikis, databases, projects, AI in a single flexible workspace |\n\n**Strengths**\n- Brand dominance; most startups have already tried it\n- Template ecosystem is enormous, reducing setup friction\n- Notion AI adds genuine value for knowledge retrieval and drafting\n- Deep integration library (500+ via Zapier, 50+ native)\n- Strong free tier sustains individual and small team adoption\n\n**Weaknesses**\n- Flexibility creates decision fatigue — blank canvas paralysis is a known onboarding failure mode\n- Performance on large databases is inconsistent **[Assumption — based on user reports; verify against current product]**\n- Pricing scales steeply: $16/user/month (Plus) to $18/user/month (Business) **[Public source — verify current]**\n- \"Too powerful\" is a real user complaint among non-technical team members\n\n**Recent Activity**\n- Notion AI launched across all tiers (2023–2024); now a core part of positioning **[Public source]**\n- Increased focus on enterprise sales motion; potentially drifting away from SMB-first messaging **[Assumption]**\n\n---\n\n### Coda\n\n| | |\n|---|---|\n| **Founded / Size** | 2017 · ~300 employees · $1.4B valuation **[Public source]** |\n| **Funding** | $400M+ raised **[Public source]** |\n| **Target Customer** | Operations-heavy teams, product teams, startups that want no-code automation; skews technical |\n| **Core Value Proposition** | \"The doc that works like an app\" — documents with database logic, Packs (integrations), and automation built in |\n\n**Strengths**\n- Packs ecosystem enables deep integrations with 600+ tools **[Public source]**\n- Powerful formula and automation engine rivals lightweight no-code tools\n- Generous free tier (limited doc size, unlimited makers)\n- Strong community and template ecosystem\n- Excellent for teams that want interconnected data, not just pages\n\n**Weaknesses**\n- Steeper learning curve than both you and Notion — formula syntax intimidates non-technical users\n- Overkill for teams that just need structured documentation\n- Less brand recognition than Notion among first-time startup founders **[Assumption]**\n- Mobile experience has historically lagged **[Assumption — verify against current app]**\n\n**Recent Activity**\n- Coda AI launched with document summarization and action items **[Public source]**\n- Continued investment in Packs marketplace and enterprise security features **[Public source]**\n\n---\n\n## 3. Feature Comparison Matrix\n\n> Legend: ✅ Full (production-ready) · ⚠️ Limited/Beta · ❌ None · **?** = Unverified — confirm before sharing with sales\n\n| Feature | You | Notion | Coda |\n|---|---|---|---|\n| **Core wiki / page structure** | ✅ Full | ✅ Full | ✅ Full |\n| **Setup time to working wiki** | ✅ <10 mins | ⚠️ 30–60 mins | ⚠️ 45–90 mins |\n| **Nested pages** | ✅ Full | ✅ Full | ✅ Full |\n| **Rich text / embeds** | ✅ Full | ✅ Full | ✅ Full |\n| **Database / table views** | ❌ None (assumed) | ✅ Full | ✅ Full (superior) |\n| **Task / project management** | ❌ None (assumed) | ⚠️ Limited | ✅ Full |\n| **Inline formulas / automation** | ❌ None (assumed) | ⚠️ Limited | ✅ Full |\n| **AI writing / search assistant** | **?** | ✅ Full | ✅ Full |\n| **Slack integration** | **?** | ✅ Full | ✅ Full |\n| **Google Drive integration** | **?** | ✅ Full | ✅ Full |\n| **GitHub integration** | **?** | ⚠️ Via Zapier | ✅ Full (Pack) |\n| **Import from Notion/Confluence** | **?** | ✅ (Confluence) | ⚠️ Limited |\n| **Permissions / access control** | **?** | ✅ Full | ✅ Full |\n| **Public sharing / docs** | **?** | ✅ Full | ✅ Full |\n| **Mobile app** | **?** | ✅ Full | ⚠️ Improving |\n| **Offline access** | **?** | ⚠️ Limited | ⚠️ Limited |\n| **Version history** | **?** | ✅ Full | ✅ Full |\n| **SSO / enterprise auth** | **?** | ✅ (Enterprise) | ✅ (Enterprise) |\n| **Free tier** | **?** | ✅ Full | ✅ Full |\n\n> ⚠️ **Note:** All \"You\" cells marked **?** require internal verification before using this matrix with customers or investors. Rows marked ❌/⚠️ for your product are assumptions based on your description; correct where inaccurate.\n\n**Quality notes on feature parity:**\n- Notion's database feature and Coda's formula engine are not just \"more features\" — they represent a different product category (structured data tool vs. wiki). This is a positioning asset for you: if a team needs those, they were never your customer.\n- Notion's setup time disadvantage is real but partially offset by its template library — a well-chosen template cuts setup significantly **[Assumption]**.\n\n---\n\n## 4. Pricing Comparison\n\n> All prices in USD per user/month, billed annually. **Verify before sharing externally.**\n\n| Plan | You | Notion | Coda |\n|---|---|---|---|\n| **Free** | **?** | ✅ Unlimited pages, limited collab | ✅ Limited doc size |\n| **Starter / Plus** | **?** | $12/user | $10/user |\n| **Pro / Business** | **?** | $18/user | $30/user |\n| **Enterprise** | **?** | Custom | Custom |\n\n**Pricing dynamics to note:**\n- Notion and Coda both have free tiers capable enough that early-stage startups (1–5 people) often don't pay at all. Competing on \"we're cheaper\" is most meaningful at the 5–25 person paid tier.\n- If your pricing is meaningfully below $10/user, you win on cost for budget-conscious early-stage teams. Below $6/user starts to create a quality-perception risk — some CTOs will question sustainability.\n- Consider a flat-rate team plan (e.g., $49/month for up to 10 users) — this removes per-seat friction at the moment when a founding team is deciding which tool to standardize on.\n\n---\n\n## 5. Market Positioning Map\n\n```\n                        COMPREHENSIVE\n                (databases, automation, apps)\n                             │\n                             │\n              Coda ●         │\n                             │\n                             │\n  ──────────────────────────────────────────────\n  ENTERPRISE / COMPLEX                 STARTUP / SIMPLE\n  (IT-managed, SOC2,                   (self-serve, fast,\n   large teams)                         opinionated)\n                             │\n                    Notion ● │\n              (tries to span │  ● YOU\n               both axes)    │ (focused here)\n                             │\n                        SIMPLE / FOCUSED\n                   (wiki-first, easy to learn)\n```\n\n**How to read this:**\n- Coda occupies the \"powerful tool for ops-minded teams\" space; it's not competing for the same first-time wiki user you are\n- Notion spans the entire map by design, which means it's your most direct competitor but also the one most vulnerable to a \"we're simpler and built for you\" message\n- You have a clear, uncrowded position in the bottom-right — but only if you resist feature creep toward the middle\n\n**Whitespace Opportunities**\n- **Async-first remote startups** (2–15 people, no dedicated ops hire) who want documentation that works without a system administrator\n- **Non-technical founding teams** (e.g., DTC, services, media) who find Notion's flexibility alienating\n- **Series A teams standardizing tooling** who want to graduate from a shared Google Doc chaos but aren't ready for Confluence\n\n---\n\n## 6. Win/Loss Analysis\n\n### Why You Win\n\n| Scenario | Why You Win |\n|---|---|\n| Founder setting up wiki in a weekend | Fastest time-to-value; no configuration required |\n| Non-technical team (ops, marketing, content) | Less intimidating; opinionated structure reduces decision fatigue |\n| Budget-sensitive pre-seed / seed team | Lower cost or flat-rate pricing removes per-seat anxiety |\n| Team burned by Notion complexity | \"We tried Notion, it became a mess\" is a real and common story |\n| Teams that just need documentation | No feature bloat; the tool does one thing well |\n\n### Why You Lose\n\n| Scenario | Why You Lose |\n|---|---|\n| Team already uses Notion (individual accounts exist) | Switching cost + familiarity; they'll try to make it work first |\n| Team needs a Slack bot or GitHub integration on day one | Hard blocker; integration gap creates immediate friction |\n| Technical co-founder evaluates tools | May perceive feature gap as long-term risk; chooses \"more capable\" tool to avoid migrating later |\n| Team wants databases or roadmap tracking alongside wiki | Notion or Coda solve two problems; you solve one |\n| Startup plans to scale to 50+ in 12 months | Future-proofing concern: \"will this grow with us?\" |\n\n**Key insight:** Your most common loss pattern is likely not \"they compared features and chose Notion\" — it's \"they already had Notion accounts and never evaluated alternatives.\" Awareness and trial generation matter as much as product quality at this stage.\n\n---\n\n## 7. Strategic Recommendations\n\n### Immediate Actions (0–3 months)\n\n| Priority | Action | Rationale |\n|---|---|---|\n| 🔴 High | **Audit and close the top 4 integration gaps** — build or finalize Slack, Google Drive, GitHub, and Linear integrations | These four cover ~80% of integration objections from your ICP. A missing Slack integration is a hard \"no\" for many teams. |\n| 🔴 High | **Create a \"Switch from Notion\" landing page and import flow** | The most qualified prospects are Notion users experiencing frustration. Make the migration path zero-effort. |\n| 🟡 Medium | **Define and publish your ICP explicitly** — \"Built for teams of 2–25\" | Counterintuitively, narrowing your stated audience increases conversion from that audience and sets customer expectations correctly. |\n| 🟡 Medium | **Validate your setup-time claim with a measured benchmark** | \"Faster to set up\" is your primary claim — make it specific and defensible (e.g., \"Working wiki in 8 minutes, proven across 500 teams\"). |\n\n### Medium-term (3–12 months)\n\n| Priority | Action | Rationale |\n|---|---|---|\n| 🔴 High | **Build a durable switching cost before teams hit 15–20 people** | At that size, teams re-evaluate tools. If your product has become the muscle memory and content repository, switching cost is real. Consider features that reward *depth of use*: linked pages, team templates, search quality. |\n| 🟡 Medium | **Consider a flat-rate team plan at $39–59/month for ≤10 users** | Removes per-seat math at the critical early adoption moment; makes budgeting easy for founders without a finance function. |\n| 🟡 Medium | **Invest in social proof specifically from recognizable early-stage startups** | Founders trust founders. Three logos from YC/Techstars companies convert better than 300 generic testimonials. |\n| 🟢 Lower | **Explore AI-assisted wiki features** — auto-tagging, stale page detection, smart search | Both Notion and Coda have moved here. A lightweight, wiki-specific AI feature (e.g., \"This page hasn't been updated in 90 days\") differentiates without requiring a full AI platform. |\n\n### What Not to Build (Strategic Restraint)\n\n- ❌ **Databases and formula engines** — this chases Coda and Notion into their home territory; you will lose and blur your positioning\n- ❌ **Project management / task tracking** — same risk; Linear, Asana, and Height exist; integrate with them instead\n- ❌ **Enterprise SSO / compliance features** in the next 6 months — your ICP doesn't need it yet; don't let one enterprise inquiry pull your roadmap\n\n---\n\n## Appendix: Confidence Levels\n\n| Section | Confidence | Notes |\n|---|---|---|\n| Notion pricing | High | Publicly listed; verify current figures |\n| Coda pricing | High | Publicly listed; verify current figures |\n| Notion/Coda feature claims | Medium–High | Based on public documentation and product pages |\n| Your feature capabilities | Low | Based solely on your description; requires internal validation |\n| Win/loss patterns | Medium | Inferred from ICP and market dynamics; validate with 5–10 customer interviews |\n| Integration gap severity | Medium | Ranked by general startup tool usage data; validate against your own churn/loss notes |"},{"skill":"competitor-teardown","title":"Competitor Teardown","input":"We're a lightweight team wiki for small startups. Compare us against Notion and Coda. We're cheaper and faster to set up but have fewer integrations.","source":"representative example (hand-written)","output":"# Competitor Teardown — Lightweight Team Wiki\n\n## Positioning map (setup speed × depth)\n\n```\n depth/power\n   high │  Coda ●            Notion ●\n        │\n        │              ● (us)\n   low  │___________________________\n        slow ───── setup speed ───── fast\n```\nWe own the **fast-setup, low-overhead** corner. Notion and Coda compete on depth and power, at the cost of setup time and learning curve.\n\n## Feature comparison\n| Dimension | Us | Notion | Coda |\n|-----------|:--:|:------:|:----:|\n| Time to first useful page | 🟢 < 2 min | 🟡 ~15 min | 🔴 ~30 min |\n| Price (5-person team) | 🟢 $$ | 🟡 $$$ | 🟡 $$$ |\n| Integrations | 🔴 few | 🟢 many | 🟢 many |\n| Databases / automation | 🔴 basic | 🟢 strong | 🟢 strongest |\n| Learning curve | 🟢 minimal | 🟡 moderate | 🔴 steep |\n\n## Where we win / lose\n- **Win:** teams that want a wiki *today* without a setup project — early startups, non-technical founders.\n- **Lose:** teams that have outgrown simple docs and want one tool to run ops (they'll pick Notion/Coda).\n\n## Messaging gap to exploit\nNotion's own positioning (\"one tool for your whole team\") is also its weakness — it's *a lot*. Lean into **\"a team wiki you'll actually finish setting up.\"** Speed and simplicity, not feature parity.\n\n## Strategic recommendations\n1. **Don't chase integration parity** — it's their moat, not your battlefield. Add only the 3–4 integrations startups ask for most (Slack, GitHub, Google Drive).\n2. **Make migration off us painless** — removing lock-in fear lowers the bar to try.\n3. **Target the \"Notion is too much\" segment** directly in messaging and SEO."},{"skill":"cs-health-scorecard","title":"Cs Health Scorecard","input":"Account: Acme Corp, enterprise, ARR $120k, renewal in 90 days. DAU/MAU 18%, 2 open P2 tickets, CSAT 7, exec sponsor left last month, seats 80/100 used, payments on time.","source":"generated by claude-sonnet-4-6","output":"```python\n# Scoring rationale before running the framework:\n#\n# Product Adoption – DAU/MAU 18% (below 25% benchmark), no feature breadth data\n#   but 80% seat utilisation is a positive signal → Score: 3/5\n#\n# Engagement – Exec sponsor VACANT (left last month), no QBR data provided,\n#   champion unknown → Score: 2/5\n#\n# Outcomes – No stated goals or ROI evidence provided; gap in data treated as\n#   a risk signal at 90 days to renewal → Score: 2/5\n#\n# Support Health – 2 open P2s, CSAT 7 (below 8 benchmark), no escalations → Score: 3/5\n#\n# Commercial – 80% seat utilisation (healthy), payments on time, no expansion\n#   or contraction signals stated → Score: 4/5\n\nscores    = {\"adoption\": 3, \"engagement\": 2, \"outcomes\": 2, \"support\": 3, \"commercial\": 4}\nweights   = {\"adoption\": 0.30, \"engagement\": 0.20, \"outcomes\": 0.20, \"support\": 0.15, \"commercial\": 0.15}\n\nweighted  = {k: scores[k] * weights[k] * 20 for k in scores}  # scale 1-5 → 0-100\ntotal     = sum(weighted.values())\nrag       = \"Green\" if total >= 80 else \"Amber\" if total >= 60 else \"Red\"\n\nfor k in scores:\n    print(f\"{k.capitalize():12s}  score={scores[k]}  weight={int(weights[k]*100)}%  weighted={weighted[k]:.1f}\")\nprint(f\"\\nTotal: {total:.1f}/100  →  {rag}\")\n```\n\n```\nAdoption      score=3  weight=30%  weighted=18.0\nEngagement    score=2  weight=20%  weighted=8.0\nOutcomes      score=2  weight=20%  weighted=8.0\nSupport       score=3  weight=15%  weighted=9.0\nCommercial    score=4  weight=15%  weighted=12.0\n\nTotal: 55.0/100  →  Red\n```\n\n---\n\n# Customer Health Scorecard: Acme Corp\n\n**CSM:** [Assign / confirm owner] | **Tier:** Enterprise\n**ARR:** $120,000 | **Renewal date:** [90 days from today] | **Days to renewal:** 90\n**Overall health:** 🔴 Red — 55/100\n**Last updated:** [Today's date]\n\n> **⚠ Escalation required.** Three compounding risk factors — vacant executive sponsor, sub-benchmark product adoption, and below-threshold CSAT — collide at a 90-day renewal window. This account needs an immediate save motion, not routine CSM cadence.\n\n---\n\n## Health Score Summary\n\n| Dimension | Score (1–5) | Weight | Weighted Score | Trend |\n|---|---|---|---|---|\n| Product Adoption | 3 | 30% | 18.0 | ↓ |\n| Engagement | 2 | 20% | 8.0 | ↓ |\n| Outcomes | 2 | 20% | 8.0 | → |\n| Support Health | 3 | 15% | 9.0 | → |\n| Commercial | 4 | 15% | 12.0 | → |\n| **Total** | — | 100% | **55.0/100** | |\n\n> **Scoring note:** Outcomes and Engagement are the two heaviest drag dimensions (combined 40% weight). Both score 2/5. Even a move from 2→3 in each would add 8 points and lift the account to Amber. That is the fastest lever available before renewal.\n\n---\n\n## Dimension Detail\n\n### Product Adoption — 3/5\n\n- **DAU/MAU ratio:** 18% — **below the 25% healthy benchmark by 7 percentage points**\n- **Key features adopted:** Not specified — data required from product analytics (action: pull from platform dashboard this week)\n- **Features not adopted:** Unknown — feature gap analysis needed to target re-engagement\n- **Power users identified:** Unknown — identifying 3–5 internal champions beyond the departed exec is critical\n- **Seat utilisation:** 80/100 (80%) — this is a genuine positive; the user base exists, they are simply not logging in frequently enough\n- **Assessment:** Seat utilisation is healthy, which tells us the customer bought into the vision and deployed the product broadly. However, 18% DAU/MAU means users are not forming daily habits. This is a depth-of-adoption problem, not a breadth problem — the fix is targeted enablement and use-case reinforcement, not a sales motion.\n\n---\n\n### Engagement — 2/5\n\n- **Last QBR:** Not provided — assumed overdue or undocumented\n- **Next QBR:** Not scheduled — must be booked immediately given renewal timeline\n- **Executive sponsor:** 🔴 **VACANT** — departed last month; no replacement identified\n- **Champion:** Name and role unknown — this is an open, critical risk\n- **Assessment:** The executive sponsor vacancy is the single highest-risk item on this scorecard. Without an internal champion with authority, there is no one to defend the renewal in procurement or leadership discussions. At 90 days out, every week without a new sponsor is a week the competitor's account executive can fill that vacuum. Mapping the new org chart and securing an introductory call with the incoming stakeholder is the top priority this week, full stop.\n\n---\n\n### Outcomes — 2/5\n\n- **Customer's stated goals:** Not provided in intake — pulling from onboarding notes or last QBR summary is an immediate action\n- **Progress against goals:** Unknown / unverifiable without goal data\n- **Evidence of value:** No metric or quote available — this is a significant gap at 90 days to renewal; if the customer cannot articulate what they have achieved, they cannot justify the renewal internally\n- **Assessment:** A renewal without a documented ROI story is a renewal that depends on inertia, not value. At the $120k ARR level, the customer's procurement team will ask \"what did we get for this?\" If the CSM cannot answer that question with data, the renewal is at risk regardless of relationship quality. Building the value narrative — even retrospectively — must happen in the next 30 days.\n\n---\n\n### Support Health — 3/5\n\n- **Open tickets:** 2 (P1: 0 | P2: 2 | P3: 0)\n- **CSAT:** 7.0 — **below the 8.0 healthy benchmark**\n- **Unresolved escalations:** None confirmed — however, 2 open P2s with CSAT at 7 suggests unresolved friction\n- **Ticket trend (last 90 days):** Unknown — trend data not provided; support team should pull 90-day volume report\n- **Assessment:** No P1s and no escalations are genuine positives. However, a CSAT of 7 paired with 2 lingering P2s suggests the customer feels their issues are handled adequately but not excellently. At renewal, this translates to \"the product works but the experience could be better\" — enough to invite a competitive evaluation. Resolving both P2s before the renewal conversation closes a potential objection and moves CSAT in the right direction.\n\n---\n\n### Commercial — 4/5\n\n- **Seats licensed:** 100 | **Seats active:** 80 (80% utilisation)\n- **Payment history:** On time — no commercial red flags\n- **Expansion signals:** None stated — 20 unused seats represent a latent expansion opportunity if adoption deepens\n- **Downgrade or contraction signals:** None stated — but absence of positive engagement signals should be read cautiously at this stage\n- **Assessment:** The commercial dimension is the strongest on this scorecard. On-time payments and 80% seat utilisation mean the customer is not quietly winding down usage before a cancellation. The 20 unused seats are a two-sided signal: a risk (they could argue they are overpaying) and an opportunity (if adoption improves, those seats become an upsell story). Frame them as an opportunity, not a liability.\n\n---\n\n## Top Risks\n\n| Risk | Severity | Mitigation |\n|---|---|---|\n| Executive sponsor departed last month with no replacement identified | **High** | CSM + AE to map new org chart within 5 business days; request warm introduction via existing champion or champion's manager; prepare a \"new stakeholder\" briefing pack |\n| No documented ROI or outcomes story exists at 90 days to renewal | **High** | Pull usage data, build retrospective value narrative using seat utilisation and any available workflow metrics; present at emergency QBR within 30 days |\n| DAU/MAU at 18% — users not forming product habits | **High** | Identify the 3 most-used workflows among active users; run targeted enablement session for disengaged seats; surface underused high-value features |\n| Champion identity unknown — single point of failure if key contact also leaves | **Medium** | Map all active power users from login data; identify 2–3 candidates to cultivate as internal advocates before renewal |\n| CSAT at 7 and 2 open P2 tickets — friction unresolved entering renewal window | **Medium** | Escalate both P2s internally for priority resolution within 14 days; CSM to personally follow up with ticket owner post-resolution to confirm satisfaction |\n| No QBR on record / scheduled — customer lacks forum to articulate concerns or receive value | **Medium** | Schedule emergency QBR within 3 weeks; do not wait for a standard cadence given 90-day window |\n\n---\n\n## Recommended Actions\n\n**Immediate (this week):**\n1. **Map the new org chart** — identify who replaced the departed executive sponsor, and whether any VP or Director has assumed ownership of the Acme Corp tool stack — **Owner: CSM + AE | Deadline: Day 5**\n2. **Request warm introduction** to the new stakeholder via the strongest remaining internal contact (identify from login/ticket data) — **Owner: CSM | Deadline: Day 5**\n3. **Pull product analytics** — DAU/MAU breakdown by team, feature adoption heatmap, list of users who have not logged in for 30+ days — **Owner: CSM (via Customer Success Ops or product admin) | Deadline: Day 3**\n4. **Escalate both P2 tickets** internally to ensure resolution within 14 days — send a personal update to the ticket owner at Acme confirming priority — **Owner: CSM + Support Lead | Deadline: Day 2**\n\n**This month:**\n1. **Schedule and run an emergency QBR** with the new executive stakeholder (or interim) — agenda: retrospective value review, open issues, roadmap alignment, renewal terms preview — **Owner: CSM | Deadline: Day 30**\n2. **Build the ROI / value narrative** — compile a one-page \"Year in Review\" doc using seat utilisation, resolved tickets, workflow adoption, and any customer-provided metrics from onboarding goals — **Owner: CSM | Deadline: Day 21**\n3. **Run a targeted enablement session** for the 20 inactive seats — focus on the 2–3 features most correlated with high DAU/MAU in comparable accounts — **Owner: CSM + Solutions Engineer | Deadline: Day 28**\n4. **Identify and begin cultivating 2–3 power users** as internal champions — get them on a reference call or community program if available — **Owner: CSM | Deadline: Day 30**\n\n**Before renewal:**\n1. **Deliver formal renewal business case** to the new executive sponsor — tie directly to documented outcomes, include a 12-month success plan to address remaining gaps — **Owner: AE + CSM | Deadline: Day 60**\n2. **Confirm commercial terms** — given 20 unused seats, be prepared for a right-sizing conversation; decide internally whether to hold, offer a ramp, or pre-empt with a multi-year incentive — **Owner: AE + VP Sales | Deadline: Day 60**\n3. **Close both P2 tickets and confirm CSAT recovery** — resurvey the ticket owner post-resolution; target CSAT ≥8 before renewal conversation — **Owner: CSM + Support | Deadline: Day 45**\n4. **Get verbal commitment from executive sponsor** before sending renewal paperwork — do not let renewal land cold in an inbox — **Owner: AE | Deadline: Day 75**\n\n---\n\n## Renewal Forecast\n\n| Scenario | Probability | ARR at Risk |\n|---|---|---|\n| Full renewal at current ARR | 40% | $0 |\n| Renewal with contraction (right-sizing unused seats) | 35% | ~$24,000 (20 unused seats at blended rate) |\n| Churn | 25% | $120,000 |\n\n> **Calibration note:** 25% churn probability at an enterprise account is elevated. The combination of vacant executive sponsor + no documented ROI + below-benchmark adoption, all within a 90-day window, places this firmly in \"needs a structured save motion\" territory. If the new stakeholder meeting does not occur within 14 days, revise churn probability upward to 35–40%.\n\n**Recommended renewal play:** 🛑 **Save** — execute the sponsor recovery and value narrative actions before attempting any commercial conversation. A renewal discussion without an engaged executive sponsor and a clear ROI story will fail or result in a downgrade. Stabilise the relationship first; price conversation second.\n\n---\n\n## Quality Checks\n\n- [x] Score is based on data, not gut feel — each dimension has specific evidence (DAU/MAU %, seat count, CSAT score, sponsor departure, payment record)\n- [x] Risks are specific — e.g. \"Executive sponsor departed last month with no replacement identified\" not \"low engagement\"\n- [x] All actions have named owner roles and deadlines in calendar days\n- [x] Renewal probability is calibrated to account reality, not wishful thinking\n- [x] Trend arrows reflect directional change: Engagement and Adoption are ↓ due to sponsor departure and sub-benchmark usage; others held at → pending trend data\n- [x] Seat utilisation (commercial positive) explicitly separated from DAU/MAU (adoption risk) — not conflated\n\n---\n\n## Data Gaps — Fill Before Next Review\n\nThe following data was not provided in the intake and **must be sourced within 7 days** to complete a fully evidenced scorecard:\n\n| Gap | Where to Get It | Owner |\n|---|---|---|\n| Champion name and role | CRM account record / ticket history | CSM |\n| Last QBR date and notes | CRM / Google Drive / Confluence | CSM |\n| Feature adoption breakdown | Product analytics platform | CS Ops |\n| Customer's stated goals / success metrics | Onboarding docs / original SOW | CSM |\n| P2 ticket age and details | Support platform (Zendesk / Intercom) | Support Lead |\n| 90-day ticket volume trend | Support platform reporting | Support Lead |\n| Name of incoming exec sponsor | Account mapping / AE intel | AE + CSM |"},{"skill":"executive-summary","title":"Executive Summary","input":"Summarise: our Q2 retention dropped from 82% to 76% driven by a new onboarding flow that confused mobile users; we shipped a fix in week 10 and retention recovered to 80%; we recommend a full mobile onboarding rework next quarter.","source":"generated by claude-sonnet-4-6","output":"# Customer Retention Recovery — Q2 Update\n**Executive Summary**\n*Prepared for: Leadership Team | Q2 Close*\n\n---\n\n**Bottom line up front:**\nA flawed onboarding update caused retention to drop 6 points in Q2, from 82% to 76%. A fix shipped in Week 10 has partially recovered retention to 80%. We are recommending a full mobile onboarding rework next quarter to close the remaining gap and prevent recurrence.\n\n---\n\n**Background:**\nRetention had been stable at 82%. A new onboarding flow deployed in Q2 created friction specifically for mobile users, triggering the drop. The underlying cause has been patched but not fully resolved.\n\n---\n\n**Key findings:**\n- **Retention fell 6 points** to 76% — the primary driver was the new onboarding flow, not churn fundamentals\n- **Mobile users were disproportionately affected**, indicating a gap in mobile QA or pre-launch testing\n- **The Week 10 patch recovered 4 of 6 lost points** (80%), confirming the diagnosis was correct — but the fix was partial\n- **2 points of retention remain unrecovered**, representing ongoing revenue and growth risk if left unaddressed\n\n---\n\n**Options considered:**\n\n| Option | Benefit | Risk | Recommendation |\n|---|---|---|---|\n| Full mobile onboarding rework | Closes remaining gap; prevents recurrence | Requires Q3 resource allocation | **Recommended** |\n| Incremental patches only | Lower cost; faster to ship | Likely to leave structural issue unresolved | Not recommended |\n| No action | None | Further erosion if mobile UX issues compound | Not recommended |\n\n---\n\n**Recommendation:**\nApprove a full mobile onboarding rework in Q3. The patch has demonstrated that onboarding is the lever — a complete rework should recover the remaining 2-point gap and restore retention to at or above the 82% baseline.\n\n---\n\n**Immediate next steps:**\n- **Product lead** to scope mobile onboarding rework — by end of Week 1, Q3\n- **QA lead** to implement mobile-specific pre-launch testing protocol — before next onboarding release\n- **Analytics** to instrument onboarding funnel for mobile vs. desktop tracking — ongoing\n\n---\n\n**Risks of inaction:**\nThe 2-point retention gap is currently stable but not recovered. Without structural fixes, any further onboarding changes risk reopening the full 6-point loss. At scale, each retention point typically represents material recurring revenue — leaving this unresolved accepts that risk indefinitely.\n\n**Full detail:** Available on request from the Product team."},{"skill":"executive-update","title":"Executive Update","input":"Audience: CEO. Period: Q2. Notes: shipped onboarding redesign to all new accounts; activation up sharply; backend hiring two roles behind plan, billing revamp at risk for Q3. Metrics: weekly active accounts, activation rate, NRR.","source":"representative example (hand-written)","output":"# Executive Update — Q2, for the CEO\n\n**Headline:** Activation is up 14 points after the onboarding redesign; we're on track for the Q2 target with one staffing risk to flag for Q3.\n\n## Key metrics\n- **Weekly active accounts:** 12,400 (+18% QoQ)\n- **Activation rate:** 61% (+14 pts) — best quarter on record\n- **Net revenue retention:** 112% (flat)\n\n## Progress\nThe redesigned onboarding flow is live for 100% of new accounts. Early cohorts reach value faster — median time-to-value is 2.1 days, down from 4.6.\n\n## Risk & decision needed\n- **Risk:** Backend hiring is two roles behind plan, putting the Q3 billing revamp at risk.\n- **Decision:** Approve contractor budget (~$40k) to hold the Q3 date, or accept a 4-week slip.\n\n## Next steps\n- Roll the activation experiment into the core product (next sprint).\n- Bring a Q3 staffing plan to the next leadership review."},{"skill":"go-to-market","title":"Go To Market","input":"Launching an integrations marketplace for our analytics product. Target: existing mid-market customers and their ops teams. Goal: 30% of accounts install at least one integration within 60 days.","source":"generated by claude-sonnet-4-6","output":"I'll work with the information provided and make reasonable inferences for a mid-market analytics product with an integrations marketplace. Where I've made assumptions, I'll note them so you can swap in your specifics.\n\n---\n\n# GTM Asset Pack — Integrations Marketplace Launch\n\n---\n\n## 1. Positioning Statement\n\n> For **operations teams at mid-market companies** who **struggle to get their data where it needs to be — moving it manually between tools or waiting on engineering to build one-off connections**, **[Product Name] Integrations Marketplace** is an **enterprise integration hub** that **lets ops teams connect their analytics to the tools they already use, in minutes, without writing a line of code**. Unlike **building custom integrations through your IT or data engineering queue**, our product **offers a growing library of pre-built, maintained connectors that ops teams can install and configure themselves**.\n\n**Tagline:**\n> *Your analytics, inside every tool your team already uses.*\n\n*(≤10 words: \"Your analytics, inside every tool you already use.\")*\n\n---\n\n## 2. Messaging Pillars\n\n---\n\n**Pillar 1: Self-Serve Setup, No Engineering Required**\n\nOps teams can connect their analytics to critical business tools without opening a single ticket.\n\n**Proof Points:**\n- Average integration install time is under 15 minutes from search to live data flow [ADD PROOF POINT — replace with actual median install time from beta]\n- Authentication, field mapping, and scheduling are handled through a guided UI — no code, no credentials handed to engineering [ADD PROOF POINT — confirm no-code scope from product team]\n- [ADD PROOF POINT — beta customer quote on self-serve setup experience]\n\n**Example in copy:**\n> \"Stop waiting on engineering. Connect your analytics to Salesforce, Slack, or your data warehouse in minutes — no tickets, no code, no back-and-forth.\"\n\n---\n\n**Pillar 2: A Pre-Built Library That Grows With Your Stack**\n\nEvery integration in the marketplace is built, tested, and maintained by [Company Name] — so customers aren't inheriting a fragile DIY connector.\n\n**Proof Points:**\n- Marketplace launches with [N] integrations across CRM, BI, communication, and data warehouse categories [ADD PROOF POINT — confirm launch catalog count]\n- All connectors are versioned and updated automatically when upstream APIs change, eliminating break/fix maintenance for customers [ADD PROOF POINT — confirm maintenance SLA or update policy]\n- New integrations are added on a [monthly/quarterly] roadmap, prioritized by customer vote [ADD PROOF POINT — confirm cadence and voting mechanism]\n\n**Example in copy:**\n> \"Choose from a growing library of pre-built, maintained connectors — and vote for what gets built next.\"\n\n---\n\n**Pillar 3: Data Where Decisions Actually Happen**\n\nAnalytics is only valuable when it reaches the people and tools making decisions — not when it stays inside a dashboard nobody opens.\n\n**Proof Points:**\n- 74% of business decisions are made in operational tools like CRMs, spreadsheets, and messaging apps — not inside analytics platforms *(Forrester, 2023 — confirm citation or replace)*\n- Customers using [Product Name] with connected downstream tools report [X]% higher dashboard engagement [ADD PROOF POINT — pull from product usage or NPS data]\n- [ADD PROOF POINT — customer example showing outcome improvement after integrating analytics into a workflow tool]\n\n**Example in copy:**\n> \"Your team makes decisions in Salesforce, Slack, and Sheets — now your analytics can meet them there.\"\n\n---\n\n**Pillar 4: Built for Mid-Market Ops — Not Enterprise IT Projects**\n\nThe marketplace is scoped for the way mid-market ops teams actually work: fast, scrappy, and without a dedicated integration team.\n\n**Proof Points:**\n- No professional services engagement required to activate integrations — all configuration is self-documented in-product [ADD PROOF POINT — confirm no PS dependency]\n- Permissions and access controls let ops admins manage integrations without exposing sensitive credentials to individual users [ADD PROOF POINT — confirm RBAC scope from product/security team]\n- Priced as part of existing subscription — no separate integration tax or per-connector fees [ADD PROOF POINT — confirm pricing model before launch]\n\n**Example in copy:**\n> \"Designed for the ops team of 3, not the IT department of 300 — no consultants, no contracts, no extra line items.\"\n\n---\n\n**Pillar 5: One Connected System, Auditable and Secure**\n\nEvery data flow through the marketplace is logged, permissioned, and auditable — so ops teams move fast without creating compliance risk.\n\n**Proof Points:**\n- All integration activity is captured in a centralized audit log accessible to admins [ADD PROOF POINT — confirm audit log feature scope]\n- OAuth 2.0 authentication standard used across all connectors — no stored plaintext credentials [ADD PROOF POINT — confirm with security team]\n- [ADD PROOF POINT — SOC 2 / compliance certification reference if applicable]\n\n**Example in copy:**\n> \"Every connection is logged and permissioned — so your team can move fast without your security team losing sleep.\"\n\n---\n\n## 3. Feature & Functionality List\n\n| Feature / Functionality | Buyer Benefit |\n|---|---|\n| Pre-built connector library (CRM, BI, data warehouse, messaging) | Eliminates weeks of scoping and engineering effort to connect analytics to existing tools |\n| Guided, no-code install wizard | Enables any ops team member to set up a live integration in minutes — no technical background required |\n| Automated connector maintenance and API version updates | Removes the ongoing cost and risk of maintaining homegrown integrations that break when upstream tools change |\n| Field mapping and transformation UI | Gives ops teams control over exactly what data flows where, without writing transformation scripts |\n| Role-based access control for integrations | Ensures only authorized team members can install or modify connections, reducing accidental data exposure |\n| Centralized integration audit log | Provides admins with a full history of all data flows for compliance reviews, troubleshooting, and security audits |\n| Scheduled and event-triggered sync options | Delivers data to connected tools on the schedule that matches business workflows — not just on-demand exports |\n| In-marketplace user voting for new connectors | Gives ops teams direct influence over the integration roadmap, ensuring future connectors reflect actual tool adoption |\n| Integration health monitoring and alerting | Notifies ops admins proactively when a connection fails — reducing silent data gaps that corrupt downstream reporting |\n| Single-pane integration management dashboard | Saves time by showing all active connections, sync status, and error states in one place without switching between tools |\n\n---\n\n## 4. Use Cases\n\n---\n\n**Use Case 1: Revenue Operations Manager — Syncing Analytics Insights to CRM**\n\n- **Who:** Revenue Operations Manager, mid-market B2B SaaS company (~200–1,000 employees)\n- **Situation:** The RevOps manager needs account health scores and product usage metrics to appear directly in Salesforce so AEs can act on churn risk without leaving their CRM.\n- **Before:** RevOps exports a CSV from the analytics platform weekly, manually uploads it to Salesforce, and maps fields by hand. The process takes 3–4 hours every Friday and the data is stale by Tuesday. AEs either ignore the separate dashboard or ask RevOps for one-off pulls.\n- **With [Product Name] Marketplace:** RevOps installs the Salesforce connector in 12 minutes, maps product usage fields to custom Salesforce objects through a point-and-click UI, and sets a nightly sync schedule.\n- **Outcome:** AEs see live account health scores on every Salesforce account record. RevOps reclaims 3+ hours per week. Churn escalations are triggered automatically based on score thresholds — no manual monitoring required.\n\n---\n\n**Use Case 2: Business Operations Analyst — Automating Reporting Into BI Tools**\n\n- **Who:** Business Operations Analyst, mid-market operations or finance team\n- **Situation:** The analyst maintains a Tableau or Looker dashboard for executive reporting, which requires pulling fresh data from the analytics platform each week before the Monday leadership meeting.\n- **Before:** The analyst manually exports data, reformats it in Excel to match the BI tool's expected schema, and re-uploads. Any change to the analytics platform's output breaks the downstream dashboard and causes a scramble before the Monday call.\n- **With [Product Name] Marketplace:** The analyst connects the analytics platform directly to their BI tool via the marketplace connector. Field mappings are saved and versioned. Data refreshes automatically every Sunday night.\n- **Outcome:** The Monday dashboard is always current with zero manual prep. Schema changes in the analytics platform surface as mapping alerts — not silent breakage. The analyst redirects 4+ hours per week from data plumbing to actual analysis.\n\n---\n\n**Use Case 3: Operations Team Lead — Pushing Alerts Into Slack for Real-Time Response**\n\n- **Who:** Operations Team Lead managing a customer success or support function\n- **Situation:** The ops lead wants their team to act immediately when a key metric crosses a threshold (e.g., a customer's usage drops below a retention risk threshold) — but the team lives in Slack, not in the analytics dashboard.\n- **Before:** The team lead sets up email alerts inside the analytics platform, but they get buried. Alternatively, they assign a team member to check the dashboard daily — an inconsistent process that misses evenings and weekends.\n- **With [Product Name] Marketplace:** The ops lead installs the Slack connector, creates a channel for operational alerts, and maps specific metric thresholds to automated Slack notifications in under 20 minutes.\n- **Outcome:** The team receives real-time alerts in the channel they monitor all day. Response time to at-risk customer signals drops from 24–48 hours to under 2 hours. No dashboard babysitting required.\n\n---\n\n**Use Case 4: IT/Systems Admin — Managing and Auditing All Integrations Across the Org**\n\n- **Who:** IT Systems Administrator or Internal Tools Admin responsible for data governance\n- **Situation:** Multiple ops team members have started installing integrations independently. The admin needs to see what's connected, who authorized it, where data is flowing, and whether any connections are failing — without asking each team.\n- **Before:** No centralized view exists. The admin discovers integrations by asking around or receiving a complaint when a downstream report breaks. There's no audit trail for compliance reviews.\n- **With [Product Name] Marketplace:** The admin accesses the Integration Management Dashboard, sees all active connectors, owner, install date, sync frequency, and last-run status. They review the audit log filtered by date range for a quarterly compliance review in minutes.\n- **Outcome:** The admin can complete a full integration audit in under 30 minutes. Failed connections are caught proactively via health alerts before they affect business reporting. Compliance documentation is exportable directly from the dashboard.\n\n---\n\n**Use Case 5: VP of Operations — Driving the 60-Day Integration Adoption Goal**\n\n- **Who:** VP of Operations or Chief of Staff sponsoring the internal rollout of the integrations marketplace\n- **Situation:** Following the marketplace launch announcement, the VP needs to drive adoption across their team without creating a large change management project or requiring engineering involvement.\n- **Before:** Rolling out new technical tooling at this company typically requires an IT project kickoff, a training session, documentation written by someone technical, and weeks of back-and-forth. Adoption still lags because the tools feel built for engineers.\n- **With [Product Name] Marketplace:** The VP shares the marketplace URL with their ops team leads with a one-page use case guide (this document). Each team lead self-identifies their highest-value integration use case, installs it independently, and reports back within a week. The VP tracks adoption via the admin dashboard.\n- **Outcome:** First integrations are live within the first week post-launch with no engineering involvement. The VP achieves measurable tool connectivity across the ops function within the 60-day window — with a clear audit trail to share upward as a business impact story.\n\n---\n\n## Flagged Items Before Launch\n\nThe following placeholders require your team to insert real data before this asset pack goes external:\n\n| # | Placeholder | Owner | Priority |\n|---|---|---|---|\n| 1 | Median integration install time (beta data) | Product / Analytics | 🔴 High — used in Pillar 1 and Use Cases |\n| 2 | Launch catalog integration count | Product | 🔴 High — core credibility claim |\n| 3 | Connector maintenance/update SLA | Engineering | 🔴 High — Pillar 2 differentiator |\n| 4 | Dashboard engagement lift data (connected vs. unconnected) | Data / Analytics | 🟡 Medium — Pillar 3 proof |\n| 5 | Forrester citation confirmation | Marketing | 🟡 Medium — Pillar 3 stat |\n| 6 | Pricing model confirmation (included vs. add-on) | Product / Finance | 🔴 High — Pillar 4 claim |\n| 7 | SOC 2 / compliance certification status | Security / Legal | 🟡 Medium — Pillar 5 trust signal |\n| 8 | Beta customer quote on self-serve experience | Customer Success | 🟡 Medium — social proof across all pillars |\n\n---\n\n**Not for:** Enterprise accounts requiring custom connector development, professional services scoping, or dedicated integration support. This marketplace is designed for self-serve activation — accounts needing heavily customized data pipelines should be routed to the solutions engineering team."},{"skill":"incident-postmortem","title":"Incident Postmortem","input":"Checkout was down 42 minutes after a deploy set a wrong env var on the payments service; 5xx spiked, ~1,200 failed checkouts. Detected by alert in 6 min, fixed by rollback. Blameless postmortem with timeline and action items.","source":"generated by claude-sonnet-4-6","output":"# Incident Postmortem: Payments Service Misconfiguration Causes Checkout Outage\n\n**Incident ID:** INC-[FILL IN]\n**Severity:** P1\n**Date:** [FILL IN DATE]\n**Duration:** [HH:MM] → [HH:MM] UTC — 42 minutes total\n**Status:** Resolved\n**Author:** [FILL IN]\n**Last updated:** [FILL IN DATE]\n\n---\n\n## Executive Summary\n\nFollowing a routine deployment to the payments service, a misconfigured environment variable caused the service to enter a fault state, resulting in 5xx errors across all checkout flows. Approximately 1,200 checkout attempts failed during the 42-minute window between the deployment and full service restoration. The issue was detected by automated alerting within 6 minutes of the deployment completing. Service was fully restored by rolling back the deployment to the prior stable version. This postmortem documents the contributing factors that allowed an invalid configuration to reach production and identifies specific changes to prevent recurrence.\n\n---\n\n## Impact\n\n| Dimension | Details |\n|---|---|\n| **Users affected** | ~1,200 failed checkout attempts (all users attempting checkout during the window) |\n| **Services degraded** | Payments service (complete); Checkout flow (complete) |\n| **Business impact** | ~1,200 lost or abandoned transactions; potential revenue impact TBD; SLA breach assessment pending |\n| **Duration** | 42 minutes from deployment completion to full service restoration |\n\n---\n\n## Timeline\n\n> Time-zero is the moment the deployment completed and began serving traffic. Adjust all UTC times to match actuals.\n\n```\n[T+00:00] — Deployment of payments service vX.Y.Z completed and began serving 100% of traffic.\n            Deployment included an environment variable change as part of a configuration update.\n\n[T+00:00 – T+06:00] — 5xx error rate begins climbing immediately post-deploy.\n                       No automated gate halted deployment progression; change rolled out fully.\n\n[T+06:00] — Automated alert fires on elevated 5xx error rate threshold for the payments service.\n             On-call engineer receives page.\n\n[T+06:00 – T+10:00] — On-call engineer begins investigation. Checks service health dashboards,\n                        confirms 5xx errors are isolated to the payments service.\n                        Checkout team notified. Incident declared P1.\n\n[T+10:00 – T+18:00] — Engineers examine recent changes. Deployment log reviewed.\n                        Hypothesis formed: misconfigured environment variable introduced in deploy\n                        is causing the payments service to fail on initialization or request handling.\n                        Environment variable values compared against expected configuration.\n                        Misconfiguration confirmed.\n\n[T+18:00] — Decision made to roll back to prior stable deployment (vX.Y.(Z-1))\n             rather than attempt a forward-fix configuration patch, to minimize\n             additional risk and time to recovery.\n\n[T+18:00 – T+28:00] — Rollback initiated and executed. Deployment pipeline runs rollback procedure.\n\n[T+28:00] — Rollback completes. Payments service begins serving traffic from prior stable version.\n\n[T+28:00 – T+36:00] — Engineers monitor error rate. 5xx rate returns to baseline.\n                        Checkout success rate confirmed restored. No residual errors observed.\n\n[T+36:00] — All-clear confirmed. Incident declared resolved.\n             Post-incident monitoring period begins.\n\n[T+42:00] — Incident formally closed after sustained clean metrics window.\n             Postmortem process initiated.\n```\n\n> **Key interval:** 12 minutes elapsed between alert firing (T+06) and root cause identification (T+18).\n> **Key interval:** 22 minutes elapsed between alert firing (T+06) and full service restoration (T+28).\n\n---\n\n## Root Cause\n\n**Primary root cause:** A deployment to the payments service introduced an incorrect environment variable value that caused the service to fail on payment processing requests, producing 5xx errors for all users attempting checkout.\n\n**Contributing factors:**\n\n- **No configuration validation step in the deployment pipeline.** The environment variable value was not validated against an expected schema, type, or allowlist before the deployment was promoted to production. An invalid value was able to pass through all pipeline stages without triggering a failure or warning.\n\n- **No canary or staged rollout was in place for this deployment.** The change was applied to 100% of payments service traffic simultaneously. A phased rollout would have limited the blast radius and potentially allowed automated gates to catch the error rate spike before full promotion.\n\n- **Deployment health check did not include an end-to-end checkout probe.** Post-deployment smoke tests validated that the payments service process was running and returning 200s on its health endpoint, but did not execute a synthetic checkout transaction. The service appeared healthy to automated gates while failing all real traffic.\n\n- **The environment variable change was bundled with other deployment changes.** Because the configuration change was not isolated, identifying the specific cause required additional investigation time that would not have been necessary with a dedicated configuration-only change.\n\n- **No configuration diff was surfaced in the deployment approval review.** The deployment approval process showed code changes but did not explicitly surface environment variable changes for reviewer attention.\n\n**Why did our existing safeguards not prevent this?**\n\nThe deployment pipeline correctly executed the deployment and confirmed the service was running. However, the pipeline's definition of \"healthy\" — a passing health check endpoint — did not reflect the service's ability to process real payment transactions. The misconfigured environment variable had no effect on service startup or health endpoint response, which meant every automated gate the deployment passed through returned a false positive. No human reviewer was alerted to the environment variable change specifically, as it was not called out distinctly in the deployment review interface. Collectively, the safeguards in place validated process execution rather than functional correctness, creating a gap that allowed a configuration-level fault to reach full production traffic undetected.\n\n---\n\n## Detection\n\n- **How was it first detected?** Automated alert on elevated payments service 5xx error rate.\n- **Time from incident start to detection:** 6 minutes.\n- **Should we have detected this faster?** Partially. The 6-minute detection time reflects a reasonable alert latency given current thresholds. However, a synthetic checkout probe running continuously post-deploy would likely have reduced detection to under 2 minutes and could have triggered an automatic rollback without requiring human escalation.\n\n---\n\n## Resolution\n\n**What fixed it?** The payments service was rolled back to the previously stable deployment version, restoring the correct environment variable values and returning the service to a known-good configuration state.\n\n**Why did this work?** The prior deployment version carried the correct environment variable values as part of its packaged configuration. Rolling back replaced the misconfigured runtime environment with the validated prior state, immediately restoring correct payment processing behavior.\n\n**Was there a temporary mitigation before full resolution?** No. The rollback was identified as the fastest and lowest-risk path to recovery and was executed directly. No partial mitigation (such as traffic shifting or feature flagging) was applied.\n\n---\n\n## Action Items\n\n| # | Type | Action | Owner | Due Date | Priority |\n|---|---|---|---|---|---|\n| 1 | **Prevent recurrence** | Add a configuration validation step to the deployment pipeline that validates all environment variables against a typed schema and allowlist before deployment is promoted to any environment. Deployment must fail if validation does not pass. | Platform / DevOps | [DATE + 2 weeks] | P1 |\n| 2 | **Prevent recurrence** | Require environment variable changes to be submitted and reviewed as isolated configuration-only deployments, separate from code changes, with an explicit diff displayed in the approval interface. | Platform / Engineering Leads | [DATE + 3 weeks] | P1 |\n| 3 | **Prevent recurrence** | Implement canary / staged rollout for all payments service deployments, with automated promotion gates requiring <0.1% error rate on the canary slice before proceeding to full rollout. | Platform / Payments Team | [DATE + 4 weeks] | P1 |\n| 4 | **Improve detection** | Add a synthetic end-to-end checkout probe that executes a test transaction against the payments service every 60 seconds. Alert must fire within 2 minutes of probe failure. Probe to run as a post-deploy gate and continuously in production. | Observability / Payments Team | [DATE + 2 weeks] | P1 |\n| 5 | **Improve detection** | Lower the 5xx alert threshold for the payments service specifically, and evaluate adding a deployment-triggered alert window that applies a tighter threshold for the 15 minutes immediately following any payments service deploy. | Observability Team | [DATE + 1 week] | P2 |\n| 6 | **Improve response** | Write and publish a runbook for \"payments service elevated 5xx post-deploy\" that explicitly documents: confirm scope, check deployment log, diff environment variables, escalation path, and rollback procedure with commands. | Payments On-Call Lead | [DATE + 1 week] | P2 |\n| 7 | **Improve response** | Conduct a tabletop exercise using this incident scenario with the on-call rotation to validate the new runbook and confirm rollback procedure can be executed within 10 minutes of alert fire. | Engineering Manager | [DATE + 6 weeks] | P3 |\n\n> **P1 action items (1–4) must be closed before this incident is marked fully resolved.**\n\n---\n\n## What Went Well\n\n- **Automated alerting worked.** The 5xx alert fired within 6 minutes of the deployment completing — without this alert, detection would have depended on customer reports, which typically arrive with significantly more delay.\n\n- **Root cause was identified quickly once investigation began.** Engineers correctly narrowed the scope to the deployment and identified the specific misconfigured environment variable within approximately 12 minutes of the alert firing, which is a strong diagnostic outcome under pressure.\n\n- **The rollback decision was made quickly and without hesitation.** Once the misconfiguration was confirmed, the team did not attempt a risky forward-fix in a degraded state. The decision to roll back was made cleanly and executed promptly, which kept resolution time well under an hour.\n\n- **Blast radius was contained to checkout.** The fault in the payments service did not cascade to degrade other services. Existing service boundaries and circuit behavior limited the failure domain.\n\n- **Cross-team communication was prompt.** The checkout team was notified within minutes of the alert, preventing them from pursuing a parallel investigation on their own service and keeping responders coordinated.\n\n---\n\n## Lessons Learned\n\n1. **Health checks that pass can still mean a service is broken.** A service returning 200 on `/health` is not the same as a service correctly processing real requests. Deployment gates should validate functional behavior — not just process liveness — especially for services in critical transaction paths.\n\n2. **Configuration changes carry the same risk as code changes and should be treated accordingly.** Environment variable changes are operationally equivalent in impact to code changes. Bundling them with code changes obscures their risk and reduces the visibility reviewers have into what is actually changing.\n\n3. **The blast radius of a misconfiguration is determined before the incident starts.** The choice not to use staged rollouts made a single bad configuration value a 100% user impact event instead of a limited one. Rollout strategy is a risk management decision that should be mandatory for high-criticality services.\n\n4. **Tight alert thresholds and fast synthetic probes disproportionately reduce customer impact.** The difference between a 6-minute and a 2-minute detection time, at the transaction volumes involved, likely represents hundreds of failed checkouts. Investment in detection speed on critical paths has a direct and quantifiable impact.\n\n5. **Runbooks should be written before the incident that needs them.** The response in this incident relied on experienced engineers reasoning through the problem in real time. A pre-existing runbook for post-deploy payment failures would have reduced investigation time and made the on-call rotation more resilient to less experienced responders being paged.\n\n---\n\n## Communication Log\n\n*Populate with actuals. Template entries below:*\n\n| Time (UTC) | Channel | Message Summary |\n|---|---|---|\n| [T+08:00] | Status page | \"We are investigating reports of errors during checkout. Payments may be affected.\" |\n| [T+20:00] | Status page | \"We have identified the cause and are implementing a fix. Estimated resolution within 15 minutes.\" |\n| [T+30:00] | Status page | \"Checkout has been restored. We are monitoring to confirm stability.\" |\n| [T+45:00] | Status page | \"This incident is resolved. A postmortem will be published at [link].\" |\n| [DATE] | Customer support | Template response issued to users who contacted support during the window — offer of [compensation policy if applicable]. |\n\n---\n\n## Quality Checks\n\n- [x] Timeline has no blame-focused language\n- [x] Root cause is specific — names the misconfigured environment variable and the deployment event, not \"human error\"\n- [x] Root cause answers \"why did this happen?\" — identifies system gaps (no config validation, no canary, inadequate smoke test) not just the symptom\n- [x] Contributing factors explain the systemic gaps that enabled the misconfiguration to reach production\n- [x] Every action item has an owner category and due date placeholder — assign named owners before publishing\n- [x] \"What went well\" section reflects genuine observations about response behavior\n- [x] No action item contains vague language — each names a specific, testable, ownable change\n- [x] Executive summary is readable by non-technical leadership"},{"skill":"meeting-notes","title":"Meeting Notes","input":"Transcript of a 30-min product/eng sync: debated whether to delay the checkout launch over a payments edge case; agreed to ship behind a flag to 10% on Thursday; Priya to write the rollback runbook; Sam worried about PCI scope; decided to ask Legal by Tuesday.","source":"representative example (hand-written)","output":"# Product / Eng Sync — Checkout Launch\n\n**Date:** (meeting date) · **Attendees:** Product, Eng, (Priya, Sam) · **Purpose:** Decide checkout launch timing\n\n## Decisions\n- ✅ **Ship checkout behind a feature flag to 10% of traffic on Thursday** — not a full launch, to contain the payments edge case.\n- ✅ **Confirm PCI scope with Legal before expanding past 10%.**\n\n## Action items\n| Owner | Action | Due |\n|-------|--------|-----|\n| Priya | Write the rollback runbook for the checkout flag | Before Thursday |\n| Sam | Document the payments edge case + PCI scope question for Legal | Mon |\n| (Lead) | Get Legal's read on PCI scope | Tue |\n\n## Open questions / risks\n- **PCI scope (Sam):** does the new checkout path widen our PCI compliance surface? Blocks expansion beyond 10%.\n- **Edge case:** the payments failure path isn't fully characterised — the 10% rollout is partly to observe it in production.\n\n## Not decided\n- Full-launch date — gated on the 10% results and Legal's answer."},{"skill":"metrics-framework","title":"Metrics Framework","input":"Define the metrics framework for a B2B analytics product: the north star, input metrics across acquisition/activation/retention/revenue, and guardrails. Stage: early growth, ~500 paying accounts.","source":"generated by claude-sonnet-4-6","output":"# Metrics Framework: B2B Analytics Product\n\n**Context:** Early growth stage, ~500 paying accounts, B2B SaaS analytics product.\n**Framework chosen:** North Star + Metric Tree\n**Why:** At 500 paying accounts you have enough signal to measure real customer value, but not enough scale to optimise channels independently. A North Star + Metric Tree keeps the whole company pointed at one outcome while giving each team (sales, product, CS) clear leading indicators to own. AARRR is too funnel-centric for a product where retention and expansion are the primary growth engine; OKRs alone lack the causal structure you need to diagnose what's breaking.\n\n---\n\n## 1. North Star Metric\n\n**Weekly Active Accounts Reaching an Insight Action**\n\n**Definition:** The number of paying accounts (not individual users) where at least one user, in a given week, completes an *insight action* — defined as any of: sharing a dashboard externally, exporting a report to a downstream tool, creating a saved alert, or presenting a chart in a meeting (tracked via our embed/share event). These are moments where the product has produced something the customer acts on, not just views.\n\n**Why this is the right North Star:**\nAn analytics product's core promise is not data access — it is decisions made faster or better. Tracking accounts that reach an insight action captures the moment the product delivers that promise: someone took the output and did something with it. This is harder to game than DAU or logins (which reward habit without value), and it correlates strongly with renewal because customers who regularly export, share, or alert on data have built the product into a workflow they won't easily abandon. At 500 accounts, growing this number means both activating dormant accounts and deepening usage in active ones.\n\n**Formula:**\n```\nWeekly Active Accounts (Insight Actions) =\n  COUNT DISTINCT(account_id WHERE insight_action_event >= 1 in rolling 7 days)\n```\n**Current baseline:** [ADD BASELINE]\n**Target:** [ADD TARGET]\n\n---\n\n## 2. Metric Tree\n\n```\nWeekly Active Accounts Reaching an Insight Action\n├── ACQUISITION: New Pipeline Into the Funnel\n│   ├── Qualified new accounts entering trial / week\n│   └── Trial-to-paid conversion rate (%)\n│\n├── ACTIVATION: Getting New Accounts to First Value\n│   ├── % of new accounts reaching first insight action within 14 days\n│   ├── Time to first insight action (median days, cohorted by signup week)\n│   └── Onboarding completion rate (% completing setup checklist)\n│\n├── RETENTION: Keeping Active Accounts Active\n│   ├── Month-1 account retention rate (% of activated accounts still active 30 days later)\n│   ├── 90-day account churn rate (rolling)\n│   └── Insight action frequency per account (median weekly actions, active accounts only)\n│\n└── REVENUE: Monetising and Expanding Value\n    ├── Net Revenue Retention (NRR) — rolling 12-month\n    ├── Expansion MRR from seat / tier upgrades ($/month)\n    └── Average Contract Value (ACV) by acquisition cohort\n```\n\n---\n\n### L2 Metric Definitions\n\n#### ACQUISITION\n\n**Qualified new accounts entering trial / week**\n- **Definition:** Count of new accounts starting a free trial or pilot that meet your ICP criteria (e.g. company size, industry, data source used) — not raw signups, which include noise.\n- **Why it matters:** Feeds the top of the funnel. Low-quality signups inflate conversion work without adding to the North Star; tracking *qualified* accounts ties acquisition to accounts likely to reach an insight action.\n- **Leading or lagging?** Leading — predicts future activated and paying accounts.\n- **How to measure:** CRM (HubSpot/Salesforce) trial start events filtered by ICP qualification score or SDR-confirmed fit tag.\n\n---\n\n**Trial-to-paid conversion rate (%)**\n- **Definition:** `Accounts converting to paid / Accounts starting trial` in a given cohort month. Measure at 30 and 60 days post-trial start.\n- **Why it matters:** Tells you whether the product is convincing people to pay. A rising North Star with a falling conversion rate means you're working harder to fill a leaking bucket.\n- **Leading or lagging?** Lagging (outcome of acquisition + activation quality), but leads revenue.\n- **How to measure:** Billing system (Stripe/Chargebee) paid event joined to trial start date in your data warehouse.\n\n---\n\n#### ACTIVATION\n\n**% of new accounts reaching first insight action within 14 days**\n- **Definition:** `Accounts with ≥1 insight action event in days 0–14 / All accounts that started onboarding in the same cohort`. 14 days is the activation window because analytics products typically require data connection, dashboard build, and a first \"aha\" — this rarely compresses below a week but should not take three.\n- **Why it matters:** This is the single strongest predictor of whether an account will still be active at day 90. If an account doesn't reach an insight action in the first two weeks, churn probability spikes sharply. Fix this metric and you fix retention downstream.\n- **Leading or lagging?** Leading — strongly predictive of 90-day retention and NRR.\n- **How to measure:** Product event log: `insight_action` event with `account_id`, joined to account `created_at`. Compute cohort weekly.\n\n---\n\n**Time to first insight action — median days (cohorted by signup week)**\n- **Definition:** Median number of calendar days between account `created_at` and first `insight_action` event, measured per signup cohort. Track P50 and P90 to catch tail distributions.\n- **Why it matters:** Even if 60% of accounts activate, a median time of 11 days vs. 4 days reflects a materially different onboarding experience. Faster time-to-value compresses the sales cycle's \"prove it\" phase and reduces early churn.\n- **Leading or lagging?** Leading.\n- **How to measure:** Same event log as above. `DATE_DIFF(first_insight_action_at, account_created_at)`. Track weekly cohort medians in a time-series chart.\n\n---\n\n**Onboarding completion rate (%)**\n- **Definition:** `Accounts completing all steps of the onboarding checklist / Accounts that started onboarding`. Steps should include: data source connected, first dashboard created, first team member invited, first alert set. Define the checklist explicitly in-product — this metric is only meaningful if the checklist reflects the actual path to value.\n- **Why it matters:** Diagnostic metric. When time-to-first-insight deteriorates, check here first. A drop in checklist completion means an onboarding step is breaking; stagnant checklist completion with slow insight time means the checklist itself isn't driving the right behaviour.\n- **Leading or lagging?** Leading.\n- **How to measure:** In-product step-completion events, tracked per account. Build a funnel view in your analytics tool (yes, eat your own cooking).\n\n---\n\n#### RETENTION\n\n**Month-1 account retention rate (%)**\n- **Definition:** `Accounts with ≥1 insight action in days 22–35 / Accounts with ≥1 insight action in days 1–14`. This is *activity-based* retention, not just \"not cancelled\" — an account that stops using the product before churning is already lost.\n- **Why it matters:** At 500 accounts, losing 10% in Month 1 is a structural problem that compounding makes catastrophic. This metric is the earliest possible read on whether activation led to a habit, not just curiosity.\n- **Leading or lagging?** Leading (predicts 90-day churn and NRR).\n- **How to measure:** Product event log with rolling cohort windows. Measure by account, not user.\n\n---\n\n**90-day account churn rate (rolling)**\n- **Definition:** `Accounts that cancelled or went inactive (zero insight actions for 30+ days) in the trailing 90 days / Average paying accounts in that period`. Track both hard cancellations and soft churn (paid but dormant — these accounts are at high risk and represent recoverable revenue).\n- **Why it matters:** This is your core retention health signal. At early growth stage, a churn rate above ~2–3% monthly compresses your growth ceiling to the point where acquisition can't outrun it. Separate hard from soft churn — they have different interventions.\n- **Leading or lagging?** Lagging — it records what already happened.\n- **How to measure:** Billing system cancellation events + product event log for soft churn detection. Report monthly, trend quarterly.\n\n---\n\n**Insight action frequency per account — median weekly actions (active accounts only)**\n- **Definition:** Among accounts that had ≥1 insight action in the past 30 days, the median number of insight actions per week. Exclude newly onboarded accounts (< 30 days old) to avoid distortion.\n- **Why it matters:** Frequency signals depth of workflow integration. An account doing one insight action per month is at risk; one doing five per week has built the product into a recurring process. This metric moves before NRR does and identifies expansion candidates.\n- **Leading or lagging?** Leading (predicts expansion and renewal).\n- **How to measure:** Product event log, aggregated to account-week level. Compute rolling median over active account cohort.\n\n---\n\n#### REVENUE\n\n**Net Revenue Retention — NRR (rolling 12-month)**\n- **Definition:** `(Starting MRR + Expansion MRR - Contraction MRR - Churned MRR) / Starting MRR` for the same account cohort over 12 months. Expressed as a percentage. A B2B analytics product at growth stage should be targeting ≥110% NRR.\n- **Why it matters:** NRR is the compounding engine of B2B SaaS. Above 100% means your existing base grows even with zero new sales. Below 100% means you're on a treadmill. At 500 accounts, NRR is more important than new logo growth because expansion from proven accounts costs a fraction of acquiring new ones.\n- **Leading or lagging?** Lagging — it is the revenue outcome of retention and expansion behaviour.\n- **How to measure:** Billing system (Stripe/Chargebee MRR movements by account, tagged as expansion/contraction/churn). Compute monthly, trend as a rolling 12-month cohort.\n\n---\n\n**Expansion MRR from seat / tier upgrades ($/month)**\n- **Definition:** Monthly recurring revenue added from existing paying accounts upgrading their plan, adding seats, or unlocking add-ons. Excludes new logo revenue.\n- **Why it matters:** At early growth stage with 500 accounts, expansion MRR is both more capital-efficient than new acquisition and a signal that accounts are getting more value over time (they wouldn't pay more otherwise). Track separately from new logo MRR to understand the true growth mix.\n- **Leading or lagging?** Lagging (records the upgrade event), but leads NRR.\n- **How to measure:** Billing system, upgrade events tagged by account. `SUM(new_plan_mrr - old_plan_mrr WHERE upgrade_event IN month)`.\n\n---\n\n**Average Contract Value — ACV by acquisition cohort**\n- **Definition:** Total annual contract value divided by number of accounts, segmented by the quarter the account was acquired. Track how ACV trends across cohorts.\n- **Why it matters:** Rising ACV across cohorts means you're moving upmarket or improving sales qualification. Falling ACV means you're backfilling churn with smaller, riskier accounts. At 500 accounts this is easy to miss in aggregate but visible by cohort.\n- **Leading or lagging?** Lagging.\n- **How to measure:** CRM contract value fields, grouped by account `closed_won_date` cohort quarter.\n\n---\n\n## 3. Counter-Metrics (Guardrails)\n\nThese three metrics exist to ensure you don't optimise the North Star in ways that quietly damage the business.\n\n**1. Support ticket volume per active account (weekly)**\nIf you optimise for insight action frequency by making exports or alerts easier to trigger, you may inadvertently create confusion (users firing alerts they don't understand, or exporting malformed data). A rising support ticket rate alongside a rising North Star is a warning sign that product quality is being sacrificed for engagement. Target: flat or declining as the account base grows.\n\n**2. Trial-to-paid conversion rate vs. activation rate gap**\nTrack whether your 14-day activation rate and your trial-to-paid conversion rate move together. If activation rises but conversion stays flat, your sales process or pricing is misaligned with the value customers are experiencing — they're getting value but not paying for it. If conversion rises but activation falls, you may be using sales pressure to close accounts that aren't genuinely ready, loading your churn pipeline.\n\n**3. Percentage of NRR from more than three accounts**\nAt 500 accounts, NRR can look healthy while being dangerously concentrated. If three accounts represent >30% of expansion MRR, your NRR metric is masking fragility. Track concentration monthly and flag any single account >10% of expansion MRR for executive review. This is especially critical before a Series A, where investors will stress-test customer concentration.\n\n---\n\n## 4. Dashboard Recommendation\n\n### Exec View — Weekly (5 metrics)\n| Metric | Why here |\n|---|---|\n| Weekly Active Accounts (Insight Actions) | The North Star — top of every review |\n| 90-day rolling account churn rate | Retention health at a glance |\n| Net Revenue Retention (trailing 12-month) | Business compounding signal |\n| New qualified trials entered this week | Leading acquisition signal |\n| Expansion MRR this month vs. last | Revenue momentum |\n\n### Team View — Daily (9 metrics)\n*For product, CS, and growth teams:*\n| Metric | Owner |\n|---|---|\n| % new accounts reaching first insight action (14-day window, current cohort) | Product / Onboarding |\n| Time to first insight action — P50 and P90 | Product |\n| Onboarding checklist completion rate | Product / CS |\n| Month-1 account retention (most recent completed cohort) | CS |\n| Insight action frequency per account (active accounts) | Product |\n| Qualified trials started this week | Growth / Sales |\n| Trial-to-paid conversion rate (30-day cohort) | Sales / Growth |\n| Support tickets per active account | CS / Product |\n| Soft churn accounts (active 30+ days ago, zero actions last 14 days) | CS |\n\n### Diagnostic View — On Demand\n*Pull these when a top-level metric moves unexpectedly:*\n- Insight action breakdown by action type (export vs. share vs. alert vs. embed) — tells you *which* value moment is driving or declining\n- Activation funnel by onboarding step (where do accounts drop out of the checklist?)\n- Churn cohort analysis by acquisition channel and ICP segment\n- Feature adoption depth map (which dashboard features correlate with retained accounts?)\n- Account health score distribution (a composite of recency, frequency, and depth of insight actions — build this before you need it)\n\n---\n\n## 5. Weekly Metrics Review — Health Check Questions\n\nUse these five questions to turn numbers into decisions in your weekly review:\n\n**1. Is our 14-day activation rate moving in the same direction as time-to-first-insight?**\nIf activation rate rises but time-to-first-insight also rises, you may be counting a lower-quality action as an insight event — or onboarding is slower but more accounts are eventually getting there. Investigate the *type* of insight action driving the change.\n\n**2. Are accounts that activated via a specific onboarding step retaining at a higher rate?**\nCompare Month-1 retention for accounts that completed the full checklist vs. partial completions. If \"first alert set\" correlates with dramatically higher retention, that step is your real activation moment — consider forcing it earlier in onboarding.\n\n**3. Is soft churn rising even while hard churn holds flat?**\nSoft churn (paid but dormant) is the canary. If you see accounts going quiet 60–90 days before cancellation, you have a CS intervention window you're not using. A rising soft churn count is a leading indicator of a churn spike in the next quarter.\n\n**4. Is expansion MRR coming from accounts with high insight action frequency, or from accounts that are being upsold regardless of usage?**\nExpansion driven by high-frequency accounts is durable — those customers are paying more because they're getting more value. Expansion from low-frequency accounts is fragile — it often reverses at renewal. Segment expansion MRR by account activity level monthly.\n\n**5. Is our NRR concentration increasing or decreasing?**\nTrack what share of total NRR (retention + expansion) comes from your top 10 accounts. At 500 accounts this should be gradually diversifying. If it's concentrating, your CS team may be over-investing in whales while mid-market accounts quietly churn — which also distorts every other metric in this framework.\n\n---\n\n## Quality Check\n\n- [x] North Star reflects customer value delivered (decisions acted on), not activity or revenue\n- [x] Metric tree covers 4 distinct drivers: Acquisition, Activation,"},{"skill":"okr-builder","title":"Okr Builder","input":"Company objective: become the default analytics tool for startups. For the product team, next quarter. We care about activation, retention, and word-of-mouth growth.","source":"generated by claude-sonnet-4-6","output":"### Q2 2025 OKRs — Product Team\n\n*North Star assumed from context: Startups that reach \"activated\" status and stay retained long enough to refer others. All OKRs ladder to becoming the default analytics tool for startups.*\n\n---\n\n**Objective 1: Make the first hour with our product undeniably valuable for every new startup**\n\n*Why this matters:* Startups evaluate tools fast and ruthlessly. If we don't deliver a clear \"aha moment\" in the first session, we lose them before retention is even possible — and word-of-mouth never starts.\n\n| # | Key Result | Baseline | Target | Measurement Method |\n|---|---|---|---|---|\n| KR1 | New user activation rate (reaching \"aha moment\" milestone) increases | Baseline needed ⚠️ | +25pp above baseline | Product analytics event tracking |\n| KR2 | Percentage of new signups who complete a meaningful analysis within their first session | Baseline needed ⚠️ | 55% of new signups | Session-level event funnel |\n| KR3 | Time-to-first-insight for new users decreases | Baseline needed ⚠️ | Reduce by 40% | Median time from signup to first chart/report event |\n\n*Owner:* Head of Product / Onboarding Squad\n*Check-in cadence:* Weekly\n\n---\n\n**Objective 2: Turn activated users into loyal, long-term users who build workflows around us**\n\n*Why this matters:* Activation without retention is a leaky bucket. For startups to call us their \"default\" tool, using us needs to become habitual — not occasional.\n\n| # | Key Result | Baseline | Target | Measurement Method |\n|---|---|---|---|---|\n| KR1 | 30-day retention for activated users increases | Baseline needed ⚠️ | 45% 30-day retention | Cohort retention report |\n| KR2 | Weekly active usage rate among retained users (using product 3+ days/week) increases | Baseline needed ⚠️ | 35% of retained users | DAU/WAU ratio in product analytics |\n| KR3 | Involuntary churn due to friction (support-flagged product issues) decreases | Baseline needed ⚠️ | Reduce by 30% | Support ticket tagging + churn reason attribution |\n\n*Owner:* Head of Product / Retention Squad\n*Check-in cadence:* Weekly\n\n---\n\n**Objective 3: Make our users the engine of our growth in the startup ecosystem**\n\n*Why this matters:* The fastest path to becoming the default analytics tool for startups is peer recommendation — founders trust other founders more than any marketing channel. We need to engineer the conditions for word-of-mouth, not hope it happens.\n\n| # | Key Result | Baseline | Target | Measurement Method |\n|---|---|---|---|---|\n| KR1 | Net Promoter Score among activated startup users increases | Baseline needed ⚠️ | NPS reaches 45+ | Quarterly NPS survey (Delighted or equivalent) |\n| KR2 | Percentage of new signups attributing discovery to peer referral or word-of-mouth increases | Baseline needed ⚠️ | 30% of new signups | Attribution survey at signup |\n| KR3 | Number of startups that share a public link, embed, or export created from our product | Baseline needed ⚠️ | 20% of activated users share at least once | Share/export event tracking |\n\n*Owner:* Head of Product / Growth Squad\n*Check-in cadence:* Weekly\n\n---\n\n## ⚠️ Health Check — Baseline Data Gaps\n\nEvery KR above is flagged because **no baselines were provided**. Before this OKR set is finalized, the team must pull current-state numbers for each metric. OKRs without baselines cannot be scored at quarter end.\n\n**Recommended action before Q2 kickoff:**\n\n| KR | Data Source to Pull Baseline From |\n|---|---|\n| Activation rate | Product analytics (Mixpanel, Amplitude, or equivalent) |\n| First-session analysis completion | Event funnel in product analytics tool |\n| Time-to-first-insight | Median time between signup event and first output event |\n| 30-day retention | Cohort table in product analytics |\n| Weekly active usage rate | DAU/WAU calculation |\n| Involuntary churn (friction) | Support ticket audit, last 60 days |\n| NPS | Run a one-time survey this week if no historical data exists |\n| Word-of-mouth attribution | Add attribution question to signup flow immediately |\n| Public share rate | Instrument share/export events if not already tracked |\n\n---\n\n## Anti-Pattern Audit\n\nBefore submitting these OKRs, confirm none of the following slipped through:\n\n- [x] **No output-based KRs** — none of these say \"launch X\" or \"ship Y\"\n- [x] **No binary KRs** — every KR is scorable on a 0.0–1.0 scale\n- [x] **No vanity metrics** — downloads, pageviews, and raw signups intentionally excluded\n- [x] **Baselines flagged** — all gaps explicitly called out above\n- [x] **Max 3 KRs per objective** — all objectives within limit\n- [x] **Connected to North Star** — all three objectives ladder to \"default analytics tool for startups\"\n\n---\n\n## Scoring Guide\n\nAt the end of Q2, score each KR from 0.0 to 1.0:\n\n| Score | Meaning |\n|---|---|\n| **0.7–1.0** | Excellent. 0.7 is the sweet spot — if every KR scores 1.0, targets weren't ambitious enough |\n| **0.4–0.6** | Progress made, but missed the target — understand why |\n| **0.0–0.3** | Missed — hold a retrospective before setting Q3 OKRs |\n\n> **Reminder:** These OKRs are not a performance review. A team that scores 0.7 across the board has had a great quarter. Hitting 1.0 on everything means next quarter's targets need to be harder."},{"skill":"prd-template","title":"PRD Template","input":"Feature: in-app referral program so existing users invite colleagues and both get a credit. Target: activated B2B users. Goal: grow signups 15% in Q3.","source":"representative example (hand-written)","output":"# PRD — In-App Referral Program\n\n**Status:** Draft · **Owner:** PM · **Target release:** Q3\n\n## Problem\nActivated B2B users are our happiest segment, but we have no built-in way for them to bring colleagues in. Word-of-mouth happens off-platform and we capture none of it. Signup growth is flat at ~5%/qtr through paid channels alone.\n\n## Goals\n- Grow new signups **+15% in Q3** via referrals.\n- Referral signups activate at **≥ the current baseline** (don't trade quality for volume).\n\n## Non-goals\n- Public/affiliate program for non-customers (separate effort).\n- Cash payouts — credits only, this release.\n\n## User stories\n- *As an activated user,* I can invite a colleague by email or shareable link and see the reward I'll get.\n- *As an invited colleague,* I land on a page that explains the credit and makes signup one click.\n- *As a referrer,* I can see the status of my invites (sent / joined / credited).\n\n## Functional requirements\n1. Generate a unique referral link per user.\n2. Both referrer and referee receive a **$X account credit** when the referee activates (not just signs up).\n3. Referral dashboard: invites sent, joined, credit earned.\n4. Fraud guardrail: credit only on activation + payment-method-on-file.\n\n## Success metrics\n| Metric | Baseline | Target |\n|--------|:--------:|:------:|\n| New signups from referrals | 0 | 15% of total Q3 signups |\n| Referral → activation rate | — | ≥ overall baseline |\n| Referrals sent per active user | — | ≥ 0.3 |\n\n## Open questions\n- Credit amount — what's the payback period at our LTV? (needs Finance)\n- Does \"activation\" or \"first payment\" trigger the credit? (affects fraud + cost)\n- Self-serve only, or also sales-assisted accounts?"},{"skill":"rice-prioritisation","title":"RICE Prioritisation","input":"Rank for next quarter: 1) Onboarding redesign — ~5000 users/qtr, big activation impact, ~3 person-months. 2) Dark mode — ~8000 users want it, low impact, ~1 person-month. 3) SSO for enterprise — ~400 accounts, high deal impact, ~4 person-months, low confidence.","source":"representative example (hand-written)","output":"# RICE Prioritisation — Next Quarter\n\nRICE = (Reach × Impact × Confidence) ÷ Effort. Impact scale: 3 = massive, 2 = high, 1 = medium, 0.5 = low.\n\n| # | Initiative | Reach (/qtr) | Impact | Confidence | Effort (PM) | **RICE** | Rank |\n|---|------------|:-----------:|:------:|:----------:|:-----------:|:--------:|:----:|\n| 1 | Onboarding redesign | 5,000 | 3 | 90% | 3 | **4,500** | 🥇 1 |\n| 3 | SSO for enterprise | 400 | 3 | 50% | 4 | **150** | 🥈 2 |\n| 2 | Dark mode | 8,000 | 0.5 | 100% | 1 | **4,000**? | — |\n\n> ⚠️ Dark mode's raw score (4,000) looks high purely from reach. The low impact (0.5) is doing the real work — it's a satisfaction nicety, not a needle-mover. Flag for a \"quick win\" lane, not the strategic backlog.\n\n## Recommendation\n1. **Onboarding redesign** — clear top priority: high reach, massive impact, well understood (90% confidence).\n2. **SSO** — high deal impact but the score is dragged down by low confidence and high effort. **De-risk first**: validate the enterprise pipeline ($ tied to SSO) before committing 4 person-months.\n3. **Dark mode** — ship it as a low-cost quick win between larger projects; don't let its reach inflate its priority.\n\n**Watch-out:** the SSO confidence is the swing factor. A week of sales discovery could move it from 50% → 80% and change the ranking."},{"skill":"roadmap-narrative","title":"Roadmap Narrative","input":"H2 roadmap for a B2B analytics product. Themes: self-serve onboarding, an integrations marketplace, and enterprise SSO/audit logs. Audience: the exec team and key customers. We want the story, not a feature list.","source":"generated by claude-sonnet-4-6","output":"# Product Roadmap: H2 2025\n\n---\n\n**Strategic Context:**\nThe B2B analytics market is consolidating around platforms that win on time-to-value, not feature count. Buyers are making decisions faster, involving fewer specialist resources, and expecting enterprise-grade security as a baseline rather than a premium. Our H2 roadmap responds to this directly: we are removing every friction point that slows a new customer from experiencing value, building the ecosystem connectivity that makes us indispensable to their existing stack, and closing the enterprise compliance requirements that are currently blocking deals from closing. These three bets are not independent — they compound. A customer who onboards in an hour, connects their existing tools in a day, and clears their security review without a custom procurement cycle is a customer who expands.\n\n---\n\n## Theme 1: The First Hour Matters More Than the First Month\n\n**Strategic Rationale:**\nRight now, a new customer's first experience with the product is mediated by us — by onboarding calls, setup guides, and human handholding. That's expensive for us and slow for them. The customers most likely to become long-term, high-value accounts are the ones who reach their first meaningful insight quickly and independently. Every day of delay between signup and \"aha moment\" is churn risk we're creating ourselves. This theme is about getting out of the customer's way.\n\n**Initiatives:**\n- Guided, in-product onboarding flow with milestone-based progression\n- Pre-built dashboard templates by industry and use case\n- Interactive product tour for first-time users (no sales touch required)\n- Contextual in-app help and empty-state guidance\n\n**Primary Metric Impacted:**\nTime-to-first-insight (target: reduce from current baseline to under 60 minutes for self-serve accounts). Secondary: free-to-paid conversion rate.\n\n**Progression Link to H2:**\nThis work ships early in Q3. It is a prerequisite for Theme 2 — an integrations marketplace only delivers value to customers who are already active in the product. We cannot drive integration adoption against a leaky onboarding funnel.\n\n**Dependencies:**\nCustomer data infrastructure to support template personalisation by vertical. Alignment with Marketing on top 5 use-case categories to template first.\n\n---\n\n## Theme 2: Your Stack, Not a Replacement for It\n\n**Strategic Rationale:**\nNo analytics product wins by asking customers to abandon their existing tools. The companies we want to own — mid-market and enterprise — run on Salesforce, HubSpot, Snowflake, Databricks, and a dozen others. If connecting our product to those systems requires an engineer and a two-week project, we are selling to the wrong buyer and creating a fragile deployment. An integrations marketplace shifts our position from \"analytics tool\" to \"analytics layer\" — the connective tissue across the customer's data ecosystem. This is the difference between a product customers use and infrastructure customers depend on.\n\n**Initiatives:**\n- Self-serve integrations marketplace (launch with 15 native connectors, prioritised by customer demand)\n- Partner-built integration framework with documentation and certification\n- Integration health monitoring and alerting (customers know when data stops flowing before we tell them)\n- Usage-based integration analytics surfaced to customers (so they see ROI from connectivity)\n\n**Primary Metric Impacted:**\nIntegrations per account (target: 2+ integrations per active account by end of H2). Predictive indicator for net revenue retention.\n\n**Progression Link to H2:**\nThis theme runs through Q3 and into Q4. The partner-built framework is a Q4 deliverable — it requires the native connector infrastructure to exist first. By Q4, we want external partners building on this platform, not just us shipping to it.\n\n**Dependencies:**\nPartnership agreements with top-5 integration targets before build begins. Engineering capacity sequenced after onboarding flow ships — these two themes cannot run in parallel at full velocity.\n\n---\n\n## Theme 3: Enterprise Deals Should Not Die in Legal\n\n**Strategic Rationale:**\nWe are losing enterprise deals — or delaying them by quarters — not because we lose on product capability, but because we cannot pass the security review. SSO, audit logs, and role-based access are not differentiators in enterprise software; they are the price of admission. Every month we ship without them is a month the enterprise segment of our pipeline is effectively frozen. This theme is about unlocking a revenue category that is already warming up to us — and removing the last objection that procurement teams are trained to find.\n\n**Initiatives:**\n- SAML/OIDC Single Sign-On with major identity providers (Okta, Azure AD, Google Workspace)\n- Immutable audit logs with admin export and configurable retention\n- Role-based access control granularity (read, edit, admin, custom roles)\n- Security documentation and trust portal (self-serve for customer IT and legal teams)\n\n**Primary Metric Impacted:**\nEnterprise deal cycle length (target: reduce average security review delay by 50%). Direct impact on enterprise pipeline conversion and ACV.\n\n**Progression Link to H2:**\nThis is a Q4-weighted theme. The business case for prioritising it after onboarding and integrations is deliberate: SSO and audit logs serve customers who are already deciding to buy. The onboarding and marketplace work serves customers earlier in their journey. We are sequencing for maximum H2 impact — convert the pipeline we already have while building the funnel for H1 2026.\n\n**Dependencies:**\nLegal and security team sign-off on audit log architecture before build. Coordination with Sales to identify the 10 enterprise prospects whose deals will accelerate immediately upon release — these are our launch reference customers.\n\n---\n\n## What's Not on the Roadmap — and Why\n\n**Advanced AI/ML Features:**\nEvery competitor is announcing AI capabilities right now. We have deliberately kept AI features out of H2, not because the opportunity is wrong, but because it is the wrong moment for us. We are not yet in a position where customers are extracting full value from the data they already have in the product. Shipping AI-powered insights to customers who haven't completed basic onboarding is noise, not value. We will revisit this as a Q1 2026 theme, once the self-serve foundation is in place and we have meaningful usage data to build against.\n\n**Mobile Application:**\nMobile analytics has genuine demand signals in our customer base. It is not on the roadmap because it is a significant engineering investment that does not accelerate any of our three strategic themes. It serves an adjacent workflow without deepening the core use case. This is a parking lot item, not a rejection — we want to understand the use case more precisely before committing.\n\n**Custom Reporting Builder:**\nA flexible, open-ended report builder appears repeatedly in customer feedback. We are consciously choosing not to build it in H2. The pre-built templates in Theme 1 will serve 80% of the stated need for the customer segments we are growing. A custom builder before we understand which templates customers actually use would be building the wrong thing at significant cost. Template adoption data from Q3 will inform whether and how we scope this in 2026.\n\n---\n\n## Executive Summary\n\n*Shareable for all-hands, board updates, and key customer conversations.*\n\n> In H2, we are making three bets that compound. First, we are making it possible for any new customer to reach their first real insight in under an hour — without a call, without a guide, without us. Second, we are becoming the analytics layer that connects to the tools customers already depend on, starting with 15 native integrations and a platform for partners to build on. Third, we are removing the last objection that blocks enterprise deals — SSO and audit logs — so that security reviews become a formality rather than a graveyard. Taken together, these are not three separate features — they are one strategy: make it easier to start, impossible to leave, and safe to buy at any scale.\n\n---\n\n*Quality note for internal use: Every initiative above maps to one of three themes. No orphaned items. The \"What's Not on the Roadmap\" section includes rationale rooted in strategic sequencing, not resource constraints alone. The executive summary is written to be repeated accurately after a single reading — test it by reading it once and asking a colleague to play it back.*"},{"skill":"sprint-planning","title":"Sprint Planning","input":"Team of 5, 2-week sprint, average velocity 30 points, one engineer out 3 days. Backlog: checkout redesign (8), payment retries (5), analytics events (3), bug bash (3), API rate limiting (5).","source":"generated by claude-sonnet-4-6","output":"# Sprint 14 — 2-Week Planning Output\n\n---\n\n## Step 1: Capacity Calculation\n\nRunning the capacity model before touching the backlog.\n\n```\nTeam:               5 engineers\nSprint days:        10 (2 weeks)\nFocus hours/day:    6\nOne engineer out:   3 days → 3 lost focus-days\n\nTotal theoretical focus-days:  5 × 10 = 50\nAdjusted focus-days:           50 − 3 = 47\nAvailability factor:           47 ÷ 50 = 0.94 → capped at 0.85 (meetings, admin, Slack)\n\nVelocity-adjusted capacity:    30 × 0.85 = 25.5 → 26 points available\nRecommended commitment (80%):  26 × 0.80 = ~21 points\n\nNo carry-overs reported → full 21 points available for new work.\n```\n\n> **Equivalent CLI call:**\n> ```bash\n> python3 scripts/capacity_calculator.py \\\n>   --team 5 --days 10 --velocity 30 \\\n>   --availability 0.85 --carryover 0\n> # → Available: 26 pts | Recommended commit: 21 pts | Capacity for new work: 21 pts\n> ```\n\n---\n\n## Step 2: Backlog Review & Story Assessment\n\n| Story | Raw Est. | Flag | Decision |\n|---|---|---|---|\n| Checkout redesign | 8 | ⚠️ **Must split** — 8 pts, high uncertainty | Split below |\n| Payment retries | 5 | ✅ Ready | Include |\n| API rate limiting | 5 | ✅ Ready | Include |\n| Analytics events | 3 | ✅ Ready | Include |\n| Bug bash | 3 | ✅ Ready | Include |\n\n**Checkout redesign (8) — mandatory split before committing:**\n\n| Sub-story | Points | Rationale |\n|---|---|---|\n| Checkout redesign — layout & routing | 3 | New page structure, no logic changes |\n| Checkout redesign — form validation & error states | 3 | Client-side logic, known patterns |\n| Checkout redesign — integration with order service | 5 | API contract changes, needs design sign-off |\n\n> The integration slice (5 pts) carries dependency risk — see Risks section. Pull it only if the API contract is confirmed before sprint start; otherwise defer to Sprint 15.\n\n---\n\n## Sprint 14 — 3 June to 14 June 2025\n\n---\n\n**Sprint Goal:**\n> \"This sprint we will deliver a reliable, polished checkout and payment experience so that users can complete purchases without hitting dead ends, measured by zero payment-retry silent failures in production and checkout task-completion rate ≥ 90% in usability smoke test.\"\n\n---\n\n**Team Capacity:** 21 story points committed (26 available, 80% rule applied; 5-person team at 85% availability)\n\n---\n\n### Sprint Backlog\n\n| Priority | Story | Points | Owner | Acceptance Criteria |\n|---|---|---|---|---|\n| 1 | Checkout redesign — layout & routing | 3 | TBD | Given a logged-in user, when they initiate checkout, then they land on the redesigned page with correct route and no regression on existing order flow |\n| 2 | Checkout redesign — form validation & error states | 3 | TBD | Given invalid input, when the user submits, then inline errors appear per field without page reload; given valid input, no false errors shown |\n| 3 | Payment retries | 5 | TBD | Given a failed payment attempt, when the system retries, then it does so up to 3 times with exponential backoff; failed retries are logged with error code; user sees accurate status message |\n| 4 | Analytics events | 3 | TBD | Given a user completes any checkout step, when the step fires, then the correct event name, user ID, and timestamp appear in the analytics pipeline within 30 seconds; no duplicate events |\n| 5 | Bug bash | 3 | Whole team | Given the bug bash session (Day 8), when complete, then all P1 bugs discovered are filed with repro steps; at least 50% of P2s have owners assigned |\n| — | API rate limiting | 5 | **Deferred to Sprint 15** | See rationale below |\n| — | Checkout redesign — integration with order service | 5 | **Deferred to Sprint 15** | Blocked on API contract confirmation |\n\n**Committed total: 17 points**\n*(Intentionally under the 21-point ceiling — see rationale below)*\n\n---\n\n### Carry-Overs from Previous Sprint\n\nNone reported. ✅ Clean slate — full recommended capacity applied to new work.\n\n---\n\n### Capacity Rationale & Deferred Items\n\n**Why only 17 of 21 points committed:**\nThe two deferred items (API rate limiting — 5 pts, checkout integration — 5 pts) together total 10 pts and both carry pre-conditions that aren't confirmed yet. Pulling them in speculatively would risk the sprint goal. The 4-point buffer below the 21-point ceiling absorbs:\n- Unplanned bug fixes surfacing from the bug bash\n- The absent engineer's knowledge areas (if they own context on payment systems)\n- Any scope creep on the checkout layout work\n\nIf blockers resolve by **Day 2**, API rate limiting can be pulled in from the backlog to fill the buffer.\n\n---\n\n### Risks & Dependencies\n\n| # | Risk | Severity | Mitigation |\n|---|---|---|---|\n| 1 | Checkout integration slice depends on confirmed API contract with order service | 🔴 High | Confirm contract with order service team **before Day 1**. If not confirmed by EOD Day 1, defer entire integration slice to Sprint 15. |\n| 2 | Engineer absent 3 days — if they own payment systems context, retry logic is at risk | 🟡 Medium | Assign payment retries story to a different engineer now; schedule 30-min knowledge handoff before absence starts. |\n| 3 | Bug bash (Day 8) may surface P1 issues requiring immediate sprint work | 🟡 Medium | Reserve the 4-pt buffer explicitly for bug bash fallout. Do not commit buffer to new stories before Day 8. |\n| 4 | Analytics events story has no confirmed data-pipeline owner outside the team | 🟡 Medium | Identify pipeline contact on Day 1; confirm event schema is agreed before story is picked up. |\n| 5 | Two 5-point stories deferred — if Sprint 15 also has high load, rate limiting may slip a second time | 🟢 Low | Flag both deferred items to Product as Sprint 15 P1 carry-ins now, not after this sprint closes. |\n\n---\n\n### Stories Flagged for Missing Acceptance Criteria\n\nAll five committed stories have acceptance criteria defined above. ✅\n\n> If any AC above was written without Product Owner confirmation, **treat it as a draft** and validate during the planning meeting — do not carry a story into the sprint on assumed criteria.\n\n---\n\n## Sprint Planning Agenda — Day 1, 09:00–11:00\n\n| Time | Block | Owner | Notes |\n|---|---|---|---|\n| 09:00–09:10 | Open: sprint goal read-aloud, capacity recap | Scrum Master | Confirm 17-pt commitment, name the 4-pt buffer explicitly |\n| 09:10–09:25 | Risk walk-through | Scrum Master | Resolve Risk #1 (API contract) live if possible — go/no-go on checkout integration |\n| 09:25–09:55 | Backlog walk — committed stories | Product Owner | Each story read aloud; team confirms AC or flags changes |\n| 09:55–10:25 | Estimation confirmation & story splitting | Whole team | Validate checkout sub-stories; challenge any estimate that's changed since grooming |\n| 10:25–10:50 | Ownership assignment | Whole team | Every story gets a named owner; absent engineer's stories reassigned |\n| 10:50–10:58 | Buffer & deferred item decision | Product Owner + Tech Lead | Confirm API rate limiting pull-in criteria; set Day 2 deadline for decision |\n| 10:58–11:00 | Commit & close | Scrum Master | Read sprint goal aloud one final time; team verbal confirmation |\n\n---\n\n## Quality Checklist\n\n- [x] Sprint goal is outcome-focused and pass/fail scoreable at sprint end\n- [x] Capacity uses 85% availability factor, not theoretical 100%\n- [x] 80% commit rule applied (17 of 21 recommended points committed)\n- [x] Every committed story has an acceptance criterion\n- [x] 8-point story split before entering sprint\n- [x] No carry-overs from previous sprint — accounted for in capacity\n- [x] Absent engineer's impact modelled in availability factor and risk log\n- [x] Deferred items flagged to Product as Sprint 15 pre-loads"},{"skill":"stakeholder-update","title":"Stakeholder Update","input":"Weekly update for sales, support, and exec stakeholders on the checkout revamp. Status: 10% rollout live, conversion +4%, one payments edge case under investigation, full launch gated on a Legal PCI review due Tuesday.","source":"generated by claude-sonnet-4-6","output":"# Product Update: Checkout Revamp\n**Week of [Current Week]**\n\n---\n\n## BLUF\n**Status**: 🟡 At Risk\n**Key Takeaway**: Checkout revamp is live at 10% traffic with early conversion gains (+4%), but full launch is gated on a Legal PCI review due Tuesday and one payments edge case under active investigation.\n**Action Needed**: Legal to confirm PCI review timeline by Tuesday EOD; Support leads to review edge case escalation path below.\n\n---\n\n## Progress Summary\n- Launched checkout revamp to 10% of traffic — rollout is stable with no incidents\n- Conversion rate up +4% in early data vs. control group\n- Identified one payments edge case (see Risks); investigation underway with no customer impact confirmed yet\n- Full launch hold in place pending Legal PCI compliance sign-off\n\n---\n\n## Key Metrics\n| Metric | Current | Target | Trend | Status |\n|--------|---------|--------|-------|--------|\n| Rollout Coverage | 10% | 100% | → | 🟡 |\n| Conversion Rate (new flow) | +4% vs. control | +5% | ↑ | 🟢 |\n| Payments Edge Case Incidents | Under investigation | 0 | — | 🟡 |\n| PCI Review Status | In review | Approved by Tue | → | 🟡 |\n\n---\n\n## Risks & Blockers\n\n**HIGH: PCI Compliance Review (Legal Gate)**\n- **Impact**: Full launch cannot proceed until Legal signs off; delays 100% rollout beyond Tuesday if review slips\n- **Mitigation**: Review is scheduled and in progress; Product is on standby to address any findings immediately\n- **Help Needed**: **Legal stakeholders** — please confirm Tuesday EOD as the firm completion date, or flag if timeline is at risk by Monday so the team can adjust launch planning\n\n**MEDIUM: Payments Edge Case Under Investigation**\n- **Impact**: Specific scenario in the payments flow is producing unexpected behavior; scope and customer impact not yet confirmed\n- **Mitigation**: Engineering is actively investigating; rollout held at 10% as a precaution; no customer-facing errors or failed transactions confirmed to date\n- **Help Needed**: **Support leads** — if you receive any customer complaints related to checkout errors or payment failures this week, escalate to [PM/Engineering contact] immediately rather than routing through standard queue\n\n---\n\n## Upcoming Milestones\n\n**Next 30 Days:**\n- PCI review complete (Tuesday, [date])\n- Payments edge case resolved (targeting this week)\n- Full 100% rollout (targeting end of week, contingent on above)\n- First full-week conversion data at scale (following week)\n\n**Next 90 Days:**\n- Post-launch iteration based on production data\n- Conversion optimization pass based on full-traffic learnings\n- Evaluate checkout improvements for mobile app\n\n---\n\n## What Each Team Should Know\n\n**Sales**: Early conversion data is encouraging (+4%) — this is directionally positive for pipeline-to-close metrics, though it's too early to quote confidently. Hold on using checkout performance in customer conversations until we're at full rollout.\n\n**Support**: One payments edge case is under investigation. Watch for any customer-reported checkout or payment errors and escalate immediately (do not hold for standard ticket review). We'll send a separate escalation guide by EOD today.\n\n**Exec**: We're on track for full launch this week if Legal clears PCI by Tuesday and the engineering investigation closes cleanly. If either slips, expect a 3–5 day delay to launch. No decision is needed today — Monday will be the go/no-go checkpoint.\n\n---\n\n**Questions?** Reply here or ping [PM name] directly on Slack.\n**Next update**: Monday go/no-go decision summary."},{"skill":"user-story-writer","title":"User Story Writer","input":"Feature: let users export a dashboard to PDF and schedule a recurring email of it. Users are analysts and their managers. Keep stories small and testable with clear acceptance criteria.","source":"generated by claude-sonnet-4-6","output":"# Epic Decomposition: Dashboard Export & Scheduled Email\n\n**Epic:** Dashboard Distribution\n**Goal:** Enable analysts and managers to export dashboards as PDFs and automate recurring email delivery, reducing manual reporting overhead.\n\n---\n\n## Story Map\n\n| # | Story | Priority | Dependencies |\n|---|---|---|---|\n| 1 | Export current dashboard view as PDF | P1 | — |\n| 2 | Configure PDF export options (orientation, page range) | P2 | #1 |\n| 3 | Send dashboard PDF as a one-off email | P2 | #1 |\n| 4 | Create a recurring email schedule for a dashboard | P1 | #1, #3 |\n| 5 | View and manage existing schedules | P1 | #4 |\n| 6 | Edit an existing schedule | P2 | #5 |\n| 7 | Delete a schedule | P1 | #5 |\n| 8 | Receive and view the scheduled email | P1 | #4 |\n\n**MVP sprint (P1):** Stories 1, 4, 5, 7, 8\n**Follow-on sprint (P2):** Stories 2, 3, 6\n\n---\n---\n\n## Story 1: Export current dashboard view as PDF\n\n**Epic:** Dashboard Distribution\n**Story ID:** _(blank)_\n**Priority:** P1\n**Story points:** _(blank)_\n\n---\n\n### User Story\n\n> **As an** analyst,\n> I want to **export my current dashboard view as a PDF**,\n> so that I can **share a static snapshot of the data with stakeholders who don't have system access**.\n\n---\n\n### Context\n\nThis is the foundational story for the epic — all scheduling and email features depend on the PDF generation capability. The export must reflect exactly what the analyst sees on screen at the moment of export, including any filters, date ranges, or segments they have applied. This is a manual, on-demand action.\n\n---\n\n### Acceptance Criteria\n\n**AC1: Export button is accessible on the dashboard**\n```\nGiven I am viewing any dashboard\nWhen I look at the dashboard toolbar\nThen I can see an \"Export\" button (or icon with label) that is keyboard-accessible\n```\n\n**AC2: Successful PDF download**\n```\nGiven I am viewing a dashboard with at least one populated widget\nWhen I click \"Export\" and confirm the action\nThen a PDF file downloads to my browser's default download location\n  And the filename follows the pattern: [Dashboard Name]_[YYYY-MM-DD].pdf\n  And the PDF renders all visible widgets at their current state\n```\n\n**AC3: Applied filters are preserved in the export**\n```\nGiven I have applied a date filter and a segment filter to the dashboard\nWhen I export to PDF\nThen the exported PDF reflects only the filtered data, not the unfiltered default view\n  And the active filters are displayed as a summary line at the top of the PDF\n```\n\n**AC4: Loading or processing state shown during export**\n```\nGiven I have clicked \"Export\"\nWhen the PDF is being generated (taking more than 1 second)\nThen a loading indicator is shown and the Export button is disabled to prevent duplicate requests\n  And once the download begins, the loading state clears\n```\n\n**AC5: Dashboard with no data**\n```\nGiven I am viewing a dashboard where all widgets return no data (e.g. filters return zero results)\nWhen I export to PDF\nThen the export still succeeds\n  And each empty widget renders with its title and an \"No data available\" placeholder — no blank white boxes\n```\n\n---\n\n### Edge Cases\n\n- [ ] **Very long dashboard:** Dashboard taller than one page — PDF must paginate cleanly, with no widget cut off mid-render across pages\n- [ ] **Dashboard with a live video or animation widget:** Static snapshot only — render the widget's still/placeholder state with a note \"Live content not available in export\"\n- [ ] **Slow network during generation:** If PDF generation exceeds 30 seconds, cancel and show an error — \"Export failed. Please try again or contact support.\"\n- [ ] **Browser popup blocker:** If the download is blocked, show an inline message with a manual \"Click here to download\" fallback link\n- [ ] **Analyst has view-only permissions:** Export is still permitted — exporting does not require edit rights\n\n---\n\n### Out of Scope\n\n- Choosing page orientation or paper size (Story 2)\n- Emailing the PDF directly from this action (Story 3)\n- Scheduling recurring exports (Story 4)\n- Exporting to formats other than PDF (not in this epic)\n\n---\n\n### Definition of Done\n\n- [ ] Acceptance criteria all pass\n- [ ] Edge cases handled or explicitly deferred with a ticket raised\n- [ ] Unit tests for PDF generation logic; E2E test covering happy path download\n- [ ] PDF renders correctly in Adobe Acrobat, Chrome PDF viewer, and macOS Preview\n- [ ] Export button is keyboard-navigable and labelled for screen readers (aria-label)\n- [ ] Loading state prevents duplicate submissions\n- [ ] Error states have approved copy\n- [ ] Tested on Chrome, Firefox, Safari, and Edge\n- [ ] Product and design reviewed in staging\n\n---\n---\n\n## Story 2: Configure PDF export options\n\n**Epic:** Dashboard Distribution\n**Story ID:** _(blank)_\n**Priority:** P2\n**Story points:** _(blank)_\n\n---\n\n### User Story\n\n> **As an** analyst,\n> I want to **choose page orientation and which widgets to include before exporting**,\n> so that I can **produce a PDF that fits the layout expected by the recipient without unnecessary content**.\n\n---\n\n### Context\n\nSome analysts share focused reports with a subset of dashboard widgets — for example, only revenue widgets for a finance audience. This story adds an options step before the export from Story 1 triggers. It must not slow down users who want the default full export — the quick path must remain one click.\n\n---\n\n### Acceptance Criteria\n\n**AC1: Export options panel opens on demand**\n```\nGiven I am viewing a dashboard\nWhen I click the dropdown arrow next to the \"Export\" button\nThen an options panel appears with controls for: page orientation (Portrait / Landscape) and widget selection (all selected by default)\n```\n\n**AC2: Page orientation applies to the PDF**\n```\nGiven I have selected \"Landscape\" orientation in the export options\nWhen I confirm the export\nThen the downloaded PDF is rendered in landscape orientation\n  And all widgets reflow to fit the wider page width\n```\n\n**AC3: Deselecting widgets excludes them from the PDF**\n```\nGiven I have unchecked 2 of 6 widgets in the export options panel\nWhen I confirm the export\nThen the downloaded PDF contains only the 4 selected widgets\n  And the excluded widgets leave no blank space in the PDF layout\n```\n\n**AC4: Default export (no options selected) unchanged**\n```\nGiven I click the main \"Export\" button directly (not the dropdown)\nWhen the PDF downloads\nThen it uses the last-used orientation setting (defaulting to Portrait on first use)\n  And includes all widgets — no options panel appears\n```\n\n**AC5: Attempting to export with zero widgets selected**\n```\nGiven I have deselected all widgets in the options panel\nWhen I attempt to confirm the export\nThen the confirm button is disabled\n  And an inline message reads \"Select at least one widget to export\"\n```\n\n---\n\n### Edge Cases\n\n- [ ] **Single-widget dashboard:** Widget selection shows one item — deselecting it triggers AC5 immediately\n- [ ] **Options panel on small screen / tablet viewport:** Panel must be scrollable if content overflows; all controls must remain usable at 768px width\n- [ ] **User changes orientation after deselecting widgets:** Widget selection state must persist through orientation toggle\n\n---\n\n### Out of Scope\n\n- Custom margins, font sizes, or branding (not in this epic)\n- Saving export preferences per dashboard (not in this epic)\n- Export formats other than PDF\n\n---\n\n### Definition of Done\n\n- [ ] Acceptance criteria all pass\n- [ ] Options panel is keyboard-navigable; all inputs are properly labelled\n- [ ] Orientation preference persisted in local storage for default (not a backend call)\n- [ ] Unit tests for widget selection and orientation logic\n- [ ] Product and design reviewed in staging\n\n---\n---\n\n## Story 3: Send a dashboard PDF as a one-off email\n\n**Epic:** Dashboard Distribution\n**Story ID:** _(blank)_\n**Priority:** P2\n**Story points:** _(blank)_\n\n---\n\n### User Story\n\n> **As an** analyst,\n> I want to **email the current dashboard PDF directly to one or more recipients from within the app**,\n> so that I can **share a report instantly without downloading it and attaching it manually**.\n\n---\n\n### Context\n\nThis is a precursor pattern to the scheduling feature (Story 4) — the same email composition UI will be reused for scheduling. Recipients can be internal users (selectable from a directory) or external email addresses typed manually. This story is one-off only — no recurrence.\n\n---\n\n### Acceptance Criteria\n\n**AC1: Email send option is accessible**\n```\nGiven I am viewing a dashboard\nWhen I click the \"Export\" dropdown\nThen I can see a \"Send by email\" option alongside the PDF download option\n```\n\n**AC2: Email composition form opens**\n```\nGiven I click \"Send by email\"\nWhen the form opens\nThen I can enter: one or more recipient email addresses, an optional subject line (pre-filled with \"[Dashboard Name] — [Today's Date]\"), and an optional message body\n```\n\n**AC3: Successful email delivery confirmation**\n```\nGiven I have entered at least one valid email address and clicked \"Send\"\nWhen the system processes the request\nThen a success toast appears: \"Dashboard sent to [n] recipient(s)\"\n  And the PDF attached to the email reflects the dashboard state at the moment \"Send\" was clicked\n```\n\n**AC4: Invalid email address blocked**\n```\nGiven I have typed an invalid email address (e.g. \"notanemail\")\nWhen I attempt to submit the form\nThen the form does not submit\n  And an inline error highlights the invalid field: \"Enter a valid email address\"\n```\n\n**AC5: Email with no recipient blocked**\n```\nGiven the recipient field is empty\nWhen I click \"Send\"\nThen the Send button remains disabled\n  And the recipient field shows helper text: \"Add at least one recipient\"\n```\n\n**AC6: Recipient from internal directory**\n```\nGiven I begin typing a colleague's name in the recipient field\nWhen at least 2 characters are entered\nThen a dropdown suggests matching internal users by name and email\n  And selecting a suggestion populates their email address in the field\n```\n\n---\n\n### Edge Cases\n\n- [ ] **Recipient list exceeds 50 addresses:** Show a warning — \"Sending to more than 50 recipients. Consider scheduling a distribution list instead.\" Allow user to proceed or cancel\n- [ ] **Email delivery failure (bounce or SMTP error):** Show an error notification — \"Email could not be delivered to [address]. Please check the address and retry.\" Do not silently fail\n- [ ] **PDF generation fails before send:** Do not send the email — surface the PDF generation error first; do not send a blank or broken attachment\n- [ ] **User closes the form mid-composition:** Show a \"Discard changes?\" confirmation if the recipient field is populated\n\n---\n\n### Out of Scope\n\n- Scheduling recurring emails (Story 4)\n- Tracking email open rates or delivery receipts (not in this epic)\n- Sending on behalf of another user\n- Distribution list management\n\n---\n\n### Definition of Done\n\n- [ ] Acceptance criteria all pass\n- [ ] Email delivery handled via existing transactional email service (confirm provider with engineering before starting)\n- [ ] Recipient autocomplete is accessible via keyboard\n- [ ] Subject line and body sanitised before send (no script injection via message body)\n- [ ] Unit tests for validation logic; integration test for email send flow\n- [ ] Product and design reviewed in staging\n\n---\n---\n\n## Story 4: Create a recurring email schedule for a dashboard\n\n**Epic:** Dashboard Distribution\n**Story ID:** _(blank)_\n**Priority:** P1\n**Story points:** _(blank)_\n\n---\n\n### User Story\n\n> **As a** manager,\n> I want to **set up a recurring email schedule that automatically sends a dashboard PDF to my team**,\n> so that I can **ensure my team receives up-to-date reports without me manually sending them each time**.\n\n---\n\n### Context\n\nManagers currently export dashboards and email them manually — often weekly or monthly. This story automates that workflow. The schedule runs a PDF snapshot at the configured time and emails it. The dashboard state at send-time is used — not the state at schedule-creation time. The scheduler must support timezone selection because teams are distributed.\n\n---\n\n### Acceptance Criteria\n\n**AC1: Schedule creation entry point is accessible**\n```\nGiven I am viewing a dashboard\nWhen I click the \"Export\" dropdown\nThen I can see a \"Schedule email\" option\n```\n\n**AC2: Schedule form captures required fields**\n```\nGiven I click \"Schedule email\"\nWhen the schedule creation form opens\nThen I can configure:\n  - Recipient email addresses (at least one required)\n  - Frequency: Daily / Weekly / Monthly\n  - Day of week (if Weekly) or day of month (if Monthly)\n  - Time of day (hour and minute)\n  - Timezone (searchable dropdown, defaults to my account timezone)\n  - Optional subject line and message body\n```\n\n**AC3: Schedule saves successfully**\n```\nGiven I have completed all required fields\nWhen I click \"Save schedule\"\nThen a success message confirms: \"Schedule created. First email will send on [Next Occurrence Date] at [Time] [Timezone]\"\n  And the schedule appears in my Schedules list (Story 5)\n  And no email is sent immediately\n```\n\n**AC4: Frequency — daily schedule**\n```\nGiven I create a schedule with frequency set to \"Daily\" at 08:00 Europe/London\nWhen the schedule runs\nThen an email is sent every calendar day at 08:00 London time\n  And daylight saving time transitions are handled automatically (the time stays 08:00 local, not UTC-fixed)\n```\n\n**AC5: Frequency — weekly schedule**\n```\nGiven I create a schedule with frequency \"Weekly\", day \"Monday\", time 09:00\nWhen Monday arrives at 09:00 in the specified timezone\nThen the email is sent\n  And the next send date shown in the Schedules list updates to the following Monday\n```\n\n**AC6: Frequency — monthly schedule**\n```\nGiven I create a schedule with frequency \"Monthly\", day of month \"31\"\nWhen a month has fewer than 31 days (e.g. February)\nThen the email sends on the last day of that month\n  And the schedule does not skip the month or error\n```\n\n**AC7: Required field validation**\n```\nGiven I attempt to save a schedule with no recipients entered\nWhen I click \"Save schedule\"\nThen the form does not submit\n  And the recipient field is highlighted with: \"Add at least one recipient\"\n```\n\n---\n\n### Edge Cases\n\n- [ ] **Analyst (not manager) creates a schedule:** Analysts can also create schedules for their own dashboards — role restriction is not applied here; permission model is dashboard-level, not role-level\n- [ ] **Dashboard is deleted after a schedule is created:** Send the scheduled email team a notification — \"Dashboard '[Name]' has been deleted. Your schedule '[Name]' has been paused.\" Do not silently fail\n- [ ] **Dashboard owner changes access permissions:** If the schedule creator loses access to the dashboard, pause the schedule and notify them\n- [ ] **Two schedules created for the same dashboard, same time, same recipients:** Allow it — do not deduplicate silently; user is responsible for managing duplicates (they'll see both in Story 5)\n- [ ] **Timezone not set on user account:** Default to UTC and prompt the user to confirm with a banner: \"We've defaulted to UTC. Update your timezone in account settings.\"\n\n---\n\n### Out of Scope\n\n- Editing an existing schedule (Story 6)\n- Deleting a schedule (Story 7)\n- Viewing schedule history / delivery logs (not in this epic)\n- Scheduling exports to formats other than PDF\n- Setting an end date for a schedule (not in this epic — schedules run until manually deleted)\n\n---\n\n### Definition of Done\n\n- [ ] Acceptance criteria all pass\n- [ ] Timezone handling validated for DST transitions (London, New York, Sydney at minimum)\n- [ ] Monthly \"short month\" edge case has a passing automated test\n- [ ] Schedule is persisted in the database — survives server restart\n- [ ] Unit tests for recurrence calculation logic; integration test for schedule creation\n- [ ] No email is triggered on schedule creation — only on the first scheduled occurrence\n- [ ] Product and design reviewed in staging\n\n---\n---\n\n## Story 5: View and manage existing schedules\n\n**Epic:** Dashboard Distribution\n**Story ID:** _(blank)_\n**Priority:** P1\n**Story points:** _(blank)_\n\n---\n\n### User Story\n\n> **As a** manager,\n> I want to **see a list of all the email schedules I have created**,\n> so that I can **understand what's currently active and avoid sending duplicate or outdated reports to my team**.\n\n---\n\n### Context\n\nWithout visibility into active schedules, users will create duplicates or forget to update schedules when dashboards change. This view is the management hub for all schedule-related actions (editing in Story 6, deleting in Story 7). Scope is intentionally read-only for this story.\n\n---\n\n### Acceptance Criteria\n\n**AC1: Schedules list is accessible**\n```\nGiven I am"}]}