If you're an author, the moment comes when you hand off the final draft and the book is published.
If you make music, you eventually stop altering the mix and cycling through cover photos. You finish the album and release it.
The book might have a convoluted plot. Maybe the album could use more insightful lyrics.
But they're done.
Most software, though, is never done.
SaaS introduced the expectation that apps should continuously evolve and grow. The web made a steady stream of updates possible. It's hard to remember that it wasn't always that way.
At 37signals, we just released Campfire for group chat. You pay for it once and own it for life.
Campfire is done. We made a great app, culled and polished it inside and out, then shipped 1.0. Does group chat need to change constantly? Do you want it to?
Done doesn't mean unsupported. We've shipped a number of fixes and improvements since its debut. Think of these like errata after a book is published.
We're not dreaming up features, though. Maybe that day will come, but that will be a different Campfire, like the 2nd edition of a book.
Our love of finished software started long before ONCE. Basecamp Classic and Basecamp 2 are done — still running, still supported, and still loved by customers, but not a single new feature for years.
Building new versions of Basecamp from the ground up means we’re not constrained by past decisions. It also means that customers don’t have to change until they’re ready.
It’s not just products. We aspire to finish features, too.
Since our projects are fixed time, variable scope, we work on a new feature for a few weeks and then ship it. Often, there’s a lot left on the cutting room floor — scopes we trimmed to stay within the appetite and clever ideas that came up along the way.
What’s on the cutting room floor is there for a reason. Like any artistic endeavor, software gets better through subtraction, too. If it wasn’t essential then, we don’t assume it’s essential later.
After we ship, we let it go. We don't look at adoption rates, we just let people use it in the real world. It never fails that the things we hated to cut aren't even missed a few months later.
Features have a cost. Change has a cost. The cost is often worth it, but not always.
Customers experience the cost, but so do the people working on the product. If you build an addition on your house, the costs don't end when you pay the last contractor. You still have to pay to heat and cool it. You still have to pay taxes on the additional square footage. And the next time you want to make a change, you have fewer options than before. It's the same with software.
We overestimate how much users want change. The people who take the time to share what's missing or the friction that gets in their way absolutely do. Investors and board members and the people who chose the OKRs do.
Many users, though, love the product just as it is. They see the quirks and shortcomings, but for them, familiarity and stability are strengths. They want the software to get out of their way. They want to be able to rely on it. There's something addictive about a "What's new!" screen every few days, but can you think of a non-digital tool you wish changed every time you use it?
Be clear about what you're creating and why. Use all of your intuition, experience, and skills to build the best version of it.
Then, consider it done.
If you make music, you eventually stop altering the mix and cycling through cover photos. You finish the album and release it.
The book might have a convoluted plot. Maybe the album could use more insightful lyrics.
But they're done.
Most software, though, is never done.
SaaS introduced the expectation that apps should continuously evolve and grow. The web made a steady stream of updates possible. It's hard to remember that it wasn't always that way.
At 37signals, we just released Campfire for group chat. You pay for it once and own it for life.
Campfire is done. We made a great app, culled and polished it inside and out, then shipped 1.0. Does group chat need to change constantly? Do you want it to?
Done doesn't mean unsupported. We've shipped a number of fixes and improvements since its debut. Think of these like errata after a book is published.
We're not dreaming up features, though. Maybe that day will come, but that will be a different Campfire, like the 2nd edition of a book.
Our love of finished software started long before ONCE. Basecamp Classic and Basecamp 2 are done — still running, still supported, and still loved by customers, but not a single new feature for years.
Building new versions of Basecamp from the ground up means we’re not constrained by past decisions. It also means that customers don’t have to change until they’re ready.
It’s not just products. We aspire to finish features, too.
Since our projects are fixed time, variable scope, we work on a new feature for a few weeks and then ship it. Often, there’s a lot left on the cutting room floor — scopes we trimmed to stay within the appetite and clever ideas that came up along the way.
What’s on the cutting room floor is there for a reason. Like any artistic endeavor, software gets better through subtraction, too. If it wasn’t essential then, we don’t assume it’s essential later.
After we ship, we let it go. We don't look at adoption rates, we just let people use it in the real world. It never fails that the things we hated to cut aren't even missed a few months later.
Features have a cost. Change has a cost. The cost is often worth it, but not always.
Customers experience the cost, but so do the people working on the product. If you build an addition on your house, the costs don't end when you pay the last contractor. You still have to pay to heat and cool it. You still have to pay taxes on the additional square footage. And the next time you want to make a change, you have fewer options than before. It's the same with software.
We overestimate how much users want change. The people who take the time to share what's missing or the friction that gets in their way absolutely do. Investors and board members and the people who chose the OKRs do.
Many users, though, love the product just as it is. They see the quirks and shortcomings, but for them, familiarity and stability are strengths. They want the software to get out of their way. They want to be able to rely on it. There's something addictive about a "What's new!" screen every few days, but can you think of a non-digital tool you wish changed every time you use it?
Be clear about what you're creating and why. Use all of your intuition, experience, and skills to build the best version of it.
Then, consider it done.