Lessons relearned

The idea for the Business of Software conference first popped into my head in March this year. We’ve now got 2 weeks to go until the conference starts. This is the second business I’ve started (I also co-founded Red Gate Software). Although the businesses are clearly very different, there are some interesting parallels. Here are some lessons I’ve relearned:

Having a good product isn’t enough
Even if you have an excellent product, you can’t just drop it into the marketplace and expect people to find it, and buy it. If you build a better mousetrap, the world will not beat a path to your door. Of course, you can’t market a dog: a good product is necessary, but not sufficient. Whatever your product – whether it’s software or a conference – you need to spend a lot of time, thought, effort and, less importantly, money on getting people to notice it.

Try twenty small things; not one big thing
If you don’t know what you’re doing, you can never tell what’s going to work and what’s not. Rather than intellectualising a lot, selecting the single best way of doing things, and then doing it, it’s best just to get out there and try things. Some things will work, some things will fail, but slowly you’ll start to turn the flywheel. We tried many things to market the conference: print ads, Google ads, web ads, asking speakers to publicise the conference, sofware giveaways, a free ebook, blog articles, themed fortune cookies and speaker interviews. In the end, the most successful bit of marketing was when Joel Spolsky mentioned an advert we’d run in San Jose airport. There’s no way we could have predicted that: we tried enough and eventually we got lucky.

Listen to other people
Getting other people’s perspectives, and their advice, is always useful. I’m fortunate enough to have had advice – and help – from some great people.

Ignore other people
Many people – often the same people – will tell you that what you want to do can’t be done; it’s a dumb idea; it will never work. Listen to them, but do it anyway.

Minimize the downside
Minimizing the downside is as important as maximizing the upside: only risk as deep as your pockets go. For the conference, that meant guaranteeing the minimum number of hotel rooms I could, even though that limited the potential upside. For Red Gate, it meant only spending the money we had, and carrying on contracting for my previous job for the first 6 months after start-up.

Maximize the downside
Although you don’t want to bankrupt yourself, your pride is less valuable. Putting yourself in a position where failure means humiliation, or embarrassment at least, is a powerful motivator. With Red Gate, running it as a Micro ISV for an hour or two a day in parallel with the day job would have been easy. If I failed, nobody would notice, and my world would have continued much as before. By quitting the day job and publicly announcing my intentions to friends, family and colleagues I removed the easy exit.

At some point, you need to take the plunge. You’re never going to have enough evidence or data to predict that what you’re going to do is going to work. Think about it, but then just do it. For the conference, that point came when we had about 30 attendees. The speakers were asking if the conference was going ahead and others were questioning its viability. Backing down and cancelling would have been easy. It was scary, but I decided to go ahead, knowing that there was a good chance that I wouldn’t get enough sign-ups, that the conference would flop, and that I’d make a tit of myself. Paradoxically, increasing the chance of looking like an idiot on failure actually decreased the overall chance of looking like an idiot.

I’ll be expanding on some of these points in more depth over the next couple of weeks, and I’ll add some more lessons learned once the conference is over. I hope to see you in San Jose.

Enjoyed this post? Subscribe to our RSS feed or subscribe by e-mail