Product Launch Research with Ditto + Claude Code

LLM summary: Run a 7-question pre-launch concept validation study and a 5-question post-launch sentiment study to produce six launch deliverables plus a Launch Impact Report in ~75 minutes.

A complete Claude Code guide to researching product launches using Ditto's 300,000+ synthetic personas. Two phases — pre-launch concept validation and post-launch sentiment measurement — compressed from six weeks to 75 minutes.

1. Why Product Launch Research Matters

Product launches have two research phases that most companies skip: pre-launch concept validation and post-launch sentiment measurement. They skip them because traditional research takes too long. By the time a focus group delivers findings, the launch window has closed or the budget is committed.

The result: products launch on assumption. The founding team assumes the concept resonates. The product team assumes the feature priority is right. The marketing team assumes the messaging will land. The pricing team assumes the price feels fair. These assumptions compound into a launch that looks prepared on a slide but misfires on contact with the market.

The Traditional Launch Research Problem

With Ditto and Claude Code, pre-launch concept validation takes approximately 45 minutes (7 questions, 10 personas). Post-launch sentiment measurement takes approximately 30 minutes (5 questions, fresh group). The total — 75 minutes — replaces 4–8 weeks and $15,000–$50,000 of traditional research.

2. The Two-Phase Approach

Product launch research has two distinct phases, each with a specific purpose, timing, and question set. They are designed to work together as a before-and-after pair around the launch moment.

Why Two Separate Phases

• Different groups, different perspective. Pre-launch uses a group who hasn't heard of the product. Post-launch uses a fresh group who may or may not have encountered it. This captures market-level awareness, not just the reactions of people you've primed.
• Different questions, different purpose. Pre-launch asks "Would this resonate?" Post-launch asks "How is this landing?" The first informs what to build and how to position it. The second informs what to adjust and where to invest next.
• The comparison is the insight. When pre-launch personas say "This sounds exciting, I'd try it immediately" but post-launch personas say "I've heard of it but it seems like [competitor] with a different logo," you have a messaging problem. When pre-launch says "Price feels fair" but post-launch says "It's expensive compared to [competitor]," you have a positioning problem. The gap between expectation and reality is where the learning lives.

3. The 7-Question Pre-Launch Concept Validation Study

This question set is designed to produce the raw material for all six launch readiness deliverables simultaneously. Each question targets a specific launch concern while feeding multiple outputs. Questions must be asked sequentially (each builds conversational context from prior answers).

Why This Question Sequence Works for Launch Research

• Q1 captures unfiltered first impressions. Before the persona has time to rationalise, you capture the raw emotional reaction: excitement, scepticism, confusion, indifference. If 7/10 say "that sounds confusing" before any follow-up questions, you have a clarity problem that no amount of feature work will fix.
• Q2 tests whether the concept fits real life. Enthusiasm in Q1 doesn't guarantee adoption. Q2 forces personas to place the product in their actual workflow. "I'd use it every morning before standup" is a different signal from "I'm not sure when I'd use it." Specificity of use case correlates with adoption likelihood.
• Q3 reveals what matters most. Not what you think the hero feature is, but what the market thinks. When 8/10 personas say they'd try the collaboration feature first, but your launch plan leads with the analytics dashboard, you've misread the priority.
• Q4 identifies the objections you'll face. Every barrier mentioned is an objection your sales, marketing, and onboarding teams need a response for. "I wouldn't trust my data with a new company" appears consistently across categories. "Switching from [competitor] would take weeks" reveals migration concerns that require a launch-day solution.
• Q5 is the natural language goldmine. How personas describe the product in their own words is how your marketing copy should read. If 6/10 say "It's basically [simple description]" but your landing page says something entirely different, you have a messaging-market mismatch. These one-sentence descriptions become headline candidates.
• Q6 anchors pricing before launch commitment. Three data points per persona: expected price, steal price, and too-expensive price. The spread tells you whether your target market has a narrow or wide price tolerance. A narrow spread (everyone says $20–30) means precise pricing is critical. A wide spread ($10–$100) means segments have radically different willingness to pay.
• Q7 captures what's missing. This is the post-launch roadmap written by your target market. "If it had [X], I'd switch immediately" is a feature request with conversion intent attached. "Nothing is missing, it's perfect" (rare) is the strongest possible launch signal.

4. Complete API Workflow: Step by Step

Prerequisites

• Ditto API key (see installation guide for access)
• A 2–3 sentence product/feature description suitable for Q1
• The 7 pre-launch questions above, customised with your product context

Step 1: Create Research Group

curl -s -X POST "https://app.askditto.io/v1/research-groups/recruit" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Pre-Launch Validation - [Product Name] - [Date]",
    "description": "Target customers for pre-launch concept validation of [product description]. [Add context about ideal customer profile, industry, demographics.]",
    "group_size": 10,
    "filters": {
      "country": "USA",
      "age_min": 25,
      "age_max": 50,
      "employment": "employed"
    },
    "sampling_method": "random",
    "deduplicate": true
  }'

Step 2: Create Study

