I recently made a list of all the products I've built (in full or in part) since I started working for myself, and there have been at least ten of them. Yet, none of these have gotten significant traction, and most have eventually folded (with the exception of my most recent project, which I'm sure will eventually be a huge success ;-). I have never really done a post-mortem for anything I've built, so I decided to write out a brief description of each, including my take on why it failed. To be fair, other people have successfully executed projects that are very similar to some of my failed products, so I'm not saying that any of these ideas is unworkable. Here they are (in no particular order).
1) Tweedledo
This was a web-based todo list (still live at http://www.tweedledo.com). I built the initial version in late 2009, and added features through the beginning of 2010. This was mostly an experiment that eventually became a semi-useful product (for me at least). The key differentiator from other task lists was that you could use SMS or email to make the item show up on your todo list. I find that I often want to write something down while I'm talking to a friend, and this is a simple way to make it an actionable item. I never really figured out how to get people to use this - I told some friends about it, and while a bunch tried it out, the product didn't seem to be sticky. When coupled with the lack of a reasonable revenue model, I eventually abandoned it. I still use it on occasion to write down my own tasks, although I have found that sticky notes/whiteboards are more useful.
2) InstantQ
This product provided a replacement for the restaurant pagers that alerted patrons when their table was ready. Rather than using a pager, this system notified patrons via a SMS or phone call. We got to the semifinals of the MIT 100K business plan competition with this concept, and were accepted into YCombinator (even though Paul Graham hated the idea). Basically, when we started to talk to restaurants, we realized that most restaurants didn't need it (since they didn't have lines, even at peak times). The ones who had the most demand already used pager systems, and weren't really interested in getting rid of it (even if we were cheaper on a per-unit basis).
Incidentally, at least one company (www.qless.com) has managed to build a business out of a similar product. It turned out that the primary challenge here was building an effective sales and marketing strategy rather than just building technology (which was relatively simple). QLess succeeded by casting a much wider net than just restaurants - they focused on all sorts of businesses with waitlist problems. Our engineering-heavy team wasn't able to make the sales effort that was required for this to succeed. We may have actually given up too soon on this one, although I have no idea as to the actual size of the business opportunity.
3) InstantQ V2
This was our pivot from the original InstantQ product. Paul Graham imagined a dial that restaurants could turn to adjust demand on a real-time basis. What we built was a restaurant marketing platform that sent targeted, time-sensitive promotions to drive demand on off-peak nights. Business were supposed to get email addresses and phone numbers from their customers, and we would then send out promotions on a nightly basis. This was built by the same engineering-heavy team that build the previous product. We gave sales/BD our best effort, overall spending about three to four months trying to market this by going door-to-door at local restaurants. Eventually, we discovered that the willingness to pay was much too low when compared with the amount of time required to close a sale. It can also be difficult to get restaurant patrons to give away their personal information - I think that significant marketing expertise is required to make this work.
After a while, we got tired of selling and gave up, allowing our startup to die. To be fair, there were issues in both my personal life (my father passed away quite suddenly) and my business partner's personal life (his wife got pregnant) that made our arrangement untenable. However, I think that we were fundamentally unable to execute on this idea in the first place. I suspect that this business could have worked if we had tweaked some parameters and assembled a more sales and marketing-heavy team.
4) Rentize
The concept behind this was that you could rent your things to people in your neighborhood. We built a product (in early 2010) that allowed people to list the things they had for rent, with the idea that we would build the other half (allowing people to actually rent those items) once we had a significant inventory of goods in our database. We killed the platform before launch for a number of reasons.
After spending a while thinking about the things that people would rent, we identified a few major categories (tools, party supplies, etc...). We quickly realized most items wouldn't actually rent for all that much on a per-day basis. When you couple this with the fact that the parties involved have to schedule two meetings (one to pick the item up and another to drop the item off), the value proposition seemed pretty bad. We figured that most people wouldn't go through the schlep required to make a few bucks. Even if you ignore this, the amount we could make as a per-item commission would be pretty small.
A few companies appear to have built this concept into a company (eg RentCycle), but they have had to essentially hack the system by focusing on B2B rentals. Businesses usually have a physical location, allowing customers to walk in and pick up/drop off the items (reducing friction). Some rental businesses even provide drop off/pick up services, reducing friction even more. Businesses can also charge more per day for a rental than would a regular person, and typically carry insurance that covers loss or damage (eliminating the need for the marketplace to carry insurance).
5) Wish List
This product was a wish list that allowed people to find the best prices on the things they wanted. Basically, you type in whatever you want, and the product finds the best prices on the Internet. It then sends periodic email updates as prices drop. The problem with this (we found) is that most people don't know exactly what they want to buy. As we did user testing, we realized that people weren't responding terribly well to the product.
Our conclusion was that a search engine wasn't really appropriate, and that a browse-based interface would probably be more effective (since people didn't know exactly what they wanted off the bat, and needed to be guided down a decision tree). To make this feasible, we would have had to narrow down the scope of the product from "everything" to one particular vertical. One of my business partners (the guy who had been working on this the longest and held controlling equity) was unwilling to pivot the concept, leading to a standoff where the other two of us walked out. The product eventually ended up dying as the remaining guy went back to work.
The lessons learned here were more structural than technical (I think that the product could have gone a lot further if there hadn't been irreconcilable differences between the founders). First of all, I learned not to ever do free work "for equity." In this case, I worked for about six weeks without having anything signed, and when I walked out, I got nothing for my efforts. This is not to say that I won't come on as co-founder, but I believe that the initial dating phase should involve a paid contract (I'm willing to be flexible on rate so long as there is a good faith effort). Also, no work happens before the paperwork is signed (I will give people one day of free work as a good faith effort, but that's my limit).
In addition, I learned that I have to be aware of what my business partners are working on at all times. At some point, I kind of realized that I was doing all of the work (building/refining the product), and no one else was really getting anything done. When I am engrossed in coding, it can be challenging to pay attention to the other aspects of the business, but I need to do this.
6) SimplyHours
This was a platform that allowed people to hold open office hours. People could register and list office hours, and other people could come in and schedule them (by providing a phone number or Skype). We got a few VCs to actually use this, and they seemed to respond relatively well (got some reasonable leads). We started to think that this could be used as a marketing platform for service professionals (basically, people would offer open office hours every day or week to bring in new customers).
This idea was abandoned when my partner decided that he wanted to work on something different. I was already in talks with my current business partner to come aboard his startup, so I didn't continue the project alone. The site is no longer live because the domain expired, although I may put it back up at some point, since I think that there could be some potential to make this work.
This mishap only helped to reinforce the "I don't work for free" stance. I'm still friends with the guy I worked on this with, but I believe that he significantly undervalued my work. Basically, I built the whole damned thing, and then he wasn't willing to put in the time to market it (he did put in some time, but less than I spent building it). He now pays for programming talent on an hourly basis.
7) SpeakerGram
This provided a platform to connect speakers and conference organizers. Speakers could put up a profile, and then organizers could use the platform to request engagements. We signed up about 3,000 speakers, including some high-profile people. After running the site for a month or two, we realized that there were two sides to this, the speakers and the conference organizers. In order to succeed, we would have to initially focus on one or the other.
After some debate, we decided to focus primarily on meeting the needs of speakers (our friends at One Clipboard have built a great solution that caters to conference organizers). There were actually two kinds of speakers - the speakers who get too many requests to handle, and the speakers who would like more requests. Serving the latter would primarily involve doing lots of SEO/SEM (which was basically uninteresting to us), so we decided to serve the former. We were already serving Foursquare, who was getting several requests per day, so we used them as the prototype, building out a number of new features. We signed on a few more customers, and were ready to start billing them (at one point we were a week from launch). However, back-of-the-envelope revenue calculations told us what our investors had been saying all along - the market wasn't big enough. We looked at the most popular features in our platform, which led us to the next product offering.
Eventually, we decided to shut the product down because it was taking up too much of our time. As a startup, we have limited resources, and supporting our existing product was detracting us from building the next thing. We decided the honorable thing to do would be to let our customers know we were shutting the product down, and to give them a reasonable amount of time to find a new solution. In the end, we announced our shutdown around the end of December, and shut off new signups at that time. Existing customers were promised support until February 1, and we offered to export data for anyone who requested it. The site is actually still live (http://www.speakergram.com), but we will be taking it down in the next month or so.
8) About/Team/Press
For a small company (and even a large one), managing a website can be a pain in the butt. First of all, you have to build these pages in the first date, and then you have to keep them up to date. Most likely, this requires some sort of content management system or static web pages that are distinct from the company's actual product. In many cases, the engineers are the only ones who can update the about/team/press page, and they are busy doing other things. The result is that most companies have about/team/press pages that are significantly out of date. Ironically, these pages are some of the most frequently viewed on a website. We built a solution that allowed people to easily create and manage a company's about, team, and press pages.
We abandoned this when we were on the verge of launching an MVP (the customer feedback was reasonable given the state of our product). There were some issues with market sizing, but this wasn't really the resulting cause. Essentially, my business partner decided that he wasn't interested in spending his time selling this product, and decided he wanted to do something else instead (something more exciting). We ended up restarting the company, leading to what we're working on right now. It's actually live on the web, although I'm not going to publish the URL because the demo is slightly broken (and I don't have time right now to fix it).
9 & 10) Two Consulting Projects
I can't say much about these since I signed NDAs in both cases, but I built two projects as consulting gigs (one in early 2010, and another in early 2011). The idea in each case was that I might come on full-time if the product took off, but as I learned previously to always charge for my work, they were initially structured as consulting work.
The first project was built for someone who was already a successful offline businessman. It was a great idea with significant revenue potential, but represented a huge departure from the client's existing business. In addition, there were significant regulatory hurdles that we would have needed to clear. I built a working web-based prototype, and delivered it to the customer, but in the end, he never had sufficient time to see this through to launch. I think that his initial vision was too large - he wanted to roll out web and mobile at the same time, but had no idea how big an undertaking it is to even launch one product. I got paid, but I was kind of disappointed because I would have liked this to launch (I think it would be useful to a lot of people).
The second project was built for someone I knew socially who approached me when I had some time to do extra work. I could tell that he or she wasn't serious about this project, but somehow suppressed those concerns (I will write it off to poor judgment). The project quickly spiraled out of control as the client added more and more features to the specification. In the end, the client decided to change his or her mind and work on something completely different, and expected to not pay for any of the work I did. Fortunately I learned my lesson on previous projects, and collected an up-front deposit, so it wasn't a total loss. I ended up spending about twice as many hours on this as we had initially anticipated in the SOW, and collected only a fraction of the contract price. In the end, neither this nor the alternate concept ever launched, and this one hit the deadpool before it went live. I think that it had some potential, but clearly the person I was working with had neither the experience nor skill to pull it off.
My big learning here is that I need to carefully vet all clients, even if I am doing work on a contract basis. If I think that the client isn't serious about launching this or see any other red flags (such as the lack of ability to focus on a single project), I need to run away as quickly as possible. Also, it definitely makes sense to have a lawyer read all contracts before signing.
11) Scaffold
This is the project we're working on right now. No post-mortem yet, since we are destined for incredible success. It's completely different from anything I have worked on before, and I think that it has a huge amount of potential.
Conclusion
I think it's important to pick apart both your successes and your failures. In many cases, you learn a lot more from the failures than from the successes (since, when you fail, you make mistakes that you can learn from and try to avoid the next time). At this point, I've worked on enough projects to see some interesting patterns emerge when I study things at a macro level. It can be difficult to see your flaws when you are deeply engrossed in something, but if you step back, you can a slightly more detached view. While I've pretty much run out of space for this blog post, It is likely that these patterns will be the focus of a future essay.
Find a discussion of this post on Hacker News