पाठशाला Pathshala · उत्पाद Utpād, The product · Lesson 01 · Start

The MVP that is actually minimum

Most first versions are small products. The useful kind is a test: one workflow, built in weeks, that settles the one assumption the company cannot survive being wrong about.

Pathshala, The Founder Library · 11 October 2026 · 9 min read

Ask a founder to show you the MVP and you will usually be shown a product: login, dashboard, settings, a payments page, three user roles and a roadmap. It took five months. It is minimum only in the sense that the team wanted more. The version that earns the name is smaller than feels respectable and finishes faster than feels safe, because it is not a product at all. It is an experiment with a user interface.

This lesson gives you the test for whether a first version is minimum, the method for finding the one assumption it must settle, a way to cut the build to a single workflow, and a three-week calendar. The point throughout is Eric Ries’s: the output of an MVP is not a product. It is learning you could not have bought any other way.

What the word was meant to mean

Ries’s 2009 definition is the one worth keeping: the version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. Read the sentence again and notice what is not in it. Not the smallest product. Not the first release. Not a demo. The unit of measure is learning per unit of effort, and that ratio is what a founder is optimising when deciding what to build first.

The consultancy SyncDev, whose use of the term predates the Lean Startup movement, defines it more commercially as the unique product that maximises return on risk for both the vendor and the customer. The two definitions agree on the thing that matters: an MVP is sized by the risk it retires, not by the features it contains. A first version that retires no risk is not minimum however small it is. One that retires the biggest risk is minimum however long it took, though it rarely needs long.

Ries also warns that the method has overhead. You have to manage to learn something from the first iteration, which means deciding in advance what you expect to see and what result would change your mind. A team that ships and then looks at the numbers to see what they mean has built a product. A team that writes the prediction first has built an MVP. The difference costs an hour and is the whole discipline.

Find the assumption that kills the company

Every business plan is a chain of assumptions. For a company selling GST-compliant billing software to small manufacturers in Ludhiana the chain runs something like: owners feel the pain of manual invoicing; they will let a stranger see their sales data; they will pay a monthly fee rather than a one-time price; the accountant will not block it; the owner will do the data entry rather than a clerk who leaves every six months; the product can be sold without a field visit. Write yours out as a list of plain sentences. Most founders have never seen their own chain in one place and are surprised by how long it is.

Now score each link on two questions. How confident are you that it is true, and how bad is it if it is false? The riskiest assumption is the one with low confidence and high consequence, and it is usually not the technical one. Founders with engineering backgrounds reach for the hardest thing to build because that is the risk they know how to retire. The company more often dies on a behavioural assumption: the owner will not do the data entry; the accountant does block it; the fee feels like rent and the one-time price feels like ownership. The MVP exists to test the link you would least like to be wrong about, which is also the one you have least evidence for.

One assumption at a time. A first version that tests three assumptions at once produces one number and no way to know which assumption moved it. If it fails you do not know what to fix; if it succeeds you do not know what to keep.

One workflow, not one product

Having picked the assumption, build the single workflow that exercises it and nothing else. A workflow has one user type, one trigger, one path and one outcome the user would recognise as the value. For the billing company it is: the owner opens a link on the phone, enters a sale, a GST invoice goes to the customer on WhatsApp. No login, because the link can carry identity. No dashboard, because a weekly summary can be a message the founder types. No catalogue, because twenty products can be a drop-down the founder maintains by hand. No payments, because the first twenty customers are invoiced on UPI by a human.

Michael Seibel’s YC lecture on planning an MVP compresses the method to three verbs. Timebox it: ask what can be built in a fixed window such as three weeks and cut whatever does not fit. Write it down: a written spec makes scope changes visible, and without one a three-week plan quietly becomes three months. Cut it: if the schedule slips remove the unimportant items first and the important ones if you must, because getting something out matters more than any item on the list. His summary of the lesson is that you should be able to build it in weeks not months, and his summary of the whole talk is to launch something bad quickly.

He allows one exception. A heavy MVP is sometimes unavoidable in regulated industries, hard tech and biotech, where nothing can be put in a customer’s hands without years of work. Even there he says the first thing to ship is a plain website explaining the product, which takes days. Most founders who believe they are in the exception are not. A lending product can test whether borrowers will share bank statements before it has a lending licence. A diagnostics company can test whether clinics will send samples before it has a lab.

