Do you have a product idea floating around in your head? Perhaps you have a list of ideas you keep in Evernote, of ebooks to write, apps to build, or services to offer. Without spending the time and money to build all of those product ideas out, how can you figure out which ones will be worth building? How can you validate your idea?
Deandre’s Story
Recently I received an email from Deandre Durr, a fellow Ohio native who heard my interview on the Matt Kremer Podcast. He asked:
My best friend just moved back home and is an experienced Ruby Developer. He has agreed to be my tech cofounder if I validate my idea—which goes after the finance market as well for freelancers. What would be your first step (with basic development skills)?
Now, at first take, I was thinking: “Here’s a guy who is building an application for freelancers about finance. He could be competition to my product, Harpoon.” However, I quickly shoved that sort of fear-based thinking aside and instead chose an abundance mentality, one that trusts that there is plenty of room for a quality product, and just focuses on solving a need in the best way.
Deandre’s friend is putting him in a great position. For many of us, nobody is forcing us to validate our product ideas, and as a result, we tend to work on what we want to, or what excites us the most and are tempted to just build it without real validation other than our hunches. In Deandre’s case, he has to show proof of product validation before it can be built by his Ruby friend. What a great challenge!
Validation Tactics
So, what are the first steps in validating a product idea? How do you figure out if people want to purchase your product before you build it?
First off, a disclaimer. The real answer to this question is that you can’t validate your product with 100% certainty until it is out there for the world to buy. You can get pretty good validation of whether it will work or not, but nothing is going to be a guarantee. So, if it is possible, the best validation is to build the minimum viable product (MVP) and launch it. In doing this you are not only validating the product itself but your ability to market it effectively.
The good news is that you don’t have to build the product in its entirety to do this. If there is something that your product will do that you can do manually (even though it won’t scale), start with that. If you have an idea for an eBook, you can get a basic cover design and write the first chapter, give that away and then ask for pre-orders of the full version.
If it works out that you can build an MVP, that’s awesome. Especially if the MVP doesn’t take too much time or money to put together. However, what do you do if you can’t even build an MVP? What are some validation approaches then?
Knowledge-driven Validation
The most natural method of validating a product that you can’t build an MVP for is to simply utilize the knowledge that you’ve gathered about the target audience so far. We do this without even trying. If we knew a particular reason why the product wouldn’t work out we wouldn’t entertain building it.
With the knowledge-driven approach, we can read articles, listen to podcasts, and do some web searches to find out as much as we can about our audience’s problems, and whether or not our solution will be a good one.
While this is the most natural approach, it is also the weakest. It might provide a good foundation for validating your product, but you will build a stronger case by trying one of the next two methods.
Data-Driven Validation
Thanks to the digital nature of our lives today, there is more data out there than we know what to do with it. That is why many people make a living by being analysts, and there is even a term called “Big Data”, used to describe data sets so large that traditional data processing applications are inadequate. Data analysis is big business these days, and one approach to product validation is to learn more about it.
Now, thankfully you don’t need to have access to an IBM mainframe to validate your product from data. This data could be as simple as using Google’s Adwords Keyword Planner to determine the monthly search volume for a particular phrase. The point of data-driven validation is to gather some actual, hard data. No longer are you going off of a hunch, you have real numbers to validate why you should build a product.
This data can be something that you find by using tools around the web, or data that you can acquire yourself. For example, you could create a survey that targets your validation needs and get that survey out in front of your potential audience.
Of course, the danger here is that you could draw the wrong conclusions from your data, and still build a product that won’t have enough thrust to take off. Again, this is why an MVP is the best approach to product validation, but it certainly doesn’t hurt to have a set of hard data as your validation foundation.
Hypothesis-Driven Validation
The final method of product validation without an MVP is to use a hypothesis-driven approach. The steps of the scientific method are as follows:
- Ask a Question
- Do Background Research
- Construct a Hypothesis
- Test Your Hypothesis by Doing an Experiment
- Analyze Your Data and Draw a Conclusion
- Communicate Your Results
While many people would argue that launching a successful product is more of an art than a science, using a structured approach to validating your product isn’t necessarily a bad idea. With the hypothesis-driven approach, you begin with a statement that encompasses the assumptions that you have about why people are willing to purchase your product. For example, here are a few hypotheses that led us to build Harpoon the way that we did:
- Freelancers are yearning to have more control over their finances.
- Freelancers will pay for a tool that helps them run their business more efficiently.
- Freelancers will pay for a tool that sends invoices and collects payment from their clients.
- Freelancers don’t want to double-enter data into two tools (a financial planning app and an invoicing tool).
These are just a handful of hypotheses that we had before building Harpoon with its current feature set. Some of them will require more work than others to validate, but some can be done quite easily. For example, the hypothesis that “Freelancers will pay for a tool that sends invoices and collects payments from their clients” can be validated by researching whether tools like this exist. You can even find people on Twitter talking about how they are using these tools, and follow up with “What is your favorite thing about X?”
It doesn’t have to take much to provide enough validation to know whether or not you should move forward with a project, the key to this approach is asking the right questions, forming the right hypotheses, and getting high-quality data to support them.
Conclusion
I’ve hammered it throughout this article, but there is only so far these validation methods can take you until you need to ship an MVP. However, in Deandre’s case, he has to come up with something to validate the idea to his potential partner.
Validating your product is a multi-layered activity. Let’s say for example that Deandre validates his product idea and he and his friend begin to build. They still should focus on building only an MVP and then validating that solution. The shorter the steps are between building something, then testing how well it is received, the quicker you will realize when you are barking up the wrong tree, and whether or not you should correct your course or abandon ship before the damage is too great.
For more on this subject, check out The Lean Startup, which goes into more detail on the advantages of a short “build, test, and analyze” cycle.
