Think MVP: Forget about big projects—they never get finished

Published on April 15, 2016
Last modified on May 16, 2022

Think MVP: Forget about big projects—they never get finished

Estimated reading time: 3 minutes

Here’s how a normal project start-up goes:

  1. A project is conceptualized and is aimed at making a dent in the universe.
  2. To execute it, a software developer is identified after a careful examination of the latter’s potentials.
  3. A project plan is made for the entire project, with six months development and testing in mind. Everyone knows their tasks.
  4. It cannot go wrong.

It does. It's actually pre-programmed to go wrong.

  • The project is taking forever; it never gets completed.
  • The project gets twice or thrice more costly than planned in over six months.
  • Everyone is stressed out and in panic.
  • The software developer gets fired and a new developer takes over. The new developer concludes that the previous one was incompetent, everything is useless, and that the project should start over.
  • The project is in ruins, and the client loses a lot of money.

Rome was not built in one day―and neither is software.

But if you follow these steps, you'll complete your project.

  1. Make an exhaustive list of all the things you want done.
  2. Divide your list into version 1, 2, 3, and 4.
  3. Version 1 should contain the main requirements for the MVP (minimum viable product) to go live.
  4. Move all nice-to-have features to versions 2, 3, or 4. The goal is to make version 1 as small as possible, so that:
    • You can start quickly and keep your cost down.
    • You can void a situation where money is spent developing things that users don’t need.
  5. Wait for user feedback before implementing “cool” features.

Sub-projects (sprints)

Ask your software developers to divide the versions into phases, which are called “sprints.” A sprint should not take more than two weeks to complete. Immediately after each sprint, it’s important that you re-evaluate the project with your developers so that you can identify if you need to make changes.
  • Has the overall project changed? If yes, how much?
  • Are there things that are no longer necessary? If yes, remove them from the project.
  • Were new features added―are these really necessary (MVP)?
As your project progresses, adjust your expectations, schedules, and budget based on what you learned from your evaluation. If you do that, you’ll always know where you are with your project.

Remember: you won’t earn money until your project is launched. It is, therefore, important to go live as soon as possible. You can always add new features later ― it's about getting live with your minimum viable product (MVP)!