opencode-knowledge-work 0.0.0-stage → 0.1.1

package/content/product-management/skills/product-management-stakeholder-update/SKILL.md

@@ -0,0 +1,352 @@
+---
+name: stakeholder-update
+description: Generate a stakeholder update tailored to audience and cadence. Use when writing a weekly or monthly status for leadership, announcing a launch, escalating a risk or blocker, or translating the same progress into exec-brief, engineering-detail, or customer-facing versions.
+argument-hint: "<update type and audience>"
+---
+
+# Stakeholder Update
+
+> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).
+
+Generate a stakeholder update tailored to the audience and cadence.
+
+## Usage
+
+```
+/stakeholder-update $ARGUMENTS
+```
+
+## Workflow
+
+### 1. Determine Update Type
+
+Ask the user what kind of update:
+- **Weekly**: Regular cadence update on progress, blockers, and next steps
+- **Monthly**: Higher-level summary with trends, milestones, and strategic alignment
+- **Launch**: Announcement of a feature or product launch with details and impact
+- **Ad-hoc**: One-off update for a specific situation (escalation, pivot, major decision)
+
+### 2. Determine Audience
+
+Ask who the update is for:
+- **Executives / leadership**: High-level, outcome-focused, strategic framing, brief
+- **Engineering team**: Technical detail, implementation context, blockers, decisions needed
+- **Cross-functional partners**: Context-appropriate detail, focus on shared goals and dependencies
+- **Customers / external**: Benefits-focused, clear timelines, no internal jargon
+- **Board**: Metrics-driven, strategic, risk-focused, very concise
+
+### 3. Pull Context from Connected Tools
+
+If **~~project tracker** is connected:
+- Pull status of roadmap items and milestones
+- Identify completed items since last update
+- Surface items that are at risk or blocked
+- Pull sprint or iteration progress
+
+If **~~chat** is connected:
+- Search for relevant team discussions and decisions
+- Find blockers or issues raised in channels
+- Identify key decisions made asynchronously
+
+If **~~meeting transcription** is connected:
+- Pull recent meeting notes and discussion summaries
+- Find decisions and action items from relevant meetings
+
+If **~~knowledge base** is connected:
+- Search for recent meeting notes
+- Find decision documents or design reviews
+
+If no tools are connected, ask the user to provide:
+- What was accomplished since the last update
+- Current blockers or risks
+- Key decisions made or needed
+- What is coming next
+
+### 4. Generate the Update
+
+Structure the update for the target audience using the templates and frameworks below.
+
+**For executives**: TL;DR, status color (G/Y/R), key progress tied to goals, decisions made, risks with mitigation, specific asks, and next milestones. Keep it under 300 words.
+
+**For engineering**: What shipped (with links), what is in progress (with owners), blockers, decisions needed (with options and recommendation), and what is coming next.
+
+**For cross-functional partners**: What is coming that affects them, what you need from them (with deadlines), decisions that impact their team, and areas open for input.
+
+**For customers**: What is new (framed as benefits), what is coming soon, known issues with workarounds, and how to provide feedback. No internal jargon.
+
+**For launch announcements**: What launched, why it matters, key details (scope, availability, limitations), success metrics, rollout plan, and feedback channels.
+
+### 5. Review and Deliver
+
+After generating the update:
+- Ask if the user wants to adjust tone, detail level, or emphasis
+- Offer to format for the delivery channel (email, chat post, doc, slides)
+- If **~~chat** is connected, offer to draft the message for sending
+
+## Update Templates by Audience
+
+### Executive / Leadership Update
+Executives want: strategic context, progress against goals, risks that need their help, decisions that need their input.
+
+**Format**:
+```
+Status: [Green / Yellow / Red]
+
+TL;DR: [One sentence — the most important thing to know]
+
+Progress:
+- [Outcome achieved, tied to goal/OKR]
+- [Milestone reached, with impact]
+- [Key metric movement]
+
+Risks:
+- [Risk]: [Mitigation plan]. [Ask if needed].
+
+Decisions needed:
+- [Decision]: [Options with recommendation]. Need by [date].
+
+Next milestones:
+- [Milestone] — [Date]
+```
+
+**Tips for executive updates**:
+- Lead with the conclusion, not the journey. Executives want "we shipped X and it moved Y metric" not "we had 14 standups and resolved 23 tickets."
+- Keep it under 200 words. If they want more, they will ask.
+- Status color should reflect YOUR genuine assessment, not what you think they want to hear. Yellow is not a failure — it is good risk management.
+- Only include risks you want help with. Do not list risks you are already handling unless they need to know.
+- Asks must be specific: "Decision on X by Friday" not "support needed."
+
+### Engineering Team Update
+Engineers want: clear priorities, technical context, blockers resolved, decisions that affect their work.
+
+**Format**:
+```
+Shipped:
+- [Feature/fix] — [Link to PR/ticket]. [Impact if notable].
+
+In progress:
+- [Item] — [Owner]. [Expected completion]. [Blockers if any].
+
+Decisions:
+- [Decision made]: [Rationale]. [Link to ADR if exists].
+- [Decision needed]: [Context]. [Options]. [Recommendation].
+
+Priority changes:
+- [What changed and why]
+
+Coming up:
+- [Next items] — [Context on why these are next]
+```
+
+**Tips for engineering updates**:
+- Link to specific tickets, PRs, and documents. Engineers want to click through for details.
+- When priorities change, explain why. Engineers are more bought in when they understand the reason.
+- Be explicit about what is blocking them and what you are doing to unblock it.
+- Do not waste their time with information that does not affect their work.
+
+### Cross-Functional Partner Update
+Partners (design, marketing, sales, support) want: what is coming that affects them, what they need to prepare for, how to give input.
+
+**Format**:
+```
+What's coming:
+- [Feature/launch] — [Date]. [What this means for your team].
+
+What we need from you:
+- [Specific ask] — [Context]. By [date].
+
+Decisions made:
+- [Decision] — [How it affects your team].
+
+Open for input:
+- [Topic we'd love feedback on] — [How to provide it].
+```
+
+### Customer / External Update
+Customers want: what is new, what is coming, how it benefits them, how to get started.
+
+**Format**:
+```
+What's new:
+- [Feature] — [Benefit in customer terms]. [How to use it / link].
+
+Coming soon:
+- [Feature] — [Expected timing]. [Why it matters to you].
+
+Known issues:
+- [Issue] — [Status]. [Workaround if available].
+
+Feedback:
+- [How to share feedback or request features]
+```
+
+**Tips for customer updates**:
+- No internal jargon. No ticket numbers. No technical implementation details.
+- Frame everything in terms of what the customer can now DO, not what you built.
+- Be honest about timelines but do not overcommit. "Later this quarter" is better than a date you might miss.
+- Only mention known issues if they are customer-impacting and you have a resolution plan.
+
+## Status Reporting Framework
+
+### Green / Yellow / Red Status
+
+**Green** (On Track):
+- Progressing as planned
+- No significant risks or blockers
+- On track to meet commitments and deadlines
+- Use Green when things are genuinely going well — not as a default
+
+**Yellow** (At Risk):
+- Progress is slower than planned, or a risk has materialized
+- Mitigation is underway but outcome is uncertain
+- May miss commitments without intervention or scope adjustment
+- Use Yellow proactively — the earlier you flag risk, the more options you have
+
+**Red** (Off Track):
+- Significantly behind plan
+- Major blocker or risk without clear mitigation
+- Will miss commitments without significant intervention (scope cut, resource addition, timeline extension)
+- Use Red when you genuinely need help. Do not wait until it is too late.
+
+### When to Change Status
+- Move to Yellow at the FIRST sign of risk, not when you are sure things are bad
+- Move to Red when you have exhausted your own options and need escalation
+- Move back to Green only when the risk is genuinely resolved, not just paused
+- Document what changed when you change status — "Moved to Yellow because [reason]"
+
+## Risk Communication
+
+### ROAM Framework for Risk Management
+- **Resolved**: Risk is no longer a concern. Document how it was resolved.
+- **Owned**: Risk is acknowledged and someone is actively managing it. State the owner and the mitigation plan.
+- **Accepted**: Risk is known but we are choosing to proceed without mitigation. Document the rationale.
+- **Mitigated**: Actions have reduced the risk to an acceptable level. Document what was done.
+
+### Communicating Risks Effectively
+1. **State the risk clearly**: "There is a risk that [thing] happens because [reason]"
+2. **Quantify the impact**: "If this happens, the consequence is [impact]"
+3. **State the likelihood**: "This is [likely/possible/unlikely] because [evidence]"
+4. **Present the mitigation**: "We are managing this by [actions]"
+5. **Make the ask**: "We need [specific help] to further reduce this risk"
+
+### Common Mistakes in Risk Communication
+- Burying risks in good news. Lead with risks when they are important.
+- Being vague: "There might be some delays" — specify what, how long, and why.
+- Presenting risks without mitigations. Every risk should come with a plan.
+- Waiting too long. A risk communicated early is a planning input. A risk communicated late is a fire drill.
+
+## Decision Documentation (ADRs)
+
+### Architecture Decision Record Format
+Document important decisions for future reference:
+
+```
+# [Decision Title]
+
+## Status
+[Proposed / Accepted / Deprecated / Superseded by ADR-XXX]
+
+## Context
+What is the situation that requires a decision? What forces are at play?
+
+## Decision
+What did we decide? State the decision clearly and directly.
+
+## Consequences
+What are the implications of this decision?
+- Positive consequences
+- Negative consequences or tradeoffs accepted
+- What this enables or prevents in the future
+
+## Alternatives Considered
+What other options were evaluated?
+For each: what was it, why was it rejected?
+```
+
+### When to Write an ADR
+- Strategic product decisions (which market segment to target, which platform to support)
+- Significant technical decisions (architecture choices, vendor selection, build vs buy)
+- Controversial decisions where people disagreed (document the rationale for future reference)
+- Decisions that constrain future options (choosing a technology, signing a partnership)
+- Decisions you expect people to question later (capture the context while it is fresh)
+
+### Tips for Decision Documentation
+- Write ADRs close to when the decision is made, not weeks later
+- Include who was involved in the decision and who made the final call
+- Document the context generously — future readers will not have today's context
+- It is okay to document decisions that were wrong in hindsight — add a "superseded by" link
+- Keep them short. One page is better than five.
+
+## Meeting Facilitation
+
+### Stand-up / Daily Sync
+**Purpose**: Surface blockers, coordinate work, maintain momentum.
+**Format**: Each person shares:
+- What they accomplished since last sync
+- What they are working on next
+- What is blocking them
+
+**Facilitation tips**:
+- Keep it to 15 minutes. If discussions emerge, take them offline.
+- Focus on blockers — this is the highest-value part of standup
+- Track blockers and follow up on resolution
+- Cancel standup if there is nothing to sync on. Respect people's time.
+
+### Sprint / Iteration Planning
+**Purpose**: Commit to work for the next sprint. Align on priorities and scope.
+**Format**:
+1. Review: what shipped last sprint, what carried over, what was cut
+2. Priorities: what are the most important things to accomplish this sprint
+3. Capacity: how much can the team take on (account for PTO, on-call, meetings)
+4. Commitment: select items from the backlog that fit capacity and priorities
+5. Dependencies: flag any cross-team or external dependencies
+
+**Facilitation tips**:
+- Come with a proposed priority order. Do not ask the team to prioritize from scratch.
+- Push back on overcommitment. It is better to commit to less and deliver reliably.
+- Ensure every item has a clear owner and clear acceptance criteria.
+- Flag items that are underscoped or have hidden complexity.
+
+### Retrospective
+**Purpose**: Reflect on what went well, what did not, and what to change.
+**Format**:
+1. Set the stage: remind the team of the goal and create psychological safety
+2. Gather data: what went well, what did not go well, what was confusing
+3. Generate insights: identify patterns and root causes
+4. Decide actions: pick 1-3 specific improvements to try next sprint
+5. Close: thank people for honest feedback
+
+**Facilitation tips**:
+- Create psychological safety. People must feel safe to be honest.
+- Focus on systems and processes, not individuals.
+- Limit to 1-3 action items. More than that and nothing changes.
+- Follow up on previous retro action items. If you never follow up, people stop engaging.
+- Vary the retro format occasionally to prevent staleness.
+
+### Stakeholder Review / Demo
+**Purpose**: Show progress, gather feedback, build alignment.
+**Format**:
+1. Context: remind stakeholders of the goal and what they saw last time
+2. Demo: show what was built. Use real product, not slides.
+3. Metrics: share any early data or feedback
+4. Feedback: structured time for questions and input
+5. Next steps: what is coming next and when the next review will be
+
+**Facilitation tips**:
+- Demo the real product whenever possible. Slides are not demos.
+- Frame feedback collection: "What feedback do you have on X?" is better than "Any thoughts?"
+- Capture feedback visibly and commit to addressing it (or explaining why not)
+- Set expectations about what kind of feedback is actionable at this stage
+
+## Output Format
+
+Keep updates scannable. Use bold for key points, bullets for lists. Executive updates should be under 300 words. Engineering updates can be longer but should still be structured for skimming.
+
+## Tips
+
+- The most common mistake in stakeholder updates is burying the lead. Start with the most important thing.
+- Status colors (Green/Yellow/Red) should reflect reality, not optimism. Yellow is not a failure — it is good risk communication.
+- Asks should be specific and actionable. "We need help" is not an ask. "We need a decision on X by Friday" is.
+- For executives, frame everything in terms of outcomes and goals, not activities and tasks.
+- If there is bad news, lead with it. Do not hide it after good news.
+- Match the length to the audience's attention. Executives get a few bullets. Engineering gets the details they need.

