ASO course · lesson 2 of 60
ASO strategy: set goals, scope and success metrics
Turn a vague growth request into a measurable project with explicit boundaries.
By Gabriel Machuret · Editorial methodology
Before you start: The bottleneck diagnosis from lesson 1.
Module 1: Foundations and diagnosis
Plan about 50 minutes for reading, practice and review
You will produce: A project charter with objective, deliverables, exclusions, owners, dependencies and acceptance criteria.
Understand the decision
Translate ambition into a decision
“Improve ASO” describes an activity, not a result. A stronger brief identifies an audience, desired behavior, period and constraint: help first-time Australian hikers recognize the journal use case, then evaluate activation after download. A target is a planning assumption, not a promise. Write both the outcome you want and the work you can actually control.
Separate deliverables from outcomes
A keyword map, six screenshots and a test brief are deliverables. Incremental qualified users are an outcome influenced by demand, product quality and execution. The project can guarantee delivery of agreed work, but cannot guarantee a ranking or uplift. This distinction makes approval easier: reviewers can judge whether the work is complete without confusing completion with experimental success.
Make boundaries operational
Scope should identify stores, territories, languages, versions, asset formats, approval owners and publication responsibility. Add what is excluded, such as paid media management or native translation, and how new requests are handled. A scope that simply says “all ASO” allows silent assumptions to become delays. Agree which decisions can be made with current evidence and which need additional access.
Apply the method in practice
Convert the objective into a decision contract
Ask the sponsor what decision they expect to make after the work. If the answer is “grow globally,” ask which available product, audience and revenue model could make that useful now. Write an outcome that can be measured and a deliverable that can be accepted independently. A completed metadata pack can meet its acceptance criteria even when the later test is inconclusive. Conversely, a temporary ranking increase cannot excuse an inaccurate or unusable handover. Name who owns the business metric and who accepts the work. If those are different people, both need to understand the contract before production begins.
Estimate capacity through dependencies
Break the work into research, drafting, design, review, console preparation and verification. Estimate each with the people who will do it. Translation is not only a word-count expense: it may require new keyword research, recreated screenshots and product-language checks. Mark dependencies that can block the critical path, such as unavailable app access or a reviewer on leave. Distinguish hands-on effort from elapsed time; two hours of editing can wait a week for approval. Limit the first delivery to a scope that can complete the entire chain rather than starting six markets and finishing none.
Handle changes without losing the original outcome
A change request should identify the new deliverable, its reason, additional dependencies and what moves out of the current capacity. Present choices rather than silently compressing the original work. For example, adding a second language could replace the screenshot test this cycle or move the release date. Record the decision and update acceptance criteria. Do not measure the team against the old schedule after agreeing a larger scope. A useful charter also states who can publish, who can approve a claim and what happens if a required approval is unavailable.
Platform references for this work: Apple — Creating your product page
Your step-by-step procedure
- Write the business objective in one sentence and identify its metric owner.
- List the deliverables required to investigate or address the diagnosed constraint.
- Assign a reviewer, publisher and acceptance condition to each deliverable.
- Record exclusions, dependencies and a process for changing scope.
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 asks for “global growth.” The initial scope becomes one iOS listing for Australia, a relevance map, a metadata draft and a creative test proposal. German localization and ad buying are excluded. Acceptance means the drafts are accurate, within current requirements and approved by the product owner. Success is evaluated separately against comparable acquisition and activation evidence. A later German launch becomes a new decision with its own language-review dependency.
| Deliverable | Acceptance evidence | Dependency |
|---|---|---|
| Keyword map | Relevant terms with sources and exclusions | Product walkthrough |
| Metadata draft | Approved strings and field checks | Product owner review |
| Creative proposal | One hypothesis with control and treatment | Design capacity |
This charter creates three reviewable outputs, not three promised growth results. A reviewer can inspect whether the strings match the product and whether the experiment has a decision rule before any traffic arrives. If design capacity disappears, the metadata work may proceed while the creative proposal is rescheduled. The output, timing and expected learning change explicitly. That makes the scope useful as an operating document instead of a sales promise that everyone interprets differently.
Build a handover someone can use
Objective
State the useful customer action, target population and review window. Example: more new Australian journal creators, with activation measured separately from downloads.
Deliverables
List the exact files and decisions to be delivered. “Metadata” should specify platform, locale, fields and draft or submission responsibility.
Acceptance
Identify the reviewer and observable completion evidence. Require accurate claims and validated fields; keep uncertain business results outside delivery acceptance.
Dependencies
Name needed access, designers and reviewers. Attach dates and an alternative sequence when a dependency is late.
Change control
Record what an extra market displaces, who agreed the tradeoff and the revised delivery date.
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.
- Rewrite a vague project request into a one-market brief.
- Create an acceptance checklist for three deliverables.
- Write a scope-change example and who must approve it.
Scenario challenge
A founder adds German and Japanese listings two days before delivery. Write two feasible choices: preserve the original market and schedule the expansion, or replace an agreed deliverable with a properly scoped localization brief. Explain research, reviewer and asset dependencies rather than multiplying the English copy by two.
Assess your work
- Deliverable acceptance does not depend on a guaranteed ranking.
- Each requested market has a product-readiness reason.
- Publishing responsibility and approval authority are explicit.
Common mistakes to catch
- Quoting a universal delivery schedule before seeing access and approval constraints.
- Treating an additional language as a cost-free copy change.
Knowledge check
A stakeholder requests five extra markets after approving one. What changes?
Read the answer and reasoning
Reassess research, translation, design, QA and measurement effort before accepting the expansion. Show how it affects sequence and dependencies, then record an agreed scope change. Silently spreading the same effort across six markets weakens the original acceptance criteria and makes subsequent results difficult to interpret.
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.
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 ASO experiment planner.
Loading your progress…
Progress is saved only in this browser. It does not sync across devices. Mark a lesson complete after doing its exercise.