How do you know when to stop the tweaking and release a product? The short answer: You don't.
Jason Fried is the co-founder and president of 37signals.
You've been working on something for months. You've gone through dozens of iterations, countless tweaks, tons of testing. You're pleased with the results but can't quite let go: Is it really ready for its debut?
Good question. In fact, this is one of the hardest questions an entrepreneur can face—because it is almost impossible to answer.
Sure, some things are more obviously done than others. Food, for example, needs to be taken out of the oven if you expect anyone to want to eat it. But I founded a software business, not a restaurant.
In general, here's how software firms test for doneness. At the outset of a project, the company drafts something called a functional specifications document, or spec. The spec clearly documents what the product requires in order to be considered shippable. Once the items on the spec have been checked off, the product is ready to go.
This method works. But I've never much liked it, mostly because it requires you to define the finished product months or even years in advance. So we've always taken a different approach. We define, in general terms, the problems we're trying to solve and begin by designing around those. We don't try to predict the product's final form, or even its full feature set. The only thing we know is where to begin.
And that means we never really know where to end. In fact, in theory, a software project could go on indefinitely.
For a while, it seemed as if that was going to happen with the redesign of Basecamp, 37signals's project-management tool and our best-selling product. When we started, back in March 2011, a January 2012 launch seemed reasonable.
But as that date approached, we began to feel uneasy. The new Basecamp looked good and dealt with most of the key problems we had set out to resolve. But it didn't feel done. The problem was, none of us could articulate exactly why.
Different people had different ideas about what needed to be added—or cut—before the product went live. Most of these were good ideas. But if we tried to do them all, the new Basecamp wouldn't come out for another year. And that wasn't an option.
I briefly considered putting on my dictator's hat and simply declaring when the project would be done. But that seemed wrong. I wanted all of us to feel good about the product. And besides, releasing something new to the world should be a source of confidence and pride, not anxiety attacks.
As our January deadline came and went, we decided to seek the counsel of our best adviser. Fortunately, that adviser is Amazon.com founder Jeff Bezos, who bought a small stake in 37signals in 2006. We scheduled a call and bent his ear for about an hour, painstakingly detailing why we were so stymied.
Jeff responded with a simple question: What was the single most important feature that we all felt was missing? That was easy. We all knew that the product needed a calendar. In fact, we'd already planned to add one—after the launch. Then Jeff asked us about the second most important feature we all thought was missing. The fog broke: There wasn't a single No. 2. There were a bunch of smaller things that some of us agreed on, but none were nearly as important as the calendar. Suddenly, the answer was obvious. Build the calendar, and Basecamp would be done—or done enough to release.
In retrospect, it seems so obvious. But that's so often the case with business decisions. We were all too close to the project to see. In any case, we learned an important lesson. And the product debuted in March.