How to plan your SaaS MVP in five steps without wasting months

Executive overview

Early-stage founders routinely spend months building products nobody wants because they skip structured planning before writing code. Rob Walling presents a five-step framework—define hypothesis, outline core features, pick the right build approach, create a timeline, and launch in phases—that keeps an MVP focused on proving or disproving a single testable assumption.

The core insight is that an MVP is not a simplified version of a product; it is an experiment designed to validate a hypothesis as cheaply as possible.

The framework is illustrated throughout with two example products: BumpCRM (a horizontal CRM with a limited feature set) and Postcard (an email service provider built specifically for realtors).

Step 1: define the objective and success metrics

• Write down the specific hypothesis the MVP must prove or disprove before building anything.
• BumpCRM hypothesis: will existing CRM users switch to a cheaper, simpler product with one-third the features?
• Postcard hypothesis: do realtors care enough about email marketing to pay for a vertical-specific ESP?
• For BumpCRM, success means getting 10–40 people championing the idea, then measuring whether 50% of early-access users stick around for six months.
• For Postcard, success is 1-on-1 conversations with 100 realtors and at least 10% expressing strong interest.
• Numbers are directional guides, not hard pass/fail thresholds—context, pricing, and market all affect what "good" looks like.

Step 2: outline core features

• Work closely with 10 early-access customers to find the shared subset of features they actually need.
• If the Venn diagram of user requirements covers 100% of a competitor's feature set, the idea as scoped does not work.
• The goal is to identify a small, common feature set—perhaps 20–40% of a full product—that satisfies the majority of early users.
• If no common subset emerges, either find more focused early-access customers or reconsider the idea.
• For Postcard, the right answer at this stage is not to build an ESP at all—package pre-built email sequences or a done-for-you service on top of an existing platform like Mailchimp instead.
• Avoid feature bloat; leave out polished account deletion, billing flows, and similar secondary concerns.

Step 3: choose the right MVP approach

• Three options: human automation, no-code tools, or full custom code.
• Human automation means doing the work manually (or via a virtual assistant) behind the scenes with zero software built—ideal for proving demand before any engineering investment.
• No-code uses tools like Bubble, Airtable, or Softr to assemble a functional but unscalable prototype quickly.
• Full code is justified only when the hypothesis genuinely requires it, and only if you have the technical skills or budget to execute it.
• Non-developers should choose problem spaces solvable with automation or no-code; commissioning a full-code build without technical skills is expensive and risky.
• Match the approach to your strengths, not to your aspirations for the finished product.

Step 4: create a development timeline

• Most founders skip this step; not having a schedule leads to months of unfocused building.
• Write out every task needed to ship, then assign realistic deadlines to each phase and milestone.
• Track progress in a spreadsheet to stay accountable and spot when you are falling behind.
• Separating the planning session from the building session removes decision fatigue during execution—when you sit down to build, you just work the list.
• Even an imperfect schedule is better than none; it gives you a reference point to measure drift.

Step 5: launch in phases

• Do not open the floodgates to your entire launch list at once—use a phased rollout.
• Start with the 10 early-access customers: gather feedback, iterate, and squash bugs before widening access.
• Early access should be paid from the start; avoid free betas or lifetime deals to ensure you attract genuinely interested users.
• Tell early users they can use the product free until they get value, then charge a flat monthly rate.
• When Rob launched Drip, he rolled it out to 3,400 subscribers over five months, starting with 100–200 users and scaling to 500–600 every two weeks.
• Building between cohort releases keeps the product improving in step with growing demand and is how he found product-market fit.