This is the second post for 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. Here’s the first post.
TL;DR
A mandate is not alignment. The clapping in that kickoff meeting doesn't mean everyone is moving the same direction. Engineering, design, and leadership all have different fears. You can't argue people out of fears they haven't admitted to.
Run a two-week discovery sprint with a signed, written output. Write an MVP definition leadership can actually picture. And when someone escalates for their pet feature, hand them the bill and ask them to sign it.
The C-suite announced the initiative. Everyone nodded. Someone said: “Customer-centric.” There was a slide with a rocket emoji. People agreed it’s needed.
Then the meeting ended.
A mandate is not alignment. It’s just permission to start the hard part. And the hard part is the people. Engineering doesn’t want a second codebase. Design has never thought in touch targets. Leadership has a vague picture in their head that looks like Instagram but costs nothing. Getting all three moving the same direction before you’ve written a single line of code is the actual job.
Most companies don’t fail at mobile because they picked the wrong features. They fail because they never actually got aligned in the first place. They just assumed the clapping meant something.
The Scope Fight Is Never About Scope
I’ve sat in a lot of mobile scoping meetings. They all go the same way. Engineering wants to cut. Stakeholders want to add. Design wants three more weeks. Nobody is actually listening to each other. An hour passes. Everyone leaves annoyed, and nothing is resolved.
What’s actually going on in that room has nothing to do with features. It’s fear.
Engineering’s fear is the hidden one. They’re scared of the codebase they don’t know how to staff or maintain. The senior engineer in the corner isn’t worried about your MVP. He’s worried about being on-call at 2 AM when the iOS build breaks and nobody on the team knows what they’re looking at. He says “we need more time” because he can’t say “I don’t trust this plan.”
Design’s fear is about losing craft control. They’re afraid of losing the ground they’ve spent years earning. They have a design system. It works. Mobile breaks their assumptions about layout, interaction, handoff. What they’ve built their professional reputation on suddenly doesn’t apply, and nobody is acknowledging that.
Leadership’s fear is what keeps them up. It’s the 1.8-star app store review that lives in Google results forever. They’ve watched competitors embarrass themselves publicly on mobile. A bad launch doesn’t disappear. It sits there.
You cannot argue people out of fears they haven’t admitted to. What you can do is address the actual exposure each group is carrying.
For engineering: put it in writing. Agree in writing to a staffed mobile pod, a defined on-call model, and an explicit owner. Remove the ambiguity before it becomes a standoff. For design: pull them in before you’ve wireframed anything. Let them define quality on mobile rather than defending against decisions already made. For leadership: get go/no-go criteria agreed on now, before launch pressure makes everyone stupid.
Persuading harder doesn’t work. Changing what people are actually worried about does.
How to Actually Get Aligned
Run a Mobile Discovery Sprint: Don’t call it a brainstorm. Run a time-boxed sprint, two weeks max, with eng, design, and product in the room, and a specific deliverable at the end. Answer three questions: What does the user need to do on mobile that they can’t do well on web? What are the hardest technical constraints? What’s the minimum version we could ship and learn from?
Keep pulling the conversation back to constraints, not possibilities. End with a written, signed-off list of what’s in scope, what’s explicitly out, and the rationale for each call. That document will save you later.
Write an MVP Definition Leadership Will Actually Sign: The mistake you make is writing an MVP definition engineering can execute, but leadership can't picture.
The version that holds up has three parts.
Write a user story in actual English, not PM-speak. “A customer can pay their bill from their phone without calling support, in under three minutes.” That’s it. That’s your north star.
After that, list the features required to make that story true. Just those. That's the whole list. Don’t add anything else.
And include a list of what’s explicitly not in this version, along with a rough placeholder for when it’s reconsidered. This is the part everyone skips. Don’t skip it. The exclusion list is what keeps scope from rotting.
Handle the Scope Creep Stakeholder: There is always one. The senior leader who decided their feature must be in version one, or they will escalate.
Don’t fight it. Don’t fold either.
Make the cost visible: “I want to take this seriously. Can I walk you through what we’d have to cut or delay to fit this in V1? Once you see the full picture, if you still want to prioritize it, I’ll back that call and take it to [exec sponsor] to reset the timeline.”
That's the whole move. You're not saying no. You're handing them the bill and asking them to sign it. Most of the time, they don't want to sign it.
How to Not Die in the Last Month
Web-first companies always blow up mobile launches the same way. They build for six months, pick an arbitrary date, and then spend the last two weeks discovering that nobody ever defined what “done” actually meant.
What’s the acceptable crash rate? Nobody knows. How long does App Store review take? Someone guesses three days. It’s actually a minimum of ten, and that’s if nothing gets rejected. Are analytics instrumented? Mostly. Does the rollback plan exist? There is no rollback plan.
Fix this now, before you’re in it.
Before the project starts, get written agreement on:
Performance: Spell out P95 load time, the crash-free rate threshold, and that there’s no ANR on primary flows.
App Store: Set submission ten-plus business days before launch. Get metadata signed off. And talk about what happens if it gets rejected.
Analytics: Core flows need to be firing. Baseline verified in staging. And you should be able to answer one basic question: did the user finish what they came to do?
Feature flags: Every major feature can be turned off without a re-release.
Go/no-go: Define what's a hard blocker and what's negotiable, in writing, before launch pressure turns every opinion into a crisis.
The reason to do this up front isn't process religion. It's that everyone's judgment degrades under launch pressure. The CEO wants the date they announced. Marketing already sent the teaser. Engineering is running on nothing. In that environment, a pre-agreed checklist is the only thing left with any authority.
The Escalation Nobody Wants to Do
You did everything right. The sprint was clean. The MVP held. The milestones were real. And there is still one person blocking the whole thing for reasons that, if you’re honest with yourself, are mostly political.
Rookie PMs wait. They absorb it, absorb it, absorb it, and then eventually say something they regret. Now there’s a relationship problem sitting on top of the product problem.
The move is to go earlier, not angrier.
Write it down: the blocker, the impact, and your recommendation. Bring it to your exec sponsor not as a complaint, but as a decision that needs to be made at a higher level. “Here’s the situation, here’s what’s at risk, here are the options I see, here’s what I’d do. I need your call.”
That’s it. Clean, documented, no drama. You’re not throwing anyone under the bus. You’re doing the actual job, which is surfacing decisions to the people with authority to make them.
One more thing. The job people hired you for is building an app. The job you’re actually doing is building your company’s ability to build apps. Every time you handle one of these moments without making it a crisis, you’re teaching the org something. You’re making the next mobile project easier.
You’re the first one through the door. Make it look like you’ve done it before.
App Zero is a 4-part series for product managers at established companies launching their first consumer mobile app.