sinapse-ai 1.0.0

package/squad-product/tasks/create-product-onboarding-runbook.md

@@ -0,0 +1,150 @@
+---
+task: create-product-onboarding-runbook
+responsavel: "@ps-product-ops-specialist"
+responsavel_type: Agent
+atomic_layer: Task
+elicit: false
+
+Entrada:
+  - campo: context
+    tipo: object
+    origem: "workflow ou manual"
+    obrigatorio: true
+
+Saida:
+  - campo: resultado
+    tipo: document
+    destino: "stakeholders"
+
+Checklist:
+  - "[ ] Validar inputs e pre-condicoes"
+  - "[ ] Executar steps conforme documentado"
+  - "[ ] Verificar criterios de qualidade"
+  - "[ ] Gerar output no formato especificado"
+---
+
+# Create Product Onboarding Runbook
+
+## Metadata
+- **Agent:** ps-product-ops-specialist (Mosaic)
+- **Complexity:** Medium
+- **Estimated Time:** 3-4 hours
+- **Produces:** PM onboarding runbook, learning path, checklist, 30-60-90 day plan
+
+## Purpose
+Criar runbook de onboarding para novos Product Managers que entram na agencia, garantindo produtividade rapida e alinhamento com nossos padroes e frameworks.
+
+## Steps
+
+### Step 1: Onboarding Timeline
+**30-60-90 Day Plan:**
+
+**Days 1-7: Orient**
+- [ ] Meet the team (all squad members + key stakeholders)
+- [ ] Access setup (all tools, channels, documents)
+- [ ] Read product playbook (core framework understanding)
+- [ ] Review current client portfolio (active engagements)
+- [ ] Shadow experienced PM on 3+ client meetings
+- [ ] Review 2-3 completed projects (understand our output quality)
+
+**Days 8-30: Learn**
+- [ ] Deep dive on assigned client(s) (product, metrics, stakeholders)
+- [ ] Review decision log for assigned client(s)
+- [ ] Attend all sprint ceremonies (planning, demo, retro)
+- [ ] Conduct 3+ internal interviews (dev, design, QA perspectives)
+- [ ] Complete frameworks quiz (validate understanding)
+- [ ] Lead first client meeting (with experienced PM observing)
+- [ ] Write first sprint status report
+
+**Days 31-60: Contribute**
+- [ ] Lead sprint planning independently
+- [ ] Prepare and present first metrics review
+- [ ] Conduct first user interview
+- [ ] Handle first client request (intake + reframe)
+- [ ] Create first roadmap update
+- [ ] Identify first improvement opportunity
+
+**Days 61-90: Own**
+- [ ] Full ownership of assigned client(s)
+- [ ] Lead first QBR independently
+- [ ] Contribute to product playbook (add learning)
+- [ ] Mentor next new PM (if applicable)
+- [ ] 90-day review with leadership
+
+### Step 2: Essential Knowledge Modules
+**Learning Path:**
+| Module | Content | Duration | Assessment |
+|--------|---------|----------|-----------|
+| 1. Squad Framework | Squad structure, agents, workflows | 2h | Quiz |
+| 2. Product Principles | Our principles, frameworks, standards | 2h | Discussion |
+| 3. Client Management | Engagement model, communication, QBRs | 2h | Role play |
+| 4. Discovery Methods | Interviews, research, validation | 3h | Practice session |
+| 5. Delivery Process | Sprints, estimation, launch, tech debt | 2h | Observe + lead |
+| 6. Analytics | Metrics, dashboards, experiments | 2h | Dashboard review |
+| 7. Tools | Tool stack, setup, best practices | 1h | Self-paced |
+| 8. Templates | Template library, when to use each | 1h | Practice |
+
+### Step 3: Critical Frameworks Reference
+**Frameworks Every PM Must Know:**
+| Framework | Author | Use Case | Reference |
+|-----------|--------|----------|-----------|
+| Continuous Discovery | Teresa Torres | Weekly research habits | discovery-methodology-playbook |
+| JTBD Interviews | Bob Moesta | Understanding user motivations | conduct-jtbd-interviews task |
+| RICE Scoring | Intercom | Prioritization | run-backlog-prioritization task |
+| OKRs | Doerr | Goal setting | define-quarterly-okrs task |
+| Strategy Canvas | Kim & Mauborgne | Competitive positioning | create-strategy-canvas task |
+| Shape Up | Ryan Singer | Scoping and betting | run-shape-up-betting-table task |
+| Dual Roadmap | Industry practice | Client communication | prepare-client-roadmap task |
+| Product Health Score | Composite | Product monitoring | calculate-product-health-metrics task |
+
+### Step 4: Common Mistakes to Avoid
+**New PM Pitfalls:**
+| Mistake | Why It Happens | Prevention |
+|---------|---------------|-----------|
+| Taking client feature requests at face value | Want to please client | Always reframe with Mironov method |
+| Committing to dates too early | Pressure from client | Use confidence levels, not dates |
+| Skipping discovery | Urgency pressure | Minimum: 3 interviews before building |
+| Not documenting decisions | "I will remember" | Log every decision within 24h |
+| Ignoring tech debt | Not visible to client | Protect 15% budget always |
+| Over-engineering solutions | Want to impress | MVP first, iterate from data |
+| Solo decision-making | Efficiency temptation | Consult Product Trio always |
+| Not tracking metrics | "We will do it later" | Baseline from Day 1 |
+
+### Step 5: Support System
+**Who to Ask for What:**
+| Need | Go To | How |
+|------|-------|-----|
+| Product strategy question | ps-product-strategist (Charter) | Async or scheduled |
+| Research methodology | ps-discovery-lead (Quorum) | Async or pair session |
+| Analytics help | ps-product-analyst (Delta) | Async or dashboard walkthrough |
+| Delivery/sprint question | ps-delivery-manager (Tempo) | Daily standup or async |
+| Client situation advice | ps-client-product-manager (Proxy) | Immediate (Slack DM) |
+| Process/template question | ps-product-ops-specialist (Mosaic) | Async |
+| Escalation | ps-orchestrator (Vector) | Immediate |
+
+**Buddy System:**
+- Every new PM is paired with experienced PM for first 60 days
+- Weekly 30-min check-in with buddy
+- Buddy reviews first 3 client deliverables before sending
+
+### Step 6: Onboarding Success Criteria
+**Assessment at Each Stage:**
+| Checkpoint | Criteria | Assessor | Pass/Fail |
+|-----------|---------|----------|-----------|
+| Day 7 | Can explain our product approach | Buddy | |
+| Day 14 | Tools set up, access confirmed | Ops | |
+| Day 30 | Led first client meeting successfully | PM Lead | |
+| Day 60 | Operating independently on client work | PM Lead | |
+| Day 90 | Full ownership, contributing to team knowledge | Leadership | |
+
+**Feedback Collection:**
+- Day 7: "What is confusing so far?"
+- Day 30: "What is missing from onboarding?"
+- Day 90: "What would you change for the next person?"
+- Use feedback to improve this runbook continuously
+
+## Output Artifacts
+- `pm-onboarding-runbook.md` | `30-60-90-plan-template.md` | `frameworks-reference-card.md` | `onboarding-checklist.md`
+
+## Quality Criteria
+- 30-60-90 plan comprehensive | Learning modules defined with assessments | Common mistakes documented | Support system clear | Success criteria measurable | Feedback loop built in | Runbook updated based on each onboarding experience