curl -s -X POST "https://app.askditto.io/v1/research-studies" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Pre-Launch Validation: [Product Name] - [Date]",
    "research_group_uuid": "GROUP_UUID_FROM_STEP_1"
  }'

Save the study id — you need it for asking questions, completing, and sharing.

Step 3: Ask Questions (Sequential)

Ask each question one at a time. Wait for the job to complete before sending the next. This ensures personas have conversational context from prior answers.

# Question 1
curl -s -X POST "https://app.askditto.io/v1/research-studies/STUDY_ID/questions" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "question": "When you first hear about [product/feature description], what comes to mind? What excites you? What makes you sceptical?"
  }'

# Response includes a job ID:
# { "job_id": "job-abc123", "status": "pending" }

Step 4: Poll for Responses

# Poll until status is "finished"
curl -s -X GET "https://app.askditto.io/v1/jobs/JOB_ID" \
  -H "Authorization: Bearer YOUR_API_KEY"

# When complete:
{
  "id": "job-abc123",
  "status": "finished",
  "result": {
    "answer": "My first reaction is..."
  }
}

Poll with a 5-second interval. Most questions complete within 30–90 seconds. Once complete, send the next question. Repeat for all 7 questions.

Step 5: Complete the Study

curl -s -X POST "https://app.askditto.io/v1/research-studies/STUDY_ID/complete" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json"

This triggers Ditto's AI analysis, producing: overall summary, key segments identified, divergence points, shared mindsets, and suggested follow-up questions. Poll the study status until it reaches "completed".

Step 6: Get Share Link

curl -s -X POST "https://app.askditto.io/v1/research-studies/STUDY_ID/share" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json"

# Response:
{
  "url": "https://app.askditto.io/organization/studies/shared/xyz123"
}

Step 7: Retrieve Full Study Data for Deliverable Generation

# Get the completed study with all responses and AI analysis
curl -s -X GET "https://app.askditto.io/v1/research-studies/STUDY_ID" \
  -H "Authorization: Bearer YOUR_API_KEY"

This returns all persona responses, demographic profiles, and Ditto's completion analysis. Use this data to generate the six launch readiness deliverables described in the next section.

5. Generating the Six Launch Readiness Deliverables

Once the pre-launch study is complete and you have all 10 persona responses to all 7 questions, Claude Code should generate each deliverable using the extraction logic below.

Deliverable 1: Launch Readiness Scorecard

Source Data

• Primary: Q1 responses (initial reaction — excitement vs scepticism)
• Secondary: Q2 (use case clarity), Q3 (feature demand), Q5 (descriptive clarity)

Extraction Logic

1. From Q1, score each persona's reaction on a 5-point scale: Strong Positive (5), Positive (4), Neutral (3), Negative (2), Strong Negative (1). Use language cues: "love this," "excited" = 4–5. "Interesting but..." = 3. "I don't see the point" = 1–2.
2. From Q2, score use case specificity: Vivid and specific (5), General but plausible (3), Vague or forced (1).
3. From Q3, check whether first-try features align with planned hero features. Alignment score: High (same feature), Medium (related), Low (different feature).
4. From Q5, score description accuracy: captures the core value (5), partially captures it (3), misses it entirely (1).
5. Aggregate into an overall launch readiness score (average of all dimensions).

Output Format

## Launch Readiness Scorecard: [Product/Feature]

### Overall Score: X.X / 5.0 [READY / NEEDS WORK / NOT READY]

| Dimension | Score | Evidence | Implication |
|-----------|-------|----------|-------------|
| Concept Resonance (Q1) | X.X/5 | X/10 positive, X/10 neutral, X/10 negative | [Interpretation] |
| Use Case Clarity (Q2) | X.X/5 | X/10 vivid use cases, X/10 vague | [Interpretation] |
| Feature Alignment (Q3) | High/Med/Low | Hero feature matched X/10 first-try choices | [Interpretation] |
| Descriptive Clarity (Q5) | X.X/5 | X/10 accurately described the concept | [Interpretation] |

### Launch Readiness Verdict
- **Score 4.0+:** Strong launch signal. Concept resonates, use cases are clear, features align.
- **Score 3.0-3.9:** Conditional launch. Specific improvements needed before go.
- **Score below 3.0:** Reconsider. Concept needs significant rework or repositioning.

### Top 3 Strengths
1. [What resonated most strongly across personas]
2. [Second strongest signal]
3. [Third]

### Top 3 Concerns
1. [Most common hesitation or objection]
2. [Second]
3. [Third]

Deliverable 2: Feature Priority Ranking

Source Data

