Product Agent

Product Agent Skill

Product Agent validates iOS/macOS app ideas by analyzing problems, markets, and competition. It provides honest, structured assessments to help you decide whether to build.

When This Skill Activates

Use this Skill when the user wants to:

• Discover or validate product ideas
• Analyze market opportunities
• Check if an app idea is worth building
• Understand competitive landscape
• Assess problem severity
• Get honest feedback on app concepts

How It Works

This skill performs structured product analysis using reasoning and web research. No external tools required — Claude analyzes the idea directly and researches the market via WebSearch/WebFetch.

Quick Start

When the user provides an app idea, perform the Problem Discovery Analysis below and present the results.

If the user hasn't provided enough detail, ask: 1. What's the app idea? (required) 2. What platform? (iOS, macOS, or both — default: iOS/macOS) 3. Who's the target user? (optional but improves analysis)

Problem Discovery Analysis

For each idea, analyze and produce these fields:

1. Problem Statement

One-sentence description of the core problem the app solves.

2. Target Users

Who experiences this problem most acutely? Be specific about demographics, roles, and context.

3. Pain Points

List 4-8 specific, concrete pain points users experience today. Each should be observable and verifiable.

4. Severity Score (1-10)

Rate how painful this problem is:

• 1-3: Weak problem, low urgency — users barely notice
• 4-6: Moderate problem, decent opportunity — users work around it
• 7-8: Strong problem, good opportunity — users actively seek solutions
• 9-10: Critical problem, excellent opportunity — users are desperate (rare)

5. Frequency

How often do target users encounter this problem? Daily problems are stronger than weekly ones.

6. Current Solutions

Research existing alternatives using WebSearch. For each competitor:

• Name and brief description
• Key strengths
• Main limitations
• Pricing model

7. Market Opportunity

Assess the opportunity using one of: WEAK, MODERATE, STRONG, EXCELLENT. Include reasoning about market saturation, differentiation potential, and timing.

8. Recommendation

The most important field. Provide an honest verdict:

• BUILD — Clear opportunity, go for it
• PROCEED WITH CAUTION — Opportunity exists but significant risks
• DO NOT BUILD — Market saturated, weak problem, or better alternatives exist

Include:

• Specific reasons for the verdict
• Key risks
• What would need to be true for this to succeed
• Alternative approaches if "don't build"

Output Format

Present results as structured JSON for easy consumption by other skills:

{
  "problem_statement": "One-sentence core problem",
  "target_users": "Who experiences this problem",
  "pain_points": ["List of specific pain points"],
  "severity_score": "N/10",
  "frequency": "How often users encounter this",
  "current_solutions": ["Existing alternatives and their limitations"],
  "opportunity": "WEAK|MODERATE|STRONG|EXCELLENT — reasoning",
  "recommendation": "Honest verdict with detailed reasoning"
}

Follow the JSON with a human-readable summary highlighting the key takeaway.

Research Process

1. Analyze the idea — Break down the problem, users, and value proposition 2. Search for competitors — Use WebSearch for "[category] apps iOS", "[competitor] features", "[competitor] pricing" 3. Check App Store landscape — Search for similar apps, ratings, reviews 4. Assess market trends — Search for "[category] market growth", "[category] trends 2026" 5. Synthesize findings — Combine analysis into structured output

Interpreting Results

Key Field: recommendation

This is the most important field. It contains:

• Honest assessment of whether to build
• Market reality check
• Competitive analysis
• Specific reasons for the verdict

The analysis is brutally honest — if it says "don't build", there's usually a good reason.

Severity Score

• 1-3: Weak problem, low urgency
• 4-6: Moderate problem, decent opportunity
• 7-8: Strong problem, good opportunity
• 9-10: Critical problem, excellent opportunity

Opportunity Assessment

Look for keywords:

• "WEAK" — Saturated market or marginal problem
• "MODERATE" — Some opportunity with differentiation
• "STRONG" — Clear gap in market
• "EXCELLENT" — Underserved need with high demand

Common Workflows

1. Quick Idea Validation

User provides an idea. Run the full analysis and focus on the recommendation and severity_score.

Decision framework:

• Score 7+, STRONG opportunity, BUILD verdict — Green light
• Score 4-6, MODERATE opportunity, CAUTION verdict — Needs differentiation strategy
• Score <4, WEAK opportunity, DON'T BUILD verdict — Red light

2. Comparing Multiple Ideas