package/squad-product/tasks/create-product-playbook.md

@@ -0,0 +1,191 @@
+---
+task: create-product-playbook
+responsavel: "@ps-product-ops-specialist"
+responsavel_type: Agent
+atomic_layer: Task
+elicit: false
+
+Entrada:
+  - campo: context
+    tipo: object
+    origem: "workflow ou manual"
+    obrigatorio: true
+
+Saida:
+  - campo: resultado
+    tipo: document
+    destino: "stakeholders"
+
+Checklist:
+  - "[ ] Validar inputs e pre-condicoes"
+  - "[ ] Executar steps conforme documentado"
+  - "[ ] Verificar criterios de qualidade"
+  - "[ ] Gerar output no formato especificado"
+---
+
+# Create Product Playbook
+
+## Metadata
+- **Agent:** ps-product-ops-specialist (Mosaic)
+- **Complexity:** High
+- **Estimated Time:** 8-12 hours
+- **Produces:** Comprehensive product playbook, operational guides, best practices library
+
+## Purpose
+Compilar playbook operacional de produto que codifica como a agencia faz product management. O playbook e a "inteligencia coletiva" — o que aprendemos funciona, padronizado e replicavel.
+
+## Steps
+
+### Step 1: Playbook Structure
+```
+PRODUCT PLAYBOOK
+════════════════
+Version: [v1.0]
+Last Updated: [date]
+Owner: ps-product-ops-specialist (Mosaic)
+
+TABLE OF CONTENTS:
+1. How We Do Product Management
+2. Client Engagement Model
+3. Discovery & Research Playbook
+4. Delivery & Sprint Playbook
+5. Analytics & Metrics Playbook
+6. Client Communication Playbook
+7. Tool Stack & Setup Guide
+8. Templates & Artifacts
+9. Escalation & Decision Guide
+10. Onboarding Guide for New PMs
+```
+
+### Step 2: Core Sections Content
+
+**Section 1: How We Do Product**
+```
+OUR PRODUCT PRINCIPLES:
+1. Evidence over opinion — data and research drive decisions
+2. Outcomes over outputs — measure value, not features shipped
+3. Continuous discovery — discovery is a habit, not a phase
+4. Client as partner — collaborative, not order-taking
+5. Quality over speed — tech debt is paid, not ignored
+6. Transparency — share good and bad news equally
+
+OUR FRAMEWORKS:
+- Discovery: Continuous Discovery Habits (Teresa Torres)
+- Strategy: Strategy Canvas + Positioning (Dunford)
+- Prioritization: RICE + MoSCoW
+- Delivery: Shape Up appetite + Scrum sprints
+- Metrics: AARRR Pirate Metrics + Product Health Score
+- Client Management: Dual Roadmap + QBR Cycle
+```
+
+**Section 2: Client Engagement Model**
+```
+ENGAGEMENT LIFECYCLE:
+1. Onboarding (Week 1-2): Setup, discovery, quick win
+2. Foundation (Month 1-2): Strategy, roadmap, processes
+3. Delivery (Ongoing): Sprint execution, continuous discovery
+4. Optimization (Quarterly): QBR, metrics review, strategy refresh
+5. Handoff/Renewal: Package preparation, transition or continuation
+
+ROLES PER ENGAGEMENT:
+| Role | Responsibility | Allocation |
+|------|---------------|-----------|
+| Product Strategist | Vision, strategy, OKRs | 10-20% |
+| Discovery Lead | Research, validation | 20-30% |
+| Product Analyst | Metrics, data, experiments | 15-25% |
+| Delivery Manager | Sprints, releases, tech debt | 20-30% |
+| Client PM | Communication, scope, relationship | 15-25% |
+| Product Ops | Processes, tools, templates | 5-10% |
+```
+
+### Step 3: Situational Plays
+**Playbook Plays (specific situations):**
+
+**Play: New Client Kickoff**
+```
+Trigger: New client engagement starts
+Timeline: First 2 weeks
+Steps:
+1. Stakeholder mapping (Day 1)
+2. Product health baseline (Day 2-3)
+3. Quick win identification (Day 3-5)
+4. Discovery sprint plan (Day 5-7)
+5. Roadmap draft (Day 7-10)
+6. Kickoff presentation (Day 10-14)
+Success: Client has clear vision of engagement direction
+```
+
+**Play: Metric Decline Response**
+```
+Trigger: Key metric drops >10% WoW
+Timeline: Within 48 hours
+Steps:
+1. Verify data accuracy (is tracking correct?)
+2. Check for external factors (seasonality, outage)
+3. Segment analysis (which users affected?)
+4. Recent changes review (did we ship something?)
+5. Root cause hypothesis
+6. Communicate to stakeholders
+7. Action plan
+Success: Root cause identified, action in progress
+```
+
+**Play: Client Escalation**
+```
+Trigger: Client expresses dissatisfaction
+Timeline: Same day
+Steps:
+1. Acknowledge immediately (never defensive)
+2. Gather full context from all sides
+3. Internal alignment on response
+4. Client meeting within 24h
+5. Written action plan within 48h
+6. Weekly check-ins until resolved
+Success: Client satisfaction restored
+```
+
+**Play: Feature Launch**
+```
+Trigger: Feature ready for production
+Timeline: Per launch checklist
+Steps: [reference execute-feature-launch-checklist task]
+```
+
+### Step 4: Best Practices Library
+**Curated from experience across clients:**
+| Practice | Category | When to Apply | Evidence |
+|----------|----------|--------------|---------|
+| Weekly user interviews | Discovery | Always | Teresa Torres - reduces risk |
+| 15% tech debt allocation | Delivery | Every sprint | Prevents velocity decline |
+| Now/Next/Later roadmap | Client | All roadmap presentations | Reduces false commitments |
+| Dual roadmap system | Client | All engagements | Internal alignment + client clarity |
+| Sprint confidence vote | Delivery | Every planning | Improves commitment accuracy |
+| Feature flag rollouts | Delivery | All launches | Reduces launch risk |
+| Monthly NPS pulse | Analytics | All products | Early churn detection |
+
+### Step 5: Anti-Patterns (What NOT to Do)
+| Anti-Pattern | Why It Fails | Better Approach |
+|-------------|-------------|-----------------|
+| Building without validating | Wasted effort, wrong solution | Validate problem first |
+| Promising dates to clients | Creates false expectations | Use confidence levels |
+| Skipping tech debt | Velocity decreases over time | Protect 15% budget |
+| Output-focused metrics | Measures effort, not value | Measure outcomes |
+| Single point of contact | Knowledge risk, burnout | Cross-train team |
+| No retrospectives | Same mistakes repeated | Bi-weekly retros |
+| Verbal scope changes | Leads to disputes | Always document |
+
+### Step 6: Playbook Maintenance
+**Update Triggers:**
+| Trigger | Action | Owner |
+|---------|--------|-------|
+| New best practice confirmed | Add to practices library | PM who discovered |
+| Play fails in practice | Update or remove play | Team retrospective |
+| New framework adopted | Add to frameworks section | Product Ops |
+| Client feedback pattern | Update relevant plays | Product Ops |
+| Quarterly review | Full playbook review | Product Ops |
+
+## Output Artifacts
+- `product-playbook.md` (master document) | `plays/[play-name].md` (individual plays) | `best-practices-library.md` | `anti-patterns.md`
+
+## Quality Criteria
+- All core processes documented | Situational plays have clear triggers and steps | Best practices based on evidence (not opinion) | Anti-patterns included (what NOT to do) | Onboarding path clear | Quarterly review scheduled | Team contributed to content

