UzCombinator
UZ
EN
Startup School
Curriculum0/19
Module 1
Idea and problem
  1. 1What a startup is, and how it differs from a small business4 min
  2. 2Finding a real problem4 min
  3. 3Judging an idea: market, timing and team4 min
  4. 4Co-founders and the team4 min
Module 2
Customers and validation
  1. 5How to run a customer interview5 min
  2. 6Who your first users are4 min
  3. 7Testing demand cheaply5 min
Module 3
Building the MVP
  1. 8What an MVP is, and what it is not4 min
  2. 9Building fast: code, no-code and ready-made tools4 min
  3. 10Launching and collecting feedback4 min
  4. 11Signs of product-market fit4 min
Module 4
Growth and metrics
  1. 12Choosing the metric that matters4 min
  2. 13Unit economics: CAC, LTV and margin4 min
  3. 14Your first growth channels4 min
  4. 15Keeping your users4 min
Module 5
Fundraising and pitching
  1. 16Do you need funding? Stages and sources4 min
  2. 17Building a pitch deck4 min
  3. 18Meeting investors4 min
  4. 19Terms and valuation basics4 min
Module 3Lesson 84 min

What an MVP is, and what it is not

Building the MVP
An MVP is a tool for learning, not a finished product. How to decide what to leave out.
MVP stands for "minimum viable product". The term is used a lot and often misunderstood. For some, an MVP is a rushed product full of bugs. For others, it is a first version with every feature, just with plainer design. Neither is right.

What an MVP is

An MVP is the smallest product that lets you find out whether customers really value its core. Its job is to teach you. You release the MVP, watch how people use it and choose your next step based on what you see.
An MVP has to be in the hands of real users. A prototype only you look at, or slides you show investors, is not an MVP: neither tells you anything about how customers behave.

Find the core value

Every product has a heart: the reason a customer actually uses it. Your MVP should deliver only that heart. Ask yourself three questions:
  • Who is the one main user?
  • Which single job do they get done with the product?
  • What are the steps of that job from start to finish?
Take the idea of credit tracking for shops. The heart might be this: the shop owner sees on one screen who owes how much, and can send a reminder to a debtor. Reports, multiple shops, staff permissions, stock tracking: all of that comes later.

What to leave out

  • A complex admin panel. At first you can change the data yourself, directly in the database or a spreadsheet.
  • Perfect design. Keep it clean and clear, but do not spend weeks on pretty animations.
  • Separate features for many kinds of users. Serve one main user.
  • Preparing for heavy load. Do not worry about millions of users before you have hundreds.
  • A complicated sign-up. A phone number or a Telegram login is often enough.
Be careful with language. If some of your customers work in Uzbek and some in Russian, you may need both languages from day one. That decision depends on your customers, not on your convenience.

Minimal does not mean broken

The core flow has to work reliably. If a user tries to do the main job and the product breaks, you learn nothing: people see the bugs, not the idea. Few features, but features that work: that is the rule for an MVP.

Examples

  • Instead of an app to track couriers for a delivery service: a Telegram bot and a Google Sheet at first.
  • Instead of a platform for tutors: a single page you update by hand, with sign-ups through Telegram.
  • Instead of a complex analytics system: a report prepared by hand every week.
In each case the customer gets the core value, and the team learns what is really needed.

Limit the time

An MVP should usually ship in a few weeks. If the plan runs past two or three months, cut the scope. Long builds are dangerous: the more you build, the more attached you become to the product, and the harder it gets to accept customers saying no.

Three common mistakes

  • Building too much. The team delays launch week after week for "one more feature" and learns nothing.
  • Building too little. The product does not deliver the core value, so users drop it and you wrongly conclude the idea is bad.
  • Building for the wrong user. The MVP goes to a random audience instead of the people who feel the problem most.

After the MVP

Once the MVP is out, the real work begins. Watch whether people complete the main job, whether they come back and what they complain about. Then you choose one of three paths: strengthen what works, change your approach, or stop and move to a different problem. All three decisions mean the MVP did its job.

Try this

Write one sentence: "Our MVP lets [user] do [job] by [method]." Then list every feature you have planned and delete at least half of them. Estimate how many weeks the rest will take to build.