Run analysis on each idea, then compare:

• Severity scores (higher = better)
• Opportunity assessments (STRONG > MODERATE > WEAK)
• Recommendation verdicts
• Current solutions (fewer/weaker competitors = better)

3. Iterative Refinement

If initial analysis says "don't build", explore pivots:

• Narrow the niche (e.g., "note-taking" -> "note-taking for academic researchers")
• Change the target user
• Add a unique angle (e.g., AI-powered, privacy-focused)

Re-run analysis for each pivot and look for improving severity and opportunity scores.

After Running Discovery

1. Highlight the recommendation — this is what the user cares about most 2. Explain the severity score — put it in context 3. Summarize pain points — these validate the problem 4. Discuss opportunity — is the market good? 5. Present alternatives — if "don't build", what should they do instead?

Deep-Dive Skills

After running discovery, use these specialized Skills for deeper analysis:

competitive-analysis Skill

When discovery shows potential and you need to understand competition in detail:

• Feature comparison matrices
• Pricing analysis across competitors
• SWOT for each competitor
• Differentiation opportunities

market-research Skill

When discovery shows potential and you need to size the opportunity:

• TAM/SAM/SOM calculations
• Growth trends and projections
• Market maturity assessment
• Revenue potential estimates

Workflow:

1. product-agent → Quick validation (problem discovery)
2. If promising, use deep-dive Skills:
   - competitive-analysis → Understand players
   - market-research → Size opportunity
3. Make go/no-go decision with full data

Example

User asks: "Should I build a password manager for the Apple ecosystem?"

You research and analyze, then present:

{
  "problem_statement": "Users need secure password management that seamlessly integrates across Apple devices without relying on third-party services.",
  "target_users": "Apple ecosystem loyalists who own multiple Apple devices and prioritize privacy and native integration.",
  "pain_points": [
    "Existing password managers prioritize cross-platform over deep Apple integration",
    "Third-party managers don't fully integrate with iOS autofill and Face ID",
    "Subscription fatigue from cross-platform services they don't need",
    "UIs that don't follow Apple Human Interface Guidelines"
  ],
  "severity_score": "3/10",
  "frequency": "Daily, but existing solutions work adequately",
  "current_solutions": [
    "iCloud Keychain - Free, deeply integrated, improving rapidly. Limited organization.",
    "1Password - Polished, $36-48/year, cross-platform focused",
    "Bitwarden - Open source, cheaper, generic UI"
  ],
  "opportunity": "WEAK - Highly saturated market with Apple's own iCloud Keychain as dominant free incumbent. Any differentiating feature risks being absorbed by Apple in the next OS update.",
  "recommendation": "DO NOT BUILD. Apple's iCloud Keychain is free, pre-installed, and continuously improving. The differentiation window is tiny, willingness to pay for marginal improvements is low, and one security breach would be catastrophic for an indie developer. Consider instead: tools that augment iCloud Keychain, niche password management (API keys for developers), or a different underserved problem in the Apple ecosystem."
}

Summary: This is not recommended. iCloud Keychain dominates as a free, deeply-integrated solution. Unless you have a truly novel approach or serve a specific underserved niche, the market is too saturated.

Tips for Effective Use

1. Be specific in idea descriptions — More detail = better analysis 2. Trust the recommendation — The analysis is designed to be honest 3. Look for patterns — Similar apps getting "don't build" = saturated market 4. Focus on severity + opportunity — Both must be strong 5. Read current_solutions — Shows what you're competing against 6. Save your analyses — Build a knowledge base of validated/invalidated ideas

---

Remember: This analysis is brutally honest. If it says "don't build", listen. It's saving you months of wasted effort on weak ideas.

Common Usage Patterns

This document shows real-world workflows for using the Product Agent skill effectively.

Pattern 1: Quick Idea Validation

Use Case: You have a single app idea and want quick validation before investing time.

What to do: Provide the idea and let the skill run its analysis.

What to Check: 1. severity_score — Is it 6+? 2. opportunity — Does it say "STRONG" or "MODERATE"? 3. recommendation — Does it say "BUILD" or "PROCEED WITH CAUTION"?

Decision Making:

• Score 7+, STRONG opportunity, BUILD verdict — Green light
• Score 4-6, MODERATE opportunity, CAUTION verdict — Needs differentiation strategy
• Score <4, WEAK opportunity, DON'T BUILD verdict — Red light

---

Pattern 2: Comparing Multiple Ideas

