One of the most important Basecamp features I ever designed never actually made it into the product.
Back in 2009, I designed the due dates for To-dos feature in Basecamp Classic (looking back it’s hard to believe Basecamp was without due dates on To-dos for its first 5 years!). Shortly after we thought it might be useful to see those due dates on the two-week calendar that appears at the top of your Basecamp Dashboard.
It seemed pretty straightforward. We’d need to design a way to display any dated to-dos alongside your milestones while making them visually distinct. We’d need to figure out what to do if you had too many to reasonably show at once as well as what happens when you click one. A very typical feature brief. We spent about a week going back-and-forth until we came up with a pretty nice solution.
Everyone felt good about the direction so former Basecamper, Josh Peek, and I set off to build it out and got everything ready to ship—all that was left was to get a thumbs-up and run a database migration. So we let the rest of the team know we were ready and then… *crickets*.
At first I remember being a little worried. Did they miss my message? Was it no good? Was anyone paying attention? Then I realized: it didn’t matter. You see, there wasn’t a manager with crossed arms tapping their foot; no due date; no client itching for it; no schedule pressuring us to move on to the next thing. There was no external pressure at all and the feature wasn’t making a case for itself.
So now what? We’d done everything right. We had an idea for a useful addition to Basecamp and so we worked hard to come up with a good, solid design. We felt good enough about the feature to fully implement it. This is what we do in product, development, right? We come up with ideas for making the product better, we design, implement, test and… ship. I mean, we did all that work? Shipping is the period on the sentence of product development! But we didn’t ship this and it’s still not in Basecamp Classic today.
Why not?
Everyone at 37signals knew we’d been working on this (we were a very small team), we used Basecamp all day, every day and nobody ever said, “Man, I really would have liked to see that to-do on the calendar…when’s that finally coming?”. Customers weren’t asking for it either. As time went by, the feature branch was still in my local Git repo, but nobody ever mentioned it again.
It was good, probably useful, it might have even made some customers really happy and we spent weeks working on it. I believe most companies would have shipped it so why didn’t we?
Every feature has hidden costs. Some are worth the cost—sometimes many times over—but others only drag your app into the red. One more thing on the screen you can click, one more option, another setting, more decisions for users to make (Kathy Sierra calls this cognitive load). Your app gets slower and customers notice it feels slower. Designers have to juggle more pieces. Development gets more complex, difficult, and time-consuming with every new piece you bolt-on. That’s a lot to ask of a feature that’s only fine.
Shipping != Success
I think about this feature often. It’s probably the most memorable one I’ve worked on because it never shipped. It reminds me that what’s important isn’t how much time I’ve spent or how hard I’ve worked because those things have no bearing on its value to customers. Sometimes you have to get real before you can tell if your design is working, sometimes you’ve got to build it out. It’s a clear sign of a healthy process when you can say “no” and move on at any stage. It takes maturity to not count it as a failure but see value in the lesson. It says a lot about a company that values more than sunk cost.
If projects that ship are the only ones that are deemed successful then you’ve set the bar pretty low. Who’s going to ever risk trying a radical idea, invent a new technique, imagine an original interaction, or try anything at all that isn’t a sure thing if there is any chance they’ll be deemed a failure? Who will risk missing a deadline, going over budget, or trying something that ultimately just doesn’t work? If your goal is always to ship, you’ll probably do a lot of that but it won’t be your best work. Besides, who wants to use a product where every idea ships?
Because everything happened in Basecamp I was able to go back and review this nearly 7 year old project, read the entire conversation, and find all my design mock-ups. If you can’t do this with your work, maybe you should be using Basecamp, too. Your first one is free when you sign-up today.
