I think as a Startup you should spend 90% of your time on refining and validating the Problem Definition. Do as much as you can of that activity without even creating a single line of code. Since most probably you are solving a human problem, you should interact with as many humans as possible.
Lets be honest, unless you are creating a rocket or some really cool new technology, most Web Services/Apps can be implemented by anyone. YOUR job as Startup is not to reinvent the wheel for the solutions but live and breath the problem definition. After all it will be much cheaper and faster to fail if you have not built the product yet.
This _sounds_ like great advice, and "I want to believe" too, but this article is not convincing. The way it's written, I just see some principles flatly stated and not even backed up with anecdote--it's not even a data point. The HN title "A Learned Learned..." contains the most indication that the OP is speaking from experience and not off the top of his head.
Forgive me for not knowing the OP, his experience/reputation, or his company and its product. I expected a bit more explanation for his position. Also, I'm a bit skeptical of the "refundable credit" for a non-existing service or product. I'd like to hear more about how that's possible.
While I agree that you should validate your ideas before spending copious amounts of time programming, I don't think that you should sell people on an imaginary product. Unless you already have an established reputation, it's highly doubtful that people will pre-order something on mere talk alone.
I think that it's a better idea to stick with the MVP (minimum viable product) model and iterate rather than try to figure out revenue and customers right off the bat.
That totally depends on your market. I understand that many programmers are uncomfortable with selling stuff that doesn't exist yet, because to them it feels fraudulent. But there are a lot of ways you can get around that feeling and leave customers feeling happy.
A good example is Kickstarter. People sell imaginary products on there all the time. And this has gone on in the software business for a long time. Microsoft, for example, got their start selling a product that didn't exist:
I think that approach was a little dubious (although it's hard to argue with the results), but I'm perfectly happy with Kickstarter. For me, the difference is that with Kickstarter they're being honest.
There are also things you can do that are in between. For example, the landing page that talks about a "coming soon" product is fine by me. As is a guerrilla user test where you have people look at several things, some of which are products that don't exist yet. Or getting your clients to sign a letter saying, "If you build X, we will pay you Y for it."
And honestly, people do order things on talk alone. A lot of enterprise software starts out that way. It seems crazy from a programmer perspective, but if you're running a business you frequently make small bets on new suppliers to see whether they can deliver. And sometimes large bets if they have something you really want.
This is great advice, does anyone have some resources on how to pre-sell or pre-validate a product without much to show? I mean, I've always tried but if you describe something to someone and say "do you want this? Will you pay $20 for this?" they always say, "cool! sure!" and then don't answer when you come collecting product in hand.
Another option is the concierge delivery method. This works for some ideas better than others. Eric Ries (and many others) go into greater details. Basically, you manually deliver the service. So, if you were a grocery delivery service, maybe you would find some potential customers and have them submit a Wufoo form with their grocery order and then you would fulfill it. Skillshare did this (http://www.mikekarnj.com/blog/2011/08/01/how-to-launch-your-...).
patio11 has a good description on his site kalzumeus.com of how he market tested Appointment Reminder before he sold it to his customers. Sorry, don't have the link on me, but his whole site is pretty chock-full of good advice on selling software. Going through his lifecycle email course now, learning a lot.
The basic premise is you set up a landing page that sells your product or service, and after someone clicks "buy" "add to cart" or "sign up" you count that as a conversion.
Drive initial traffic to test via PPC in order to avoid social bias.
we definitely experienced this at matchist, and it has made us waste valuable months. now, we don't build ANYTHING unless at least 3 customers request it and unless it will affect the bottom line (no fancy feature upgrades)
If you, like a lot of the startups outthere , are going ot make another better shopping, better video sharing, or better... whatever service/product then by all means, do that. But I bet you nobody who ever did anything original did that first. Because by definition if you want to come up with something new and different, people will invariably say No until they can actually touch it and feel it. After that they may or may not say yes, but definitely not before.
Does advice like this apply in some way to personal/career development?
I would like to break in to a particular technical field. I believe that to work in that field, I'll need to demonstrate some measure of experience in that field. To that end, I'll need to build. This feels like a 'build first, sell later' kind of approach.
Or should I tip the scale toward 'selling' myself on the basis of my other useful experience, and build my expertise on the job?
IMO - you have to always sell first in everything you do... yes we want to build first to prove first... but convincing someone else you are capable is the first thing to be done... assuming you can really do it - if you don't sell first no one will give you the chance...
Before even delving into development beyond the internal spikes, put together your business model! You should have a pretty good idea who (and how numerous) your customers are, how much they're willing to pay, and how to reach them. Once you have those, you have some revenue numbers. From there, you can extrapolate at least a rough outline of a business plan.
If you can't figure out who the customers are or what they'll pay or how to get them to pay, then maybe you're sitting on a nice open source project instead. Lack of a business objective doesn't mean you shouldn't do it, but maybe it means you shouldn't try to make a living from it.
After our first failed startup due to a lack of costumer interest we didn't even touch a text editor until 120 customer interviews. We wanted to be damn sure the problem we were attempting to solve was an actual problem.
During this search process we built out our business model canvas making the necessary changes along the way. Each week we focused on a certain section of the canvas and challenged those assumptions against what our customers were saying.
This is at its core tremendous advice... But let me temper it: don't sell, validate. In many applications sale risk is cheap enough (customers forgiving enough) that sales-as-validation is ok. Sometimes it sets up really bad expectations, though.
It's easy enough to validate without selling: just don't take people's money. It's less valuable than sales since you can't be sure people are making accurate financial decisions until you have their money, but it's both dramatically better than sitting in isolation coding and carries very low social risk.
I really think its worth re-reading Venkatesh Rao's "Entrepreneurs are the new Labour" and his dissing of the Lean Startup movement (tldr - it's a great way for in estors to have control / viaibility over many more compliant startups than if entreprenuers really had peer power.)
Yes, go validate your assptions, get out of the building. But decide where your exit is, where your talents lie and how much is the opportunity cost.
Excellent advice. Quite often when technical founders aren't quite sure how to go about the validation process, we tend to double-down on development. Instead the exact opposite is what seems to work best; get out there and talk to people you think need your painkillers.
It also helps to be your own customer (or in that demographic). I'd suggest that you should have some kind of validation metric for knowing when to continue with the project as well, otherwise a project can drag on for much longer than it should.
Do folks have experiences to share on validating the idea without giving it away? Isn't there a risk that the if you tell people one of them will take your idea and run with it?
"Don't worry about people stealing an idea. If it's original, you will have to ram it down their throats." -- Howard H. Aiken
I think it's a legitimate worry, but a small one. Novice entrepreneurs overvalue ideas. The majority of startups make major changes along the way. E.g., PayPal was, what, Levchin and Thiel's fifth product?
And the real magic to PayPal wasn't money transfer; it was the loss prevention that kept the business viable. The thing that distinguishes successful entrepreneurs isn't that they all had one good idea 5 years ago. It's that they kept having new ideas, and had the drive to push their ideas out into the world so that they could learn enough to spark the new ideas.
Practically, there may be a very small number of people who a) are smart and experienced enough to appreciate your idea, b) have more resources to execute, and c) aren't busy doing something they like better. Try not to let those people understand the secret sauce. But those people are hopefully not your customers, who are the main ones you should be validating your idea with.
You test your idea on actual customers, you don't tell your idea to HackerNews. And even awesome companies like Facebook screw up when they test by running bad tests. Example: Home. Facebook tested Home on employees who usually use iPhones. Oops. If any of them read Robert Scoble or talked to a single Android fanboy, they'd realize Android is about customization. If a Nexus fanboy likes the Sulia widget or whatever you call it, said fanboy is not going to want to use Home when Home displaces Sulia.
[+] [-] 31reasons|13 years ago|reply
Lets be honest, unless you are creating a rocket or some really cool new technology, most Web Services/Apps can be implemented by anyone. YOUR job as Startup is not to reinvent the wheel for the solutions but live and breath the problem definition. After all it will be much cheaper and faster to fail if you have not built the product yet.
[+] [-] tyang|13 years ago|reply
[+] [-] 205guy|13 years ago|reply
Forgive me for not knowing the OP, his experience/reputation, or his company and its product. I expected a bit more explanation for his position. Also, I'm a bit skeptical of the "refundable credit" for a non-existing service or product. I'd like to hear more about how that's possible.
[+] [-] ddedden|13 years ago|reply
I think that it's a better idea to stick with the MVP (minimum viable product) model and iterate rather than try to figure out revenue and customers right off the bat.
[+] [-] wpietri|13 years ago|reply
A good example is Kickstarter. People sell imaginary products on there all the time. And this has gone on in the software business for a long time. Microsoft, for example, got their start selling a product that didn't exist:
http://en.wikipedia.org/wiki/Microsoft#1972.E2.80.9383:_Foun...
I think that approach was a little dubious (although it's hard to argue with the results), but I'm perfectly happy with Kickstarter. For me, the difference is that with Kickstarter they're being honest.
There are also things you can do that are in between. For example, the landing page that talks about a "coming soon" product is fine by me. As is a guerrilla user test where you have people look at several things, some of which are products that don't exist yet. Or getting your clients to sign a letter saying, "If you build X, we will pay you Y for it."
And honestly, people do order things on talk alone. A lot of enterprise software starts out that way. It seems crazy from a programmer perspective, but if you're running a business you frequently make small bets on new suppliers to see whether they can deliver. And sometimes large bets if they have something you really want.
[+] [-] Swizec|13 years ago|reply
[+] [-] saraid216|13 years ago|reply
[+] [-] mrgreenfur|13 years ago|reply
[+] [-] realdlee|13 years ago|reply
[+] [-] waterside81|13 years ago|reply
[+] [-] hayksaakian|13 years ago|reply
Drive initial traffic to test via PPC in order to avoid social bias.
[+] [-] biot|13 years ago|reply
[+] [-] startupstella|13 years ago|reply
[+] [-] thornad|13 years ago|reply
[+] [-] jabbernotty|13 years ago|reply
I would like to break in to a particular technical field. I believe that to work in that field, I'll need to demonstrate some measure of experience in that field. To that end, I'll need to build. This feels like a 'build first, sell later' kind of approach.
Or should I tip the scale toward 'selling' myself on the basis of my other useful experience, and build my expertise on the job?
[+] [-] taf2|13 years ago|reply
[+] [-] beat|13 years ago|reply
If you can't figure out who the customers are or what they'll pay or how to get them to pay, then maybe you're sitting on a nice open source project instead. Lack of a business objective doesn't mean you shouldn't do it, but maybe it means you shouldn't try to make a living from it.
[+] [-] ryanSrich|13 years ago|reply
During this search process we built out our business model canvas making the necessary changes along the way. Each week we focused on a certain section of the canvas and challenged those assumptions against what our customers were saying.
[+] [-] tel|13 years ago|reply
It's easy enough to validate without selling: just don't take people's money. It's less valuable than sales since you can't be sure people are making accurate financial decisions until you have their money, but it's both dramatically better than sitting in isolation coding and carries very low social risk.
[+] [-] lifeisstillgood|13 years ago|reply
Yes, go validate your assptions, get out of the building. But decide where your exit is, where your talents lie and how much is the opportunity cost.
[+] [-] trevoro|13 years ago|reply
[+] [-] Terpaholic|13 years ago|reply
[+] [-] jfabre|13 years ago|reply
Don't code an half-baked product to test the market when you can build demos and talk to real people.
[+] [-] mkoble11|13 years ago|reply
Unfortunately, I can't find it on his blog or searching Google or I'd post it. :\
[+] [-] noveltyaccount|13 years ago|reply
[+] [-] wpietri|13 years ago|reply
I think it's a legitimate worry, but a small one. Novice entrepreneurs overvalue ideas. The majority of startups make major changes along the way. E.g., PayPal was, what, Levchin and Thiel's fifth product?
And the real magic to PayPal wasn't money transfer; it was the loss prevention that kept the business viable. The thing that distinguishes successful entrepreneurs isn't that they all had one good idea 5 years ago. It's that they kept having new ideas, and had the drive to push their ideas out into the world so that they could learn enough to spark the new ideas.
Practically, there may be a very small number of people who a) are smart and experienced enough to appreciate your idea, b) have more resources to execute, and c) aren't busy doing something they like better. Try not to let those people understand the secret sauce. But those people are hopefully not your customers, who are the main ones you should be validating your idea with.
[+] [-] tyang|13 years ago|reply
[+] [-] tyang|13 years ago|reply
Otherwise perfect. A+.
[+] [-] jk4930|13 years ago|reply