The correctness of an MVP, when it is and when it ceases to be.

The Minimum Viable Product or MVP is what you define as the minimum set of features that drive the project to something viable in the market hence it stops being an MVP whenever you add extra features.

To avoid deviating your development efforts from the MVP target we need to spot which are the things that lead us out of this scope, which is -usually- thinking and re-thinking the product once and once more again, bringing on new ideas, brainstorming after defining the MVP and so on and so forth.

The steps for being successful in reaching a certain stage is to define that stage properly.

At the risk of sounding like a novel, let's dive through a silly example:

We want to develop a markdown editor.

After analyzing the whole we end up with the following acceptance criteria:

• The user writes in the left side in desktop and in the top side in mobile.
• While the user is writting, we need to translate the markdown to HTML in real time.
• The HTML needs to be rendered in the right side in desktop and in the bottom side in mobile.

Then we start coding and a new idea comes in:

• To reach a standardized look and feel we need to add styles on each possible output tag so they will look always the same, regardless of the browser.

This new idea needs to be pushed away. We can add it to the loop but it will never be in the MVP "Epic", it may be for the V1.

Once we reach the MVP acceptance criteria, congratulations! We ended a stage on our development.
Then we can analyze again the market, how our product fits in it, re-think about what we did, bring a new set of features, polishing, UX and look and feel improvements and set a limit grouping a bunch of those.
Exactly the ones that are 100% defined and clear and that together will lead us to our base final product.

This new bunch of features will be our V1 Epic.
We start developing them yada yada and then we can publish our markdown editor:

Markdown Editor with JavaScript

JoelBonetR ・ Aug 23 ・ 1 min read

#markdown #javascript #webdev #programming

There's always room for improvement and of course this is a silly example. On a real product you need to analyse and define much more stuff but the process is mostly the same. You can split the stages in as many ones as you need, but the MVP needs to be a single stage.

If the project suits for it and you want to work with alpha and beta versions before the release you can do:
PoC -> Alpha xx (as many alphas as you need) -> Beta xx (as many betas as you need) -> MVP -> polishing -> V1 (First production release).

Just establish the boundaries before hand and don't deviate development efforts to things that are not in the current scope.

You can check a full post on the topic here:

Stages in Software Development

JoelBonetR ・ Aug 27 ・ 3 min read

#devrel #computerscience #programming #testing

Hope it helps somehow 😀

From my understanding, an MVP is just a fancy way of saying a product is unfinished but is considered good enough for release. The criteria for "good enough" is something you and/or your team would have to define.

There is not a hard rule that determines what is and is not an MVP. It's all subjective, and usually involves real tradeoffs. If it is difficult to define "good enough", ask yourself questions such as "what are the core features", "what features make the product stand out", or "how important is this feature for success"?

For example, you could quickly publish an MVP blog with little to no features. However, you could define goals/milestones/phases where you continue to perfect and optimize the success of your blog. Work could continue for years by adding features like algorithms, notification services, video players, etc. When is the project considered complete? That is up to you.

In the art world, they have a similar acronym, Work In Progress (WIP). Artists typically mark projects as WIP when they are mostly satisfied with their work but they know they will continue polishing. Like art, apps are never truly finished.

I'll try to map my response to your questions.

1. It depends
2. Whenever the project is deemed complete
3. Planning ahead by defining achievable goals, milestones, and constraints.
4. When you are planning, define big goals around your limitations such as funding, release points, or project age. Once you reach those goals it is time to move to the next phase.