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.
Jesse
on 13 Feb 12Pure gold right there. It’s tough to do. So tough to let go of those sunk costs (or designs/features).
Anonymous Coward
on 13 Feb 12@37signals
Any thought about renaming “Basecamp Next” to something else?
The name “Next” suggests to customers to migrate off Basecamp (legacy) over to this new product.
Are you afraid Next will cannibalize your legacy Basecamp business … and result in net-zero new sales?
Colin8ch
on 13 Feb 12Thanks Jason- Interesting timing for this post, we made a few tough feature removals in our public launch last week for merchee.com
Being really excited about building the “coolest” bells and whistles doesn’t trump user feedback- if they don’t use it, don’t understand it or don’t see the value of it in the beta, then take it out.
Turki Fahad
on 13 Feb 12Totally been there :)
I was reading “Getting Real” and we were less than a month to launch our startup edintity.com and the book only added to what my gut was telling me “We have to kill some of our already done ready to launch features!”
The development team were like “Your kidding?” Its hard but I knew it was the right decision because the assumption that features are better is totally wrong, what is right is that you need to focus on the core of what your solving and leave the features out of it.
Such a decision for our case made what we are trying to solve pop up more than what the features would have done.
I rather have the cake (the core) any day than the fancy candles (features)
Thanks :) Turki Fahad Founder of edintity.com
Darcy Fitzpatrick
on 13 Feb 12This is how the film and television industry works to a tee.
The writer puts a structure in place, full of feature requests.
The director will change some of those features in light of how they play out on the screen, and even add in a few extra features that they were inspired to do in the process.
THEN the editor takes all that hard work, and does the really hard work of cutting. Editing is all about peeling away all the work the writer and director did until you have that exquisitely realized final piece. No doubt, it will be minus several features the writer and director thought they wanted at the time, but will most likely agree at this final stage that the finished product is better off without them.
Justin Reese
on 13 Feb 12@Darcy: That is so apt, and it can be so hard to do. I remember watching our nearly-completed short film, turning to my partner and saying “okay, what if we lose the narration and couch scenes?” This meant tossing an entire meta-layer of the narrative, scrapping 10-20% of our run time, telling our (volunteer) cast that a whole day of sacrificial shooting was wasted, and putting uncertain faith in the audience. Ended up being a clear win, but it was a hard decision when staring at all the work you were about to throw away.
So: don’t let a short-sighted decision in the past jack up the future.
Alan
on 13 Feb 12“Killing stuff right before it ships is the sign of a healthy product and development process. “
?
Your process needs to be revamped. How about:
1) Better planning at the beginning. E.g. Underplanning your features…ya know… all that MVP stuff.
2) Have faster feedback loops so you’re not waiting to cut features at the end. Setup communication channels so everyone is always asking…’does this make sense’ instead of waiting till the end.
At the end if you’re figuring out what you product should look like…that is bad, bad news.
JF
on 13 Feb 12Alan: This isn’t about planning, it’s about using. And it’s not about turning something fat into something lean, it’s about turning something lean into something even trimmer.
As Darcy said above, it’s all about editing. Sometimes you have to cut the things you made to make the things you’re left with much better. It’s why artists often record far more tracks than make it on the album. You just don’t know what’s going to work until you hear/use it all together.
Ryan
on 13 Feb 12Alan, if you have access to a crystal ball that we don’t know about, let us know. We find it hard to predict the future, so we often have to build things and try them out in order to accurately judge their value.
Darcy Fitzpatrick
on 13 Feb 12@Justin Reese
Good on you for making the tough but right call. I’ve been faced with the “but we spent half a day and thousands of dollars on that scene” dilemma before where the scene just isn’t working, doesn’t fit.
The first, normal reaction is feeling beholden to everyone who worked on that scene to keep it. But then you realize, they, like you, only want the best possible final product to shine through. They’d be far less happy seeing their hard work ruining the movie than they would seeing its absence contributing to its success.
@Alan Despite the fact that I agree with @JF and @Ryan, it’s true that sometimes a little more forethought can save you a lot of expensive trimming. In the case of the movie scene I mentioned above, if I’d been less precious during the writing stage I would have noticed that scene was all needless exposition and interrupted the flow from the previous scene to what came next. While my ego prevented me from seeing that at the time, the experience of having to pay for it later taught me a valuable lesson, so in a sense it was worth it.
Keep making the same mistake like that again and again and then you know you’ve got a problem.
Tom G
on 13 Feb 12I have a great name for your new version: Basecamp
Alan
on 13 Feb 12@ Ryan & JF I appreciate the follow up guys – but I’m still seeing contradictions in what 37Signals has promoted in the past and what is outlined here. I’m still a bit confused.
@JF The ‘lean -> even trimmer’ argument still sounds to me that more was built/planned than was needed… if in the end you found out you could trim your product, then you realized you didn’t build your MVP – right? Which leads to more questions: Was the research, planning or customer engagement done incorrectly?
@Ryan Using UX to determine value seems a bit backwards doesn’t it? I would argue that UX is used as a competitive advantage to enhance a pre-determined value.
My last company used Basecamp so I’ll use it as an example:
Value = Teams always share files. Basecamp MUST have file sharing to compete.
Competitive Advantage (UX) = Our file sharing is very easy, fast and integrates perfect with rest of app. This is the part where the ‘feels right’ comes in.
In this example, no amount of ‘trying it out’ will ever make the pre-determined value (teams share files) change. If in the end 37signals decided…’you know file sharing doesn’t feel right’...then it wasn’t critical to the product.
Perhaps we’re getting into semantics or talking about similar but different things.
JF
on 13 Feb 12Alan: Yes, more was built than needed. Same with a movie. Same with an album. Same with anything creative. You toss out a lot of work. That’s not wrong, it’s right.
It’s the editing that makes it great, not being perfect on every decision up front or along the way. You have to see it all in the end, and evaluate its performance by using it over an extended period of time, to make the right calls in the end. Calling what’s in/out up front is great for broad strokes and big pictures, but nothing makes better calls than real-world actual use.
I don’t know enough about the details of the MVP movement, but if it ultimately suggests that extensive research and planning up front can substitute for building, using, and evaluating the real thing, then I’m not much a fan.
GeeIWonder
on 14 Feb 12Agree—except with the ‘creative’ qualifier. It follows thus that learning from ‘mistakes’ (if you are honest enough to acknowledge them as such) is not such a bad thing after all.
Richard Newton
on 14 Feb 12As da Vinci said, “simplicity is the ultimate sophistication.” or Chanel, who once said “before leaving the house, a lady should look in the mirror and remove one accessory.”
Tim
on 14 Feb 12@ Alan, JF
Jason you’re not wrong – I think MVP is being misused here. I’m a big advocate of your methodology (getting real, rework, defensive design) and MVP – they co exist. I used them together all the time.
Get a small data set together to test a hypothesis then build. Evaluate. Iterate. Very simple. Add features but make every feature fight to earn its place.
In my last MVP – a coffee of the month subscription service – I got some data from a survey, built the MVP then started removing two products that didn’t feel right (as you describe) – no amount of planning could have seen that (my customers asked for it) – so where does that leave Alan? Sure thrashing early is necessary but so is building.
Ryan
on 15 Feb 12We don’t see it that way. I would suggest reframing it. I think of UX as simply consumption—what it’s like to be on the receiving end. All of the value of a product is in the consumption, whether you call it “UX” or not.
So think of it like we have to consume what we made in order to judge whether it is as valuable as we had hoped. Maybe that’s clearer.
JF
on 15 Feb 12@GIW “It follows thus that learning from ‘mistakes’ (if you are honest enough to acknowledge them as such) is not such a bad thing after all.”
Steps on the way to get to the final design/idea/product aren’t mistakes. Likewise, designs you throw out aren’t mistakes, they help shape the final design. They are the building materials of design.
Des Traynor
on 15 Feb 12But But, only 9 years ago, in 2003, you said something that vaguely contradicts what you’re saying today in 2012, a mere 9 years later.
How dare you mildly adjust your opinion of software development over the course of a decade. What a disgrace.
:)
I am being facetious, it just irritates me how often people are outraged if a post here on a 20 person blog contradicts anything from the previous 8 years. People change. Perspectives change. How they built BC Next doesn’t have to be an exact replica of how they build BCC.
They’re a different company now, they’re bigger, better known, richer, more to lose, more to gain.
The Project Management space isn’t where it was in 2004 when Basecamp launched. The table stakes are way different. We’re not going to be blown away by AJAX and the yellow fade technique, so unsurprisingly they’ve had to push the boat out a bit to see what works, and now they’re cutting back what doesn’t.
It’s working for them too, it’s a great piece of work.
Gerard Kelly
on 15 Feb 12Removing a feature is definitely better than releasing a half baked feature (I think 37s covered this in Rework under something like “Make half a product not a half assed product” or something.
The company I’m currently with had spent a week implementing functionality before I joined that was originally scrapped but brought up again. The implementation was awkward, non-intuitive and needed a rework. The argument came down to “yeah its not a great experience but its already written”. I’m glad to say we decided to scrap the old code and go back to the drawing board to make sure we get it right.
I think such a review should be made after every feature completion – just like Jason has said here.
FriscoCO
on 18 Feb 12Going back to the original article, it’s always best to release the absolute best product that you can, even if it requires throwing away hours worth of work for a mediocre product. As with any creative process, sometimes those small, finishing edits can be exactly what makes your product shine. And without deleting those unnecessary details, things can seem too bogged down, or like you’re trying too hard. Thanks for bringing up part of the process that’s usually ignored! Frisco Colorado Real Estate
This discussion is closed.