Don't let this happen to you - lessons from a failed side project

It was August. It was a rare warm day in Seattle and I was optimistic. I was itching to make something, to get back into programming. I’d been too business and not enough geek at my day job at Microsoft. I didn’t know that seven months later I’d be angry at a good friend.

We were sitting on bench overlooking the Ballard docks in the sun, and my friend was describing a great idea he had for using software to improve people’s lives. He already ran a reasonably successful blog about happiness and living well, so I took him seriously. I was interested.

Mistake #1: Starting a project with unfettered optimism

Steve Blank warns that startups are not small versions of large companies. Large companies execute on a proven system, and startups are searching for a viable business model. I should have approached this potential new business with healthy skepticism: what are the biggest risks? how might we efficiently verify assumptions for the business?

The next step was meeting with his partner on the project, a good friend of his. We met in a U District restaurant. They were showing me mockups of the app they’d been thinking about for a while now. It led users through a daily set of steps to maintain mindfulness. This would then lead to better, happier lives. They were excited, and I was caught up in it. They told me they had spoken to many others about this, sometimes shown the same mockups I was seeing, and people were positive. I was in. Let’s do this!

Mistake #2: No customer empathy

None of us asked the right questions of our potential customers, so we didn’t deeply understand them. They were friends, acquaintances, and they were primed to like anything we created. We needed real empathy: What does their day look like? How do they decide where to spend their time and money? Without that, we speculated about what exactly users wanted and needed. I was at a particular disadvantage, because I hadn’t been part of the conversations that did happen.

With initial customer conversations complete, it was time to build a prototype! I started enthusiastically learning Ruby on Rails. I was impressed at Rails’ database migrations. At Microsoft, even their cutting edge developer tools had no support for changing the database schema. And with ActiveRecord I didn’t have to type SQL directly! I was excited, I was learning, I was making progress. I was deep in the tech and the prototype wasn’t ready for customers yet.

Mistake #3: Too focused on the technology

I have a Computer Science degree, and I love writing code. I love making things. And after years of managing projects at Microsoft, it was great to jump in again. But in startups or business in general, that’s not the hard part. Its the customers! It’s the market! It’s building a viable business system, and technology is only a part of that. At the very least we should have been continuing customer conversations, not waiting for the prototype to be “ready.”

It was November. I was trying to make progress as fast as I could while learning Rails, but I could tell that my co-founders were getting frustrated with me. And I was frustrated as well: what were they doing? We still didn’t have facebook or twitter accounts, and the blog hadn’t been created yet. Shouldn’t they be doing something? There’s no way they could be spending as much time on this project as I am, right?

Mistake #4: One dev, two business guys, no clear expectations

It’s not automatically a problem to start with this ratio, as long as it’s clear what each person will be doing. Unless these are your business guys. There’s a lot of research (customer, market, competitive) to be done in an early startup, but my guys were waiting for a prototype so we could start the next phase of the project. I should have brought this up early and loudly. But it was easier to focus on the code.

It was December. We had just finalized the name. I’d been working hard for three months, working down our backlog. We hadn’t released to anyone yet. We had pushed our launch party out into early January. That was when we’d demo the product and open the beta.

Mistake #5: High-fidelity big release

Our big launch party/release combo came directly from the Visual Studio playbook. Just having a backlog was not Agile enough - we should have released to customers often. Better yet, we could have read The Lean Startup and defined and tested a concierge minimum viable product with zero code.

The launch party arrived and it was all smiles. Our friends came. Their friends came. All of them said they’d use DayTender. I had pushed really hard the previous few days to get ready for that night, and it seemed to have paid off. I was on a high.

The next week things started to cool off. Fewer and fewer folks signed up or came back. Week after week we debated about which features would make the site worthwhile. We pushed out several point releases over the two months, but that flood of excited users never materialized.

Mistake #6: More features never get you out of a death spiral

It’s a classic mistake to add features to get user engagement. If you didn’t understand users well enough to build something useful for them in the first place, that pattern is unlikely to change. And it’s highly unlikely that you’ll get automatic viral growth just because your product is so good. Starting something new is hard. We weren’t beating the streets. We should have been marketing heavily or meeting with existing and potential customers.

That spring was painful. I was really frustrated with all the effort I had spent and was spending on point releases. And I saw no change in the metrics. We could see every step that our few users were taking in our app, and we argued about what it all meant.

I wanted to regroup and start customer interviews again. My partners in the project wanted to launch a cool new app. They told me that this time it was viral. This time it would work. I was extremely skeptical.

Mistake #7: I never asked the right questions of my co-founders

Yes, one of them was my friend but I’d never worked closely with him on a project before. I should have gone over hypothetical situations with them. Understood their core goals for the project. Agreed on what success looks like. Failure, too. We should have read through The Founder’s Dilemmas together.

I ended up cutting things off with these guys. I definitely wasn’t signed up for another project. I spent less time with my friend for a while. It was uncomfortable with them, and I was a bit angry about how all if it played out. I tried to temper that with the knowledge that I got myself into the situation.

The beginning

This taste left me wanting more of the startup world. What could I do better next time? I love solving problems, and figuring out how to get a business off the ground seemed like a pretty big problem. Not long after all of this I left Microsoft. Now, at LIFFFT we’re always getting better at techniques like customer development and lean startup and we help other companies do the same.

As you pursue side projects, remember to take a balanced approach. It’s exciting! It’s fun! You’re following your dream! But learn from my mistakes and protect yourself from heartbreak.