The Importance of Quick and Dirty
At 37signals, we've been building software for nearly 10 years. We've created 20-some apps. Some, such as Basecamp, Highrise, and Campfire, are things we sell to the public. But the majority are internal tools we use to run our own business.
Do something over and over, and chances are, you'll get better at it. We certainly have. The software we make today is better than anything we've done in the past.
Our standards have gotten higher, too. When we work on something, we pay careful attention to the details and take the time to polish every little thing until it's just right. As a result, 37signals is known for a focus on quality, and we take that reputation very seriously.
It turns out that that's a problem.
You heard me right: An obsessive focus on quality can be a bad thing.
Let me explain. We recently began exploring an idea for a new software product. We're pretty sure that the idea is good and the market is there. But of course, we had to test our hunches before jumping in.
So one of our designers, Jonas Downey, and I began mocking up some concepts. For six weeks, we sketched out a bunch of ideas for the product until we finally felt we had a great idea.
Jonas and I are designers. We have basic programming skills (he's way better at it than me), but both of us can take a concept only so far before we need to bring in a real programmer. We tapped Jeffrey Hardy, who has been with 37signals for five years and helped build some of our most important products. His vast experience with everything we do makes him an especially great person to work with on new products.
All of us were excited and working hard, but a week later, we had almost nothing to show for our effort. Nearly two months had passed since we had set out to test our idea, and we still had no idea if it would work.
We work on software every day. What happened?
What happened was we forgot we were just building a quick-and-dirty demo for ourselves. We didn't need to worry if the software could handle thousands of concurrent users. It didn't matter how people would sign up or how much the product would cost. We didn't need to worry about whether something was called a "response" or an "answer" or a "comment." Later on, perhaps, we could spend hours debating which one was right. But for now, any word would do.
It's hard to imagine this kind of thing happening at 37signals 10 years ago. Back then, we had no problem making something quick and dirty. When we were messing around with an idea, we didn't care about quality or being perfect. We just wanted to see if it would work. To be sure, that's a low bar. But low is just the right height when exploring something brand new.
A decade ago, we were young and lean. We were bursting with ideas and eager to test them as quickly as possible. If they worked, then we'd invest the time to make them perfect.
We also were green. And that was a blessing. Because we didn't know what we were doing, we simply did whatever we had to do to make things work. We scrapped and stumbled and more or less willed ideas into existence. It's what nearly every start-up does, and it's a valuable skill--even when your business is as old as mine is. In fact, especially when your business is as old as mine is.
But at 37signals, we've become so consumed with producing high-quality products that we've forgotten how to do quick and dirty. You might say that our "just-make-the-damn-thing-as-quickly-as-possible" muscle has atrophied. If you don't use it, you lose it. We've lost it.
It was a great wake-up call. A company gets better at the things it practices. Practice quality, and you get better at quality. But quality takes time, so by working solely on quality, you end up losing something else that's important--speed.
I suspect we're not the only company dealing with this problem. In fact, I bet that obsessing about quality too early in the creative process prevents a lot of good ideas from taking shape. As businesses grow, all sorts of things that once were done on the fly--including creating new products--have a way of becoming bureaucratized. As a result, the wrong sets of pressures are brought to bear. Doubts, deadlines, resource planning...all of this stuff is essential. But only later on. Fretting about such matters at the outset only gets in the way.
It's not an issue just for mature businesses. I casually advise a few young companies, and I'm always surprised when I see them overthinking simple problems, adding too much structure too early, and trying to get formal too soon. Start-ups should embrace their scrappiness, not rush to toss it aside. The ability to run with scissors is a blessing, not a curse.
I talked this over with our programmer, Jeffrey, and he instantly saw what I meant. It had been a long time since he'd whipped something up quickly without worrying about its long-term viability, he admitted. So long that he'd nearly forgotten how to do it.
With all this in mind, the three of us regrouped. Fortunately, Jeffrey had a vacation coming up in three days. We decided that we would see if this idea was viable before he left.
We cobbled something together. It was crude and inelegant and something we never would release to the public. But it was good enough for us to determine that our idea was worth exploring. After using the quick-and-dirty demo internally for a couple of weeks, I think we are onto something big. So now it's time to dig in and do it right.
We intend to repeat this pattern moving forward. In many ways, we're returning to our roots: quick, dirty, scrappy, and impatient up front; quality obsessed, careful, and thoughtful later on.