Validation is about testing the biggest risks and assumptions of a product idea up front, by running a series of quick and cheap experiments.
Our primary risk is usually that no-one wants our product. Only users can validate potential solutions, as they have the problem it’s solving, so it’s essential to get in front of them, to test our product idea in the real world.
These confirm which products work for users and which don’t, so we build only the path(s) that gets users where they actually want to go.
“They own the problem, you own the solution” - Rob Fitz
Prototypes should be built and tested in days, not weeks or more, and should be cheap to produce. This gets answers quicker, and avoids us getting too attached to any individual solution.
Negative results (e.g no interest from users) should be celebrated! You want to find out things that could destroy your product as soon as possible. This is valuable data and stops us wasting time on solutions that don’t work for users.
That said, negative results might mean a range of things: the problem may not be real or urgent, or the solution may not be effective or desirable for users, so make sure to understand the reasons behind any results, by asking the right questions, before ditching an idea completely.
There are many ways to prototype:
A Minimum Viable Product is the classic validation method. For early tests, this is really a prototype.
The prototype should take a Wizard of Oz approach, where as much as possible is done manually, to spend less time coding and more time getting it in front of people.
For example, the Yipit founders manually compiled their aggregate daily deals email. They tested demand quickly and were able to easily validate and iterate.
This doesn’t scale, but our aim is validation, not growth. It also doesn’t work for all types of product, which should be considered during our evaluation.
Similarly, check if there is a scaled down version that you can do quicker and cheaper, to get the same learning. For an educational course site, for example, teach part of your intended course to someone in your target audience first (without building the site or course at all).
To test demand for a concept you can create a landing page that looks real, including a ‘buy’ button, similar to Kettle & Fire.
Send traffic (likely via adwords) and see if anyone buys, thinking it’s real. If they do (and they paid you real money), you have strong demand validation and a functioning traction channel.
You don’t have a product at this point, so send your buyers an email saying the product is out of stock and offer a refund or discount if they wait until its ready (refund anyone who doesn’t reply, of course).
Keyword and trend search
Writing as prototype
Writing before you code, such as on a blog or forum, clarifies your understanding of the problem area. It also tests whether the problem or solution connects with people, shows who your target audience might be, and shows whether you have a way of getting traction with them.
If you can attract attention to the article, you might have an audience. If you can’t, you might not.
A quick way of testing ideas is to imagine a letter written from a happy customer to you, describing why and how your product has transformed their life.
This doesn’t validate demand directly (no actual customer was involved), but does help frame your product focus on the actual outcome to the user. If you can’t think of how a user might gain in this way, your solution may not be solving a problem.
There are many ways to validate, and it can be overwhelming to try and figure out what method to use. But the most important thing is getting your idea out into the real world to see if it has potential with real users - the methodology is secondary. The only way to fail is to not ship your prototype. Good luck!