ASO course · lesson 3 of 60
ASO audience research and app value propositions
Describe one audience through its problem and buying context rather than a broad demographic label.
By Gabriel Machuret · Editorial methodology
Before you start: Your scoped app brief and access to product or customer knowledge.
Module 1: Foundations and diagnosis
Plan about 50 minutes for reading, practice and review
You will produce: An audience and proposition brief containing the use case, benefit, evidence and main objection.
Understand the decision
Define the situation before the persona
“People aged 18–45” is too broad to guide listing copy. Describe the situation: a walker wants to remember what happened on a trail without publishing to a social network. Include the trigger, current workaround, desired result and objection. This gives you language to research and a product promise to demonstrate instead of a list of demographic assumptions.
Connect benefits to proof
A benefit explains why a capability matters. A feature such as offline entry becomes a benefit when it solves a specific situation, but only if the shipped product actually supports that behavior. Pair each proposed claim with a screen, workflow or documented limitation. If you cannot show the claim working, qualify it or remove it before it reaches the store.
Choose the primary audience deliberately
An app may serve several audiences. The default listing still needs a coherent opening message. Choose the audience with both product fit and business relevance, then document secondary use cases for later localized or targeted experiences. Trying to address everyone in the first screenshot often produces vague language that helps nobody recognize their own problem.
Apply the method in practice
Find the moment when the need becomes urgent
Start with the event that makes someone seek an app. A hiker finishing a memorable walk has a different job from a hiker lost at a junction. Both may type words about trails, but only the first situation fits a journal without navigation. Describe the trigger, desired result, current workaround and constraint. A situation can include “no signal,” “limited time” or “does not want a public post,” but each must be investigated rather than borrowed from a persona template. These distinctions later help you reject attractive keywords that create the wrong expectation.
Build a claim-to-proof ladder
Write the capability first, then the user benefit, then the evidence and limitation. “Attach photos to an entry” can support “remember the details of your walk.” It does not establish secure cloud backup, offline availability or unlimited storage. Open the released app and capture the actual workflow. Ask the product owner to resolve claims that touch account behavior, data handling or payment. Use the smallest accurate promise that still matters to the audience. This produces stronger creative because a screenshot can demonstrate a specific benefit rather than decorate an abstract slogan.
Select an audience without inventing market size
Compare candidate situations on current product fit, evidence of need and business relevance. Keep a separate confidence column: a compelling internal idea is weaker evidence than repeated customer accounts of a current behavior. You can choose a focus for learning without claiming it is the largest segment. Record what would make you switch, such as interviews showing that the proposed benefit is already solved by a simpler tool. The default listing needs a coherent message; secondary situations can remain in the research backlog or later receive a targeted listing when supported.
Platform references for this work: Apple — Creating your product page · Google Play — Metadata policy
Your step-by-step procedure
- Write three situation statements using “When…, I want…, so I can…”.
- For each statement, identify the actual product action that delivers value.
- Record one objection and the evidence that could answer it.
- Choose a primary situation and explain why it takes priority now.
Worked example and interpretation
Trail Notes and numerical research scenarios are fictional teaching examples. Platform limits, where shown, come from the linked official references.
Trail Notes considers hikers who want private memories and athletes who want competitive performance analysis. The journal supports the former and lacks training analytics for the latter. “Remember every walk privately” has a stronger product fit than “Train like a professional.” The team records privacy as a proposition requiring a check of the actual sharing defaults, rather than assuming that the absence of a feed proves every aspect of privacy.
| Situation | Promise | Proof or limitation |
|---|---|---|
| Remember a walk | Save photos with a journal entry | Demonstrate the current editor |
| Find a safe route | Turn-by-turn guidance | Unavailable: reject this promise |
| Keep a private record | Control who sees entries | Verify sharing defaults before using |
The first row offers a direct path from need to product evidence. The second is unsuitable even if its search demand appears higher. The third is promising but cannot be approved merely because the app lacks a social feed: account sharing, storage and default visibility still need review. This distinction prevents a positioning workshop from becoming a source of unsupported privacy or capability claims. The resulting brief should include both approved language and words the team must avoid.
Build a handover someone can use
Primary situation
Describe the trigger and desired result in ordinary customer language. Include the current workaround so the benefit has context.
Value statement
Write one sentence connecting a released capability to the outcome. Avoid stacking unrelated audiences into the same sentence.
Evidence
Attach a product screen or documented workflow for each important promise, including the app version reviewed.
Objection
Name the question most likely to stop a suitable user and the proof available to answer it honestly.
Boundary
Record unsupported use cases such as navigation, and explain why they must not enter keywords or creative.
Your ASO assignment
Use your own app and evidence, or work through the teaching case. Keep your observations separate from assumptions and explain the reasoning behind your decisions.
- Create a situation-to-benefit-to-proof table with three rows.
- Mark unsupported claims and name who can verify them.
- Draft a 20-word positioning statement for your primary situation.
Scenario challenge
Draft two first-screenshot headlines for Trail Notes: one for remembering walks and one for finding routes. Explain why the second must be rejected for the current product even if respondents prefer its wording. Then identify one uncertainty you would investigate about the first.
Assess your work
- The situation is recognizable without demographic stereotypes.
- Every promise can be traced to a real feature or clearly stated limitation.
- The chosen audience has a reason to use the app after installation.
Common mistakes to catch
- Describing aspirations the product cannot deliver.
- Using a competitor’s strongest claim without verifying your own capability.
Knowledge check
Your most popular audience idea needs a feature on next quarter’s roadmap. Should it lead today’s listing?
Read the answer and reasoning
No. Lead with value available in the current release. Record the future audience as a hypothesis for the launch plan, with a dependency on product availability and verification. Demand does not make an unavailable feature an acceptable current promise.
Sources and further reading
Platform references reviewed 29 September 2026. These sources support platform capabilities and constraints; the teaching frameworks, assignments and illustrative cases are original course material.
- Apple — Creating your product page — Product-page fields and presentation guidance.
- Google Play — Metadata policy — Accurate, relevant metadata and prohibited presentation.
Your ASO lesson notes
Use this space for your assignment, evidence and handover. Select Save to keep a draft in this browser, or download a copy to take with you.
Notes stay on this device and are not submitted to ASO Agency.
Complete your assignment with the Interactive ASO audit checklist.
Loading your progress…
Progress is saved only in this browser. It does not sync across devices. Mark a lesson complete after doing its exercise.