• Primary: Q3 responses (first feature they'd try)
• Secondary: Q2 (how they'd use it), Q7 (what's missing)

Extraction Logic

1. From Q3, extract every feature or capability mentioned as the first thing they'd try.
2. Count frequency: how many of 10 personas mentioned each feature.
3. From Q2, identify which features appear in the described workflow (implicit priority).
4. From Q7, identify requested features that don't exist yet (gap features).
5. Rank features by combined frequency from Q3 + Q2, then append gap features from Q7.

Output Format

## Feature Priority Ranking: [Product/Feature]

### Existing Features (Ranked by Customer Demand)
| Rank | Feature | Q3 First-Try | Q2 In-Workflow | Representative Quote |
|------|---------|-------------|----------------|---------------------|
| 1 | [Feature A] | 7/10 | 8/10 | "This is the first thing I'd click on" |
| 2 | [Feature B] | 4/10 | 6/10 | "I'd use this every day in my standup" |
| 3 | [Feature C] | 2/10 | 3/10 | "Nice to have but not why I'd sign up" |

### Gap Features (Requested but Not Planned)
| Feature Request | Frequency | Representative Quote | Priority |
|----------------|-----------|---------------------|----------|
| [Gap 1] | 5/10 | "If it had this, I'd switch immediately" | High |
| [Gap 2] | 3/10 | "Would be nice but not essential" | Medium |

### Launch Implication
Lead with [Feature A] in launch messaging and onboarding.
[Feature C] can be deprioritised or moved to a later release.
[Gap 1] should be on the immediate post-launch roadmap.

Deliverable 3: Objection Library

Source Data

• Primary: Q4 responses (what would stop them)
• Secondary: Q1 (scepticism signals), Q7 (concerns disguised as feature requests)

Extraction Logic

1. From Q4, extract every barrier, concern, or objection mentioned.
2. Categorise each objection: Trust, Price, Complexity, Switching Cost, Competition, Missing Feature, Other.
3. Count frequency per category and per specific objection.
4. From Q1, capture scepticism signals that represent latent objections.
5. For each objection, draft a response using evidence from the study itself (e.g., positive signals from other personas).

Output Format

## Objection Library: [Product/Feature]

### Objection Frequency
| Category | Frequency | Top Specific Objection |
|----------|-----------|----------------------|
| Trust / Security | X/10 | "I wouldn't trust my data with a new company" |
| Price | X/10 | "Seems expensive for what it does" |
| Switching Cost | X/10 | "Migration from [competitor] would take weeks" |
| Complexity | X/10 | "Looks like it has a learning curve" |
| Competition | X/10 | "How is this different from [competitor]?" |

### Objection-Response Pairs
| Objection | Frequency | Suggested Response | Evidence |
|-----------|-----------|-------------------|----------|
| "I don't trust new companies with my data" | 4/10 | [SOC 2 certification, data residency, encryption details] | Persona 3: "If they had SOC 2, I'd feel better" |
| "Seems expensive" | 3/10 | [Value comparison, ROI framing from Q2 use cases] | Persona 7: "If it saved me 2 hours a week, $X is nothing" |
| "Switching would be painful" | 3/10 | [Migration support, import tools, parallel running] | Persona 5: "If they handled the migration, I'd consider it" |

### Pre-Launch Actions
1. [Address top objection before launch with specific deliverable]
2. [Address second objection with specific content/feature]
3. [Monitor third objection post-launch for frequency]

Deliverable 4: Natural Language Bank

Source Data

• Primary: Q5 responses (describe it in one sentence)
• Secondary: Q1 (first-impression language), Q2 (workflow language)

Extraction Logic

1. From Q5, collect all 10 one-sentence descriptions verbatim.
2. Identify recurring phrases, metaphors, and framing patterns.
3. From Q1, extract emotional language (positive and negative) used to describe the concept.
4. From Q2, extract workflow-specific language that describes how the product fits their life.
5. Organise by usage category: headline candidates, tagline candidates, feature descriptions, value propositions.

Output Format

## Natural Language Bank: [Product/Feature]

### One-Sentence Descriptions (Q5, verbatim)
1. "It's like [comparison] but for [specific use case]" (Persona 1)
2. "A tool that [simple action] so you can [outcome]" (Persona 2)
...
10. "[Description]" (Persona 10)

### Recurring Language Patterns
| Pattern | Frequency | Example |
|---------|-----------|---------|
| "[Comparison] for [use case]" | 4/10 | "Figma for customer research" |
| "Finally, a way to [outcome]" | 3/10 | "Finally, a way to test ideas without waiting weeks" |
| "Like having a [role] on demand" | 2/10 | "Like having a focus group on demand" |

### Headline Candidates (from persona language)
1. "[Most common one-sentence description, refined]"
2. "[Second most common framing]"
3. "[Most emotionally resonant phrase from Q1]"

### Words That Resonate (positive signals)
[fast, easy, finally, game-changer, exactly what I need, ...]

### Words That Concern (negative signals)
[complicated, another tool, expensive, not sure how, ...]

### Marketing Copy Recommendations
- **Landing page headline:** Use the "[comparison] for [use case]" framing — it's how your market naturally describes you
- **Tagline:** "[Refined version of most common Q5 description]"
- **Avoid:** [Words/phrases that triggered negative reactions in Q1]

Deliverable 5: Pricing Recommendation

Source Data

• Primary: Q6 responses (expected price, steal price, too-expensive price)
• Secondary: Q4 (price as barrier), Q2 (value perception from use case depth)

Extraction Logic

1. From Q6, extract three data points per persona: expected price, steal threshold, and too-expensive threshold.
2. Calculate ranges and medians for each threshold.
3. Identify the "acceptable range" (between median steal and median too-expensive).
4. Cross-reference with Q4: how many mentioned price as a barrier?
5. From Q2, assess depth of use case engagement — more engaged users tolerate higher prices.

Output Format

## Pricing Recommendation: [Product/Feature]

### Raw Price Perception (Q6)
| Persona | Expected Price | Steal Price | Too Expensive |
|---------|---------------|-------------|---------------|
| P1 | $X/mo | $X/mo | $X/mo |
| P2 | $X/mo | $X/mo | $X/mo |
...
| P10 | $X/mo | $X/mo | $X/mo |

### Price Thresholds
| Threshold | Median | Range |
|-----------|--------|-------|
| Expected (fair) | $X/mo | $X - $X |
| Steal (great deal) | $X/mo | $X - $X |
| Too expensive | $X/mo | $X - $X |

### Acceptable Price Range: $[steal median] - $[too-expensive median]
### Recommended Launch Price: $X/mo

### Rationale
- [Why this specific price point within the acceptable range]
- Price as barrier (Q4): X/10 mentioned price concerns at [proposed price]
- Use case engagement (Q2): [High/medium/low] engagement suggests [higher/lower] price tolerance

### Price-Sensitivity Segments
- **Price-sensitive group (X personas):** Expect $X or less, cite [reasons]
- **Value-focused group (X personas):** Accept $X-$X, cite [value drivers]
- **Premium-tolerant group (X personas):** Would pay $X+, cite [willingness drivers]

Deliverable 6: Risk Register

Source Data

• Primary: Q4 (barriers), Q7 (feature gaps)
• Secondary: Q1 (scepticism signals), Q6 (pricing risks)

Extraction Logic

1. From Q4, extract all barriers and assess severity (blocks adoption vs delays adoption vs minor concern).
2. From Q7, extract all feature gaps and assess impact (must-have vs nice-to-have).
3. From Q1, extract scepticism signals that could become public objections post-launch.
4. From Q6, identify pricing risks (wide spread, many "too expensive" responses, segment-specific sensitivity).
5. Score each risk by likelihood (frequency in study) and impact (severity of consequence).

Output Format

## Risk Register: [Product/Feature]

### Critical Risks (address before launch)
| Risk | Source | Likelihood | Impact | Mitigation |
|------|--------|-----------|--------|------------|
| [Trust/security concern] | Q4 (6/10) | High | High | [Specific action: SOC 2, security page, etc.] |
| [Missing must-have feature] | Q7 (5/10) | High | High | [Build before launch or address in launch messaging] |

### Moderate Risks (address in launch plan)
| Risk | Source | Likelihood | Impact | Mitigation |
|------|--------|-----------|--------|------------|
| [Pricing perception] | Q6 (4/10 say "expensive") | Medium | Medium | [Adjust pricing or improve value communication] |
| [Switching barrier] | Q4 (3/10) | Medium | Medium | [Migration support, import tools] |

### Low Risks (monitor post-launch)
| Risk | Source | Likelihood | Impact | Mitigation |
|------|--------|-----------|--------|------------|
| [Minor feature gap] | Q7 (2/10) | Low | Low | [Add to post-launch roadmap] |
| [Niche scepticism] | Q1 (1/10) | Low | Low | [Monitor for frequency increase] |

### Overall Risk Assessment: [GREEN / AMBER / RED]
- GREEN: No critical risks. Launch with confidence.
- AMBER: 1-2 critical risks that can be mitigated before launch.
- RED: 3+ critical risks or 1 critical risk with no clear mitigation.

6. The Post-Launch Sentiment Study (5 Questions)

Run this study 1–4 weeks after launch with a fresh research group (not the same personas from pre-launch). This captures market-level sentiment, not primed reactions.

Creating the Post-Launch Group

curl -s -X POST "https://app.askditto.io/v1/research-groups/recruit" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Post-Launch Sentiment - [Product Name] - [Date]",
    "description": "Target customers for post-launch sentiment measurement of [product]. Same demographic profile as pre-launch group for comparability.",
    "group_size": 10,
    "filters": {
      "country": "USA",
      "age_min": 25,
      "age_max": 50,
      "employment": "employed"
    },
    "sampling_method": "random",
    "deduplicate": true
  }'

