Whether you're a startup or a product team inside a large company, building a mobile app follows the same process.
When this process is run well, it moves faster than most people expect. A true MVP should be put in the hands of users as quickly as possible to learn and iterate, often possible within 6 to 10 weeks of development.
But it's tricky to get right.
This guide walks you through each step, from start to finish. It covers what happens at each stage, who needs to be in the room, and what decisions need to get made.
This is the process we've at Studio for every product we've shipped over the years. It's been pressure-tested across 100+ launches. Every step is in here because we've seen what happens when teams skip it.
Step 1: Start With the Problem to Solve (Not a List of Features)
Before you do anything else, the very first thing you need to do is to clearly articulate the problem you're trying to solve.
Almost nobody does this.
Most teams skip straight to brainstorming a list of features. But features are solutions. If you come up with solutions before you even know what problem you're solving, that means you're guessing. More commonly, you'll end up building a "solution in search of a problem" - a product that technically works, but that nobody needs.
Before anyone designs or builds anything, get three things down on paper:
- A product brief: who's on the team, what the industry looks like, what you know about the users, and what's already been tried. Every stakeholder needs to read this before kick-off.
- A one-page problem statement: outline the problem you're solving, who you're solving it for, how they handle it today, and why it's worth solving.
- Success metrics: what quantifiable metrics would prove whether the product is working or not? These need to be tied to business objectives. "Users love it" is not a success metric. "30% of new users come back after day 7" is.
Then get every stakeholder into a room for a kick-off meeting. This meeting has one purpose: to align everyone on the problem you're solving. Solutions come later. A lot of times this is the hardest part. And if that room isn't aligned on the problem, no amount of design or engineering will save you later.
End the Kick-Off With a Hypothesis
The kick-off should end with one clear deliverable: the hypothesis you plan to test with your MVP. Take the problem you just aligned on and turn it into a one-sentence bet structured in the following way:
"[User type] struggles to [goal] because [cause], resulting in [impact]."
That's the bet that the whole project exists to test, and every scoping debate gets settled against this sentence (more on the MVP below).
Step 2: Product Strategy (De-risking Your Riskiest Assumptions)
The product strategy phase is focused on defining and clearing product assumptions, both internally (i.e. have you identified the right API to integrate?) and externally (i.e. do users today struggle with this problem?). Eventually, its outcome is a feature set you feel enough confidence in to move into the design and development phase
Talk to Users First
No product should be built without talking directly to an end user. Not a single line of code should get written before this happens.
Structure the user interviews around your assumptions and ask unbiased questions:
- Good: "Walk me through the last time you hit this problem. How did you solve it?"
- Bad: "Would you use an app that does X?" - this begs for a polite yes.
Make sure to recruit people who match your target users. Interviewing folks who don't have the problem you're trying to solve won't give you information that's useful.
Map the User Journey
Map the user journey on a whiteboard: key users on one side, the outcome they're trying to reach on the other, and the steps they take to get there today in between.
Mark where they struggle with the tools they have now.
Those pain points are the raw material for everything that follows.
Run a Competitive Analysis
After mapping the user journey, run a competitive analysis. Make a list of everyone that's trying to solve the same problem.
This could be apps, but could also include workarounds like spreadsheets and group chats.
Benchmark who does what well (the things nobody does well is usually your wedge).
Sketch Three Concepts, Then Pick a Direction
Once the research starts coming together, come up with three product concepts (i.e. three different directions the product could take). Each should be a short, plain-language description + concept images from the designer. Not real designs, just enough to picture each concept and compare them.
Put the research summary and the three directions into a deck, get the decision maker in the room, and decide which to pursue. Pick the direction that best addresses the pain points you found, and that you could build within the six-week test.
Step 3: Define the MVP (the Minimum Feature Set to Test Your Hypothesis)
The MVP is the minimum feature set necessary to prove or disprove the hypothesis you defined during kick-off. The question to ask yourself when coming up with this list is: "What is the absolute smallest amount of software our team can make in order to test our hypothesis?"
The deliverable is a product requirements document that outlines every feature the MVP will include, each with a short description. The only features that should make it into the MVP should be the ones that are absolutely necessary to deliver the core value prop of your app so you can test your main hypothesis. Anything that is not necessary to test the hypothesis can wait for a future release.
Keep in mind: the MVP is an experiment, not an early draft of the final product.
Our initial assumptions are almost always wrong, and the purpose of the MVP is to gather data to prove or disprove your riskiest assumptions, so we can learn and iterate quickly towards building a product people want. And often the product you launch is often very different from the product you initially set out to build
The pushback we hear to this is typically some version of: "what if we ship the small version, it's not good enough, and people never come back?" Maybe. We'll find out. Until real users touch the product, you're designing in a vacuum - you're just guessing.
And the goal of the MVP is to get something into the hands of real users as quickly as possible, so we can see how they use it, see if our initial assumptions were correct - and make adjustments based on what we learn.
Step 4: Design Just Enough to Start Building
Now that your MVP feature set is locked and ready to go, it's time to create the designs that will be handed off to engineering to build.
Wireframe the Main User Journey
Wireframes are rough, un-styled layouts of each screen - basically just boxes and labels showing how each screen will be laid out, and what happens when you tap on certain things. At this point you're just working out how the app will function and what the flows will be before you get into real, high fidelity designs. The beauty of wireframes is that they're cheap to make and cheap to change, which allows you to easily explore ideas.
Start with the critical path of the app, the main flow users will go through to get the core value of the product, and deliberately skip everything else. Things like onboarding, error states, settings screens, etc can all come later.
For example, if you were building an app for finding someone to play ping pong with, you'd wireframe find-your-friends, start-a-match, and the go button.
Start at the center of the product and work your way out.
Move to High-Fidelity Designs
Once the wireframes for the critical path are signed off, the design team puts together the UI/UX (i.e. the finalized versions of each screen). To this stage on track, the product manager needs to stay close to the design work and make sure everything being mocked up is technically feasible. A beautiful screen that engineering can't build is wasted time.
Set Up the Handoff to Engineering
By the time designs for the initial screens are being completed, make sure the project board (Linear, Jira or whatever tracker you use) is loaded with user stories for the first 2-3 sprints. These are short, plain descriptions of functionality told from the user's perspective ("as a player, I can invite a friend to a match").
The first sprint's stories should have final designs attached, so engineering can start immediately. Stories for the later sprints don't need to have designs yet - design should work one sprint ahead, so engineers never have to wait on screens.
Step 5: Estimation, Scoping, and Budget
Before the first engineering sprint starts, every stakeholder is asking the same two questions: how long will this take, and what will it cost? Here's how to approach these questions.
Estimate Every Story in Points
Go through each of the user stories with the engineers who will actually be building them. Have them roughly estimate each story and agree on the priority order you'll build them in.
Every story gets a point score. Use the Fibonacci sequence (e.g. 1, 2, 3, 5, 8, 13) to ballpark how much effort you think it will take to implement, and have the team align on how many points they can complete in a single 2-week sprint.
Now you can use these estimates to work backwards into a timeline. Total points divided by points-per-sprint will tell you how many sprints you'll need to build the MVP. For example, 100 story points, divided by 25 points per sprint, means you have 4 sprints worth of work - or 8 weeks). And team size multiplied by the timeline will give you the estimated cost to build.
Points per sprint is dependent on a team’s velocity - factors like team size, time spent working together prior, seniority, and so on, all contribute to velocity.
These estimates are meant to be a forecast, not a promise. And its accuracy can depend on a bunch of different factors that you won't be able to predict in advance. Expect to make adjustments to the estimate as you make progress and learn. That's the reason for the next decision:
Fix the Budget or the Scope, Never Both
Since you know the estimate is going to flex based on unforeseen variables that you can't predict ahead of time, avoid keeping both budget and scope fixed. You can fix one of them, but we advise our clients to keep at least one of them flexible:
- Fix the budget. Rank the feature list by business value and ship the most valuable work the budget covers.
- Fix the scope. The must-have features ship, across however many sprints that it takes.
It's never a good idea to fix both of them. If the money and the feature list are both locked, the only thing left that can give is quality - and in our experience it's never a good idea to sacrifice quality over scope & budget.
Staff the Build Team
Once the estimate is signed off, the engineers and QA join the product manager and designer, and they start building. We typically suggest at least 1-2 frontend engineers, a backend engineer, and a half-time QA specialist at the absolute minimum.
The exact type of frontend engineers will depend on whether you decided to go native (iOS, Android) or cross-platform.
For most MVPs we suggest going native on the one platform most of your users live on, because it allows you to build an amazing consumer-grade experience, and also helps you avoid making the same mistake across platforms. But if that level of polish isn't as important for your users (e.g. if you're building an enterprise analytics product), cross-platform can be a great option because it allows you to build for both platforms (and web) all in one codebase.
Once you have the team in place, the first engineering sprint begins - roughly 30 days after kick-off.
Step 6: Build in Two-Week Engineering Sprints
Engineering should operate in fixed 2-week sprints. And the goal of every sprint should be a new working release of the app, each one with more features and polish than the last.
Here's the cycle that gets run inside each sprint:
- Sprint planning. A two-hour meeting with whoever owns prioritization. You review the product backlog (the list of all the possible features to be built in the MVP, prioritized by business value), and lock in the stories you plan to ship in the next 2-week sprint. New ideas go in the backlog for future sprint planning.
- Daily scrums. Fifteen minutes each day where you go over what got done, what's next, what's blocking. A daily design call runs alongside this.
- Sprint review. A meeting where the team demo's each of the stories they shipped in the sprint, open to all stakeholders.
- Retrospective. Take time to reflect on how well the team is working together, and what needs to be improved or adjusted for the next sprint.
At the end of a sprint, the work should be potentially shippable - a real, installable build every two weeks, released to stakeholders and testers (the public launch comes later, more on this shortly).
Aim for the MVP to be completed within about 3 sprints (5 or 6 at the absolute max). If the plan says 10 sprints, you need to adjust the scope. Rip half of it out, only keep the features that test your hypothesis. That's your MVP. Get that to market.
When something goes over the estimate anyways (and something always does), move it to the next release build. Don't compromise quality to hit a self-imposed scope. Teams that finish their work early should pull the next story off the backlog and keep moving forward.
Step 7: Test the Whole Way Through
QA needs to be part of the sprint team from day one - running acceptance tests on every internal build in the same iteration as the dev team. If you wait to do testing during a "hardening phase" at the end, you'll end up finding bugs when they're most expensive to fix.
There are two practices back that make this work:
- Peer code reviews: every piece of code needs to be reviewed by another senior engineer before being merged
- Unit & integration tests should run continuously to making sure new code doesn't break things that were already working
Make sure you give every tester a zero-friction way to report bugs too. It should be as easy as possible to file a bug report so users don't just ignore them.
Step 8: Beta Test, Then Launch
Don't ship your MVP straight into the app stores. Instead, we suggest releasing it to progressively larger groups over time. We call this a beta ladder.
Each new group knows less about the product than the last, so each group catches problems the previous one was too close to see. The product manager writes the test cases (a script of what to try and what should happen), and every test group works through them:
- First, start with the core project team
- Then, expand to teammates outside of the project
- Next, invite project stakeholders
- Then bring in a small subset of real users
- Open it up to a larger, private beta test group
- Finally, run an open beta test (or soft launch)
Once the open beta is able to hold up to real usage, the app is production-ready.
A quick note before you launch: get two things ready. First, audit your analytics (Segment plus Mixpanel is a solid default) to confirm every event is tagged and the KPI data you've been capturing since Step 3 is flowing in properly. And second, prep your app store listing so that you're ready to submit to the app store as soon as your beta test is complete.
Step 9: Keep Iterating - Launch is Just the Starting Line
Everything you did to get to this point was building up to this moment. Now it's time to put your product into the market. This is when the hypothesis you came up with in step 1 will be put to the test with real users for the first time.
The 2-week engineering sprint cadence keeps going once you launch. The only thing that changes is that real user data replaces assumptions and feedback from testers.
The Moment of Truth: Does Your Hypothesis Hold?
Put a paid campaign behind the product, enough to get your first 100 users or so. And compare what users are actually doing against what you assumed they'd do. Then ask the question the whole project has been building toward: was your hypothesis correct?
- Are they actually using the product to solve the problem the way you expected?
- Do they make it through the core journey you designed, or drop off partway? Where?
- Do they use the product for a short time and leave for good, or do they come back?
- What are they doing that you didn't expect? Surprises in the data are often the product telling you what direction you should go next
Review the metrics against the success metrics you defined at the beginning of the process. If the numbers hold - your hypothesis is validated. You know what's working.
If you missed them, one of your key assumptions didn't hold. The data will show you where the problem lives (people churning in the first week, nobody taking the key activation step, etc) but not why - that takes more research to figure out.
Either outcome is a win because you found out in weeks, not months or years. And you still have runway to act on what you learned.
What to Iterate On Next
If you hit your numbers, the temptation is to build everything you cut from the MVP. Resist this urge. You have a small group of users who love the core thing you've built, and every new feature you add pulls attention away from that core.
We always suggest going deeper before you go wider:
- Remove friction from the core journey first. Make the thing they're using even easier to use by removing all the rough edges
- Re-evaluate the features you cut from the MVP against real usage. Some of the features you thought made sense previously will look pointless in the context of actual behavior. And other things you didn't think mattered as much will turn out to be high priority
- Treat every addition as a new experiment. Rather than just shipping new features, focus your next sprints on testing your NEXT riskiest assumption ("these people will also…"), and ship the smallest amount of software that you can to test it and get real user data
If you missed your numbers, diagnose which aspect of your hypothesis was incorrect before you ship new features:
- Right problem, wrong solution. Users show up, use the product, and drop at the same part of the flow. You need to figure out why they're dropping off, why your current solution isn't working, and what you need to do to actually solve the problem.
- Wrong people. It's possible the users your campaign brought in were not the right segment and may not actually have the problem. If this is the case, the product might be fine - fix your targeting, and re-interview people who actually match your target user.
- The problem isn't painful enough. If the users signed up and never really engaged, then you might be building a vitamin and not a painkiller. If this is the case, you may need to go back to the drawing board. Revisit the problem statement itself.
Whichever it is, the next move is to go back to the strategy & research step. Run user interviews, do research into your ideal users, and re-visit the user journey map - with churned users and real behavioral data instead of assumptions. You're running strategy again with better inputs.
Both paths end in the same place: a re-prioritized list of what to build next. That list needs somewhere to live, which is what comes next.
Set Up the Roadmap Ritual
After launch, new feature ideas and bug fixes start flowing in regularly. Every batch of feedback you address spawns a new batch. And you need a system that captures them without letting them run the roadmap.
Here's how we do it:
- We create a shared board with five columns: done, current sprint, backlog, newly added, and an icebox
- Every feature idea gets added to the "newly added" column
- Every two weeks the stakeholders meet, and each person gets a set number of votes to spend on what gets built next. The roadmap gets set through voting so the loudest voice in the room doesn't dominate
Alongside the roadmap meeting, set three bigger reviews: 30, 60, and 90 days after launch. In each meeting go over KPIs, usability tests, app store optimization tracking, and planning the next iteration.
By this point, your team will be in an iteration look of coming up with a hypothesis, building the smallest thing that tests it, getting it into users hands, analyzing the data, and iterating based on what they learn.
Product is never "done." And so the team will continue iterating through this loop and improving the product, and their development process, over time.
The Iteration Muscle Is the Whole Game
Mobile development is faster and cheaper than it has ever been. And that means the things that are most valuable are a) building the right thing, and b) the ability to get product to market, learn from user feedback, and iterate quickly.
This is the process we run on every product we ship - for companies like QVC, Black Rifle Coffee, and Mustard, among others.
If you're planning to hire an agency to run it, we've written a guide on how to choose a mobile app development company, including the questions to ask before you sign anything.
And if you want a senior team that can step in on day one and run the process for you as a partner - with product, design, and engineering under one roof, and years of experience shipping products together at scale - we'd love to chat. Book a call and tell us about your project.