ai-app-opportunity-mvp-research

name

ai-app-opportunity-mvp-research

description

Use this skill whenever the user asks to research AI app opportunity keywords, Sensor Tower-style app intelligence, ASO keyword opportunities, App Store or Google Play competitor analysis, Diandian popularity metrics, Similarweb/Semrush website-to-app opportunity discovery, or whether an AI keyword/direction is suitable for an iOS/Android MVP. This skill is especially relevant for prompts like "帮我调研这个 AI App 机会词", "这些词哪些可以先做", "用 Sensor Tower / 点点 / Similarweb 看看能不能做 App", "输出 Go/No-Go MVP 判断", or when the user provides screenshots, tables, chat notes, app store search results, competitor reviews, pricing notes, or website traffic data and expects a decision-oriented MVP research report.

AI App Opportunity MVP Research

This skill turns messy AI app opportunity notes into a decision-oriented MVP research report. It combines:

• App Store Optimization discipline: keyword classification, search result structure, competitor metadata, review pain points.
• Startup validation discipline: market evidence, problem-solution fit, monetization proof, risks, next validation steps.
• Deep research discipline: source discipline, data completeness, explicit citations when web sources are used.
• The user's practical workflow: Sensor Tower is the main commercial validator, Diandian is auxiliary, website tools discover demand but do not prove app opportunity.

Core Principle

Separate three levels of judgment:

Level	Question	Allowed conclusion
Trend discovery	Is this topic growing on the web/search side?	"worth app-side validation"
App opportunity	Do app store search structure and competitors show a real app market?	"promising / weak / unclear"
MVP decision	Is there enough evidence to design an MVP now?	"Go / Conditional Go / Observe / No-Go"

Do not jump from trend discovery to MVP decision. Website traffic, Google Trends, SEO volume, or social buzz can generate candidate keywords, but they must be validated against Sensor Tower and app store evidence before recommending development.

When Starting

First identify the research mode:

Mode	User input	Primary task
Keyword triage	Many candidate keywords	Rank which terms deserve deeper validation
Single direction validation	One keyword or app idea	Decide Go / Conditional Go / Observe / No-Go
Competitor deep dive	One or more apps	Extract monetization, keyword, review, and positioning lessons
Website-to-app discovery	Websites, SEO keywords, Similarweb/Semrush data	Turn web demand into app-side validation candidates
MVP design	Direction already selected	Produce positioning, V1 scope, monetization hypothesis, and next actions

Ask a question only when a missing detail changes the research scope. Otherwise proceed and mark missing data explicitly.

Data Source Priority

Use this priority order when sources conflict:

1. Sensor Tower or equivalent mobile intelligence data: downloads, revenue, keyword coverage, ranking, geography, platform split.
2. App Store / Google Play live evidence: search result structure, titles, screenshots, ratings, reviews, update activity.
3. First-hand product experience: onboarding, paywall, pricing, trial, generated output quality.
4. Competitor reviews: 1-2 star pain points and 4-5 star praise.
5. Diandian data: keyword popularity and search result count as auxiliary ASO signals.
6. Similarweb / Semrush: website-side demand and SEO keyword discovery.
7. Google Trends: early trend discovery only.

If the user provides screenshots or copied tables, treat them as user-provided evidence. Preserve uncertainty and do not invent missing fields.

Required Workflow

Step 1: Audit Data Completeness

Create a data completeness table before analysis. Mark each item as available, partial, or missing, and explain how missing data affects the conclusion.

Required items:

• Sensor Tower revenue/downloads for top competitors.
• Sensor Tower keyword coverage/ranking for core competitors.
• App Store search result structure.
• Google Play search result structure.
• Diandian popularity and search result count, if available.
• Competitor reviews, especially 1-2 star reviews.
• Competitor paywall/pricing/product experience.
• Similarweb/Semrush website signals, if the direction came from web demand.
• Google Trends signal, if used for discovery.

