Other Sources of Lean Startup Validation
I'm a huge fan of The Lean Startup book. My wife is an academic researcher so the idea of identifying assumptions (research questions) and then testing each hypothesis seems like a good idea.
I think often people, including me, think of "email sign ups" and "revenue" as the only sources of validation. In the last 2-3 weeks I've been contacted by a few sales & marketing consultants. After the most recent one I thought, this is actually validation that the website is clearly communicating the product and value; sales people see a product they can potentially sell.
Here's what I'm thinking, if I built a "mobile phone fart app" or if the product on the website wasn't clear, these sales consultants wouldn't see an opportunity to sell something so wouldn't be contacting me.
There's obviously still a lot of work to do. I need to attract potential customers and I need to convert them to paying customers. I'm not saying its perfect or done but I do believe it's moving in the right direction and I take the recent unsolicited contact as confirmation of that.
One last thought, for my app in the B2B space, I feel job boards are also a source of confirmed assumptions. If potential customers are posting jobs that a software product can automate or introduce efficiency then I think it's fair to assume there is a need for the product (at what price, who knows).
Hope that helps,
Hi Simon,
Love your hypothesis-driven thinking!
While I completely agree with your logic (why on earth would someone approach you to sell something which is unsellable?) I've come to see all signals except money changing hands as "nice to have" at best.
I've come to a (very sad) conclusion in the past couple of years, mostly from my own failures:
There's only one validation for your idea, and that is people paying for your product/service.
I have a good friend who calls this "straight to money" - find the shortest path to get people to open up their wallets. Until someone pays you, you can never get validation.
I've had countless "close but no cigar" moments in the past decade. Now I'm focused on revenue. By the way, I don't necessarily charge my clients - a willingness to commit pre-order money (not charged until the product is delivered) is as good as money in the bank in my eyes.
I'd actually let a couple of people try to sell your product as validation for that. Give them a very limited contract that you can back out of any time (an affiliate link with limited time?)
Looking forward to hearing more about your progress!
Cheers
Jonathan
Thanks for following Lakebed and for your input.
I disagree, somewhat. To clarify, IMO, it's OK to disagree online, some people get really upset. I have heard "it's not validated until someone pays" before.
I think for a small, simple product, yes "straight to the money" is valid. For anything larger, it's simply not viable. Let's say I built an app that does X. I release it, I market it, and no one buys. No one has opened their wallet and thus the app isn't validated. Taking it as a pass/fail means that at this point App X has failed and we should close up shop.
If instead we say "people are interested but it's missing Y feature" or "people are interested but they say the price is too high" then we have small validation of small assumptions/hypotheses. So, we need to iterate, keep was is validated & working and build/improve what is not working.
I actually think the big stumbling block here is the definition of the word "validated". I'm not saying, nor do I believe, that my entire software and business model is validated. But I do believe some small assumptions are being validated allowing me to focus on the next steps and new assumptions towards winning first customers.
Hi Simon,
First of all, disagreeing online is awesome, it lets a plethora of opinions clash and reform - as they say in science - Thesis -> Anti-thesis -> Synthesis. As long as it's not personal, a healthy disagreement is a great way to learn!
Second, I completely agree with what you said - to quote Zig Ziglar - "Remember that failure is an event, not a person.". If I were to paraphrase in our context, a product doesn't "fail" or "succeed", at any given moment it's in a certain phase.
Regarding large projects, when I'm validating a project that takes human FTE's years to build, a lot of the time I'll take on a few manual service projects - I'll offer to manually (and at sweatshop rates) do the service for one of my clients. This teaches me a few things - Will they pay for it? Do they actually want the product I had in mind or will they give me a lot of feedback that will induce a minor pivot?
Obviously manually doing what the software should do isn't scalable, but building software for large amounts of money just to test it out is very risky.
I always think you should start by doing things that don't scale.
On a personal note I'd like to say a couple of things:
Cheers
Jonathan