The 5 Post-Launch Questions

Post-Launch Study Workflow

Follow the same API workflow as Steps 2–7 in Section 4, but with the post-launch group and 5 questions instead of 7. Total API time: approximately 10–15 minutes. With analysis: ~30 minutes end-to-end.

7. The Launch Impact Report

The Launch Impact Report is the capstone deliverable. It compares pre-launch expectations (Phase 1) against post-launch reality (Phase 2) across every dimension. This is where the two-phase approach pays off.

Report Structure

## Launch Impact Report: [Product/Feature]
## Pre-Launch Study: [Date] | Post-Launch Study: [Date]

### Executive Summary
[2-3 sentence summary: Did the launch land as expected? What surprised us?]

### Dimension-by-Dimension Comparison

#### 1. Concept Resonance
- **Pre-launch (Q1):** X/10 positive, average score X.X/5
- **Post-launch (Q1 awareness):** X/10 have heard of it, X/10 have a positive impression
- **Gap:** [Aligned / Positive surprise / Negative surprise]
- **Insight:** [What this means for the product]

#### 2. Feature Priority
- **Pre-launch (Q3):** Top feature demand was [Feature A] (X/10)
- **Post-launch (Q4 switching triggers):** Top conversion driver is [Feature X]
- **Gap:** [Do the features that excited pre-launch actually drive conversion post-launch?]
- **Insight:** [Alignment or misalignment between desire and action]