package/squad-product/tasks/create-product-tracking-plan.md

@@ -0,0 +1,154 @@
+---
+task: create-product-tracking-plan
+responsavel: "@ps-product-analyst"
+responsavel_type: Agent
+atomic_layer: Task
+elicit: false
+
+Entrada:
+  - campo: context
+    tipo: object
+    origem: "workflow ou manual"
+    obrigatorio: true
+
+Saida:
+  - campo: resultado
+    tipo: document
+    destino: "stakeholders"
+
+Checklist:
+  - "[ ] Validar inputs e pre-condicoes"
+  - "[ ] Executar steps conforme documentado"
+  - "[ ] Verificar criterios de qualidade"
+  - "[ ] Gerar output no formato especificado"
+---
+
+# Create Product Tracking Plan
+
+## Metadata
+- **Agent:** ps-product-analyst (Delta)
+- **Complexity:** Medium-High
+- **Estimated Time:** 4-6 hours
+- **Produces:** Tracking plan, event taxonomy, metric definitions, implementation spec
+
+## Purpose
+Definir plano de tracking completo para medir product metrics de forma consistente e confiavel. Um bom tracking plan e a fundacao de todas as decisoes baseadas em dados.
+
+## Steps
+
+### Step 1: Define Metric Framework
+**North Star Metric:**
+```
+Metric: [the ONE metric that best captures value delivered to users]
+Formula: [how it is calculated]
+Leading Indicators: [metrics that predict North Star movement]
+Lagging Indicators: [metrics that confirm North Star impact]
+```
+
+**Metric Hierarchy:**
+| Level | Metrics | Review Cadence |
+|-------|---------|---------------|
+| North Star | [1 metric] | Weekly |
+| L1 — Acquisition | [signup rate, CAC, channel mix] | Weekly |
+| L1 — Activation | [activation rate, time-to-value, aha completion] | Weekly |
+| L1 — Engagement | [DAU/MAU, session frequency, feature adoption] | Weekly |
+| L1 — Retention | [D7/D30/D90, cohort curves, churn rate] | Weekly |
+| L1 — Revenue | [ARPU, MRR, expansion revenue, LTV] | Monthly |
+| L2 — Feature | [per-feature adoption, usage depth] | Bi-weekly |
+
+### Step 2: Design Event Taxonomy
+**Naming Convention:**
+```
+Format: [object]_[action]
+Examples: page_viewed, button_clicked, form_submitted, feature_activated
+```
+
+**Event Categories:**
+| Category | Purpose | Examples |
+|----------|---------|---------|
+| Pageview | Navigation tracking | page_viewed |
+| Interaction | User actions | button_clicked, form_submitted |
+| Lifecycle | Key moments | account_created, trial_started, plan_upgraded |
+| Feature | Feature usage | feature_activated, feature_completed |
+| Error | Failures | error_occurred, payment_failed |
+| System | Backend events | email_sent, notification_delivered |
+
+### Step 3: Define Event Spec (per event)
+**Event Card:**
+```
+EVENT: [event_name]
+────────────────────────────────
+Category: [pageview|interaction|lifecycle|feature|error|system]
+Trigger: [exactly when this fires]
+Description: [what this event represents]
+
+Properties:
+| Property | Type | Required | Description | Example |
+|----------|------|----------|-------------|---------|
+| [prop_1] | string | Yes | [what it captures] | [example value] |
+| [prop_2] | number | Yes | [what it captures] | [example value] |
+| [prop_3] | string | No | [what it captures] | [example value] |
+
+User Properties (attached to all events):
+| Property | Type | Description |
+|----------|------|-------------|
+| user_id | string | Unique user identifier |
+| account_id | string | Organization/account identifier |
+| plan_type | string | Current subscription plan |
+| user_role | string | Role within the product |
+| signup_date | date | When user first signed up |
+
+Funnel Membership: [which funnels this event belongs to]
+Dashboard: [which dashboard uses this metric]
+Owner: [who is responsible for this event]
+```
+
+### Step 4: Map Events to Funnels
+**Core Funnels:**
+```
+ACQUISITION FUNNEL:
+landing_page_viewed → signup_started → signup_completed → email_verified
+
+ACTIVATION FUNNEL:
+first_login → onboarding_started → [key_action_1] → [key_action_2] → aha_moment_reached
+
+CONVERSION FUNNEL:
+trial_started → feature_explored → pricing_viewed → checkout_started → payment_completed
+
+ENGAGEMENT FUNNEL:
+session_started → [primary_action] → [secondary_action] → session_ended
+```
+
+### Step 5: Data Quality Rules
+**Validation Rules:**
+| Rule | Description | Impact if Violated |
+|------|-------------|-------------------|
+| Required properties always present | Every event has user_id + timestamp | Cannot attribute events |
+| No duplicate events | Same event + timestamp + user = 1 record | Inflated metrics |
+| Consistent naming | All events follow taxonomy convention | Broken dashboards |
+| Property type enforcement | Numbers are numbers, strings are strings | Analysis errors |
+| Event ordering | Timestamps sequential within session | Funnel miscalculation |
+
+**QA Checklist Before Launch:**
+- [ ] All events fire in correct sequence
+- [ ] Properties have correct types and values
+- [ ] No PII (personally identifiable information) in event properties
+- [ ] Events fire on all platforms (web, mobile, API)
+- [ ] Duplicate prevention works
+- [ ] Events appear in analytics tool within expected latency
+
+### Step 6: Implementation Spec for Engineering
+**Per Event Group:**
+```
+Implementation Priority: P0 (launch blocker) | P1 (week 1) | P2 (week 2)
+Platform: Web | Mobile | Backend | All
+Analytics Tool: [Amplitude/Mixpanel/Segment/etc.]
+Code Location: [where tracking code should go]
+Test Method: [how to verify it works]
+```
+
+## Output Artifacts
+- `tracking-plan.md` | `event-taxonomy.md` | `event-specs/[event-name].md` | `funnel-definitions.md` | `data-quality-rules.md`
+
+## Quality Criteria
+- North Star metric defined | Naming convention consistent | Every event has trigger + properties + owner | Funnels mapped to events | Data quality rules specified | No PII in events | Implementation priority assigned

