One of the most common questions I’m asked is, “Ross, I built this [thing], but I don’t have any customers. How do I find people that will use it and pay for it?” Most first-time entrepreneurs I meet usually have what I like to refer to as “product fever.” They’re so excited about their own idea that they begin to believe all they need to do is build it and the rest will fall in place. Sorta like the movie, Field of Dreams. Great movie, but it’s still fiction.
Expectation vs. Reality
The most common symptom of product fever is delirium. Trust me, I’ve experienced this – wild excitement about your own product to the point that you develop unfounded illusions of grandeur and a countless list of potential features. If you’re serious about pursuing your idea, you’re talking about investing your own time and most likely your own money pursuing your idea. For most people, including myself, you can’t afford for people not to buy or use your product if you build it.
Oftentimes I talk to entrepreneurs (and even large companies) who have succeeded in solving a problem that no one has. Or, they’ve simple built a “better” or more customizable mouse trap.
So how do you know if you’ve got a winning product or a dud? How can you verify that an audience exists who is willing to pay for your product before you spend countless hours and dollars building it? After reading this post, you’ll have a solid understanding and appreciation for the process of validating a new product idea and why it’s important to do product validation before you ever start building your software product.
[Disclaimer: I’ll be completely honest, this post is going to be skewed to the world of commercial B2B software products because that’s where my professional experience and interests lie. If you’re building consumer-based SaaS products or mobile app or games then your mileage may vary (strategy should still apply, but your tactics may be different).]
What Comes First – The Product or The Market?
The fallacy of the great product makes us think that all it takes is a great idea. We read startup stories like Snapchat, Facebook, and Amazon.
Think back to the dotcom bubble. Landgrab economics was the mentality for many startups. They were simply buying up web properties and worrying about the business model and profit later. So what comes first – the product or the market?
Many people think that if they build a product they can find a market to jam it into later. It doesn’t quite work that way. The startup gurus talk about Product-Market fit, but in my opinion we should be calling it Market-Product fit. There has to be a need for what you’re trying to build.
Most likely, your customers already know they have the problem. If they do, chances are they’re already attempting to solve it themselves. For example, most B2B software products are geared towards process improvement and automation. But the truth is, existing processes for most people are simply good enough. Meaning, the benefits don’t outweigh the cost. The idea seems better in your own mind because your sample size is n=1.
So before you quit your day job, it’s a good idea to find out if people are even willing to use and pay for your product. In the product development world, this process of determining if people see value in your product idea is known as validation. In the context of product development, I like AcceratorU’s definition of validation – “the process of achieving increased certainty that a product idea will be successfully adopted in market. ” By definition, validation has nothing at all to do with you and everything to do with your intended audience/market.
But why is product validation important?
- When it comes to new product ideas, you’re making assumptions, sometimes a lot of them. It’s important to make sure your key assumptions are right as early in the lifecycle as possible. The include assumptions about the user/customer, their workflow, the context of their pain points, etc.
- Product validation helps mitigate the risk of building something nobody wants or would buy so you don’t become another statistic in the startup graveyard. You’ll know very quickly if people will buy your product before you build it.
- The process of product validation puts you in direct contact with your users. If your idea is good then you’ll need to make sure you’re building something that’s easy-to-use and your users love. Trust me, they’ll tell you if it sucks.
- Agility. If you find out you’re headed down the wrong path with your product, it’s a lot easier (and a hell of a lot cheaper) to course-correct sooner rather than later.
- The process of product validation will help you limit the amount of time and money spent in the early stages of the product lifecycle.
What You Should Validate
Product validation will help you answer your hypotheses. For my clients large and small, I always get them to write-out their initial hypotheses by trying to answer 3 questions: WHAT, WHO, and HOW. It’s important to write down your hypotheses. If not, you and your development team will go crazy trying to capture and organize your stream of consciousness.
- What is the biggest problem you’re trying to solve?
- Who has the problem?
- Who is the customer? Who are the users? (they’re not always the same person)
- How do you solve this problem? Is software the best solution?
- How many people have this problem? How big is the addressable market?
- How are you going to reach your audience of customers and users?
- How will you make money?
- How do you know if people will use your product?
To boil it down, we really need to validate 3 things:
- Market demand
- The problem, or pain point, you’re trying to solve
- The proposed solution and product
I’m not going to lie to you, product validation is one of the hardest things to do in a product lifecycle. If it were easy, startups and new product ventures wouldn’t have the 90%+ failure rate for which they’ve become famous. Just remember, the important questions you need to answer don’t actually require that you have your product built, or even a prototype. At most, a few sketches is all you’ll need.
How You Should Validate
Finding answers to the questions outlined above is important. How you do it is pretty simple. Actually, you probably learned how in 3rd or 4th grade. It’s called the scientific method and it’s been used since the 17th century to help mankind understand the world, acquire new knowledge, or correct old knowledge. If you can’t remember, here’s a quick refresher:
- Form your question
- Create your hypothesis
- Draw a conclusion
The approach to validating your product idea is very similar. Your idea, question and hypothesis probably came through observation…or divine inspiration like a few people I know. But for many, this is where they stop. They fail to create experiments to test their assumption’s validity.
In Eric Ries’ book, The Lean Startup, we learn that the validated learning loop (BUILD-MEASURE-LEARN) is the fundamental feedback loop that startups should use to turn ideas into products, gauge customer response, and learn whether to pivot or persevere. As a startup, your processes should be geared to accelerate that feedback loop.
You’re probably thinking, “That’s great, Ross; but you just got through telling me not to build my product first.” You’re right. But the entire learning loop can be abstracted to more than just building your product.
I subscribe to a much broader interpretation of BUILD that applies to creating any asset for the purpose of learning from your customers or potential product idea. This could be a presentation about the assumed problem, a landing page, a simple website, a brochure, or even a PPC campaign. These are all examples of BUILD assets that will help you validate your assumptions.
If you spend your time creating BUILD assets that you can collect quantitative and qualitative data from then you’ll be able to LEARN whether or not your assumptions are correct.
In Part 2 of this series, I’ll teach you tactics that you can use and artifacts you can create that will help you dive deeper.
Things To Remember For Product Validation
- Write down your hypotheses and assumptions before you ever write a line of code.
- Learn from your potential customers and users. The idea may be yours, but let them dictate the direction of the product.
- Trust the process and iterate – you may not know what you want, but now you know how to get it.