Smart founders try to test their idea before investing the time and money into building it. Some founders trust their gut more and jump straight to building, but I've seen this approached fail more often than it succeeds.
It's almost never the correct approach, but the slowest way to validate is to build the whole app.
Here are some beliefs that drive founders to build first, validate later:
- people need the final product to get value out of it
- it needs to look great when you launch
- we already know what to build, it's just like
$competitorProduct - there's no simpler solution that we can put in front of users
- we need the app to solve the problem at scale
If you nod strongly in agreement with any of these please double check. It might be that you're right, or it might be that you're avoiding uncomfortable feedback.
A better approach is to test your assumption early with minimal investment. Here are a few ways you can validate your idea in order of effort levels.
If there is already a market for a product you're building, then you got your answer about the demand. Now the only question is if you can get people to buy from you.
There is a market for search engines, but good luck dethroning Google.
If you're solving a problem for which there's no good solution yet, you should be able to find people that are willing to commit to buy from you once you've built the solution.
This is sometimes done with a landing page "smoke test". You set up a landing page where the purchase flow works as expected until the fulfilment stage where you tell the customer that the product or service is currently unavailable. I've never tried this because I find it unethical, but it works.
What you can do, that's also ethical, is to reach out and be upfront with people. Tell them about your idea for a solution and see if they'd be interested. If it's a serious enough problem for them they will definitely sign up.
Multi-million dollar businesses were started this way.
Or, in other words build a proof-of-concept. This is a temporary solution that you might discard later, but it helps answer an important question: do people get value from your offer?
For example, for a custom wallpaper generation app I reached out to people on Instagram, I've then generated the wallpaper manually and sent it to them. This is not scalable approach, but it gave me a sense of how many people respond well to my offer.
Stripe, the second largest payment processor in the world, started off with the founders themselves doing the manual work to integrate their solution into people's websites. This way, they removed an obstacle for the client and they also got feedback from their customers.
Start with a simpler version of your product. It could be that it's something that resolve just a narrow problem for a fraction of your target market.
For example, if you plan on building a web app for marketing agencies to help with ads on Instagram, Facebook, Google Search and Youtube, you could release a first version that works only with Instagram. It's not ideal, but some users would get value from it and you get some cash-flow and user feedback.
An important note here is that each increment of your product needs to be functional.
(this comic is from User Story Mapping by Jeff Patton)
That is the 5-6 figures question.
Software projects are a significant investment for any company. Just the direct costs are in the 5 figure range even for the smaller projects, and from there the sky is the limit. That's without considering the time and energy required from the management and other relevant associates.
But that's business, and the goal is to have a wildly positive return on investment.
The role of validation is to spend a little money early to make sure that the bigger budgets are spent wisely. That's why the validation ladder guides you to make increasingly larger investments only when you have some confirmation that you're going in the right direction.