The problem with faking it, is that it becomes hard to distinguish between the fakers and the makers. And if most everyone is a faker, then even makers can be seen like a faker too. After spending enough time in Los Angeles and New York, possible our national fake-it capitals, I can't tell you how frustrating it is to spend time, money and effort trying to figure out who has real juice. Especially when fakers are faking it so hard that they are standing tall next to the real makers. So instead of encouraging people to fake-it. Just make it. Something made is undeniable, something faked can be outed at any moment. If what you want to make is too big to make, then make it smaller, and if that's still too big, then make it smaller again. Instead of building on your fakes, build on your makes. Having interviewed literally hundreds of candidates for jobs, I have gladly hired a small time maker 100 times over a big time faker.
For most of the examples cited, it doesn't really matter whether someone is faking it or making it. The whole idea is to connect up people with ideas of what can exist (entrepreneurs) together with people with ideas of what should exist (customers). There's no money changing hands; all you're giving is an e-mail address. If the product ends up not existing in the end, you're out the 5 seconds it took to type it in. If the product does end up existing, both you and the entrepreneur end up winning big.
The article doesn't say to fake being successful. It is talking about faking the product (or feature). There is some clever stuff there, and I’m not sure your criticism is relevant.
This contemptible approach turns your rightful marketing costs into negative externalities for everyone else, filling a formerly efficient market with nonexistent bullshit. I'd love to see the FTC nail anyone guilty of this, though they probably can't afford to keep up. Maybe we need a blacklist.
EDIT: some of the examples involve actually providing the service you're advertising, albeit in an unscalable way, and that's perfectly legitimate. Just don't promise something you aren't at all ready to deliver.
What about Dropbox's method? There was no lead-gen site that tried to imply for 99% of it that the product already existed; instead, there was just a video containing synthetic "this is how we imagine this working" flows, and a request for people to sign up if they were interested in seeing that vision realized.
If "this isn't available" was clear up front, it sounds like a volunteer market research panel, which is ethical iff requested openly (though I may not have been inclined to sit through it unless I also needed ideas).
> Food on the Table did the tasks for their early customers by hand. Rather than creating web software, they implemented the service in person.
I tried this on a project, and then ended up with the by-hand parts as a millstone around our necks. My partner and I couldn't agree on how to automate the service, basically. I realized at some point it violated Derek Sivers' advice, "Work on on your business instead of in your business.". So, if you're going to do something laborious by hand that should be done by computer, make sure you are going to be able to automate it later on. I'm never starting another business where everything isn't self serve, automated and done at the beginning.
>I'm never starting another business where everything isn't self serve, automated and done at the beginning.
Isn't this the exact point which the article argues against? Perhaps the problem was really that you couldn't work out a good methodology to automate these tasks with your partner, a problem that would've occurred even if you'd tried to automate it at the beginning.
I think the real takeaway here is just the same "fail fast, fail early" we see everywhere, but taken to the next level. Get Real urges you to ship your product as early as possible, but this is saying that you don't even need the product to get started.
The article cited the quoted as an example of 'fake it before you make it'.
My example is how I tried that, starting 'lean' - handling some procedures by hand at first in lieu of writing a web interface and backend.
Part of the problem was my partner and I were learning to work together, but mainly lack of time. This was compounded by a Catch-22 situation: I lacked time to automate due to how much time it took to handle manually. The business was growing very rapidly while we were trying to expand features for the public as well as automate management procedures. It was my first successful venture and having failed to do this right, I learned my lesson.
I don't agree that you need to automate from the beginning. I launched a site where I did everything manually behind the scenes and never needed to automate; figuring out the automation code would have been the trickiest, hardest part of the development process, and I saved a lot of time by not doing it upfront. Even had I reached the point where I needed to write it, I would have had a much better idea of incoming data and desired outputs to write it far more accurately than stabs in the dark pre-launch.
The advice I was given from similar workshops with Steve Blank etc. is to do things by hand until you have to automate; when you reach the point when you have to automate to scale, it's a good problem to have.
I can understand having the problem where you can't agree on automation strategy; options range from outsourcing the manual work to fully implementing algorithms, and even those can wildly differ. Obviously it depends on your specific situation, but I don't think your example is an argument against "Wizard of Oz" launches per se, just an example that it isn't always gravy.
I'm not suggesting this should be an absolute rule... just pointing out one situation where it didn't work out, in an unexpected way. It's a good problem to need to automate to scale - unless you aren't able to do it, in which case you're screwed.
I'm firmly behind the lean approach (though I don't think this article says anything new). However, I do often wonder how customers really feel when they hit a "Sign Up" link and are taken to an inexpertly crafted Wufoo form designed to harvest their address.
Dropbox got it right, but I've seen several examples where I think "I hope this scales, 'cos those first 50 visitors know they've been tricked and ain't coming back".
Yeah -- I think this shines when you're solving a problem that's so important, and unaddressed, that people are all over it when all you have is an email form.
Lots of B2B companies will sign up a customer first and then use the revenues from that to build the product. It's no different from contract development - you spec out what you'll be delivering, agree on a price, and then build it. The only difference is that you retain rights to the product, so that you can sell it to some other customer as well.
I've worked at a company whose motto was "Smoke and Mirrors". They'd try to sell based om the wireframe, but tell the customer it was a fully functional product that just need to be customised for their environment.
I never really saw it work that well for them. Sure they could get a lot of interest but any sales they closed were a nightmare to deliver because you had to develop a system in a timeframe that only allowed some tweaking.
EDIT: what I mean is that it's fine to use the model you mention, but IMO you have to be upfront with the customer about it.
That's true, but I don't think the op is saying you'll get contracts based on mock-ups. I think the goal of "faking it" is simply to gauge potential interest. I've done it in the past, and it yielded very interesting results.
We did that for several years with web apps over SAP.
We developed a series of reusable building blocks, grabbed from one implementation to the other. But what was presented to clients were nice and trendy png screens, based on the last information we got from them.
Leaving our competitors in the dust, with their product releases, documentation and aging interfaces.
But it's over now, today I'm in a SaaS startup, and here we can't fake anymore. When people try your app, they see the real thing.
The Earbits guys do this for a video tour of their website. The first time you visit it there's a banner link to watch that video, but if you click it it says something along the lines of "thank you for your interests, we wanted to know if people actually want to see that video before hiring Spielberg to make it for real". This is brilliant and the fun part of the message even makes users happy with not seeing the video.
Pitch meetings for TV/movie scripts often have writers making up stories on the spot. Then if they get the green light, what they're really thinking is, "Holy shit! Now I have to find a way to write that!"
Only difference is that pitch meetings for TV shows usually have a known commodity attached to the pitch -- someone whose very presence is meant to reduce at least one of the five hundred thousand risk variables associated with a TV pitch. If that known commodity is an established writer -- let's say Larry David, or Aaron Sorkin, or whoever -- then the execs can reasonably assume that he'll be able to write whatever he's just sold.
Rarely, if ever, does someone without a track record even get a network pitch meeting. And even then, he'll get it only if some big name or piece of IP is associated with him. The strength of the concept matters relatively little compared to what name or "brand" is attached.
All this is for good reason, obviously. It would make little economic sense for networks to drop millions of dollars on ideas alone. For that kind of money, they could hire legions of fresh college grads to sit in a room all day, eat ramen, and generate concepts for someone else to write. As it is in the tech world, execution is everything in the creative business. There are a striking number of parellels in both industries, actually. (Full disclosure: have worked in both industries).
There are also pitch meetings to production companies, where writers are hired to do TV episodes. Unknowns sometimes get their breaks there. Harlan Ellison did. Tracy Torme did. Still happens today. I went too wide, mentioning movies, I guess.
Another upshot to this method is that
(a) a business/product guy can do it without an engineer.
(b) and if its an engineer faking it, it will give her/him some insight into what it takes to build it.
