How to Validate Your Startup Idea in 1 Week
So, you’ve just had a brilliant idea for a game-changing new product. Your palms are shaking with excitement. You can’t think of anything else.
TABLE OF CONTENTS
So, you’ve just had a brilliant idea for a game-changing new product. Your palms are shaking with excitement. You can’t think of anything else but getting this thing into the world as fast as possible.
Alright, easy there tiger. Inspiration is an artist’s game, but it’s not the way to build a startup. You’ve got a spark, but like it or not, as Lenny Manor says, your idea sucks until proven otherwise.
The good news is that there are tried and tested ways of proving your idea doesn’t suck. You can, if you’re lucky and focused, validate your startup idea in 1 week.
Sounds crazy? It really isn’t — you always want to validate as soon as possible, otherwise, you may end up burning a lot of resources and losing a lot of time. We’ve been there and done that — read more about our painful experience of slow product validation on our blog.
How to Start
99% of startup ideas start the same way. A flash of insight, and an idea for some product or service. The problem with building solution-first is that you might be creating something of little or no value to anyone.
One way or another, every startup eventually learns the same easy-to-hear, difficult-to-live-by truth:
Solve a problem someone will pay you to solve, or don’t bother.
Now, there are two ways to proceed here. Either you spend time researching the problem and those who suffer from it, or you just skip this step and start building a prototype, get it in front of people, and see how it performs. Both paths should be designed for figuring out as fast as possible whether your idea sucks or not.
Path 1: Interview First
Interviewing is valuable if you’re working off a ‘hunch’. You know, you’ve got some signals here and there that this is a problem, and your spidey-sense is tingling. This is especially so when you’re focused on a problem you personally have never suffered from.
Path 2: Skip to Prototyping
It can be absurdly quick to make a prototype these days, so if your idea is something that scratches your own itch, or is something truly novel that you think would bring unique value (think Facebook, Airbnb) as opposed to alleviating an existing pain point, then it can make perfect sense to just skip the interview research and start building.
Whichever path you take, the most important step is to define the problem you want to solve.
Start with the Problem
Begin by defining:
- The problem.
- Who suffers from this problem?
Your first job is to articulate the problem clearly, in a sentence or two, in terms of a hindrance or blockade to a job or task that a specific type of person wants to get done.
You want to get the problem on the stand, so to speak, to be interrogated from every angle.
With whatever you come up with, there will be some underlying assumptions that need to be correct for the problem to be worth tackling. This is where your attention needs to go. For example:
Small-scale vegetable growers in the Netherlands lose hours every week selling and distributing their stock to restaurants.
The big claim here, that the potential customer (small-scale growers) is losing hours every week, is actually underpinned by an assumption that losing hours every week is a problem big enough to warrant paying for a solution. If this wasn’t the case, then you’d be losing hours yourself building something no one wants.
The point here is to tease out those assumptions that aren’t strongly supported by evidence, and especially those which if they were false, would make your whole investigation pointless. Your first job is to validate the problem, i.e, prove or disprove that the problem even exists as you understand it.
This is where you either start interviewing people who you believe suffer from this problem, in order to understand it deeper, or you start prototyping. Let’s start with interviewing.
Go Forth and Talk to People
You’ll want to find people who fit the profile of someone suffering from the problem you just defined. In a nutshell, you want to find out the following about your potential customers (source: Insanegrowth.com):
- Do they experience the problem?
- How painful it is for them?
- How do they solve the problem now?
- Would they pay for a solution to the problem?
Center your research questions around these points. UX expert Erika Hall believes a good research question must be specific, actionable, and practical. It needs to be possible for you to get an answer that you’re confident enough in to move forward.
Once you get to interviewing though, you need to come up with a list of human-friendly questions whose job it is to answer your research questions. You shouldn’t just regurgitate your research questions. Why? Well, put yourself in the shoes of a vegetable grower who is asked, “How do you currently manage the selling and distribution of your products to restaurants?”. Is that an easy question to understand, let alone answer? It’s difficult to know where to start in responding to a question like that. Much better would be to ask: “Could you walk me through all the interactions you have with a restaurant that wants to buy from you?”.
See the difference? In the latter question, you’re triggering the interviewee to think about the first interaction they have with a potential customer, and they will naturally be able to explain the process chronologically from there. Their answer will give you a clear overview of the process, making it easier to jump in and ask follow-up questions to clarify certain aspects.
“To be able to ask a question clearly is two-thirds of the way to getting it answered.” — John Ruskin
The last step is of course to schedule some interviews. Start with your own definition of the type of person who suffers from this problem, then identify a solid list, one that will really get you, 10 people, to agree to talk.
To find people, you can try Linkedin, which lets you search for people in particular industries. You can reach out with a connection request and a small note, or get a month’s free trial of Linkedin Premium and message anyone without making a connection request. Or get creative. Go to meetups. Use mutual connections if you have them.
Entrepreneur Brent Summers suggests an interesting alternative strategy to customer interviews: get your customers to call you using Amazon mTurk.
Make sure to account for all the people you don’t get back to you or refuse to talk to when deciding how many people to contact. Remember that for the people you are talking to, you are just a random meeting that is of no real benefit to them.
A good heuristic is that 10% of cold messaging will result in an interview. To make things as simple and low effort as possible. Keep your messages short and to the point. Avoid back-and-forth conversations.
For instance, Calendly is a great tool that lets your interviewee pick a time directly on your calendar. Use tools like this or offer some time slots upfront to reduce friction.
Then, like Lara Croft, you venture forth into the unknown and return with treasure. Hopefully.
Making Sense of Your Findings
You’ll want to now return to your research questions and summarise your responses. Compare them to your assumptions. Were you right about them, wrong, or a bit of both? You’re looking here to update a living model of the situation and redefine your problem in terms of what you learned.
Ultimately, you don’t want to progress until you have a clear idea of the problem, and are confident that you can be paid to solve it, either by your customer directly, or some third party (advertisers, public funding, etc). In saying that, forget about validation in a pure sense. Your definition of the problem is a guiding star, but you can never be sure it stands up to reality 100%.
Your job is to understand systematically, as best you can, by working through your research questions, answering new ones to address the blind spots, and repeating the process until you have an understanding of the problem based on solid, validated assumptions.
Planning a Minimum Viable Product
Right, so either you now have a solid footing on the problem plaguing your potential customer, or you haven’t done any formal interviewing, but nonetheless have a good enough grip on the problem that you need to start testing solutions in order to move forward.
This is when you start prototyping. I’ll switch to using the term Minimum Viable Product (MVP), rather than Prototype because I think it’s more descriptive about how the solution you create should be designed.
The job of your MVP is threefold:
- Find out how to solve the customer’s problem
- Find out if you can get paid to solve your customer’s problem
And do so as quickly and simply as possible. The below image sums it up pretty well:
Designed by Brady Bonus
In the top example, the first version is just a wheel. If the problem you’re trying to solve is comfortable transport, a wheel obviously doesn’t help much. It’s not until you get to the fourth iteration that the problem is solved at all. The bottom right example is much better, because from version 1 the customer is able to travel comfortably, and in every subsequent iteration they’re able to travel even more comfortably.
But if you were looking to deliver food, the bottom right example would be overkill. Why build a comfortable truck, with all the complex engineering involved, when a simple scooter will do the job?
This is the idea of an MVP. Just remember, the job of an MVP is to find out how to solve the problem. It’s a learning exercise first, a selling exercise later.
Making the Thing Easy to Use
Many commentators in recent years have suggested variations on the MVP, like Minimum Loveable Product, Minimum Awesome Product, and Simple Loveable Complete. All of these are responses to the fact that users have certain expectations about how a product should look and feel, especially in software, and clunky, ugly, or difficult to use solution might turn people off.
You have to understand that your potential customers, if you’ve done your homework properly, really want their problem solved, but maybe not bad enough to fight through a poor user experience.
With whatever you build, you want people to actually use it in a way that benefits them. And since you have no track record, remember to make things easy to use, without losing sight of the desired action which the solution enables. Start by asking, “What is the outcome this solution needs to provide?”, — and let all your design choices optimize for that.
“A good user experience is only as good as the action it enables.” — Erika Hall
Part of this is not just making it simple to use, but removing all barriers to using the solution, like lack of motivation. You need to facilitate your customers’ natural motivation to solve their problems.
Behavioral scientist Dr. BJ Fogg sums up this idea nicely in his Fogg Behaviour Model. The basic idea is that the easier it is to take action, the less motivation is needed to do so.
In designing your MVP, you want to make it as easy to understand and use as you possibly can, while keeping in mind that you can increase someone’s motivation to use it by incorporating natural motivators:
- Pleasure — The experience of doing something in a fun and effortless way, that gives you something you desire
- Hope — seeing the potential of your solution, your user imagines how this will improve their life in the future
- Social acceptance — Can the product or service improve their relationships? Will benefiting from it improve their relationship with their boss, or can they make new relationships?
How Do You Know if Your Solution Works?
Aside from using the MVP as a vehicle for learning how the solution should look, you should, in the same MVP, or a later version, validate whether or not it works. Ask yourself: how will you know that your solution is valid? You can design an elegant MVP that you and your team are super proud of, but without a way to measure how it performs, you’re wasting your time.
Figure out what kind of results you need to have in order to know your solution does the job. If you’re relying on qualitative feedback, what kind of feedback and how much of it do you need? Are there particular actions or behavior that your customers/users take which would signify a success? How will you track this data? If you are going to charge money somewhere in the customer experience, how many purchases do you need to be confident that you’re on the right track?
Everyone’s Favorite (Ourselves Included) — Build the Thing
The tools and know-how for how to launch MVPs quickly are staggering. The list below consists of just a few of the low-cost tools you can use to build with, but it is by no means exhaustive. Good news — you don't need to know how to code to have a great launch, and that’s why we start our list with:
No-Code App Builders
Let you create highly custom, surprisingly powerful software, without knowing how to code. Learning-curve varies between them depending on how powerful they are. Best-in-class is Bubble, which you can combine with pre-built templates to launch rapidly.
Zeroqode No-Code Templates
Content Management
To keep track of information processed by your service you can, of course, of course, use Excel or Google Sheets, but there’s also Airtable, which adds a bunch of extra, super-useful features.
Service Connectors
When you get an email from this source, create an entry in my spreadsheet and post it to Facebook. When someone fills in my form, automatically send an email. Rules like these can be created without code using Zapier or Integromat.
Analytics
To keep track of user behavior in digital products, Google Analytics, Mixpanel, and Bitly are all solid tools.
Payment Services
If you need to charge your users, you have a ton of options. Stripe is the reliable, user-friendly heavy-weight, but depending on your use case, you also have Zoho Checkout, Chargify, MoonClerk, and of course, Paypal.
Yourself!
There’s a famous idea in the startup world called ‘Do things that don’t scale'. Popularised by Paul Graham of the prestigious startup incubator: Y Combinator, this approach commands you to get intimate with your customers, recruit them manually, chase them individually for feedback, and deliver solutions that work — even if the fancy sorting algorithm is just you and a spreadsheet. Not only can you often get things moving faster this way, but being closer to the problem, you’ll spot all its nuances and opportunities, rather than them being hidden behind the software. Graham’s analogy is that of hand-cranking an old car to get it going before it can continue under its own steam.
Get It Out There
You, of course, want to expose your MVP to people who fit the profile of your potential customers. If you have done a bunch of interviews, you have a massive advantage, as you can ask these same interviewees to try out your MVP.
You can also launch on Product Hunt, as many startups do (we wrote about how we got one of our products to #3 of the day there ). You’ll have to do some marketing and SEO if you plan for people to find your product themselves.
Ultimately, you have to think creatively about how to connect with people who could actually benefit from your MVP. Just posting on r/startups isn’t gonna do the job.
Your potential customers have plenty of distractions. The access you have to feedback and tools with which to construct your startup is as low as it’s ever been. This does mean though that your competition has never been higher.
A Final Word
How do we know this model of quick product validation works? We’ve used it ourselves.
Earlier this year our co-founder Levon bought a property. He wanted a way to exhibit it online to attract potential buyers, showing off what it looked like and providing a way for interested parties to contact him.
The market didn’t have a simple solution for that. So we decided to build one ourselves.
We used Asana to create tasks and manage the build, and Bubble to develop the app in just a couple of weeks. When it was complete, we launched on Product Hunt, where we got over a hundred upvotes and a bunch of positive feedback. That gave us the confidence to pursue the project further, and we are now running an open beta to see where this product journey takes us.
What MyDoors, and tons of other similar success stories prove, is that there is a niche for every kind of product or service imaginable. Traditionally, the friction to plugging that space with a solution has been the costs of developing and bringing something to market.
That is no longer the case. If you’re dedicated and use your time wisely (check our latest blog post on productivity for great ideas) — then a week might be all you need to set the wheels in motion.