package/squad-product/tasks/create-strategy-canvas.md

@@ -0,0 +1,59 @@
+---
+task: create-strategy-canvas
+responsavel: "@ps-product-strategist"
+responsavel_type: Agent
+atomic_layer: Task
+elicit: false
+
+Entrada:
+  - campo: context
+    tipo: object
+    origem: "workflow ou manual"
+    obrigatorio: true
+
+Saida:
+  - campo: resultado
+    tipo: document
+    destino: "stakeholders"
+
+Checklist:
+  - "[ ] Validar inputs e pre-condicoes"
+  - "[ ] Executar steps conforme documentado"
+  - "[ ] Verificar criterios de qualidade"
+  - "[ ] Gerar output no formato especificado"
+---
+
+# Create Strategy Canvas
+
+## Metadata
+- **Agent:** ps-product-strategist (Charter)
+- **Complexity:** Medium-High
+- **Estimated Time:** 3-4 hours
+- **Produces:** Strategy canvas, ERRC grid, differentiation map
+
+## Purpose
+Criar Strategy Canvas (Kim & Mauborgne, Blue Ocean Strategy) visualizando posicionamento competitivo e definindo diferenciacao.
+
+## Steps
+
+### Step 1: Identify 6-10 Value Factors (from competitors, user interviews, analysts, sales criteria)
+### Step 2: Score Competitors (1-5 scale per factor)
+### Step 3: Plot Canvas (X=factors, Y=investment level, curves per player)
+**Key Insight:** If curve looks like competitors, competing on their terms. Differentiation requires different curve shape.
+
+### Step 4: ERRC Grid
+**Eliminate:** Factors industry takes for granted
+**Reduce:** Investment below standard
+**Raise:** Above standard
+**Create:** New factors never offered
+
+### Step 5: Design Target Strategy Canvas
+**Three Tests:** Focus (lead on 2-3 factors) | Divergence (curve looks different) | Compelling Tagline (one sentence)
+
+### Step 6: Document with Roadmap Implications
+
+## Output Artifacts
+- `strategy-canvas.md` | `errc-grid.md` | `differentiation-map.md`
+
+## Quality Criteria
+- 6-10 factors from real data | Min 2 competitors + status quo | ERRC actionable | 3 tests passed

