Mobile app product management: plan for the moment of use
Mobile app product management begins with the situation in which someone reaches for their phone. A task performed briefly on a train or repeatedly at a work site has different constraints from the same task at a desk. Those constraints belong in the product scope before the team chooses screens.
Choose a task that benefits from mobile access
Imagine an inspector recording equipment faults while walking around a building. The useful result is a submitted report attached to the correct location, with a photo and notes. The camera and immediate access matter because the inspector is standing beside the equipment.
Describe the existing workflow and the part the app improves. A complete office reporting system may be unnecessary for the first release. Capturing a reliable field report can be valuable even if supervisors still review it on the web.
Let the first session reach a useful result
Work backward from submitting that report. The inspector needs the right site, permission to report there and enough guidance to identify the equipment. Collect only the setup information needed for those decisions at that point.
Use platform conventions where they help people understand navigation and controls. Apple's Human Interface Guidelines provide the iOS reference. Android's app-quality guidance considers user value, experience, technical quality and safety together. Neither source replaces research into the inspector's actual working conditions.
Decide what survives an interruption
The inspector may receive a call, lose the connection or close the app halfway through a report. Define which work remains on the device, which has reached the service and how the person can tell the difference.
For this hypothetical release, save the draft locally after edits and queue submission when offline. Show the report as pending until the service confirms receipt. If access to the site has changed before submission, keep the draft and explain the problem instead of silently discarding it.
Android's guidance on UI-state production distinguishes inputs and processing from the state presented to the user. For the product brief, make the corresponding outcomes explicit: editing, pending, submitted and failed cannot all look like a completed report.
| Situation | What the inspector needs |
|---|---|
| Connection unavailable | A saved draft and a visible pending status |
| App reopened during editing | The unfinished report and its attachments |
| Upload rejected | A reason where known, preserved work and a recovery action |
| Service confirms receipt | A submitted report that can be reopened |
Ask for access where it becomes necessary
Request camera access when the inspector chooses to take a photo, with an explanation tied to that action. Decide what remains possible after refusal. In this example, the inspector can continue writing the report and attach an existing image if permitted.
Review data collection with the people responsible for privacy and security. A field app may expose workplace images or location information, so the product needs clear rules for who can see the report and what is retained. Copying every available device signal into analytics does not answer a product question.
Set a device scope and test the whole journey
Agree the supported operating systems, screen sizes and input methods. Test readable text at larger settings, screen-reader navigation, camera behavior and a return from the background. Include the devices and conditions the intended audience actually uses.
Before launch, complete a report through a real interrupted session and reopen it after submission. Then observe whether the first cohort can report faults without returning to paper. The launch checklist covers release readiness, while product analytics helps define completion without counting a screen view as a submitted report.
Sources
Discuss your product's next step
I help define product priorities, plan launches and investigate where users drop out.