If Sensor Tower revenue is missing, do not claim commercialization is proven.

Step 2: Classify Keywords

Classify every keyword into one of:

Type	Meaning	Example
Main keyword	Broad category term	AI headshot, PDF scanner
Scenario keyword	Specific use case	LinkedIn headshot, invoice generator
Audience keyword	Clear user segment	resume photo for job seekers
Function keyword	Product capability	video translator, image translator
New/rising keyword	Fresh term from website/search trends	AI tattoo generator

Prefer MVP entry through scenario, audience, or function keywords when the main keyword is dominated by large general tools.

Step 3: Analyze App Store Search Structure

For each target keyword and platform, summarize the top results:

• Top 10 composition: exact vertical apps, broad/general AI tools, unrelated apps, incumbents.
• Whether smaller vertical apps appear.
• Ratings, review counts, freshness/update activity.
• Screenshot/message patterns.
• Whether the search page reveals a realistic entry wedge.

Do not treat search result count alone as opportunity. A low result count with no monetizing competitors is weak evidence.

Step 4: Validate Commercialization With Sensor Tower

Use Sensor Tower-style evidence to answer:

• Are top exact competitors earning meaningful revenue?
• Are downloads and revenue both present, or only downloads?
• Is revenue concentrated in one head app, or distributed across smaller vertical apps?
• Is there iOS-only, Android-only, or cross-platform evidence?
• Which countries drive demand?
• Which keywords do the competitors actually rank for?

Small vertical proof is especially important: a smaller app with modest downloads but meaningful revenue is often a better MVP signal than a giant general app earning money.

Step 5: Use Diandian as Auxiliary ASO Validation

Treat Diandian popularity as a directional signal, not a replacement for Sensor Tower:

Diandian signal	Interpretation
popularity < 40	likely low volume unless it is a new/rising term
40-49	basic demand; observe or validate further
50-59	worth focused Sensor Tower/app store validation
60-69	strong demand; competition likely stronger
>= 70	high demand and usually competitive

The user's working heuristic:

• Popularity around 40 may correspond to roughly 500 daily organic downloads for the first result.
• 50 may correspond to roughly 1000 daily downloads.
• 60 may exceed 1500.
• 70 may exceed 3000.

Always label this as experience-based, non-official, and directional. If Diandian conflicts with Sensor Tower revenue/keyword coverage, prefer Sensor Tower.

Step 6: Analyze Reviews and Paywall

Review pain points become MVP opportunities only when:

• They appear repeatedly.
• They affect purchase, retention, trust, or output quality.
• A V1 product can realistically solve them.
• They map to a clear positioning or feature choice.

Common review categories:

Review pain	Possible MVP implication
too expensive	lower price, credit pack, one-time purchase
forced subscription	transparent pricing or non-subscription option
not like me	similarity-first generation
poor quality	quality benchmark before launch
too slow	faster turnaround as differentiator
too few styles	narrower but better scenario templates
refund/trust issues	clearer payment promise and refund policy
bugs/crashes	reliability as a wedge only if competitors are weak

Do not invent pricing or paywall details. If product experience is missing, say so.

Step 7: Map Website Signals Back to App Validation

Similarweb, Semrush, Google Trends, and competitor websites help discover new AI use cases. They do not prove app opportunity.

For each website-side signal, map it back:

Web signal	Required app validation
SEO keyword growing	Check App Store / Google Play top 10
High website traffic	Check whether app competitors monetize
Many web tools, few apps	Check whether app workflow is natural
Rising Google Trends query	Check Sensor Tower keyword and competitor revenue
Paid web tool exists	Check whether mobile willingness-to-pay exists

State clearly when the finding is "web-side only."

Step 8: Score the Opportunity

Use the 100-point score as an auxiliary decision tool:

