App research often begins with a neat idea and a list of nearby apps. That creates a weak comparison: it favours the proposed product before the evidence has earned that preference. A better process asks what a user does today, what that solution costs them, and what would justify switching.
1. Write the complete job
Describe the trigger, the work and the desired outcome in one sentence. “A timer for teachers” is a category. “Start and adjust a visible classroom activity without interrupting instruction” is a job. The second version reveals alternatives such as a browser timer, presentation software, a physical clock or an existing classroom suite.
Task: A small language school needs tutors to start visible timed exercises quickly on a shared screen. The example names no real school or product and contains no market claim.
2. Include substitutes, not only direct rivals
The strongest alternative may be free, bundled into software the user already owns, or manual. Record at least one direct app, one free substitute and one familiar workaround. If the proposed advantage disappears against any of them, that is a useful finding.
| Question | Evidence to capture | Do not infer |
|---|---|---|
| What does it do? | Current store description, product documentation, observed workflow | That every advertised feature works well |
| What does it cost? | Exact price, currency, period, region and observation date | Lifetime cost from an unlabeled monthly figure |
| Why switch? | Repeated, current problem evidence and a concrete improvement | Demand from feature difference alone |
| Can users leave? | Export, recovery, cancellation and data-portability evidence | Low switching cost because signup is easy |
3. Preserve scope around every number
A price without currency and billing period is not comparable. A revenue estimate without store, country and date range is not a market size. Keep the raw observation and its limitations next to the value. Unknown values should remain visible rather than becoming zero.
4. Compare rows that answer decisions
Use rows such as complete job, strongest remedy, exact price, relevant complaint evidence, free boundary, switching cost, acquisition evidence and missing information. “Show only differences” is useful only after the evidence types are compatible.
5. End with the smallest decisive check
A comparison should produce a test, not a verdict disguised as a score. Examples include interviewing five users who recently paid for the current remedy, checking whether a supposedly missing export now exists, or measuring response to one concrete switching promise. Set a stop condition before the test.
Source references
- Apple iTunes Search API overview — public catalogue search and its usage terms.
- Apple Search API construction — parameters and approximate request limit.