Skip to content

The minimum viable research you need before you build an MVP.

Building an MVP before doing minimum viable research is the most common way founders waste six to twelve months. The research takes two weeks. The rebuild after discovering a wrong assumption takes six months.

BY Tuaha Jawaid8 MIN READBUILD

Research before building MVP: the framework, the common mistakes, and the evidence that separates a defensible answer from a confident one.

The Minimum Viable Product concept has been so broadly adopted that it has lost its original meaning. Eric Ries defined the MVP in "The Lean Startup" (2011) as a version of the product that allows the team to collect the maximum amount of validated learning about customers with the least effort. The emphasis was on learning, not on speed to build.

In practice, the MVP concept is often used to justify skipping the research stage entirely. The reasoning goes: build the smallest thing possible, put it in front of customers, and learn from their behavior. The problem with this logic is that many of the most critical questions about a startup are not answerable by observing customer behavior with a product. They require understanding the economics, the buyer's decision process, and the competitive landscape before there is any product to observe.

Two weeks of structured research before building an MVP reduces the probability that the MVP answers the wrong question. According to a 2023 study in the Journal of Business Venturing analyzing 89 early-stage B2B startups, companies that completed a structured validation phase before building their first product iteration were 2.3 times more likely to reach product-market fit within 18 months than companies that built first and validated after.

The four questions minimum viable research must answer

Before building an MVP, you need answers to four questions. These are not nice-to-have context. They are the minimum set of answers that prevents the six most common MVP-stage mistakes.

Question one: is the person who experiences the problem the same person who would make the purchase decision?

This question sounds obvious. In practice, it is frequently unexamined. A product designed for end users at a company (engineers, salespeople, marketers) may need to be sold to a manager, a VP, or an IT department that did not experience the original problem. If the sales motion required to acquire the buyer is fundamentally different from the user motion required to make the product valuable, the MVP needs to serve both, which often changes the product architecture significantly.

Question two: what is the minimum feature set that closes the gap between the current solution and your product for the buyer's most acute pain point?

The purpose of MVP research is not to produce a feature list. It is to identify the single workflow step where the current solution fails most expensively, so the MVP can target that specific step. A product that does five things adequately will lose to a product that does one thing perfectly in a B2B context, because buyers evaluate tools on whether they solve their most acute problem, not on feature breadth.

This requires knowing the buyer's current workflow in detail, which comes from customer discovery interviews (see our article on customer discovery interview methodology), not from assumptions about how the workflow probably works.

Question three: what price must the product reach to make the unit economics viable, and will the buyer pay that price?

At MVP stage, many founders underprice to reduce friction on early sales. The problem is that an MVP sold at a price 40 percent below the economically viable price generates data about how buyers respond to a $300 per month product when the business only works at $500 per month. That data is not useful for predicting whether the product will succeed at the correct price point.

Test the actual price before building. If five buyers balk at $500 per month and three say it is in range, you have a more realistic signal than fifty downloads of a $29 per month MVP.

Question four: what would make this buyer not switch to your product even if it were free?

The question of switching cost barriers is almost never asked before MVP stage and almost always encountered during sales. If 60 percent of your target buyers have a three-year lock-in contract with an incumbent software provider, that is information that should change your go-to-market timeline before you build, not during your first sales cycle.

What minimum viable research looks like in practice

Day one to three: secondary research. Build a bottoms-up market size estimate using public data sources. Identify the top five named competitors and map their pricing pages, review site ratings, and job postings. Identify the regulatory constraints applicable to your product.

Day four to seven: five customer discovery interviews. Focus on current workflow, failure modes, switching costs, and economics. Use the past-behavior question format described in the customer discovery interview methodology article.

Day eight to ten: synthesize findings and answer the four questions. If any question cannot be answered with reasonable confidence, do more research before building. Two more interviews or two more days of secondary research is far less expensive than a wrong MVP.

Day eleven to fourteen: build the research brief. A two-page document that states the buyer persona, the specific problem, the target price, the current solution, and the three most important assumptions the MVP will be designed to test. This document is the specification for the MVP, not a list of features.

The research brief should be specific enough that someone else could read it and build the right MVP. If it is not specific enough for that, it is not specific enough to build from.

A worked 30-day pre-MVP research plan

Week one is desk research. Pick the three primary sources for your category: a public incumbent’s 10-K from SEC EDGAR, a relevant BLS or category dataset, and a freely available industry benchmark like OpenView’s SaaS Benchmarks. Read them in that order. Take notes on what surprised you and what confirmed your assumptions. The output is a one-page summary of the category as it actually exists today.

Week two is competitive mapping. Identify three direct competitors and three indirect substitutes including do-nothing. For each, capture pricing, ICP, recent product announcements, and user-review pain points from G2 or Capterra. Score each on the six axes that matter: feature parity, distribution reach, capital position, hiring velocity, integration surface, and switching cost. The output is a competitive map, not a feature matrix.

Week three is customer conversations. Source 25 cold contacts at the ICP definition you wrote in week one. Send the cold emails, get on 8 to 12 calls, and run them with the discipline The Mom Test advocates. Take notes during, not after. Cluster the pain points and switching frictions. The output is a synthesis document with frequency counts and direct quotes.

Week four is the decision memo. One page. Cover: build, pivot, or kill with kill criterion named. Sections: ICP, top three validated pain points, switching cost analysis, pricing hypothesis with three comparable wedges, named falsifier. The memo is the brief for the MVP. If the memo cannot be written cleanly, the MVP is premature.

What pre-MVP research is not

Pre-MVP research is not a substitute for a prototype. It is the foundation that makes the first prototype testable. If you build before the memo exists, you are building blindfolded; if you research past the memo, you are procrastinating. The discipline is to stop when the memo is defensible and start building the moment it is.

The pattern that produces a successful first build is not exhaustive research followed by a complete MVP. It is just-enough research to choose the wedge, a 30-day landing-page test or no-code prototype, and a customer-development loop running in parallel. Y Combinator’s Startup School makes this point repeatedly: founders who launch ugly versions early outperform founders who launch polished versions late, because the launch is where the real learning starts.

The single deliverable test

The fastest way to evaluate whether your pre-MVP research is done is the single-deliverable test. Can you write a single cold email that an ICP-target person would read and reply to? The email forces every prior piece of research to crystallize: a clear ICP, a credible value proposition, a non-pushy reason to talk, a specific question. If you cannot draft the email in under an hour, the research is still missing something concrete. If you can, you have enough.

That email is the cheapest test of every other piece of research you have done. Send 25 of them. The reply rate, the questions you get back, and the objections that surface tell you more about the market than another two weeks of reading. Verdikt’s methodology treats the cold-email exercise as the implicit acid test of the intake brief: a brief that cannot generate a credible cold email is a brief that has not produced a real ICP yet.

FAQ

Frequently asked questions

How long should pre-MVP research take?
Two weeks is sufficient for most B2B ideas. Consumer-facing ideas with very large potential user populations may require additional research because the buyer and user are the same person, which creates a higher need to understand behavioral patterns rather than just workflow and economics. Do not extend pre-MVP research beyond four weeks: beyond that point, additional research produces diminishing returns and the research phase becomes a substitute for action.
What is the difference between pre-MVP research and customer discovery?
Customer discovery is one component of pre-MVP research. Pre-MVP research also includes secondary market research (market sizing, competitive landscape, regulatory context) and economic modeling (unit economics, pricing benchmarks). Customer discovery interviews contribute the qualitative buyer behavior data that secondary research cannot provide.
PUT IT TO WORK

Test your own idea. Get a verdict in under one hour.

Start a verdict