Skill 寫法圖鑑

synthesize-research

Anthropic | 規劃與釐清 | 原文 | Apache-2.0

把訪談、問卷和回饋綜整成主題、發現和 roadmap 建議

中文翻譯

---
name: synthesize-research
description: 把訪談、問卷和回饋裡的使用者研究,綜整成有結構的洞察。用於手上有一堆訪談筆記、問卷回覆或客服工單要釐清、需要抽出主題並依頻率與影響力排序發現,或想把原始回饋變成 roadmap 建議時。
argument-hint: "<research topic or question>"
---

# 綜整研究(Synthesize Research)

> 如果看到不認識的 placeholder,或需要確認目前連了哪些工具,請看 [CONNECTORS.md](../../CONNECTORS.md)。

把來自多個來源的使用者研究,綜整成有結構的洞察和建議。

## 用法

```
/synthesize-research $ARGUMENTS
```

## 工作流程

### 1. 蒐集研究輸入

接受下列任何組合的研究:
- **貼上的文字**:訪談筆記、逐字稿、問卷回覆、回饋
- **上傳的檔案**:研究文件、試算表、錄影摘要
- **~~knowledge base**(如果有連上):搜尋研究文件、訪談筆記、問卷結果
- **~~user feedback**(如果有連上):拉最近的客服工單、功能需求、bug 回報
- **~~product analytics**(如果有連上):拉使用資料、漏斗指標、行為資料
- **~~meeting transcription**(如果有連上):拉訪談錄音、會議摘要和討論筆記

問使用者手上有什麼:
- 是哪一種研究?(訪談、問卷、可用性測試、分析資料、客服工單、業務通話筆記)
- 有多少來源/受訪者?
- 有沒有他們正在調查的特定問題或假設?
- 這份研究要支援哪些決策?

### 2. 處理研究

從每個來源擷取:
- **關鍵觀察**:使用者說了什麼、做了什麼、經歷了什麼?
- **引言**:能說明重點的逐字引言
- **行為**:使用者實際做了什麼(對比他們說自己會做什麼)
- **痛點**:挫折、變通做法和未被滿足的需求
- **正面訊號**:什麼運作得好、讓人開心的時刻
- **背景**:使用者族群、使用情境、經驗程度

### 3. 找出主題和模式

套用主題分析(thematic analysis),主題分析、親和圖(affinity mapping)和三角驗證(triangulation)技巧的詳細說明,請見下面的**研究綜整方法論**。

把觀察歸成主題,計算各主題在受訪者之間出現的頻率,並評估影響的嚴重程度。記下矛盾和意外。

建立優先順序矩陣:
- **高頻率 + 高影響**:最優先的發現
- **低頻率 + 高影響**:對特定族群很重要
- **高頻率 + 低影響**:使用體驗上的改善
- **低頻率 + 低影響**:記下來但降低優先順序

### 4. 產出綜整

產出有結構的研究綜整:

#### 研究概覽
- 方法:哪幾種研究、多少受訪者/來源
- 研究問題:我們想學到什麼
- 時間範圍:研究是什麼時候進行的

#### 關鍵發現
針對每個主要發現(目標 5 到 8 個):
- **發現陳述**:用一句清楚的話描述這個洞察
- **證據**:支持的引言、資料點或觀察(標明來源)
- **頻率**:有多少受訪者/來源支持這個發現
- **影響**:它對使用者體驗或業務的影響有多大
- **信心程度**:High(證據強)、Medium(有跡象)、Low(早期訊號)

發現依優先順序排列(頻率 x 影響)。

#### 使用者族群/Persona
如果研究揭露了不同的使用者族群:
- 族群名稱和描述
- 關鍵特徵和行為
- 獨特的需求和痛點
- 有資料的話,附上規模估計

#### 機會領域
根據發現,找出機會領域:
- 哪些使用者需求沒被滿足或服務不足
- 現有解法在哪裡不夠
- 哪些新能力能釋放價值
- 依潛在影響排序

#### 建議
具體、可執行的建議:
- 要做什麼、改什麼,或進一步調查什麼
- 連回特定的發現
- 依影響和可行性排序

#### 未解問題
研究沒有回答的事:
- 理解上的缺口
- 需要進一步調查的領域
- 建議的後續研究方法

### 5. 檢視與延伸

產出綜整之後:
- 問有沒有哪些發現需要更多細節,或換個框架來講
- 提議產出特定的成品:persona 文件、機會地圖、研究簡報
- 提議針對未解問題建立後續研究計畫
- 提議草擬對產品的影響(發現應該如何影響 roadmap)

## 研究綜整方法論

### 主題分析(Thematic Analysis)
綜整質性研究的核心方法:

