Startup Survival Guide: How to build a product people want.

This an excerpt from a workshop I give titled "Startup Survival Guide: From Zero to Seed. Chapter 3: How to build a product people want" in which goal of the survival guide is to decrease your chance of startup failure, not necessarily a guaranteed path to success (if you have one, let me know).

Start by reading

• Chapter 1 - Startup Survival Guide: Recruiting a co-founder
• Chapter 2 - Startup Survival Guide: Picking a Problem to solve, not an idea.

At this stage, you already have a co-founder that you admire, trust, respect and has a high degree of charisma (Chapter 1).

You also have identified a problem that ideally you have lived yourself or understand very well and meets the criteria of a problem that causes frustration, takes too much time, is too expensive and more importantly, you are already spending money on a terrible solution that does not really solve the problem (Chapter 2).

If you don't have the right co-founder and don't have a painful problem to solve as tools in your survival kit, your startup's chances of survival are now very slim. There's no lean, scrum, design-thinking, or any innovation voodoo that can replace a great team and problem. That said, let's dive into building a product people want.

Less is more

At this stage, the biggest threat to your startup survival is taking too long to launch a product.

Building and launching a product is the best way to validate that you did indeed pick a worthy problem. If for some reason your assumptions were wrong, you need to repeat Problem (Chapter 2) and Product (Chapter 3) again, until you nail it.

However, if you took so long that you never launched before the money ran out or you missed in your first try and don't have enough time to do a second, or third, (or fourth) try before money running out, then your startup will die.

You need to launch a product sooner than later and the framework I will share with you now will help you launch products without ever missing or moving a deadline.

Step One: With the problem defined, think of the result of the solution. 

In our previous chapter, we created a list of problems deliberately not thinking of the solution to help us in this stage. Let's say that the problem is that "getting to work takes too much time", instead of thinking of a solution like building a hyperloop, a tunnel, a personal flying vehicle, a telepresence robot (all valid solutions) or the like, we will focus instead on the result of the solution:

If the problem is that getting to work takes too much time, then, the solution should result in getting to work takes less time.

At this step, let's not worry about what we will build to take less time to get to work. We have a problem well defined and we have a result of the solution well defined. Now we pick the when.

Step Two: Pick a launch date, the only variable that does not change is time.

We first define the "when" then the "what". The more money and time you have, the farther from today you can launch. The less time and money you have the closer to today you must launch. Specifically, this means that instead of planning around a set of features and with your team and then deciding when they will be built, you pick a launch date first and then decide what to build that solves the problem in some manner.

Since at this stage you should be a small team of two or three founders and you have raised very little or no funding, it should be days or a couple of weeks, not months. (If you are independently wealthy, then you do you.)

This approach helps fight the perfectionist in all of us, that little voice of "it's not quite ready yet" that leads us to convince ourselves that if we just move the date by a few days then it will work. Days turn into weeks, and weeks into months, until you run out of money and/or time.

I like to assume that the first version won't work, probably not the second or the third, so let's just get them over with quickly so we can finally get to a version that will work. Rather than thinking that the first version will work "as long as I just build this one feature that is absolutely necessary otherwise people won't use it, I just need a little bit more time".

If the first version does work as a solution for your customers, then great! that first version you launched in a few days or weeks proved that the problem was worth solving and now you can iterate faster. This happens very rarely.

Keep it simple. If you keep time as the constant and the scope as the variable then you will be forced to reduce the scope of the solution. If you near the deadline and feel like you need to extend it, reduce scope, don't extend the deadline. Smaller scopes make simpler and better products, not necessarily bad products. (Read Jason Cohen's Simple, Lovable and Complete concept in I hate MVPs. So do your customers. Make it SLC instead. )

If you have a few hours before launch and it is not quite ready yet, and you just need a few more hours... then don't move the launch hour reduce scope, and if you can't reduce it, launch it! It will not be what you originally envisioned and surely there will be flaws you did not even consider, but if the problem is worthy, your customers will use your flawed product while providing valuable feedback and now you and your team will be highly motivated to iterate quickly. If your assumptions on the problem or solution were wrong, well then you did not waste valuable months to find out, you can try again.

Going back to our example, let's assume we have two months of funding from savings, an accelerator, and/or some grant. Then I would say, let's build a product over the next 3 days. Giving us room to launch, measure, and do the process again if we missed. Thus, we have:

Problem: Getting to work takes too long

Result of the Solution: Getting to work takes less time

Launch Date: 3 Days

What could I build in 3 days to how long it takes to get to work? A Skateboard!

This is straight from Henrik Kniberg skateboard analogy in Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable

Anecdotally, when I first started using this illustration to better convey how to build a product, scooter companies like Bird and Grin did not exist. Now scooter companies are billion dollar companies. So technically, they stopped at step two and reached what most entrepreneurs can only wish for.

Takeaway: Launch with date, not when it's ready.

Stay tuned for Chapter 3: Launch

Feel free to reach out on twitter andresbarreto (faster) or through here if you have comments or questions