Dimension	Points	What to check
Sensor Tower revenue validation	25	at least one exact/near competitor earns meaningful revenue
Platform validation	10	iOS/Android evidence matches the intended launch platform
Keyword opportunity	15	there are usable scenario/audience/function entry terms
Small vertical proof	15	smaller focused apps can earn, not only head/general tools
Competitive entry feasibility	10	top results are not fully locked by incumbents
Review pain point opportunity	10	repeated pain points are V1-solvable
Monetization feasibility	10	pricing/paywall/revenue model evidence exists
Website-side supporting signal	5	web demand supports discovery but does not carry the decision

Interpretation:

Score	Conclusion tendency
80-100	strong candidate for MVP design
65-79	worth deeper validation
50-64	signal exists but not ready for MVP
30-49	low priority, observe
<30	not recommended

Step 9: Apply Downgrade Rules

Downgrade the conclusion when:

• Sensor Tower revenue data is missing.
• Only trend or website data is available.
• Exact competitors have weak revenue.
• Only broad/general tools make money while vertical apps do not.
• The keyword is dominated by large incumbents with no realistic entry wedge.
• The main user pain points cannot be solved by a V1 product.
• Only one platform has data but the conclusion claims both platforms.
• Pricing/paywall is missing but the report makes a confident monetization recommendation.

Step 10: Decide

Use one of four conclusions:

Conclusion	Use when
Go	enough evidence supports MVP design now
Conditional Go	direction is promising but key evidence is missing
Observe	signal exists but commercial or execution proof is weak
No-Go	evidence does not support continuing

Always include conditions. Example:

Conclusion: Conditional Go. The direction has commercial signal from [competitor/source], but still lacks [missing evidence]. Do not enter development until [next validation] is completed.

MVP Recommendation Rules

If recommending an MVP, define:

• One target user group.
• One main entry keyword and up to two auxiliary keywords.
• One positioning sentence:

For [target user] in [specific scenario], provide [core outcome], differentiated by [evidence-backed wedge].

• No more than five V1 core functions.
• Pricing only if competitor paywall, pricing, or revenue evidence exists.
• Differentiation only from evidence: keyword gap, review pain, paywall weakness, vertical proof, search structure, or product experience.
• First-month validation metrics.

Use P0/P1/P2 priority for features:

Priority	Meaning
P0	required to test the core paid hypothesis
P1	improves conversion but can be delayed
P2	nice-to-have, not in V1

Output Format

Use the full template in references/report-template.md for complete reports.

For quick triage, use this shorter structure:

# [Keyword/Direction] App MVP Research

## One-Sentence Decision
Conclusion: [Go / Conditional Go / Observe / No-Go]. [Core reason].

## Data Completeness
| Data item | Status | Impact |

## Keyword & Search Structure
| Keyword | Type | Platform | Search structure | Opportunity |

## Commercial Proof
| Competitor | Platform | Downloads | Revenue | Evidence quality | Interpretation |

## Key Risks
| Risk | Evidence | Mitigation / next validation |

## Score
| Dimension | Points | Reason |

## MVP Recommendation
Only include if Go or Conditional Go.

## Next Actions
| Priority | Action | Tool/source | Expected output |

Forbidden Behavior

• Do not invent downloads, revenue, ranking, popularity, prices, reviews, search volume, or screenshots.
• Do not use Google Trends as core MVP evidence.
• Do not treat website traffic as app revenue proof.
• Do not recommend development only because a head competitor earns money.
• Do not ignore small vertical competitors.
• Do not turn every negative review into an opportunity.
• Do not output vague conclusions like "market is promising" without evidence.
• Do not give more than five V1 core features.
• Do not claim both iOS and Android are viable when data covers only one platform.
• Do not produce a strong Go when critical data is missing; use Conditional Go or Observe.

Reference Files

• references/data-source-playbook.md: how to interpret Sensor Tower, Diandian, app stores, reviews, website tools, and Google Trends.
• references/report-template.md: full decision-report template.
• references/trigger-examples.md: examples of prompts that should and should not trigger this skill.