The ideal way to validate it is to be so immerse in the industry/problem such that you understand most of the pain points. Do the job that your ideal customer is doing. Attend the conferences they're going to. Visit the forums they're visiting. Read the websites they're visiting. Analyze the reviews they're posting in TrustRadius/G2Crowd. Look at their Linkedin profiles to see what their day to day involves.
I think this is a great reason to have a co-founder. I co-founded a company with a domain expert, and her ability to get in front of and understand our target audience was way more important to our startup success than my development ability (and the equity shares reflected that). I mean, we needed each other, but she was far more unique than I was.
The alternative for a developer is you immerse yourself into a different domain, or you build tools for developers. Both of which are good paths, but the former is far more time commitment and latter is more common (and thus more competitive).
It's called an inducement for a reason.
Too many "product people" or "visionaries" or whatever just don't know how to do user research and validation.
Too many people also have no idea how to solicit unbiased feedback and too many rely on asking questions and not nearly enough observation or testing.
Though I have had good experiences talking to different industries because it could be as simple as a 20 min phone call.
I find that if people are really facing problems that they want to get rid of and someone is genuinely interested in solving it for them, they are usually open to chatting. It does take some effort to reach out.
I have had success talking to 30-50 individuals before I come up with a solution and customer development is also a skill that needs to be develop .
For instance, cold call companies and pretend you have the best version of your product on the phone or create a landing page that offers your "future product", buy PPC ads, and get people to fill out a lead gen form.
In both cases, once you talk a little bit, let them know the product is still under development and ask if they'd like to be contacted again once development is done.
So its critical that you find a good sponsor/client in the early days. One that you have easy access to and you work together with until your product gets to the point where its utility is obviously apparent to new clients. And work it from there.
When your working with your first client they will inevitably drag you down into the small details (improve this/ make this). I call these the "meh" features. What you need to do is focus on analysing the underlying reason why they want the "meh" features and work on eradicating that reason. If you crack it, you get a "wow" feature. And that brings traction.
For example, we designed a financial platform for schools in a developing country. Finance operations in schools is complex with varying chains of manual processes. Our "meh" features were digitising these processes, improving each individual task. Our "wow" feature was to completely automate the end-end process for a small subset of schools with similar requirements. Instead of making their tasks easier, we just completely removed the need to do them. After that it was pretty apparent what we had to do.
After doing 10-20 of those interviews, I got pretty good at coming up with an internal "pain scale" - where this particular problem sits in terms of overall pain the customer is experiencing, and thus how much they are willing to commit to solving the problem.
Read “The Mum Test”[1]. It will make you aware that you to get unbiased feedback you need to remove your identity from the idea so that people aren’t nice to protect you.
They were miswanting. And it's a HUGE glossed over fact when talking to customers.
My point is that I believe hypotheticals take a lot pressure off and allow you to be super vague in interviews. For the past, talk about real situations. For the present, do a role play.
Unfortunately I only read it after making all the mistakes it lists - but I know from personal experience that everything it says is correct.
Basically, if you want to find out whether you're baby's ugly, you have to make sure people think the photos are of a baby, not your baby.
Ideally you have orders for the product before you start building it, don't put all your eggs in if I build it they will come.
Exactly. The best validation is people paying for a product.
As an example, I mentored at Lean Startup Machine. We'd have them form up into teams around ideas. The first thing they'd ask for was verbal feedback. But they were quickly supposed to move to increasing levels of demonstration of commitment.
One team, for example, had the notion that restaurants needed an easier way to get insight into customer experiences. They went out and found restaurant managers, and first confirmed that they had the hypothesized problem. But they quickly moved beyond words, asking if the managers would be willing to let them trial the system in the restaurant. Since enough of them said yes, they build something simple and put those little printed cardboard triangles on a bunch of tables. They then hacked together reports for the managers based on the data collected. The managers liked the reports. They then asked the managers how many would be willing to pay, right then, some modest monthly charge for ongoing use of the system.
If I recall rightly, this team discovered that when actual money was on the line, the reports were just a nice-to-have. In that situation, it's still reasonable to persevere, as you may have hypotheses about what really will get them to cross the line. But it's also reasonable to kill the idea.
There's a big difference, though, between what is taught and what people do. I was an early adopter of both the Agile movement (XP in particular) and Lean Startup approaches, and in both cases I'm kinda horrified by what it turned into in practice. With the Agile movement, it was quickly captured by companies who wanted to feel like they were doing something different while still retaining most of their top-down pathologies and high-debt code bases.
With the Lean Startup approach it's harder to say how it turned out, as early-stage startups rarely produce reports like this. But my general impression is that, as with Agile, people pick the parts that seem fun and easy, and avoid the hard parts. I think this was made worse by the flood of VC money, especially around Uber-for-X startups. Who wants a method that will kill your probably-bad idea early if you can get tens or hundreds of millions? The bad idea might work out or you might thrash your way to a good one. And if it still failed? Well, now you're a seasoned founder of a venture-backed startup. By some measures, although not mine, that's way better than having a quiet, cheap failure.