Use Case: You have 3-5 ideas and want to pick the best one.

What to do: Run discovery on each idea, then compare:

• Severity scores (higher = better)
• Opportunity assessments (STRONG > MODERATE > WEAK)
• Recommendation verdicts
• Current solutions (fewer/weaker competitors = better)

Example:

Idea A: Severity 7/10, STRONG, BUILD
Idea B: Severity 4/10, WEAK, DON'T BUILD
Idea C: Severity 6/10, MODERATE, PROCEED WITH CAUTION

Winner: Idea A (clear green light)

---

Pattern 3: Deep Market Analysis

Use Case: You're serious about an idea and want comprehensive analysis.

What to do: 1. Run product-agent discovery with detailed context (platform, target user) 2. Follow up with competitive-analysis skill for competitor deep-dive 3. Follow up with market-research skill for TAM/SAM/SOM

Review Checklist:

• [ ] Read complete recommendation (all paragraphs)
• [ ] Analyze all pain_points (are they real?)
• [ ] Research each item in current_solutions (visit websites)
• [ ] Verify opportunity assessment (do independent research)
• [ ] Consider frequency (daily = good, weekly = less urgent)

---

Pattern 4: Iterative Refinement

Use Case: Initial analysis suggests "don't build", but you want to explore pivots.

Example flow:

Initial idea: "Note-taking app for quick capture" Result: "DO NOT BUILD — market saturated"

Pivot attempts: 1. "Note-taking app specifically for academic research with citation management" (targeting researchers) 2. "Voice-first note capture for field workers who can't use keyboards" (different use case) 3. "Notes that auto-organize into project contexts using AI" (unique workflow)

Look for:

• Severity score improving (4+ to 6+)
• Opportunity changing (WEAK to MODERATE)
• Fewer/weaker competitors in the niche
• More specific pain points

---

Pattern 5: Stakeholder Presentation

Use Case: Need to present findings to team/stakeholders.

What to do: 1. Run discovery analysis 2. Save the JSON output 3. Create a summary highlighting:

• Problem statement
• Severity score
• Key competitors
• Market opportunity
• Recommendation with reasoning

Present: 1. Walk through key sections 2. Focus on recommendation and opportunity 3. Discuss risks and mitigation

---

Pattern 6: Documentation for Decisions

Use Case: Document why you chose/rejected an idea.

What to do: 1. Run analysis for each idea considered 2. Save results alongside your project documentation 3. Include both accepted and rejected ideas with reasoning

Benefit:

• Historical record of decision rationale
• Reference for future similar ideas
• Onboarding for new team members

---

