Learning From Failure

What ever happened to Groupthink?

I get asked that periodically. If you don't know, Groupthink was the name I attached to the startup I was trying to build more than a year ago. I started with an ambitious, overly public plan, and an announcement that I was going to launch in 30 days. What I didn't say was that I had a huge, gigantic plan, and the planned 30-day launch was just the start.

If you've been reading my blog, you know the first thing that happened (I didn't launch in 30 days) and you probably know the second thing that happened (I didn't ever launch it), but now I'll make it official: it's dead and it's been dead for quite a while. I learned a ton in the process and I think my future endeavors will be stronger as a result, but I figure I might as well let everybody else learn as well.

So what was I building?

Put simply, I was building a coordination services company for small- and medium-sized businesses. I had what I thought was a pretty cool idea -- an incredibly simple, easy-to-use scripting language for coordination activities combined with a highly stateful backend system that let people build coordination functionality into their applications without having to know anything about how it all worked or even running a server. You could use the same scripts to send and receive emails, provide web forms, make phone calls, send SMS text messages, even contact somebody through XMPP chat. The system could work 24/7 with any application, even one written in Visual Basic in Microsoft Access, running on a single PC sitting in the corner of a small business that gets turned off every night. The system was designed so that anybody from an expert to a casual spare-time developer could use it, with the sweet spot being VARs and ISVs delivering custom applications to specific types of businesses. These VARs and ISVs don't have the experience (or servers) to do these things on their own, but Groupthink would have allowed them to add a wide range of coordination activities very quickly. It's not a perfect analogy, but think of it as Varolii for everybody else. And I envisioned that Varolii (a Seattle company) or one of their competitors, or possibly one of the giants like Google or Microsoft, would be the eventual acquirer.

I knew that I couldn't launch a platform without a product, so I decided I needed to build one. Plus, I wanted to keep the larger vision secret. After all, I was still figuring parts of it out. So, I made my first mistake -- I picked a first product that I personally wanted to have -- a group task manager I called Groupthink Projects. When people asked me how it was better than Microsoft Project or Liquid Planner, I said "they don't make phone calls." Unfortunately, my little demo problem was just a bit too big. I spent time on Ajax UI that it needed but that wasn't critical to my overall vision. Because I'd publicly said I was going to launch in 30 days, I ended up cutting some of the critical features (including mobile access) in order to try to make my deadline. Then, I got sick for a week and lost another week to moving my father-in-law into an Alzheimer's facility (which I talked about at Ignite Seattle 6). When you only have a month, two lost weeks is huge. By this point, I also knew that I'd pick the wrong first product, but I kept going. In retrospect, it's pretty obvious I shouldn't have, but, at the time, I felt I ought to make my deadline and shipping would be good for me.

The deadline came and went, without me launching. I started spending much more time on the backend -- the important stuff. I took time out to build a couple demo apps, including a version of Eliza that I built in a day. Talking with your psychiatrist via email or text messages didn't seem so compelling, so I added voice recognition functionality to my backend just so you could just talk to Eliza. It worked quite well, except for the huge delays caused by telephony provider Twilio's incredibly slow voice recognition.

The second first app

Although I never announced it, I decided to completely abandon the Projects app and concentrate only on the platform, but I still needed a first app. When I'd been talking with people, the coordination problem that resonated with everyone was the scheduling problem, and I had identified a very solid market in restaurant schedule coordination. I knew from field research I'd done in visiting restaurants that it was a huge problem, that paper, computer-based, and even web-based scheduling system hadn't solved the coordination problem of rescheduling people and dealing with missed shifts. You should see some of the workarounds restaurants use! So, I latched onto this as my new first product.

Dumb move. It was even bigger than the first problem and I had no passion for it. Worse, everybody thought I had morphed into a scheduling company or a restaurant software company. And all the potential investors I talked to wanted to see traction there first. Yup, traction in the first app which was really just to demo the platform. And I didn't succeed in finding any customers for the platform. Truth be told, I didn't try hard enough to get those customers -- after all, I'm not a sales guy.

The skills you have vs. the skills you need

And that relates to the final problem. I had picked a problem where I couldn't succeed without an early business partner, because way too many of those skills. I advise people all the time that they should pick problems that needs the skills they already have, yet here I'd picked a problem where about half of the skills I needed at the beginning were those I didn't have. Without a business person with marketing and sales skills, I couldn't get traction that would matter to investors.

I still really like the concept I had and I think it's inevitable that somebody will build a platform like it. I learned a ton from failing. I've moved on and I'm trying to make sure that I don't make the same mistakes next time around.

I'll write about that next.