#### 3. Pricing Perception
- **Pre-launch (Q6):** Median expected price $X, acceptable range $X-$X
- **Post-launch (Q3):** X/10 say "fair", X/10 say "expensive", X/10 say "good deal"
- **Gap:** [Is the market reacting to the price as the pre-launch study predicted?]
- **Insight:** [Pricing adjustment needed or validation confirmed]

#### 4. Barriers and Objections
- **Pre-launch (Q4):** Top barrier was [Barrier A] (X/10)
- **Post-launch (Q5):** Top remaining concern is [Concern X] (X/10)
- **Gap:** [Did the launch address the predicted barriers? Did new ones emerge?]
- **Insight:** [Which barriers were successfully addressed, which persist]

#### 5. Market Language
- **Pre-launch (Q5):** Most common description: "[one-sentence description]"
- **Post-launch (Q2):** Market describes product as: "[how they compare it to competitors]"
- **Gap:** [Is the market describing the product the way you intended?]
- **Insight:** [Messaging alignment or drift]

### What Worked
1. [Strongest alignment between pre-launch expectation and post-launch reality]
2. [Second]
3. [Third]

### What Surprised Us
1. [Biggest unexpected finding]
2. [Second]
3. [Third]

### Recommended Next Actions
1. [Highest-priority post-launch action based on evidence]
2. [Second priority]
3. [Third priority]

### Feed Into Next Launch
[What this launch taught us that should change our process for the next one]

8. Launch Tiering: Matching Research to Launch Scale

Not every release warrants the full two-phase research treatment. Launch tiering determines how much research investment each launch receives.

Tier 2 Focused Validation

For Tier 2 launches, you don't need the full 7-question study. A focused 4–5 question version validates the critical dimensions without the full investment.

# Tier 2 Questions (4 questions)
Q1: "When you first hear about [feature update], what comes to mind? What excites you?"
Q2: "What's the FIRST thing you'd want to try with this update?"
Q3: "What would stop you from using this? What's the biggest concern?"
Q4: "Does [feature] at [price] feel like a good deal, fair, or overpriced?"

Tier Decision Framework

## Tier Decision Checklist

Does this launch...
[ ] Introduce a new product or product line? → Tier 1
[ ] Enter a new market or segment? → Tier 1
[ ] Change the product's core value proposition? → Tier 1
[ ] Affect pricing or packaging? → Tier 1 or Tier 2
[ ] Add a significant new feature or integration? → Tier 2
[ ] Enhance an existing feature? → Tier 2
[ ] Fix bugs or polish UI? → Tier 3
[ ] Update documentation or minor settings? → Tier 3

If multiple boxes checked, use the highest tier.

9. The Launch Feedback Loop Advanced

The launch feedback loop connects every launch to the next. Each cycle produces data that improves the following launch's concept, positioning, messaging, and pricing.

The Five-Phase Loop

Phase 1: VALIDATE (Pre-Launch)
  Run 7-question concept validation study
  → Produces 6 launch readiness deliverables
  → Informs launch go/no-go decision
      │
      ▼
Phase 2: LAUNCH
  Execute launch with validated positioning, features, pricing
  → Use Natural Language Bank for marketing copy
  → Use Objection Library for sales enablement
  → Use Feature Priority for onboarding sequence
      │
      ▼
Phase 3: MEASURE (Post-Launch)
  Run 5-question sentiment study (1-4 weeks post-launch)
  → Capture awareness, positioning, pricing, barriers
      │
      ▼
Phase 4: COMPARE
  Generate Launch Impact Report
  → Pre-launch expectations vs post-launch reality
  → Identify gaps, surprises, confirmations
      │
      ▼
Phase 5: IMPROVE
  Feed findings into next launch cycle
  → Adjust research questions based on what mattered
  → Calibrate launch tiering based on what needed research
  → Update objection library with real post-launch barriers
      │
      └──→ Return to Phase 1 for next launch

What Improves with Each Cycle

Cross-Launch Trend Tracking

## Launch Research Trend Analysis: [Product]

### Concept Resonance Over Time
| Launch | Date | Pre-Launch Score | Post-Launch Awareness | Gap |
|--------|------|-----------------|----------------------|-----|
| V1 Launch | Jan 2026 | 3.8/5 | 4/10 aware | Resonance strong but awareness low |
| V2 Feature | Mar 2026 | 4.2/5 | 6/10 aware | Both improving |
| V3 Platform | Jun 2026 | 4.5/5 | 8/10 aware | Strong on all dimensions |

