Mobile Project Planning

Mobile Project Planning

Instructions

Mobile projects fail most often from unclear scope and mismatched platform expectations, not from coding mistakes. Use this skill to turn a product idea into a buildable plan before any architecture or code decisions are locked in.

1. Capture the Problem, Not the Screens

Start with three artifacts, in this order:

1. Job stories -- "When , I want to , so I can ." One sentence each, no UI words.
2. Top-level KPIs -- what metric proves the app is working (D7 retention, conversion, session length, completion rate). One primary, two guardrails.
3. Non-goals -- written explicitly. What the app will not do in v1.

If the team is drafting screens before these exist, stop and back up.

2. Define the MVP Cut

An MVP is the smallest app that lets a real user get the core outcome end-to-end. Use the cut checklist:

• One happy path end-to-end. No branches.
• One persona. Secondary roles come later.
• One platform (usually the one your target users skew toward).
• Manual ops are allowed. Admin consoles, CSV uploads, and humans in the loop are valid MVP substitutes.
• Paywall, auth, and onboarding can often be simplified or stubbed for v1 if the KPI does not depend on them.

Write an MVP spec that a stranger could read in 10 minutes.

3. Prioritize Platforms

Pick a launch order, do not try to ship both platforms simultaneously unless a cross-platform stack is chosen and staffed for both.

Document the decision with one paragraph of reasoning in the project README.

4. Milestone Sequencing

A mobile plan sequences five tracks in parallel, not one linear backlog:

1. Product spine -- the critical happy-path flow.
2. Platform plumbing -- auth, storage, networking, crash reporting, analytics.
3. Release pipeline -- CI, signing, internal testing track, stores.
4. Compliance -- privacy labels, permissions copy, export compliance.
5. QA assets -- device list, test plan, beta cohort.

Every milestone should move all five forward. Avoid milestones that only ship product spine, because the others then block launch.

5. Estimation Heuristics

• A screen with real data, empty state, error state, and tests is typically 2-5 engineer-days per platform, not per project.
• Every third-party SDK adds review, privacy, and binary-size cost. Budget half a day per SDK for integration plus ongoing maintenance.
• First store submission typically takes 1-2 weeks of calendar time for review, metadata, and iteration on rejections. Include this explicitly.

6. Deliverables From Planning

At the end of planning, the agent should produce:

# Product One-Pager
- Job story (primary): ...
- Primary KPI: ... (target: ...)
- Guardrail KPIs: ..., ...
- Non-goals: ...

# MVP Scope
- In: ...
- Out: ...
- Manual workarounds: ...

# Platform Plan
- Launch platform: iOS | Android | both (stack: ...)
- Follow-on platform ETA: ...

# Milestones (6-8 weeks)
- M1: spine screens + auth stub + CI green
- M2: persistence + offline read + crash reporting
- M3: store pipelines + internal beta
- M4: payments or core monetization
- M5: public launch readiness

7. Anti-Patterns to Refuse

• "Let us ship everything in the roadmap as v1." Force a cut.
• "We will decide platform later." Decide now; revisit in writing.
• "Designs first, scope later." Scope first; designs serve the cut.
• "We will do QA at the end." Plan QA into every milestone.

Checklist

• Primary KPI and guardrails are named and measurable.
• MVP fits on a single page and covers one persona on one platform.
• Launch platform is documented with rationale.
• Five parallel tracks are represented in every milestone.
• Third-party SDK count is explicit with per-SDK justification.
• Non-goals list exists and is referenced in planning reviews.
• Estimation accounts for store review latency.