# One designer, two stores and a long backlog

Companion to /learn/aso-roadmap/

## Outcome
Build a 90-day plan around dependencies and learning milestones rather than ranking promises.

Fictional example, not a client result.

## Scenario
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.

## Reasoning
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.

## Action
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.

## 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.

## Advanced considerations
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.

## Exercise
A localization dependency slips by two weeks. Should all other work be accelerated to preserve the original roadmap graphic?

## Suggested answer
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 worksheet

### Objective and priority audience
Answer:
Evidence:
Uncertainty:
Owner:
Next action:

### Capacity and named owners
Answer:
Evidence:
Uncertainty:
Owner:
Next action:

### Dependencies and approval requirements
Answer:
Evidence:
Uncertainty:
Owner:
Next action:

### Delivery milestones and release record
Answer:
Evidence:
Uncertainty:
Owner:
Next action:

### Evidence review conditions
Answer:
Evidence:
Uncertainty:
Owner:
Next action:

### Deferred work, risks and replanning triggers
Answer:
Evidence:
Uncertainty:
Owner:
Next action:

## 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.

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.

## Continue reading
- /learn/aso-strategy/
- /learn/aso-on-a-budget/
- /learn/measurement/monthly-reporting/