A 90-day ASO roadmap schedules decisions, deliverables and dependencies within available capacity. It commits to controllable work and evidence reviews; it does not promise a ranking or a conclusive experiment by an arbitrary date.
Your deliverable: Build a 90-day plan around dependencies and learning milestones rather than ranking promises.
Change the starting point. Keep the decision gates.
ILLUSTRATIVE DAYS 1–30
Establish the promise
Verify the supported product, intended audience and research hypotheses.
ILLUSTRATIVE DAYS 31–60
Prepare a coherent release
Produce and review metadata and creative, with clear publishing ownership.
ILLUSTRATIVE DAYS 61–90
Review the first evidence
Inspect available acquisition context and choose the next justified question.
New app emphasis: build an accurate starting point before interpreting early performance.
Illustrative planning framework, not client results, a ranking forecast or a universal schedule. Windows are illustrative; dependencies and useful evidence determine actual timing. This selector is local and does not predict outcomes.
01
Use the period as a planning container.
Ninety days is a way to organise work, not a scientific deadline for results. Define the objective, audience and available resources. Identify which decisions can reasonably be addressed in the period.
Read ASO timing guidance before turning a calendar into a promise. Publishing and evaluation dependencies may require changing the plan.
02
Begin with diagnosis and the baseline.
Record the live listing, relevant metrics, known changes and unresolved questions. Prioritise corrections and the strongest research needs. Do not schedule production before the product promise and intended audience are clear enough to brief.
Use an audit framework. The deliverable is a reasoned starting point with owners and dependencies, not a long list of disconnected tasks.
03
Plan production with approval capacity.
Identify which recommendations become copy, designs or implementation work. Name reviewers and the publishing owner. Reserve space for revisions and verification rather than assigning every available day to creating more assets.
Use a clear handoff and record release versions. If production slips, update the evaluation plan instead of pretending users saw the change on the original date.
04
Define the review before the release.
State which evidence will inform the next decision, what comparison is appropriate and which other changes must be recorded. A useful review can conclude that evidence is insufficient.
Review what changed, what was learned and what remains blocked. Move work when dependencies change, preserving the reason. End the period with the next justified action rather than an automatic renewal of the same backlog.
The planner in this guide changes the emphasis by starting condition. It is an interactive thinking aid, not a guarantee that every app can finish the same sequence on the same dates.
WORKED EXAMPLE / FICTIONAL APP
One designer, two stores and a long backlog
HabitHarbour is a fictional app with one part-time designer and separate iOS and Android listings. The backlog includes research, metadata, screenshot production, localization and experiments. Scheduling everything in the first month would produce an impressive roadmap and an impossible workload.
How to reason through it
Start with the constraint and work backwards from decisions. Research must inform the brief; product verification must precede claims; native review must precede localized publication. Put these dependencies on the plan before assigning dates. Keep work milestones separate from the time needed to gather useful outcome evidence.
The next practical move
Use the first phase to establish the baseline and priority audience, the second to produce and release a focused change, and the third to review evidence and choose the next iteration. Reserve capacity for corrections and approvals. If traffic cannot support the proposed experiment within the planning window, choose another useful learning activity rather than promising a conclusive result by day ninety.
Swipe horizontally to compare the decision map →
One designer, two stores and a long backlog: illustrative decision map
Decision area
What to inspect
What it means for the work
Days 1–30
Diagnose and decide
Baseline, research and approved priority brief
Days 31–60
Produce and release
Reviewed assets, owners and publication record
Days 61–90
Evaluate and adapt
Evidence review and next decision; may remain inconclusive
The trap to avoid
Do not promise a ranking position at the end of the roadmap. Commit to work the team can control: research, briefs, production, review and implementation. Outcome evidence belongs in the evaluation plan with its limitations visible.
When the situation gets more complicated
Maintain a decision backlog separately from the delivery backlog. The first contains questions such as which audience to prioritise; the second contains tasks such as exporting approved screenshots. Completing tasks cannot compensate for an unresolved strategic choice. Review both at each milestone and remove activities whose original rationale no longer holds.
FROM METHOD TO DELIVERABLE
A capacity-aware delivery plan for HabitHarbour
This fictional plan assumes a part-time designer and separate iOS and Android listings. The ranges are planning windows, not expected time-to-results. Each phase ends in an acceptance decision before dependent work advances.
Swipe horizontally to read the complete example →
Illustrative plan with dependencies. Actual windows depend on scope, capacity and release constraints.
Planning window
Deliverable and owner
Exit condition / dependency
Days 1–15
Baseline and issue record / analyst with product owner
Comparable definitions and available product workflows documented
Days 16–30
Priority brief / growth lead
Audience, promise, exclusions and approver agreed
Days 31–50
Focused asset package / designer and copy owner
Product-accurate copy and readable assets approved
Days 51–60
Publication and verification / release owner
Exact approved versions visible in the intended contexts
Days 61–90
Evidence review / analyst and decision owner
Choose retain, investigate or iterate; allow an inconclusive outcome
Reserved capacity
Corrections and re-review / relevant owners
Do not allocate every available hour to new production
Put approval capacity on the schedule
A designer’s availability is only one constraint. Confirm when product reviewers, native reviewers and publishing owners can act. Reserve time for their feedback and for verifying the published version. If the approver is unavailable, moving the design deadline earlier may simply create a queue of unfinished decisions.
Replan from the dependency that moved
If approval slips, move publication and the evidence-review window accordingly. Preserve the actual release date rather than reporting against the original plan as if users saw the change. Continue independent research where useful, but do not rush essential accuracy checks to protect an outdated calendar graphic.
End the quarter with a decision inventory
Separate finished deliverables, verified releases, answered questions and unresolved questions. Decide which work deserves the next period’s capacity and why. Remove tasks whose rationale no longer holds. If traffic did not support a useful experiment conclusion, state that limitation and choose a more informative next action instead of automatically repeating the same test.
A localization dependency slips by two weeks. Should all other work be accelerated to preserve the original roadmap graphic?
Reveal the reasoning
Replan dependent work and communicate the consequence. Independent research or review may continue, but do not remove necessary quality checks merely to preserve an outdated date. A useful roadmap reflects delivery reality.
Your working brief
Use your own app for this exercise. Fill in the six fields below and attach the evidence behind each answer. If you cannot complete a field, write the missing question and the person who can resolve it. Do not replace unknowns with optimistic assumptions.
Objective and priority audience
Capacity and named owners
Dependencies and approval requirements
Delivery milestones and release record
Evidence review conditions
Deferred work, risks and replanning triggers
For each field, distinguish an observation from an interpretation. Add the date and source where available, then identify the decision that follows. A colleague should be able to trace your recommendation back to the evidence without needing you to explain the entire project again.
Use monthly reporting to revisit decisions and dependencies during delivery.
The worked example is an original editorial framework. Its fictional app, decisions and scenarios are not an industry dataset or a claim of measured uplift.
