Start with the job, not a feature list
Write one sentence that names the person, the moment, and the outcome: “Help a parent turn a week of family meals into one shared grocery list.” This is easier to investigate than “an AI meal app.” A useful research question stays meaningful even if your implementation changes.
List what the person does today. That might be another app, a spreadsheet, a group chat, or a paper list. A technically simple workaround can be your strongest competitor. You are looking for a reason to switch, not just a feature you could build.
- Who experiences this problem, and when?
- What is their current workaround?
- What would be noticeably easier if your idea worked?
- What observation would make you abandon or narrow the idea?
Choose competitors for the same customer and task
Pick a small, deliberately varied set: a direct competitor, a popular broader product, a specialist, and a manual workaround. Record why each belongs in the set. Compare within the same store, country, and language before expanding to another market.
Search several phrases a customer might use. A single query is a discovery method, not a census of the market. Apple describes search as using both text relevance and user behavior, so a high placement should not be read as proof of commercial success.
Keep observations separate from interpretation. A listing that mentions a paid tier shows an offer exists. It does not tell you how many people buy it, what they pay after promotions, or whether the app is profitable.
- Capture the app URL, date, store, country, and visible price.
- Record the core promise and the workflow shown in screenshots.
- Note what you actually tried versus what a listing merely describes.
Read praise as carefully as complaints
Look for recurring situations, not a bag of keywords. “Sharing is confusing” and “my partner never sees the new list” may describe different problems. Keep the original text alongside your label so you can revisit that decision.
Record praise too. If customers consistently love fast setup, a redesign that adds a long onboarding flow could damage the very reason they chose the app. A gap is useful only when you understand the strengths people would give up by switching.
For each theme, record how many collected reviews mention it and how many reviews you examined. Avoid selecting only one-star reviews and presenting the result as the view of all users. Written reviews are a self-selected sample, and an unmentioned feature is not necessarily absent.
- Problem: what happened, to whom, and in which situation?
- Workaround: did the reviewer explain how they handled it?
- Frequency: how many collected reviews mention the same issue?
- Counterevidence: who likes the existing approach, and why?
Turn the evidence into a one-page research brief
Use the following outline in a document or spreadsheet. Keep source links next to each observation. The brief should help you make a decision, not make the idea sound inevitable.
A fictional example: several reviewers struggle to coordinate a grocery list with a partner. Your hypothesis might be that clear sharing status matters more than adding recipe recommendations. The next question is whether your intended users experience that problem often enough to change their routine.
- Audience and job: one person, one recurring situation, one desired outcome.
- Alternatives: what people use now and what those options do well.
- Observed friction: review patterns with counts, scope, and source links.
- Proposed difference: one workflow you would make easier.
- Reasons it may fail: small sample, strong incumbent, occasional need, or an acceptable workaround.
- Next test: a task someone can try and a decision you will make from the result.
Test the riskiest assumption before building the whole app
Ask intended users to walk through the last time the problem occurred. Look for what they actually did, where they stopped, and what the workaround cost them in effort. “Would you use this?” is weaker evidence than a concrete account of a recent task.
Next, test one small workflow with a sketch, a clickable prototype, or a manually delivered result. For the shared-list idea, ask two people to add and update items together. Observe whether they can tell whose changes are saved. Do not explain the interface while measuring whether they understand it.
Decide what would justify another iteration before you run the test. You might continue if the core task can be completed without help, narrow the audience if only one group cares, or stop if the current workaround is already good enough. These are product decisions, not a universal statistical threshold.
Where Appfox fits
Invited Appfox beta users can produce research briefs from store evidence, explore review themes, and track competitors and rankings. You can start with an idea before you have a published app. A brief can organize the evidence; customer conversations and hands-on tests are still your work.
RevenueCat, session replay, reply drafts, and API access are planned. Use the beta feature reference to check current scope before relying on a capability for your workflow.