package/content/product-management/skills/product-management-synthesize-research/SKILL.md

@@ -0,0 +1,312 @@
+---
+name: synthesize-research
+description: Synthesize user research from interviews, surveys, and feedback into structured insights. Use when you have a pile of interview notes, survey responses, or support tickets to make sense of, need to extract themes and rank findings by frequency and impact, or want to turn raw feedback into roadmap recommendations.
+argument-hint: "<research topic or question>"
+---
+
+# Synthesize Research
+
+> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).
+
+Synthesize user research from multiple sources into structured insights and recommendations.
+
+## Usage
+
+```
+/synthesize-research $ARGUMENTS
+```
+
+## Workflow
+
+### 1. Gather Research Inputs
+
+Accept research from any combination of:
+- **Pasted text**: Interview notes, transcripts, survey responses, feedback
+- **Uploaded files**: Research documents, spreadsheets, recordings summaries
+- **~~knowledge base** (if connected): Search for research documents, interview notes, survey results
+- **~~user feedback** (if connected): Pull recent support tickets, feature requests, bug reports
+- **~~product analytics** (if connected): Pull usage data, funnel metrics, behavioral data
+- **~~meeting transcription** (if connected): Pull interview recordings, meeting summaries, and discussion notes
+
+Ask the user what they have:
+- What type of research? (interviews, surveys, usability tests, analytics, support tickets, sales call notes)
+- How many sources / participants?
+- Is there a specific question or hypothesis they are investigating?
+- What decisions will this research inform?
+
+### 2. Process the Research
+
+For each source, extract:
+- **Key observations**: What did users say, do, or experience?
+- **Quotes**: Verbatim quotes that illustrate important points
+- **Behaviors**: What users actually did (vs what they said they do)
+- **Pain points**: Frustrations, workarounds, and unmet needs
+- **Positive signals**: What works well, moments of delight
+- **Context**: User segment, use case, experience level
+
+### 3. Identify Themes and Patterns
+
+Apply thematic analysis — see **Research Synthesis Methodology** below for detailed guidance on thematic analysis, affinity mapping, and triangulation techniques.
+
+Group observations into themes, count frequency across participants, and assess impact severity. Note contradictions and surprises.
+
+Create a priority matrix:
+- **High frequency + High impact**: Top priority findings
+- **Low frequency + High impact**: Important for specific segments
+- **High frequency + Low impact**: Quality-of-life improvements
+- **Low frequency + Low impact**: Note but deprioritize
+
+### 4. Generate the Synthesis
+
+Produce a structured research synthesis:
+
+#### Research Overview
+- Methodology: what types of research, how many participants/sources
+- Research question(s): what we set out to learn
+- Timeframe: when the research was conducted
+
+#### Key Findings
+For each major finding (aim for 5-8):
+- **Finding statement**: One clear sentence describing the insight
+- **Evidence**: Supporting quotes, data points, or observations (with source attribution)
+- **Frequency**: How many participants/sources support this finding
+- **Impact**: How significantly this affects the user experience or business
+- **Confidence level**: High (strong evidence), Medium (suggestive), Low (early signal)
+
+Order findings by priority (frequency x impact).
+
+#### User Segments / Personas
+If the research reveals distinct user segments:
+- Segment name and description
+- Key characteristics and behaviors
+- Unique needs and pain points
+- Size estimate if data is available
+
+#### Opportunity Areas
+Based on the findings, identify opportunity areas:
+- What user needs are unmet or underserved
+- Where do current solutions fall short
+- What new capabilities would unlock value
+- Prioritized by potential impact
+
+#### Recommendations
+Specific, actionable recommendations:
+- What to build, change, or investigate further
+- Tied back to specific findings
+- Prioritized by impact and feasibility
+
+#### Open Questions
+What the research did not answer:
+- Gaps in understanding
+- Areas needing further investigation
+- Suggested follow-up research methods
+
+### 5. Review and Extend
+
+After generating the synthesis:
+- Ask if any findings need more detail or different framing
+- Offer to generate specific artifacts: persona documents, opportunity maps, research presentations
+- Offer to create follow-up research plans for open questions
+- Offer to draft product implications (how findings should influence the roadmap)
+
+## Research Synthesis Methodology
+
+### Thematic Analysis
+The core method for synthesizing qualitative research:
+
+1. **Familiarization**: Read through all the data. Get a feel for the overall landscape before coding anything.
+2. **Initial coding**: Go through the data systematically. Tag each observation, quote, or data point with descriptive codes. Be generous with codes — it is easier to merge than to split later.
+3. **Theme development**: Group related codes into candidate themes. A theme captures something important about the data in relation to the research question.
+4. **Theme review**: Check themes against the data. Does each theme have sufficient evidence? Are themes distinct from each other? Do they tell a coherent story?
+5. **Theme refinement**: Define and name each theme clearly. Write a 1-2 sentence description of what each theme captures.
+6. **Report**: Write up the themes as findings with supporting evidence.
+
+### Affinity Mapping
+A collaborative method for grouping observations:
+
+1. **Capture observations**: Write each distinct observation, quote, or data point as a separate note
+2. **Cluster**: Group related notes together based on similarity. Do not pre-define categories — let them emerge from the data.
+3. **Label clusters**: Give each cluster a descriptive name that captures the common thread
+4. **Organize clusters**: Arrange clusters into higher-level groups if patterns emerge
+5. **Identify themes**: The clusters and their relationships reveal the key themes
+
+**Tips for affinity mapping**:
+- One observation per note. Do not combine multiple insights.
+- Move notes between clusters freely. The first grouping is rarely the best.
+- If a cluster gets too large, it probably contains multiple themes. Split it.
+- Outliers are interesting. Do not force every observation into a cluster.
+- The process of grouping is as valuable as the output. It builds shared understanding.
+
+### Triangulation
+Strengthen findings by combining multiple data sources:
+
+- **Methodological triangulation**: Same question, different methods (interviews + survey + analytics)
+- **Source triangulation**: Same method, different participants or segments
+- **Temporal triangulation**: Same observation at different points in time
+
+A finding supported by multiple sources and methods is much stronger than one supported by a single source. When sources disagree, that is interesting — it may reveal different user segments or contexts.
+
+## Interview Note Analysis
+
+### Extracting Insights from Interview Notes
+For each interview, identify:
+
+**Observations**: What did the participant describe doing, experiencing, or feeling?
+- Distinguish between behaviors (what they do) and attitudes (what they think/feel)
+- Note context: when, where, with whom, how often
+- Flag workarounds — these are unmet needs in disguise
+
+**Direct quotes**: Verbatim statements that powerfully illustrate a point
+- Good quotes are specific and vivid, not generic
+- Attribute to participant type, not name: "Enterprise admin, 200-person team" not "Sarah"
+- A quote is evidence, not a finding. The finding is your interpretation of what the quote means.
+
+**Behaviors vs stated preferences**: What people DO often differs from what they SAY they want
+- Behavioral observations are stronger evidence than stated preferences
+- If a participant says "I want feature X" but their workflow shows they never use similar features, note the contradiction
+- Look for revealed preferences through actual behavior
+
+**Signals of intensity**: How much does this matter to the participant?
+- Emotional language: frustration, excitement, resignation
+- Frequency: how often do they encounter this issue
+- Workarounds: how much effort do they expend working around the problem
+- Impact: what is the consequence when things go wrong
+
+### Cross-Interview Analysis
+After processing individual interviews:
+- Look for patterns: which observations appear across multiple participants?
+- Note frequency: how many participants mentioned each theme?
+- Identify segments: do different types of users have different patterns?
+- Surface contradictions: where do participants disagree? This often reveals meaningful segments.
+- Find surprises: what challenged your prior assumptions?
+
+## Survey Data Interpretation
+
+### Quantitative Survey Analysis
+- **Response rate**: How representative is the sample? Low response rates may introduce bias.
+- **Distribution**: Look at the shape of responses, not just averages. A bimodal distribution (lots of 1s and 5s) tells a different story than a normal distribution (lots of 3s).
+- **Segmentation**: Break down responses by user segment. Aggregates can mask important differences.
+- **Statistical significance**: For small samples, be cautious about drawing conclusions from small differences.
+- **Benchmark comparison**: How do scores compare to industry benchmarks or previous surveys?
+
+### Open-Ended Survey Response Analysis
+- Treat open-ended responses like mini interview notes
+- Code each response with themes
+- Count frequency of themes across responses
+- Pull representative quotes for each theme
+- Look for themes that appear in open-ended responses but not in structured questions — these are things you did not think to ask about
+
+### Common Survey Analysis Mistakes
+- Reporting averages without distributions. A 3.5 average could mean everyone is lukewarm or half love it and half hate it.
+- Ignoring non-response bias. The people who did not respond may be systematically different.
+- Over-interpreting small differences. A 0.1 point change in NPS is noise, not signal.
+- Treating Likert scales as interval data. The difference between "Strongly Agree" and "Agree" is not necessarily the same as between "Agree" and "Neutral."
+- Confusing correlation with causation in cross-tabulations.
+
+## Combining Qualitative and Quantitative Insights
+
+### The Qual-Quant Feedback Loop
+- **Qualitative first**: Interviews and observation reveal WHAT is happening and WHY. They generate hypotheses.
+- **Quantitative validation**: Surveys and analytics reveal HOW MUCH and HOW MANY. They test hypotheses at scale.
+- **Qualitative deep-dive**: Return to qualitative methods to understand unexpected quantitative findings.
+
+### Integration Strategies
+- Use quantitative data to prioritize qualitative findings. A theme from interviews is more important if usage data shows it affects many users.
+- Use qualitative data to explain quantitative anomalies. A drop in retention is a number; interviews reveal it is because of a confusing onboarding change.
+- Present combined evidence: "47% of surveyed users report difficulty with X (survey), and interviews reveal this is because Y (qualitative finding)."
+
+### When Sources Disagree
+- Quantitative and qualitative sources may tell different stories. This is signal, not error.
+- Check if the disagreement is due to different populations being measured
+- Check if stated preferences (survey) differ from actual behavior (analytics)
+- Check if the quantitative question captured what you think it captured
+- Report the disagreement honestly and investigate further rather than choosing one source
+
+## Persona Development from Research
+
+### Building Evidence-Based Personas
+Personas should emerge from research data, not imagination:
+
+1. **Identify behavioral patterns**: Look for clusters of similar behaviors, goals, and contexts across participants
+2. **Define distinguishing variables**: What dimensions differentiate one cluster from another? (e.g., company size, technical skill, usage frequency, primary use case)
+3. **Create persona profiles**: For each behavioral cluster:
+   - Name and brief description
+   - Key behaviors and goals
+   - Pain points and needs
+   - Context (role, company, tools used)
+   - Representative quotes
+4. **Validate with data**: Can you size each persona segment using quantitative data?
+
+### Persona Template
+```
+[Persona Name] — [One-line description]
+
+Who they are:
+- Role, company type/size, experience level
+- How they found/started using the product
+
+What they are trying to accomplish:
+- Primary goals and jobs to be done
+- How they measure success
+
+How they use the product:
+- Frequency and depth of usage
+- Key workflows and features used
+- Tools they use alongside this product
+
+Key pain points:
+- Top 3 frustrations or unmet needs
+- Workarounds they have developed
+
+What they value:
+- What matters most in a solution
+- What would make them switch or churn
+
+Representative quotes:
+- 2-3 verbatim quotes that capture this persona's perspective
+```
+
+### Common Persona Mistakes
+- Demographic personas: defining by age/gender/location instead of behavior. Behavior predicts product needs better than demographics.
+- Too many personas: 3-5 is the sweet spot. More than that and they are not actionable.
+- Fictional personas: made up based on assumptions rather than research data.
+- Static personas: never updated as the product and market evolve.
+- Personas without implications: a persona that does not change any product decisions is not useful.
+
+## Opportunity Sizing
+
+### Estimating Opportunity Size
+For each research finding or opportunity area, estimate:
+
+- **Addressable users**: How many users could benefit from addressing this? Use product analytics, survey data, or market data to estimate.
+- **Frequency**: How often do affected users encounter this issue? (Daily, weekly, monthly, one-time)
+- **Severity**: How much does this issue impact users when it occurs? (Blocker, significant friction, minor annoyance)
+- **Willingness to pay**: Would addressing this drive upgrades, retention, or new customer acquisition?
+
+### Opportunity Scoring
+Score opportunities on a simple matrix:
+
+- **Impact**: (Users affected) x (Frequency) x (Severity) = impact score
+- **Evidence strength**: How confident are we in the finding? (Multiple sources > single source, behavioral data > stated preferences)
+- **Strategic alignment**: Does this opportunity align with company strategy and product vision?
+- **Feasibility**: Can we realistically address this? (Technical feasibility, resource availability, time to impact)
+
+### Presenting Opportunity Sizing
+- Be transparent about assumptions and confidence levels
+- Show the math: "Based on support ticket volume, approximately 2,000 users per month encounter this issue. Interview data suggests 60% of them consider it a significant blocker."
+- Use ranges rather than false precision: "This affects 1,500-2,500 users monthly" not "This affects 2,137 users monthly"
+- Compare opportunities against each other to create a relative ranking, not just absolute scores
+
+## Output Format
+
+Use clear headers and structured formatting. Each finding should stand on its own — a reader should be able to read any single finding and understand it without reading the rest.
+
+## Tips
+
+- Let the data speak. Do not force findings into a predetermined narrative.
+- Distinguish between what users say and what they do. Behavioral data is stronger than stated preferences.
+- Quotes are powerful evidence. Include them generously, with attribution to participant type (not name).
+- Be explicit about confidence levels. A finding from 2 interviews is a hypothesis, not a conclusion.
+- Contradictions in the data are interesting, not inconvenient. They often reveal distinct user segments.
+- Recommendations should be specific enough to act on. "Improve onboarding" is not actionable. "Add a progress indicator to the setup flow" is.
+- Resist the temptation to synthesize too many themes. 5-8 strong findings are better than 20 weak ones.