1. **熟悉資料**:把所有資料讀過一遍。在編碼任何東西之前,先感受整體的樣貌。
2. **初步編碼**:有系統地走過資料。用描述性的 code 標記每一個觀察、引言或資料點。code 要放寬一點下,之後合併比拆開容易。
3. **發展主題**:把相關的 code 歸成候選主題。一個主題要抓住資料裡跟研究問題有關的重要東西。
4. **檢視主題**:拿主題去對照資料。每個主題的證據夠不夠?主題彼此是否互相區隔?它們合起來是否講得出一個連貫的故事?
5. **精煉主題**:清楚定義並命名每個主題。為每個主題寫 1 到 2 句話,說明它抓住了什麼。
6. **報告**:把主題寫成附證據的發現。

### 親和圖(Affinity Mapping)
用來歸類觀察的協作方法:

1. **蒐集觀察**:把每一個獨立的觀察、引言或資料點,各寫成一張獨立的便利貼
2. **分群**:依相似度把相關的便利貼放在一起。不要預先定義類別,讓它們從資料裡浮現。
3. **標記群組**:替每個群組取一個能抓住共通脈絡的描述性名稱
4. **整理群組**:如果浮現模式,就把群組排成更高層級的組別
5. **找出主題**:群組以及它們之間的關係,揭露了關鍵主題

**親和圖的提醒**:
- 一張便利貼一個觀察。不要把多個洞察合在一起。
- 便利貼可以在群組之間自由移動。第一次的分組很少是最好的。
- 如果某個群組變得太大,它大概包含了多個主題。把它拆開。
- 離群值很有意思。不要硬把每個觀察塞進群組。
- 分組的過程跟成果一樣有價值,它能建立共同的理解。

### 三角驗證(Triangulation)
結合多個資料來源來強化發現:

- **方法三角驗證**:同一個問題,用不同方法(訪談 + 問卷 + 分析資料)
- **來源三角驗證**:同一個方法,用不同的受訪者或族群
- **時間三角驗證**:在不同時間點觀察到同樣的現象

被多個來源和方法支持的發現,比只有單一來源支持的強得多。當來源之間不一致,那很有意思,可能揭露了不同的使用者族群或情境。

## 訪談筆記分析

### 從訪談筆記擷取洞察
針對每一場訪談,找出:

**觀察**:受訪者描述了自己做了什麼、經歷了什麼或感受到什麼?
- 區分行為(他們做什麼)和態度(他們想什麼/感覺什麼)
- 記下背景:何時、何地、跟誰、多常發生
- 標出變通做法,那是偽裝起來的未滿足需求

**直接引言**:能有力說明某個重點的逐字陳述
- 好的引言要具體、生動,不要空泛
- 標示為受訪者類型,不要標名字:「Enterprise admin, 200-person team」而不是「Sarah」
- 引言是證據,不是發現。發現是你對這段引言意義的詮釋。

**行為 vs. 口述的偏好**:人們「做」的常常跟他們「說」想要的不一樣
- 行為觀察是比口述偏好更強的證據
- 如果受訪者說「我想要功能 X」,但他的工作流程顯示他從來不用類似的功能,就把這個矛盾記下來
- 從實際行為去找他們透過行動顯露出來的偏好

**強度的訊號**:這件事對受訪者有多重要?
- 情緒用語:挫折、興奮、無奈
- 頻率:他們多常遇到這個問題
- 變通做法:他們花多少力氣繞過這個問題
- 影響:事情出錯時會有什麼後果

### 跨訪談分析
處理完個別訪談之後:
- 找模式:哪些觀察在多位受訪者身上都出現?
- 記下頻率:有多少受訪者提到每個主題?
- 找出族群:不同類型的使用者是否有不同的模式?
- 挖出矛盾:受訪者在哪些地方意見不一致?這常常會揭露有意義的族群。
- 找出意外:什麼挑戰了你先前的假設?

## 問卷資料解讀

### 量化問卷分析
- **回應率**:樣本的代表性如何?低回應率可能帶來偏差。
- **分布**:看回應的形狀,不只看平均值。雙峰分布(很多 1 和很多 5)講的故事,跟常態分布(很多 3)不一樣。
- **分群**:依使用者族群拆開回應。總體數字可能蓋住重要的差異。
- **統計顯著性**:樣本小的時候,對小差異做出結論要謹慎。
- **基準比較**:分數跟產業基準或先前的問卷比起來如何?

### 開放式問卷回應分析
- 把開放式回應當成迷你的訪談筆記
- 用主題為每則回應編碼
- 計算各主題在回應中出現的頻率
- 為每個主題挑出有代表性的引言
- 找出在開放式回應裡出現、但結構化問題沒有的主題,這些是你沒想到要問的事

### 常見的問卷分析錯誤
- 只報告平均值、不報告分布。3.5 的平均可能代表大家都不溫不火,也可能是一半很愛、一半很討厭。
- 忽略未回應偏差。沒回應的人可能有系統性的不同。
- 過度解讀小差異。NPS 變動 0.1 分是雜訊,不是訊號。
- 把 Likert 量表當成等距資料。「Strongly Agree」和「Agree」之間的差距,不一定等於「Agree」和「Neutral」之間的差距。
- 在交叉分析裡把相關性當成因果。

