4 ms·

> 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

> 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.

ryanlchan 15y ago
>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.
- code_duck 15y ago
  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.
jlees 15y ago
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.
- code_duck 15y ago
  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.

ryanlchan 15y ago

>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.

code_duck 15y ago
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.

jlees 15y ago

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.

code_duck 15y ago
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.