This is the third post of App Zero: Get Mobile Right the First Time is a series for PMs at established companies who've been handed a mobile mandate and don't want to blow it. We began here.
TL;DR
Every stakeholder had one feature. Perfectly reasonable. You said yes to all of them and ended up with a 2.8-star disaster with a splash screen. "Web parity" is a lazy default dressed up as requirements.
The only question that matters on day one: what does this app need to prove mobile is worth the investment? Find two or three native micro-jobs and build those. Everything else gets a deferred trigger with explicit unlock conditions.
Your MVP is already bloated. Every stakeholder had one feature. Completely reasonable. Completely necessary. Completely capable of doubling your timeline.
I’ve said yes to all of them. Never got a v1. I just planned disasters with a splash screen.
Apps took nine months to build. Launch dates slipped. I’ve lost credibility with my developers. Users handed me 2.8 stars and an App Store page of one-star reviews I couldn’t delete.
Nobody was proud of them. Nobody learned anything. "Mobile" became a dirty word in every company I worked in.
So I built a structured way to push back. This is it.
The Parity Trap
The most common mistake I've made in mobile product thinking was a framing decision. Someone in the room said, "The mobile app should do everything the website does," and nobody laughed.
Web parity is a lazy default dressed up as a requirements doc.
Stakeholders get nervous when familiar features are “missing.” Engineers default to what they’ve already built. And you, without a structured defense, capitulate because it feels safer than the argument. You end up porting a desktop experience onto a 6-inch screen, wondering why engagement is terrible.
So reframe the conversation entirely. The only question that matters:
What does this app need to do on day one to prove mobile is worth the investment?
The Three-Pillar Defense
Pillar 1: Find the 2-3 Native Micro-Jobs
Mobile does a small number of things dramatically better than web: high-frequency tasks, location-dependent actions, and anything that benefits from a push notification at the right moment. That’s it.
Your job is to identify the 2 or 3 tasks your users will want to do on their phone, on the go, without sitting down to think about it. Things like order tracking, loyalty check-ins, quick reorders, and appointment reminders. These are the things that genuinely benefit from native.
Everything else waits. Use a web view, add it to the backlog, or cut entirely.
Audit every proposed feature against one question: does mobile handle this exponentially better than a browser? If the honest answer is “not really,” cut it.
Pillar 2: The No-Hedge Scope Document
Here's the pattern that kills most mobile PRDs: everything that doesn’t make the cut gets labeled “Phase 2.”
I've written more Phase 2 parking lots than I can count. None of them shipped.
Write a scope document where non-inclusion is an explicit decision with explicit conditions attached. Write it with a trigger: “User profile editing is deferred until we hit 50K MAU or onboarding completion exceeds 60%, whichever comes first.”
Now you have a contract. Stakeholders know the feature isn’t dead. They know what unlocks it. And you’ve bought yourself a launch without the feature.
This also forces you to be honest about what you’re actually prioritizing. If you can’t name the metric that would trigger a deferred feature, you don’t believe in it yourself.
Pillar 3: The Mobile Effort/Impact Matrix
Week-one engineering estimates for mobile are always wrong. Not a little wrong. Often 2x wrong.
Things that are “cheap” on web are deceptively expensive on mobile. Complex forms, legacy auth flows, and anything that touches the OS directly (camera, location, notifications) all carry hidden costs that don’t show up in your web estimates.
Before you finalize scope, sit down with your engineers and get a mobile-specific estimate for every feature. How long on iOS? How long on Android? What changes when you factor in OS permissions, offline states, and two rounds of App Store review?
The number will go up. Plan for it.
Then build a simple matrix: estimated mobile effort on one axis, expected day-one user impact on the other. Anything in the high-effort/low-impact quadrant is not a v1 feature.
Launch Sequencing over Big Bangs
The companies that do mobile well don’t launch with everything. They launch with one or two things done so well that users tell their friends about it.
Instagram launched with filters and a feed. That's it. They built the thing people actually wanted on their phone, nailed it, and used the momentum to justify every feature that came after.
You have the same option. Launch narrow. Ship quality. Then show the data to earn more scope. A 4.4-star App Store rating from a constrained, polished v1 is a much stronger argument for headcount and budget than a 2.3-star rating.
Narrowness pays off another way. Launch two features and your metrics are legible. Launch five and you're guessing.
The 7-Question Scope Review Checklist
Copy this into your PRD. Make your team answer them. Features that can’t clear the bar get deferred with explicit unlock conditions, not vague “Phase 2” labels.
Does this feature serve one of our 2-3 core mobile micro-jobs?
If omitted, does it break the critical path, or just cause minor user friction? (Minor friction is a web view. Or a support email. Not a build.)
Are we estimating this based on actual mobile architecture, or copy-pasting web engineering assumptions?
Does this feature affect more than 5% of our target day-one user base? (If not, it’s an edge case. Edge cases don’t make v1.)
Can this be handled by an elegant error state, a web view, or a support flow instead of native code? (Honest answer: usually yes.)
If this feature delays our App Store submission by two weeks, are we still glad we built it?
Which specific mobile metric does this feature move, and is logging ready for it? (If you can’t name the metric, you can’t justify the feature.)
Your PRD is open. Start at the top of your feature list and run every item through these seven questions. Anything that fails gets a deferred trigger, not a Phase 2 label.
You’ll cut more than you expect. That’s the point.
App Zero is a 4-part series for product managers at established companies launching their first consumer mobile app.