## 結合質性與量化洞察

### 質性與量化的回饋迴圈
- **先質性**:訪談和觀察揭露「什麼」正在發生以及「為什麼」,它們產生假設。
- **量化驗證**:問卷和分析資料揭露「多少」和「多少人」,它們在規模上檢驗假設。
- **質性深入**:回頭用質性方法,去理解意料之外的量化發現。

### 整合策略
- 用量化資料來排序質性發現。如果使用資料顯示影響很多使用者,訪談出現的主題就更重要。
- 用質性資料來解釋量化的異常。留存率下降只是個數字,訪談才會揭露原因是 onboarding 改版讓人困惑。
- 呈現結合後的證據:「47% 的受訪使用者表示 X 有困難(問卷),而訪談揭露這是因為 Y(質性發現)。」

### 當來源之間不一致
- 量化和質性來源可能講出不同的故事。這是訊號,不是錯誤。
- 檢查不一致是否因為量到的是不同的族群
- 檢查口述偏好(問卷)是否跟實際行為(分析資料)不同
- 檢查量化的問題是否真的抓到你以為它抓到的東西
- 誠實報告這個不一致,並進一步調查,而不是在兩個來源之間選邊

## 從研究發展 Persona

### 建立有證據基礎的 Persona
Persona 應該從研究資料浮現,不是靠想像:

1. **找出行為模式**:在受訪者之間,找行為、目標和情境相似的群集
2. **定義區分變數**:什麼維度能區分一個群集和另一個?(例如公司規模、技術能力、使用頻率、主要使用情境)
3. **建立 persona 檔案**:針對每個行為群集:
   - 名稱和簡短描述
   - 關鍵行為和目標
   - 痛點和需求
   - 背景(角色、公司、使用的工具)
   - 有代表性的引言
4. **用資料驗證**:你能用量化資料估算每個 persona 族群的規模嗎?

### Persona 範本
```
[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
```

### 常見的 Persona 錯誤
- 人口統計式 persona:用年齡/性別/地點來定義,而不是用行為。行為比人口統計更能預測產品需求。
- Persona 太多:3 到 5 個最剛好。再多就沒辦法據以行動。
- 虛構的 persona:根據假設編出來,而不是根據研究資料。
- 靜態的 persona:隨著產品和市場演進,從來沒更新過。
- 沒有影響的 persona:一個不會改變任何產品決策的 persona 沒有用。

## 機會規模評估

### 估算機會規模
針對每個研究發現或機會領域,估算:

- **可觸及的使用者**:解決這個問題能讓多少使用者受益?用產品分析、問卷資料或市場資料來估算。
- **頻率**:受影響的使用者多常遇到這個問題?(每天、每週、每月、一次性)
- **嚴重程度**:這個問題發生時,對使用者影響多大?(阻擋性、明顯的摩擦、輕微的困擾)
- **付費意願**:解決這個問題會不會帶動升級、留存或新客戶獲取?

### 機會評分
用簡單的矩陣替機會打分數:

- **影響**:(受影響的使用者)x(頻率)x(嚴重程度)= 影響分數
- **證據強度**:我們對這個發現有多少信心?(多個來源 > 單一來源,行為資料 > 口述偏好)
- **策略一致性**:這個機會是否符合公司策略和產品願景?
- **可行性**:我們實際上做得到嗎?(技術可行性、資源可用性、見效時間)

### 呈現機會規模評估
- 對假設和信心程度要透明
- 把算式秀出來:「根據客服工單量,每個月大約有 2,000 位使用者遇到這個問題。訪談資料顯示,其中 60% 認為它是重大阻礙。」
- 用區間,不要假裝精確:「這每月影響 1,500 到 2,500 位使用者」而不是「這每月影響 2,137 位使用者」
- 把機會彼此比較,做出相對排名,不要只給絕對分數

## 輸出格式

使用清楚的標題和有結構的格式。每個發現都應該能獨立成立:讀者讀任何單一發現,不用讀其他部分就能理解。

## 小提醒

- 讓資料自己說話。不要把發現硬塞進預設的敘事。
- 區分使用者說的和使用者做的。行為資料比口述偏好更強。
- 引言是有力的證據。多放一點,並標示為受訪者類型(不要標名字)。
- 對信心程度要明確。只來自 2 場訪談的發現是假設,不是結論。
- 資料裡的矛盾是有意思的,不是麻煩。它們常常揭露不同的使用者族群。
- 建議要具體到可以行動。「改善 onboarding」沒辦法行動。「在設定流程加上進度指示器」可以。
- 忍住綜整出太多主題的誘惑。5 到 8 個強的發現,比 20 個弱的好。

英文原文

---
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.