MVP Roadmap: A 12-Week Plan From Problem to First Real Users

9 min read ยท 2026-10-25

An MVP roadmap is a short plan that takes a product from a problem worth solving to a first version in the hands of real users, with a clear way to decide what to do next. It lists the hypothesis you are testing, the smallest feature set that can test it, the build and launch steps, and the metrics that tell you whether to keep going.

The roadmap below runs 12 weeks in six phases. It works for a startup founder building a first product and for a product manager testing a new line inside a larger company. Each phase has an owner, a milestone you can check and a clear output. The guide also covers what most MVP plans skip: how to cut scope without losing the point, how to present the plan to investors or leadership, and how to decide whether to scale, pivot or stop.

The roadmap at a glance

Goal: A working MVP used by a defined group of target users, with usage data that supports a go, pivot or stop decision by week 12. Duration: 12 weeks

  1. Problem and hypothesis (Weeks 1-2)

    Confirm the problem is real and write down exactly what the MVP must prove.

    • Interview 10 to 15 people from the target segment about how they handle the problem today and what it costs them.
    • Write one problem statement and one riskiest assumption, such as "clinic managers will book shifts in an app instead of by phone".
    • Define the success signal before you build, such as a number of weekly active users or repeat uses after two weeks.
    • List the alternatives users rely on today, including spreadsheets, email and doing nothing.

    Milestone: A one-page hypothesis brief with the target user, the problem, the riskiest assumption and the success signal, signed off by the founder or product lead.

  2. Scope and user flow (Weeks 3-4)

    Choose the smallest set of features that tests the hypothesis from start to finish.

    • Map the one core user journey, from first visit to the moment the user gets value.
    • List every feature idea, then sort them into must have, should have, could have and won't have this time.
    • Cut every feature that does not serve the core journey, and plan to handle back-office tasks by hand instead of automating them.
    • Write user stories with acceptance criteria for the must-have list only.

    Milestone: A frozen MVP scope document with the core journey, the must-have list and an explicit "not in the MVP" list, agreed by product and engineering.

  3. Design and prototype (Weeks 4-5)

    Test the flow with users before writing production code.

    • Create wireframes for each screen in the core journey.
    • Build an interactive prototype in Figma and run five usability sessions with target users.
    • Fix the steps where users got stuck, then finalize the UI with a simple, consistent style.
    • Choose the tech stack and hosting with the lead developer, favoring tools the team already knows.

    Milestone: A tested prototype where at least four of five users complete the core journey without help, plus a stack decision.

  4. Build (Weeks 6-9)

    Build the must-have features in short sprints with a working version at the end of every sprint.

    • Plan two-week sprints in Jira or a simple board, with the must-have stories in priority order.
    • Set up analytics events for each step of the core journey from the first sprint.
    • Demo the working product to the founder or product lead at the end of each sprint.
    • Hold the scope: new ideas go to a parking lot list, not into the sprint.

    Milestone: A feature-complete build on a staging environment, with analytics events firing for every step of the core journey.

  5. Test and launch (Weeks 10-11)

    Get the MVP stable enough for real users and put it in front of them.

    • Run QA on the core journey across the devices and browsers your users have.
    • Invite a first group of users from the interviews and a waitlist, starting small.
    • Submit the app to the App Store and Google Play early if it is a mobile app, since review can take days.
    • Set up a feedback channel and a way to log bugs reported by users.

    Milestone: The MVP is live with the first group of target users, with no open critical bugs.

  6. Measure and decide (Week 12 onward)

    Read the data, talk to users and make a clear decision on the next step.

    • Compare activation, retention and usage against the success signal set in week 1.
    • Call or meet at least five active users and five who dropped off.
    • Write a one-page learning report: what was proven, what was not and what surprised you.
    • Hold a decision meeting to scale, pivot or stop, and draft the next roadmap if you scale.

    Milestone: A documented go, pivot or stop decision, backed by the learning report and agreed by the founders or the product sponsor.

MVP roadmap vs product roadmap

A product roadmap shows how a product will grow over quarters or years. It is organized by themes and outcomes, and it assumes the product already works for its users. An MVP roadmap is shorter and has a different job. It exists to test one hypothesis as cheaply and quickly as possible, then make a decision.

That changes what goes on it. An MVP roadmap has a success signal and a decision point at the end. It also has a "not in the MVP" list that is as important as the feature list. Once the MVP proves its value, you replace it with a product roadmap built on what users actually did.

Example: an MVP roadmap for a shift booking app

Picture a founder building an app that lets small clinics fill open nurse shifts. Clinic managers post shifts and approved nurses accept them. The riskiest assumption is that managers will post shifts in an app instead of calling their usual contacts.