### Recurring Barriers (across all launches)
| Barrier | V1 | V2 | V3 | Trend |
|---------|----|----|-----|-------|
| Trust/security | 6/10 | 4/10 | 2/10 | Declining (SOC 2 addressed it) |
| Price | 4/10 | 3/10 | 3/10 | Stable (price point validated) |
| Switching cost | 5/10 | 5/10 | 3/10 | Declining (migration tools helped) |

### Key Pattern
Trust concerns declined after SOC 2 launch. Price objections stable at 3/10
regardless of price changes. Switching cost drops when migration tools improve.
Implication: future launches should invest in migration support, not price
discounts, to reduce remaining barriers.

10. Worked Example: Launch Research for a Design Collaboration Tool

{
  "name": "Pre-Launch Validation - CanvasSync - Feb 2026",
  "description": "Product designers at companies with 10-200 employees. Work on collaborative design projects, use tools like Figma, Sketch, or Adobe XD. Responsible for UI/UX design, prototyping, and stakeholder presentations.",
  "group_size": 10,
  "filters": {
    "country": "USA",
    "age_min": 24,
    "age_max": 42,
    "employment": "employed",
    "education": "bachelors"
  }
}

11. Multi-Segment Launch Research

Different segments react differently to the same product launch. A feature that excites individual designers may alarm enterprise IT teams. A price point that feels cheap to a funded startup feels expensive to a freelancer. Multi-segment launch research captures these differences before they become post-launch surprises.

Multi-Segment Group Setup

# Group A: Freelance/solo designers
{
  "name": "Pre-Launch - CanvasSync - Freelancers - Feb 2026",
  "description": "Freelance designers and solo practitioners. Work independently or with small client teams. Price-sensitive, tool-agnostic.",
  "group_size": 10,
  "filters": { "country": "USA", "age_min": 22, "age_max": 38, "employment": "employed" }
}

# Group B: In-house design teams (10-50 people)
{
  "name": "Pre-Launch - CanvasSync - Design Teams - Feb 2026",
  "description": "Product designers working in-house at tech companies with 10-50 person design teams. Use Figma daily, collaborate across product and engineering.",
  "group_size": 10,
  "filters": { "country": "USA", "age_min": 26, "age_max": 42, "employment": "employed", "education": "bachelors" }
}

# Group C: Enterprise design organisations (50+ designers)
{
  "name": "Pre-Launch - CanvasSync - Enterprise - Feb 2026",
  "description": "Design leads and managers at large organisations with 50+ designers. Manage design systems, govern tools, report to VP Design.",
  "group_size": 10,
  "filters": { "country": "USA", "age_min": 30, "age_max": 50, "employment": "employed", "education": "bachelors" }
}

Ask the same 7 pre-launch questions to all three groups. Claude Code then produces a cross-segment comparison:

Cross-Segment Launch Comparison

## Cross-Segment Launch Analysis: [Product]

| Dimension | Freelancers (A) | Design Teams (B) | Enterprise (C) |
|-----------|----------------|------------------|-----------------|
| Resonance (Q1) | 8/10 excited | 6/10 excited | 4/10 cautious |
| Hero feature (Q3) | Real-time drawing | Stakeholder feedback | Design system mgmt |
| Top barrier (Q4) | Price | Switching from Figma | Security & compliance |
| Expected price (Q6) | $8-12/mo | $20-25/mo | $30-50/seat/mo |
| Top gap (Q7) | Offline mode | Figma import | SSO & audit logs |

### Segment-Specific Launch Strategy
- **Freelancers:** Lead with free tier + real-time drawing. Price: $10/mo.
- **Design Teams:** Lead with stakeholder feedback. Price: $20/user/mo.
  Must have Figma import at launch.
- **Enterprise:** Delay launch until SSO and audit logs are ready.
  Price: custom. Lead with design system governance.

### Beachhead Recommendation: Design Teams (B)
- Highest resonance-to-barrier ratio
- Price point validated at proposed level
- Hero feature (stakeholder feedback) is most differentiated
- Achievable barriers (Figma import is buildable)

12. Concept Testing for Products That Don't Exist Yet

The pre-launch study works for products still in the concept phase — no prototype needed. Frame Q1 around a clear problem statement and proposed solution rather than a product name.

Concept-Stage Question Adaptations

What Changes at Concept Stage

• Q2 (use case) becomes more exploratory: "How would you imagine using something like this?" rather than "Walk me through your workflow."
• Q3 (first feature) becomes aspiration-based: "What capability would matter most to you?" rather than "What would you try first?"
• Q6 (pricing) is anchored to the problem, not the product: "What would you pay to solve [this problem]?" rather than "What would you pay for [this product]?"

Concept Testing Iterations

At concept stage, you can run multiple studies cheaply. Test different framings:

# Study A: Problem-first framing
Q1: "Imagine a tool that eliminates the back-and-forth of design feedback
by letting stakeholders annotate directly on your designs in real time..."