An MVP is sized by the risk it retires, not by the features it contains.

Three first versions that were tests

Dropbox’s first public version was a video. In 2011 Ries described how Drew Houston recorded a three-minute screen demo of a product that did not yet work reliably, seeded it with jokes for the Digg audience it was aimed at, and watched the beta waiting list grow from 5,000 to 75,000 overnight. The risky assumption was not whether file sync could be built; Houston knew it could. It was whether anyone wanted it badly enough to ask. A video retired that risk for the cost of a weekend.

Zomato began in 2008 as Foodiebay, and its first version was about fifty restaurant menus that two consultants at Bain in Delhi had scanned and put on the office intranet because the café kept the paper menus stapled together so nobody could take them. In a 2012 interview Deepinder Goyal described the moment: traffic started arriving from inside Bain, and that was the signal to treat it as a business. The assumption under test was whether people would look up menus online at all. Scanned images answered it. The company built search, reviews and listings for twelve cities afterwards, and four years later had 41,000 listings.

Paul Graham’s Do Things That Don’t Scale describes the third pattern: founders of a B2B company advised to pick a single user and act as consultants building something just for them. It feels like the opposite of building a product. It is the fastest way to find out which of your assumptions survive contact with one real person who has to use the thing on a Tuesday, and Graham’s observation is that what one well-chosen user needs turns out to be what the others need too.

A worked example, in weeks and rupees

Two founders in Jaipur want to build credit-tracking software for kirana wholesalers, who extend udhaar to hundreds of retailers and track it in a ledger. The full product in their heads has inventory, billing, credit limits, a retailer app, reminders and a lending partner. A three-person team building that for six months costs roughly ₹30 lakh in salaries before a single wholesaler has touched it, and the founders cannot name which of their assumptions it would prove.

Their chain, written out, has nine links. The one with least evidence and most consequence is this: the wholesaler’s counter staff will record each credit sale on a phone at the moment it happens rather than in the ledger at night. If that is false the data is never there and nothing downstream matters. So the MVP is one workflow: a shared phone at the counter, a screen with retailer name and amount, a WhatsApp message to the retailer confirming the balance. Built in two weeks. Deployed at ten counters the founders visit in person. The number: entries made during trading hours as a share of entries made at all, by the end of week three. The prediction, written before launch: above 70 per cent and the behaviour exists; below 30 and it does not, and the product has to be built for the night-time ledger instead. Everything the founders would have spent six months building is deferred until that number is in.

The mistakes that make a first version large

Building for the second customer. The first version serves the users you can reach this month, in one city, in one segment. Multi-tenancy, roles and permissions exist for customers you do not have. Finishing the edges. Password reset, empty states, an admin panel and an onboarding tour are the work of a product, and the first version has a founder on WhatsApp for all of them. Confusing demo with test. A demo is built to be shown; a test is built to be used by someone who does not care about you. Only the second produces data. Waiting for it to be good. Seibel’s advice is to launch something bad quickly and his warning is not to fall in love with the MVP, because it is step one in a journey and most of it will be thrown away. Testing the technical risk first when the behavioural risk is larger, which is the engineer’s version of looking for the keys under the streetlight.

Three weeks, with a calendar

On the Monday of week zero, write the chain of assumptions and score it. Pick one. Write the prediction: the number you will measure, the threshold that confirms the assumption and the threshold that kills it. Write the one-page spec of the single workflow, with a list of what is explicitly not in it. On the Monday of week one, start building with the spec on the wall; every request to add something is tested against the question of whether the assumption can be settled without it. On the Friday of week two, cut whatever is not done. On the Monday of week three, put it in the hands of ten to twenty users you recruited by hand, and spend the week with them. On the Friday of week three, read the number against the prediction and write down the decision in one sentence: confirmed, killed, or the test was not clean and here is what to change.

Then do it again for the next link in the chain. A company that runs this loop every three weeks retires a risk a month. One that spends five months on a first version retires none, and discovers all of them at once on launch day.

The method is Ries’s and Seibel’s; the examples are from the public record and the sources are below. The worked figures are illustrative arithmetic, not a benchmark.