Launch something bad QUICKLY!

The MVP is 'the first thing you can give to the very first set of users you want to target, in order to see if you can deliver any value at all to them.'  It's a good idea to talk to users before building the MVP.

Advantageously, I'm a user, which means I can test if the product or solution works for me, meaning it may work for others.

So in a prelaunch startup, the idea is to launch quickly. Find someone to use the product or solution and then get feedback from them. Did they get value from using the product? Sometimes through the user feedback, we realise that the solution may need tweaking. It's in testing the MVP that we find that out. So the advice is to hold the customer and problem tightly, but hold the solution loosely.

It is also important to 'iterate' - if the solution doesn't fit one type of user, I  find out how to fix that. Maybe by doing that, I'll solve the problem better. It will help me to improve the solution.

The other thing is to focus on a small set of initial users and their highest-order problems. So it's like starting small to scale up later, a founder cannot solve everything at once.  The MVP is just a starting point.

The blog gave examples of startups that started out with a very limited functionality MVP but are now billion-dollar companies. It's always nice to see where others started from. Every start-up started small and grew. So, a lesson for me is not to get my hopes up but keep working on the solution, starting with what I have. 

So for my startup idea, I could have a simple website as my MVP.

Launching

Launches aren't that special - no one remembers when Facebook or Google launched. Hence, I don't need to make too much of a fuss about it.  So the first step is to build the website! I have the domain name...The aim is to get the customers in, so I can test the viability of my solution.  

The second recommendation is to 'box the spec', which means putting timelines around the 'spec,', i.e. what you need to do before the launch; in my case, it's building the website. Putting a timeline on it makes one focus on the main features needed for launch.

The spec should be written down so that the starting point is known when modifications need to be made. Then I can cut off any non-important stuff to enure I meet the deadline.

The important thing is to get the product out!