package/squad-product/tasks/create-user-personas.md

@@ -0,0 +1,141 @@
+---
+task: create-user-personas
+responsavel: "@ps-discovery-lead"
+responsavel_type: Agent
+atomic_layer: Task
+elicit: false
+
+Entrada:
+  - campo: context
+    tipo: object
+    origem: "workflow ou manual"
+    obrigatorio: true
+
+Saida:
+  - campo: resultado
+    tipo: document
+    destino: "stakeholders"
+
+Checklist:
+  - "[ ] Validar inputs e pre-condicoes"
+  - "[ ] Executar steps conforme documentado"
+  - "[ ] Verificar criterios de qualidade"
+  - "[ ] Gerar output no formato especificado"
+---
+
+# Create User Personas
+
+## Metadata
+- **Agent:** ps-discovery-lead (Quorum)
+- **Complexity:** Medium
+- **Estimated Time:** 3-4 hours
+- **Produces:** User personas, segment profiles, jobs-to-be-done per persona
+
+## Purpose
+Criar personas baseadas em dados reais (nao ficcionais) que representem segmentos distintos de usuarios. Combina dados quantitativos (analytics) com qualitativos (entrevistas) para gerar perfis acionaveis.
+
+## Steps
+
+### Step 1: Data-Driven Segmentation
+**Start with behavioral data, NOT demographics:**
+
+**Behavioral Dimensions to Analyze:**
+| Dimension | Data Source | Segments |
+|-----------|-----------|----------|
+| Usage frequency | Analytics | Daily / Weekly / Monthly / Churned |
+| Feature adoption | Analytics | Power user / Standard / Minimal |
+| Use case | Interviews + Analytics | Primary job they hire product for |
+| Sophistication | Analytics + Support | Self-serve / Needs guidance / Expert |
+| Value perception | Survey + NPS | Promoter / Passive / Detractor |
+
+**Segmentation Method:**
+1. Pull behavioral cohort data from analytics
+2. Identify natural clusters (2-4 segments)
+3. Validate clusters against interview data
+4. Name segments by behavior, not demographics
+
+### Step 2: Build Persona Profile (per segment)
+```
+PERSONA: [Name — a real archetype, not a fictional character]
+─────────────────────────────────────────────────────────────
+
+SEGMENT: [behavioral segment name]
+SIZE: [% of user base] | [absolute count if known]
+REVENUE CONTRIBUTION: [% of revenue or tier]
+
+CONTEXT:
+- Role/situation: [what they do]
+- Environment: [where/when they use product]
+- Experience level: [with product and domain]
+- Tools ecosystem: [what else they use alongside]
+
+JOBS TO BE DONE (Functional):
+1. [Primary job: "When I [situation], I want to [motivation], so I can [outcome]"]
+2. [Secondary job]
+3. [Tertiary job]
+
+JOBS TO BE DONE (Emotional):
+- Wants to feel: [desired emotional state]
+- Wants to avoid feeling: [undesired emotional state]
+
+JOBS TO BE DONE (Social):
+- Wants to be seen as: [desired perception]
+- Wants to avoid being seen as: [undesired perception]
+
+CURRENT BEHAVIOR:
+- How they solve the job today: [current solution/workaround]
+- Pain points with current approach: [specific frustrations]
+- Switching triggers: [what would make them change]
+- Switching barriers: [what holds them back]
+
+KEY METRICS:
+- Activation rate: [% who reach aha moment]
+- Retention (30d): [% still active at 30 days]
+- Feature usage: [top 3 features by frequency]
+- Support ticket rate: [tickets per user per month]
+- NPS: [score for this segment]
+
+PRODUCT IMPLICATIONS:
+- Features they value most: [list]
+- Features they ignore: [list]
+- Unmet needs: [list]
+- Churn risk factors: [list]
+```
+
+### Step 3: Validate Personas Against Real Users
+**Validation Methods:**
+- [ ] Map 5+ real users to each persona (they should fit naturally)
+- [ ] Review with customer-facing team (CS, Sales) — do they recognize these?
+- [ ] Check that personas are distinct (a real user should not fit 2 personas equally)
+- [ ] Verify with analytics that segment sizes match
+
+**Red Flags:**
+- Persona fits no real users → Too abstract, redo
+- All users fit one persona → Not enough differentiation
+- Persona based on demographics only → Redo with behavioral data
+- More than 5 personas → Too many, consolidate
+
+### Step 4: Define Persona Priority
+**Prioritization Matrix:**
+| Persona | Segment Size | Revenue Impact | Strategic Fit | Growth Potential | Priority |
+|---------|-------------|---------------|--------------|-----------------|----------|
+| [name] | [% of base] | [high/med/low] | [high/med/low] | [high/med/low] | P1/P2/P3 |
+
+**Rules:**
+- Max 2 primary personas (P1) — product decisions optimize for these
+- P2 personas: served but not primary design target
+- P3 personas: acknowledged but not designed for
+
+### Step 5: Create Persona Usage Guidelines
+**How teams should use personas:**
+- Product decisions: "Does this serve our P1 personas?"
+- Feature prioritization: "Which persona benefits? What is their priority?"
+- Design reviews: "Can [Persona Name] complete this task?"
+- Marketing: "How would we explain this to [Persona Name]?"
+- Support: "Is this a [Persona Name] issue pattern?"
+
+## Output Artifacts
+- `personas/[persona-name].md` (per persona) | `persona-priority-matrix.md` | `persona-usage-guidelines.md` | `segment-data-summary.md`
+
+## Quality Criteria
+- Based on behavioral data, not demographics | Min 5 real users mapped per persona | Max 4-5 total personas | Each persona has JTBD (all 3 types) | Priority assigned | Validated with customer-facing teams