Everybody has ideas all the time, and many of them are good, but the reality is that ideas are worth very little. The real challenge is to convert an idea into a viable product. That’s what is often called execution, and it’s more difficult than coming up with an idea.

Phase 1: Refine your idea

How many times somebody has tried to explain an idea they came up with and they and they end up doing an unintelligible mess of an explanation jumping from one thing to another?

At this point, I’d like to identify two things:

• What is the final vision of what you want to achieve in 3-5 years?

• What is the first step you need to accomplish to start proving the hypothesis?

Having a clear vision is important but in the early days the most important thing you can do is to define the smallest thing you can do to:

1. Help others understand what you are trying to do

2. Prove what you are trying to do is worth it.

This is what I call the scope of the MVP and it should be as small as possible.

Why to make a small MVP?

Let’s be clear, your idea might or might not work as it is. You will need to gather feedback from actual users and keep modifying your idea to adapt to what the customer wants or needs, as we don’t know that yet. The idea of making a small MVP is to embrace our lack of knowledge, use an iterative process, and learn from the users. Making the scope small helps us keep the cost of learning low and being able to iterate fast. So a small MVP means:

• It costs us less money to do it.

• We can learn from the actual users faster.

Ideally, the MVP scope will be such that it could be completed by a team of 5-7 people in three months.

Phase 2: Resourcing

So you know what you are building, now we need to find out what team and infra you need to get it done.

Theoretically, a bigger team would be able to get the MVP done quicker, but the reality is that nine women can’t deliver a child in one month. My personal preference would be to keep the team as small as possible at this stage. A small team means less monthly burnt rate, more effective collaboration, and less process required, which will, in my opinion, reduce your time to complete.

Let’s not forget about infrastructure too. You will need to pay the cloud bill while you are building the MVP, so let’s ensure you factor that cost in too. One important note here is that you will need several environments (dev, staging, prod) so ensure you include them all.

Phase 3: Execution

During the MVP execution, the scope should not change. I’d recommend establishing regular meetings to ensure we are on track to get things done on time, and also I will strongly encourage creating an over-communicating culture, especially if you are in a remote-first environment.

I like two-week cycles as it helps visualize progress and detect issues early on. At least, every cycle some new features will be deployed internally and we can see before our eyes how the product takes shape.

Final caveat

Having built an MVP doesn’t mean it should be publicly available to anyone. As the MVP is not the final product, you might want to protect yourself from the competitors by not making it public and only showing it to certain people like investors or people you are not competing with.