# Study B: Comparison framing
Q1: "Imagine a design tool that works like Google Docs -- everyone can
see changes as they happen, leave comments inline, and resolve feedback
without switching tools..."

# Study C: Outcome framing
Q1: "Imagine cutting your design review cycle from 2 weeks to 2 hours
by replacing asynchronous feedback emails with live collaborative
annotation sessions..."

Compare resonance scores across all three framings. The framing that produces the highest Q1 scores and most specific Q2 use cases becomes your positioning foundation.

13. Measuring Launch Success Over Time Advanced

Beyond the immediate post-launch study, you can run periodic sentiment checks to track how market perception evolves over months.

Sentiment Tracking Schedule

Launch Sentiment Tracking Dashboard

## Launch Sentiment Over Time: [Product]

### Awareness Trend
| Time | Aware (of 10) | Primary Channel | Perception |
|------|--------------|-----------------|------------|
| Week 2 | 3/10 | Twitter/X | "Interesting new tool" |
| Week 4 | 5/10 | Twitter/X + word of mouth | "Figma alternative with better feedback" |
| Month 3 | 7/10 | Word of mouth dominant | "The feedback tool designers are switching to" |
| Month 6 | 8/10 | Multiple channels | "Established player in design collaboration" |

### Barrier Evolution
| Barrier | Week 2 | Week 4 | Month 3 | Month 6 |
|---------|--------|--------|---------|---------|
| Switching from Figma | 5/10 | 5/10 | 3/10 | 2/10 |
| Plugin ecosystem | 4/10 | 4/10 | 4/10 | 3/10 |
| Trust/new company | 3/10 | 2/10 | 1/10 | 0/10 |
| Price | 2/10 | 2/10 | 1/10 | 1/10 |

### Key Insight
Trust barrier disappeared by month 3 (market evidence + early adopter advocacy).
Switching cost declining as Figma import tool improves. Plugin ecosystem is the
most persistent barrier -- this is the #1 post-launch investment priority.

14. Best Practices and Common Mistakes

Do

• Use neutral product descriptions in Q1. Marketing copy biases responses upward. A factual, neutral description produces honest first reactions. "A tool that does X and Y" outperforms "The revolutionary platform that transforms how you work." Scepticism captured at the study stage is scepticism you can address before launch.
• Ask questions sequentially. Each question builds on prior conversational context. Q4 (barriers) produces richer responses when preceded by Q2 (use case) and Q3 (feature priority), because the persona has mentally committed to the product. Batch-asking loses this progressive depth.
• Use identical filters for pre-launch and post-launch groups. The two-phase comparison requires demographic consistency. Different age ranges, employment status, or education levels between phases invalidate the gap analysis.
• Generate all six deliverables. The Pricing Recommendation may seem like the priority, but the Natural Language Bank often produces the most actionable output. How your market describes your product is how your landing page should read.
• Test multiple concept framings at concept stage. When the product doesn't exist yet, run 2–3 studies with different Q1 descriptions. The framing that resonates most becomes your positioning foundation. At 45 minutes per study, you can test three framings in a half-day.
• Tier every launch. Apply the Tier 1/2/3 framework to every release. This prevents two failure modes: over-researching minor updates (wasting time) and under-researching major launches (risking failure). The framework takes 30 seconds to apply and saves hours of misallocated effort.
• Keep the Launch Impact Report. Archive every report. After 3–5 launches, you have a dataset that reveals market patterns: which barriers always persist, which concepts always excite, which price ranges feel natural. This institutional memory is your competitive advantage.
• Include the "steal" and "too expensive" thresholds in Q6. The expected price alone is useful. The full range (steal, expected, too expensive) is transformative. It reveals price elasticity, segment differences, and packaging opportunities that a single price point cannot.

Don't

• Don't skip post-launch research. Pre-launch without post-launch is half the picture. You validated assumptions but never checked whether they held. The gap between "what we expected" and "what happened" is where the next launch improves.
• Don't reuse the pre-launch group for post-launch. Those personas have already been primed by the concept description. Post-launch needs fresh perspectives that may or may not have encountered the product in the market. This is a market-level awareness test, not a follow-up interview.
• Don't batch questions. The API processes them asynchronously. Sending all 7 at once means personas answer Q7 without the conversational context of Q1–Q6. Sequential asking is critical.
• Don't treat this as a pricing study. Q6 captures directional pricing signals sufficient for launch decisions. For rigorous pricing research (Van Westendorp, conjoint analysis, feature-tier allocation), use the dedicated Pricing Research guide.
• Don't oversell in Q1. If your concept description reads like marketing copy, personas will mirror that enthusiasm back to you. You want honest reactions, not validation of your copywriting. Keep Q1 descriptions factual and neutral.
• Don't launch without addressing critical-risk items from the Risk Register. If the Risk Register shows a critical risk (high likelihood, high impact), launching without mitigation is a known bet. Sometimes that bet is correct (speed matters more than perfection). But it should be a conscious decision, not an oversight.
• Don't skip the completion step. Calling POST /v1/research-studies/{id}/complete triggers Ditto's AI analysis (key segments, divergences, shared mindsets). Without this, you're missing a significant analysis layer that enriches every deliverable.
• Don't confuse concept enthusiasm with adoption intent. "This sounds amazing!" (Q1) followed by "I'm not sure when I'd use it" (Q2) is a warning sign. Enthusiasm without use case specificity predicts downloads, not retention. Weight Q2 heavily in the readiness scorecard.