Notice what was left out: payments, ratings, a nurse profile editor and an admin panel. Each one is useful later, but none of them tests whether managers will post shifts.

  • Weeks 1-2 (owner: founder): 12 interviews with clinic managers and nurses. Success signal: clinics post shifts in the app every week for a month.
  • Weeks 3-4 (owner: founder and product designer): core journey is post a shift, nurse accepts, manager gets a confirmation. Payments and ratings are out. Nurse approval is done by hand by the founder.
  • Weeks 4-5 (owner: product designer): Figma prototype tested with five managers. One confusing date picker replaced.
  • Weeks 6-9 (owner: lead developer): mobile app for nurses, web page for managers, push notifications, analytics on each step.
  • Weeks 10-11 (owner: founder): live with a handful of pilot clinics and the nurses they already work with.
  • Week 12 (owner: founders): review weekly posting data and interviews, then decide whether to add payments and expand to more clinics.

Who owns what

MVP teams are small, so one person often holds several roles. That is fine as long as every decision has one owner. Write these names on the first slide of your roadmap.

If you work with an outside development team, keep the product owner role inside your company. The team building the product should not also decide what it is for.

  • Founder or product manager: owns the hypothesis, the scope, the "not in the MVP" list and the final decision.
  • Product designer: owns the user flow, the prototype and the usability sessions.
  • Lead developer or tech lead: owns the stack, the sprint plan, code quality and the release.
  • QA or a developer with a test checklist: owns testing of the core journey before launch.
  • Marketing or the founder: owns the waitlist, the first users and the feedback channel.

How to cut scope without losing the point

Scope creep is the main reason MVPs run late. Every stakeholder has one more feature that feels essential. The fix is to judge every feature against one question: does the MVP fail to test the hypothesis without it? If the answer is no, it waits.

Some features can be faked. A person can approve accounts, send reports or match users by hand behind the scenes while the product looks automated. This is often called a concierge or Wizard of Oz approach. It lets you learn whether users want the result before you build the system that produces it.

  • Keep one core journey and remove every branch that does not serve it.
  • Use sign-in with Google or Apple instead of building a full account system.
  • Use an existing tool for payments, email or support instead of building your own.
  • Leave admin panels out and use a spreadsheet or a database view for the first weeks.
  • Support one platform first if your users are mostly on it.

Metrics to track after launch

Pick a few numbers that match your hypothesis and set them before launch. Measuring after the fact makes it too easy to pick the numbers that look good.

With a small group of users, the numbers will be noisy. Treat them as signals, and always pair them with conversations. Five calls with users who dropped off can tell you more than a dashboard.

  • Activation: share of new users who complete the core journey once. Measure it with the analytics events from the build phase.
  • Retention: share of users who come back and repeat the core action in week two and week four.
  • Frequency: how often active users perform the core action per week.
  • Willingness to pay or commit: pre-orders, letters of intent or users who agree to a paid pilot.
  • Qualitative signal: how users would feel if the product went away, asked in short interviews.

How to present the MVP roadmap to investors or leadership

Put the whole plan on one slide. Show the six phases as a horizontal timeline with the week numbers, one line per phase and the milestone under each. Above the timeline, write the hypothesis and the success signal in one sentence each. Below it, list the team and the two or three biggest risks.

Leave out the full feature list, the tech stack details and the sprint plan. Investors and executives want to know what you are testing, how you will know, when, and what you will do with the answer. If they ask about a missing feature, show the "not in the MVP" list and the reason each item waits.

Common mistakes to avoid

  • Building features before defining what the MVP must prove leads to a product nobody can judge, so write the hypothesis and success signal in week 1.
  • Letting the scope grow during the build pushes the launch back, so keep a parking lot list and add nothing to a running sprint.
  • Polishing the UI before testing the flow wastes design time, so test an interactive prototype with five users first.
  • Launching without analytics leaves you guessing, so add events for every step of the core journey in the first sprint.
  • Launching to everyone at once makes problems public, so start with a small group from your interviews and waitlist.
  • Treating the launch as the finish line means no decision gets made, so book the go, pivot or stop meeting before you launch.

Frequently asked questions

How long should an MVP take to build?

A common target is 8 to 16 weeks from scope freeze to launch, but it depends on the product, the platform and the team. A simple web app with one core journey can be faster. If your plan runs much longer, your scope is probably too big.

What should be included in an MVP roadmap?

Include the problem, the hypothesis, the success signal, the core user journey, the must-have features and a "not in the MVP" list. Add phases with owners and milestones, the launch plan and the decision meeting at the end. List the team and the top risks on the same page.

How do you prioritize features for an MVP?

Map the one core user journey and keep only the features needed to complete it. Sort the rest into should have, could have and won't have this time. Fake what you can with manual work behind the scenes.

What happens after the MVP is launched?

You measure activation and retention against the success signal and talk to active and inactive users. Then you decide to scale, pivot or stop. If you scale, you replace the MVP roadmap with a product roadmap based on what users did.

Is an MVP the same as a prototype?

No. A prototype shows how the product could work and is tested in sessions, often without real data. An MVP is a working product that real users use for their own needs, which gives you real usage data.

Generate this roadmap with AI