I'm not clear on what you mean by "losing faith in the product". Do you mean that you stopped believing that it had any value whatsoever; or that any/enough customers would ever like it; or that you lost faith in your own ability to accomplish it? Or do you just mean that... you ran out of motivation?
The key idea is not that "it takes time", but for it not to take time. In other words, to get something done ASAP. I'm talking like 2 hours, not 2 weeks or 2 months.
esr said to launch a product you need something that (a) runs; and (b) has a promise that it can be turned into something really cool in the near future. It's code + words. Note: this means that the thing that runs is not really cool. [many others also state this idea, but I really like esr's formulation]
For motivation in general (not just for launch), the same thing is true: you want to get something that works ASAP. Fred Brooks says of this style of incremental development: I was stunned by the electrifying effect on team morale of that first picture on the screen, that first running system.
I wrote the first version of my product in 2 hours (though I'd been thinking about it for a couple of weeks; and it took a 9 hour day to write the website). This isn't because I'm some great coder, but because the product was that simple. It wasn't "finished". It took a year before the first sale, and eventually I made enough to retire (for small values of retire).
The technical community seems to have these virulent quality assumption: Everything test driven, inside out, full stack, behaviour drive. This is great and a must if you have a clear product requirement and/or a clear vision.
But I think this is conflicting with the "release a MVP, crappy, early" philosophy. Maybe I'm to "slow" when doing tdd things. Maybe I just aim too high?
Maybe I've a low frustration tolerance that does not allow me to survive the gap between "end of initial euphoria" and "the first paying customer". How to to improve?
The technical community seems to have these virulent
quality assumption: Everything test driven, inside out,
full stack, behaviour drive. This is great and a must if
you have a clear product requirement and/or a clear
vision.
I think it might be an infliction particularly common among those of us who started our own thing after (too many?) years of "Enterprise" (and other larger-scale) programming.
After being burned by having to support/maintain/develop upon someone else's huge, less-than-optimally-thought-out code base you grow afraid of quick hacks, even tho those are sometimes exactly you need.
Is it because you are not convinced that aiming lower is the right thing to do; or do you believe it but you have trouble actually doing it?
Perfectionism is common in programmers (perhaps because imperfect syntax doesn't work). It means that you compare your product with "perfection", instead of comparing it with "nothing" (ie. it not existing at all.) If you tend to be critical, and quickly notice faults and omissions, then you may be a perfectionist. It seems to me that perfectionism is the number one reason why many programmers aren't successful in business. It's very difficult to overcome, but one way to begin is simply try to find what does exist in your product (and elsewhere), and just acknowledge that it does. You might not yet be convinced that it matters, but just being aware of it is a start.
For me, a crucially motivating thing was people actually being interested: feedback. When I launched that 2-hour product, I wouldn't have continued if there was no feedback. But there was (a single email!). Feedback can help survive the gap you mention, to paying customer. Before then, just getting something that does something can be very motivating (see my GP comment).
BTW: don't do tdd for a MVP! It takes too long. The advantages of tdd don't really make sense for prototype.
EDIT Ask yourself how you could cut corners, and yet still deliver some of the essence of the thing. Work out what your one essential idea is, and try asking of a particular line of code: is is absolutely necessary for that essence? Some other questions:
- error checking? *cut*
- corner cases? *cut*
- "option to save your work"? *cut*
(unless it's a DB etc, whose essence is storage)
- cover the most common cases? *cut*
(just cover *one* case)
- documentation? *cut*
(except: the essence + how to run)
- debug? *cut*
(provided it mostly runs)
- integration test? *cut*
- define formats/interfaces? *cut*
A more extreme cut is possible... No Code:
- present slides of your product (Steve Blank)
- pretend to have a product, but you just:
post on HN
one webpage (optional: a survey on it + Skype chat)
(feels wrong to me, but can be done ethically)
- adwords campaign + landing page
Consider your PHP friend... did he aim high? What specific actions did he do that were different from your other friends?
disclaimer I find it hard to cut corners on my present project. My excuses (which I'd like to overcome) are due to it being based on a new mathematical model:
- if the maths isn't realized correctly, it won't work perfectly
- showing off all its benefits (eg error checking) requires more work
- getting the foundation right will be easier to build on
- patenting (can't be done after release)
My "PHP friend" has already done several profitable projects with the least amount of perfection. He knows how to do it right, has already the traction to bring already paying users over to his other new projects. Unfortunately he lives ~500km away.
When I ask my developer colleagues about feedback for my "crappy alpha", I'm just getting totaly bullshit responses like "you need javascript input validation before the user sends his form" despite the real problem I try to resolve.
So I asked serveral of my ~100 developer contacts on different projects, unfortunately feedback was kind of the same.
But only few of them managed to release something in their spare time. So they probably have the same problem as I have.
It's hard to get in contact with people that made it, some of them just tell you "I was lucky" which is cool, but not really helpful - It's easy to say that when you've made it :)
So it sounds like you're convinced you should aim lower, but are having trouble actually doing it.
Oh no, you don't ask for feedback from your colleagues - you get it from people with the problem you're solving. From users. Your fellow developers can't even know if you solved the user problem; the best they can do is point out things like grammatical errors which, as you say, is useless.
EDIT I guess your PHP friend wouldn't have been able to bring over users for his very his first app, and I bet he remembers it vividly. You could email him, or talk on the phone. He's not the only person in the world to have shipped, but you know him, so he's an excellent person to start with. You could visit him. Consider: 500 km vs. 4 weeks. Sounds ridiculous, but if you take this journey, you won't forget his point of view.
I'm not clear on what you mean by "losing faith in the product". Do you mean that you stopped believing that it had any value whatsoever; or that any/enough customers would ever like it; or that you lost faith in your own ability to accomplish it? Or do you just mean that... you ran out of motivation?
The key idea is not that "it takes time", but for it not to take time. In other words, to get something done ASAP. I'm talking like 2 hours, not 2 weeks or 2 months.
esr said to launch a product you need something that (a) runs; and (b) has a promise that it can be turned into something really cool in the near future. It's code + words. Note: this means that the thing that runs is not really cool. [many others also state this idea, but I really like esr's formulation]
For motivation in general (not just for launch), the same thing is true: you want to get something that works ASAP. Fred Brooks says of this style of incremental development: I was stunned by the electrifying effect on team morale of that first picture on the screen, that first running system.
I wrote the first version of my product in 2 hours (though I'd been thinking about it for a couple of weeks; and it took a 9 hour day to write the website). This isn't because I'm some great coder, but because the product was that simple. It wasn't "finished". It took a year before the first sale, and eventually I made enough to retire (for small values of retire).
tl;dr release before it's ready.