Common API Errors

15. Frequently Asked Questions

How long does the full two-phase approach take?

Pre-launch concept validation: approximately 45 minutes (20–30 minutes API interaction + 15–20 minutes deliverable generation). Post-launch sentiment measurement: approximately 30 minutes (10–15 minutes API interaction + 15 minutes analysis and Launch Impact Report). Total: ~75 minutes across both phases. Compare with 4–8 weeks and $15,000–$50,000 for traditional launch research.

When should I run the post-launch study?

1–4 weeks after launch, depending on the product's reach. For a consumer product with broad launch marketing, 1–2 weeks is sufficient for awareness to spread. For a B2B product with targeted launch, wait 3–4 weeks. The goal is to capture the market's initial reaction while it's still forming, before the narrative calcifies.

Can I use this for feature launches, not just product launches?

Yes. For significant feature launches (Tier 2), use the focused 4–5 question pre-launch study. Frame Q1 around the feature rather than the product: "When you hear that [product] is adding [feature description], what comes to mind?" The same deliverables apply, scoped to the feature rather than the product.

What if the pre-launch study says "don't launch"?

This is one of the most valuable possible findings. A Launch Readiness Score below 3.0 (with critical risks identified) tells you the concept needs work before resources are committed. The cost of a 45-minute study is negligible compared to the cost of a failed launch. Use the Risk Register and Feature Priority Ranking to guide the rework, then retest with a fresh group.

How does this relate to the GTM Strategy Validation guide?

GTM Strategy Validation (see guide) determines how to reach your market: which segments, which motion, which channels, what pricing structure, what proof points. Product Launch Research determines whether the specific product or feature resonates and is ready to launch. Run GTM validation first to determine the strategy, then launch research to validate the specific product within that strategy. In practice, launch research often surfaces GTM insights as a byproduct (e.g., Q6 pricing data informs GTM pricing decisions).

Can I test a product that doesn't exist yet?

Yes. See Section 12. Frame questions around the problem and proposed approach rather than a product name. The study tests whether the concept resonates, not whether the product works. This is particularly valuable for pre-investment concept testing: validate demand before building anything.

How many personas should I use per group?

10 personas per group is the standard. Fewer than 10 produces unreliable patterns — the difference between 3/10 and 4/10 is noise, while 3/10 vs 7/10 is signal. For concept testing iterations (Section 12), you can use 8 personas per study to save time while maintaining sufficient signal.

Should the pre-launch and post-launch groups be the same demographic?

Yes, always. Use identical filters (country, age range, employment, education) for both groups. The two-phase comparison requires demographic consistency. Different filters between phases mean you're comparing different populations, not measuring how the same population's perception changed.

How do I share launch research results with my team?

Four formats: (1) The Ditto share link lets anyone explore the raw study data interactively. (2) The Launch Readiness Scorecard is a single-page executive summary. (3) The six deliverables serve different functions: product team gets Feature Priority Ranking, sales gets Objection Library, marketing gets Natural Language Bank, leadership gets Risk Register. (4) The Launch Impact Report serves as the post-mortem document.

What's the relationship between concept validation and positioning research?

Positioning research (see Positioning Validation guide) tests whether your market position and competitive differentiation resonate. Concept validation tests whether a specific product or feature concept is viable. Positioning is about the brand and its place in the market. Launch research is about the specific thing you're releasing. Validated positioning makes concept validation more reliable because Q1 descriptions are grounded in tested positioning language.

How accurate is synthetic launch research compared to real customer feedback?

EY validated 92% correlation between Ditto synthetic responses and traditional research methods. For launch research, synthetic personas are particularly strong at identifying barriers (Q4), capturing natural language (Q5), and revealing feature priorities (Q3). They are slightly less reliable for absolute pricing thresholds (Q6), where real purchasing behaviour introduces biases that synthetic personas don't replicate. Use Q6 data directionally: "the market expects $15–25" is more actionable than "the market will pay exactly $20."

Related guides:

• Go-to-Market Strategy Validation with Ditto + Claude Code
• Customer Segmentation with Ditto + Claude Code
• Validate Product Positioning with Ditto + Claude Code
• Competitive Intelligence with Ditto + Claude Code
• Test Product Messaging with Ditto + Claude Code
• Pricing Research with Ditto + Claude Code
• Voice of Customer with Ditto + Claude Code
• Content Marketing Engine with Ditto + Claude Code
• Sales Enablement with Ditto + Claude Code
• Cross-Study Patterns
• Ditto API for Claude Code: Complete Guide
• Installing the Ditto Skill

Ditto — Synthetic market research with 300,000+ AI personas. Validated by EY (92% correlation), Harvard, Cambridge, Stanford, and Oxford.
askditto.io · [email protected]