Anyone who builds products is familiar with the mad dash at the end of a project to add those last few features. When you’re running out of time it’s usually because you have more to add than your schedule allows.
But the more I learn about designing products, the more excited I get about the mad dash at the end to remove features.
This means killing work that’s been done and is technically ready to ship. It’s hard to do because it’s already done, but done doesn’t mean it’s right.
Killing stuff right before it ships is the sign of a healthy product and development process. It means you’re always questioning, reconsidering, and reevaluating. It never ever hurts to ask why.
What made sense two months ago may not make sense two weeks before launch. Other features may have taken its place. Newer ideas may have replaced earlier ideas. And sometimes it just takes time and use to realize that feature you built just isn’t scratching the itch you thought it would.
We’re just a few weeks out from the Basecamp Next launch. Last week we killed two features we’d already built and were initially pretty excited about. But they just weren’t right, they weren’t doing the job. And they were introducing new problems that we just didn’t feel good about.
Remember that people get used to the way things are. Even things that are broken or complicated become things some customers want to protect from change because they’re familiar with the intricacies of how those things work. That’s why it’s so costly to let bad designs slip into products.
Just like you shouldn’t let sunk cost determine future decisions, don’t let sunk design trick you into keeping something in your product because you already put the work in. If it’s non-essential, take it out, think it over, and invest the time post launch to make it right.