Anti-Patterns (Don't Do This)

Ignoring "Don't Build" Recommendations

Bad: Agent says "DO NOT BUILD — saturated market." You think "But I'll make mine simpler!"

Why it fails: The analysis considered the market. If it says don't build, there's usually a very good reason.

Not Reading the Full Recommendation

Bad: Check severity_score (7/10) and conclude "Great, let's build!"

Why it fails: Score alone doesn't tell the story. Read the full recommendation field.

Not Providing Context

Bad: "Task app"

Better: "Task manager with AI auto-prioritization and calendar integration for busy professionals on iOS"

Why: More context = better analysis.

Building Despite Weak Validation

Bad: Severity 3/10, WEAK opportunity, "DO NOT BUILD" — but you build anyway.

Why it fails: If it's a learning project, fine. But don't expect commercial success.

---

Quick Reference

---

Remember: Product Agent saves you time by being brutally honest. Trust the analysis.

Product Agent - Analysis Reference

This document contains the detailed output schema and analysis methodology for the Product Agent skill.

JSON Output Schema

Discovery Analysis Output

{
  problem_statement: string,        // One-sentence core problem description
  target_users: string,              // Who experiences this problem most
  pain_points: string[],             // Array of specific pain points
  severity_score: string,            // Format: "N/10" where N is 1-10
  frequency: string,                 // How often users encounter this problem
  current_solutions: string[],       // Existing alternatives and their limitations
  opportunity: string,               // Market opportunity assessment
  recommendation: string             // Detailed verdict: build/don't build with reasoning
}

Field Descriptions

problem_statement

• Type: String
• Format: One sentence
• Purpose: Clear, concise statement of the core problem
• Example: "Users need to capture fleeting thoughts before they're forgotten, but existing note apps have too much friction."

target_users

• Type: String
• Purpose: Describes who experiences this problem most acutely
• Example: "Knowledge workers, writers, and students who have frequent spontaneous ideas throughout the day."

pain_points

• Type: Array of strings
• Count: Typically 4-8 items
• Purpose: Specific, concrete pain points users experience
• Example:

  [
    "Ideas evaporate in the 5-10 seconds it takes to open a traditional note app",
    "Context switching from current task to note-taking breaks flow state",
    "Existing apps force premature organization decisions"
  ]

severity_score

• Type: String
• Format: "N/10" where N is 1-10
• Interpretation:
• 1-3: Weak problem, low urgency
• 4-6: Moderate problem, decent opportunity
• 7-8: Strong problem, good opportunity
• 9-10: Critical problem, excellent opportunity (rare)
• Example: "7/10"

frequency

• Type: String
• Purpose: How often users encounter this problem
• Example: "Multiple times per day for target users, but most users have workable alternatives"

current_solutions

• Type: Array of strings
• Purpose: Existing alternatives and their limitations
• Format: Each item typically includes the solution name and its key limitation
• Example:

  [
    "Apple Notes - Fast but still requires unlock, app launch, new note. Good iCloud sync.",
    "Drafts app - Already solves this problem very well with instant capture and automation",
    "iOS Lock Screen widgets - Can launch straight to new note in some apps"
  ]

opportunity

• Type: String
• Purpose: Market opportunity assessment with reasoning
• Common Keywords: WEAK, MODERATE, STRONG, EXCELLENT
• Example: "MODERATE - There's a narrow opportunity IF you can differentiate with fastest possible capture and unique organizing philosophy."

recommendation

• Type: String (often multi-paragraph)
• Purpose: Most important field - honest verdict with detailed reasoning
• Format: Often includes:
• Opening statement (BUILD / DO NOT BUILD / PROCEED WITH CAUTION)
• Reasons for verdict
• Specific risks or opportunities
• Alternative suggestions if "don't build"
• Bottom line summary
• Example: See examples/discovery.json

Research Methodology

Web Research Strategy

When analyzing an idea, search for:

1. Competitor discovery:

• "[category] apps iOS"
• "[category] apps macOS"
• "best [category] apps Apple"

2. Competitor details (for each):

• "[competitor name] features"
• "[competitor name] pricing 2026"
• "[competitor name] reviews"

3. Market context:

• "[category] market size 2026"
• "[category] market growth"
• "[category] app trends"

4. User sentiment:

• "[category] app complaints reddit"
• "[category] app reviews"

Analysis Framework

Problem Validation:

• Is the problem real? (Do people actually complain about this?)
• Is it frequent? (Daily > weekly > monthly)
• Is it severe? (Workaround exists vs. no good solution)
• Are people paying to solve it? (Willingness to pay signals real pain)

Market Assessment:

• How many competitors exist?
• How strong are the incumbents?
• Is Apple likely to build this natively?
• What's the differentiation angle?

Honesty Principles:

• If Apple already does this well for free, say "don't build"
• If the market has 10+ strong competitors, say "don't build" unless there's a clear gap
• If severity is below 4, the problem isn't painful enough
• Never recommend building just because the technology is interesting

Anti-Patterns

Ignoring "Don't Build" Recommendations

If the analysis says "don't build", there's usually a strong market reason. Don't override this because "mine will be simpler" or "I'll make a better UI."

Not Reading the Full Recommendation

A severity score of 7/10 alone doesn't tell the story. The recommendation field contains the nuanced reasoning.

Lack of Context

"Task app" produces a weaker analysis than "Task manager with AI auto-prioritization for busy professionals on iOS." More context = better analysis.

Building Despite Weak Validation

Severity 3/10 + WEAK opportunity = months of wasted effort. If it's a learning project, fine. But don't expect commercial success.

Integration with Other Skills

Workflow

1. product-agent → Quick validation (this skill)
2. If promising:
   - competitive-analysis → Deep competitor insights
   - market-research → Market sizing (TAM/SAM/SOM)
3. Go/no-go decision with full data
4. If go:
   - idea-generator → Refine the concept
   - prd-generator → Product requirements
   - architecture-spec → Technical design

Best Practices

1. Always produce JSON output for structured analysis 2. Read the recommendation field first — it's the most important 3. Provide platform and target user when known for better results 4. Trust "don't build" verdicts — the analysis is designed to be honest 5. Compare multiple ideas before committing to one 6. Use web research to validate assumptions about competitors and market