The MVP is a learning vehicle
Founders often describe the MVP to us as a smaller version of the full product they want to build in three years. This is the wrong mental model. A minimum viable product is not a small version of the final product. It is the smallest version of the product that can teach you the things you still need to learn before you spend the next year building.
That difference sounds subtle but it changes everything. If the MVP is a learning vehicle, the question for every feature is not does this belong in the eventual product, but will building this feature teach us something critical that we cannot learn another way? If the answer is no, the feature is cut, no matter how compelling it feels in the roadmap deck.
The ten questions before the first sprint
Before we start design or development on a SaaS MVP, we ask founders to work through ten specific questions. The answers do not need to be perfect, and they will change. But the discipline of writing them down before the team starts building almost always saves weeks of rework later.
- Who is the single primary user persona for the MVP, and what is the single job they hire the product to do?
- What is the one core workflow that, if it works, makes the product worth paying for even if everything else is rough?
- What pricing model are we testing, what are the assumptions behind it, and what data will prove or disprove those assumptions?
- What is the shortest possible onboarding that gets a new user from sign-up to first meaningful value?
- Which specific user actions in the product count as activation, and what minimum activation rate would make us optimistic after launch?
- What are the first five cohorts we will invite, how will we invite them, and what will we ask each cohort after they use the product?
- Which three analytics dashboards do we want ready on day one, and what specific decisions will each one inform?
- What billing infrastructure, payment methods, invoicing, and tax handling do we need for the launch countries?
- Who will own support in the first ninety days, what channels will we use, and what is our response-time commitment?
- What is the clear kill criteria and pivot criteria: what result after how long tells us to stop, iterate, or double down?
Onboarding and activation are the real product
For most SaaS MVPs, the hardest problem is not building features. It is getting a new user from the sign-up button to the moment where they clearly understand and feel the product's value. Teams that treat onboarding as a secondary afterthought almost always have terrible activation numbers and then blame the product, the marketing, or the users.
Before the first sprint we design the activation moment explicitly. We should be able to describe it in one sentence: a user has activated when they complete action X, which takes roughly Y minutes, and after which Z percentage of users come back on day seven. If we cannot describe that moment with confidence, the MVP scope is probably still too fuzzy and we should iterate on the scope before committing to build.
Instrument before launch, not after
Analytics instrumentation is one of the easiest things to defer and one of the most expensive to retrofit. The team naturally wants to focus on user-facing features, and analytics feels like an invisible tax right up until the moment when launch happens, everyone is excited, and then nobody can actually answer the most basic questions about how the product is being used.
Our minimum instrumentation bar for a SaaS MVP: anonymous and identified event tracking with properties and timestamps, full funnels for onboarding and activation, cohort retention by acquisition channel, error tracking and performance monitoring, billing and revenue events wired to the same user identity, and a simple weekly metrics email that goes out automatically to the whole team every Monday morning with the top ten numbers and the top ten events.
Billing, support, and the invisible 20%
The visible 80% of a SaaS MVP is the UI and the core workflow. The invisible 20% that quietly determines whether it succeeds or fails is billing, support, and administration. Teams that underestimate the invisible 20% end up scrambling at launch with manual invoices, missed support emails, no way to refund a customer, no way to reset a user's account, and no way to debug why a specific user cannot see their data.
Our baseline checklist for the invisible 20%: self-serve subscription management, clear invoicing and tax handling for at least the launch countries, dunning and failed-payment recovery flows, a basic support inbox with SLA visibility, user and team admin surfaces for password reset, role changes, and team management, and a secure admin-only account impersonation flow so support can reproduce user issues without asking for credentials.
The first ninety days
Finally, the MVP launch is not the finish line. It is the start line. The product is not finished on launch day. It is finished when we have enough real usage, enough real conversations with real users, and enough real revenue data to decide whether to iterate, pivot, or double down. The team should go into a SaaS MVP build with a clear ninety-day plan after launch, not with the vague hope that metrics will somehow appear and tell them what to do next.
Founders who prepare well before the first sprint almost always have a calmer, more productive, and more useful MVP launch. They are not flying blind. They have the instrumentation, the support coverage, the cohorts lined up, and — most importantly — the humility to treat the MVP as what it is: a structured experiment, not a finished product.