I admire the pursuit of perfection. Think of athletes, artists, and musicians who dedicate their lives to continual self-improvement—to becoming experts.
One thing every expert knows is that striving for perfection is a process. You have to be willing to fall short, learn, and try again.
You wouldn’t refuse to run in a race until you could win the Boston Marathon. And you wouldn’t refuse to play a concert until you were good enough to fill Carnegie Hall.
So why would you wait to launch a new software product until it has every single feature you might need?
The Problem with the Big Bang
Software projects are big investments with a lot riding on them. And most people’s (understandable) impulse is to aim for perfection on their first release. They see only one chance to get it right—the initial product launch.
I call this the Big Bang approach. You want Version 1.0 of your software to blow everyone’s socks off. To satisfy every business and user need. To make you millions of dollars, and maybe even win a few awards. You want it to have everything.
Unfortunately, the Big Bang is almost always a bust. No matter how carefully you plan, problems arise and slow things down, stretching out the timeline. Then new needs emerge, requiring new features and expanding the project plan. Designs must be revised over and over, creating delays and rework for developers and testers.
Eventually, these loops of change become stacked on other loops of change. The longer it takes for the software to be released, the bigger the to-do list becomes. Deadlines get pushed back again. Pressure mounts. You’ve invested thousands, and you still don’t have anything to show for it. By trying to satisfy everyone, you’ve ended up satisfying no one.
Perfection, as the old proverb says, has become the enemy of the good.
Releasing Early & Often
How do you avoid this fate? You release a small, functional version of your software and get people using it. Then you improve it gradually over time with frequent, small enhancements.
Don’t believe me? Facebook did it. Amazon does it. So does Google. They all have success with their big ideas because they made small software releases a key part of their business approach. This has given them a strategic market advantage over their competition.
For some software projects, this approach might mean setting up a predictable monthly schedule for releases. Perhaps you can do smaller updates on a web project every two weeks. It’s even possible to release an almost-constant stream of micro changes multiple times a day. It all depends on your situation and your goals.
Why Small, Frequent Releases are Better
1. They force you to focus and create value early.
There are always more ideas than money. Starting with a small release will force you to decide which ideas/functions/features are the most valuable. You’ll have to answer big questions like: Who’s the ideal user of this software? What functions will be the most valuable to them?
When you start with the things that matter the most, you can have confidence that every dollar you spend on Version 1.0 will be worthwhile. And when you share V1 with management—after a few months, not several years—you’ll be able to inspire confidence. “Look what we did with only 25% of the budget; users already love it. Here’s a list of what we’re going to add with the next 25%.”
2. They let you test ideas and reduce waste.
You may think you know exactly what your users need, but you’re wrong. Doing extended development on an unreleased software product is building a tower of hope on a foundation of assumptions. And it guarantees that some of the functions you build—likely costing thousands of dollars—will be frustrating or unnecessary to most of your users.
Good research and design will reduce your risk. But there’s no substitute for testing your product in the wild. So release a small, focused V1 and start gathering feedback. What do people love about it? What do they need to make their experience better? Which features are frustrating or difficult to use?
Moving forward, you can use your software as a platform for testing your ideas. When you add something new, start small. Build just enough to test the idea. Then collect feedback. If it’s a bust, you haven’t lost much. And if it’s valuable, your next release can focus on the improvements/additions that your users want the most.
When you look back over your project, you’ll see that most of your investment was spent on valuable things and that everything you built taught you something and refined your project plan.
Ever heard of Burbn? It was a location-based mobile app for networking with other bourbon lovers, with a complex set of features including user check-ins and photo sharing. When its creators did user research, they learned that fans’ favorite feature was the photo sharing, so they scrapped everything else. After months of experimenting and prototyping, Burbn became Instagram—one of the most popular apps in the world. If Burbn’s founders had kept to a rigid schedule and feature list, they would have ignored what their fans wanted and missed an incredible opportunity.
3. They make bug-free releases much easier.
During a Big Bang project, a large team develops multiple features simultaneously. Because each feature interacts with several other parts of the app—including other unfinished features—it’s extremely difficult to make sure they work together properly. This creates bugs and inconsistent visual design, which lead to repeated rounds of QA testing. The longer it takes to release the software, the more complex this cycle becomes.
Small releases, on the other hand, can use the continuous integration/continuous deployment approach, which allows small changes to be deployed constantly. By testing and releasing small changes, the risk involved in each change is smaller.
HBR recently told the story of Athenahealth, which used to batch up large software updates that its customers would dread receiving. Athenahealth moved to a continuous delivery of small changes for small audiences, which improved customer satisfaction and gave a boost to its internal team morale.
4. They give you more control over cost.
Big Bang projects have large, expensive teams with multiple developers and complex layers of testing and management. This, combined with their long release cycles, means accumulated costs are often not recognized until the dollar amounts have become very large. Opportunities to make decisions and manage these costs are fewer and far between. And the feeling that real value is being delivered doesn’t happen until the end of the project.
Small releases, however, give the team greater control over the value delivered and the dollars spent. With each small release, the impact of the decisions is visible through the feedback and learning. Value is felt soon and accumulates rapidly over time. And ideas that the market doens’t want are removed from the project before too much is invested in developing them.
5. They make the team happier.
When a software team is working toward a big, important release, pressure is high. Everyone is sprinting toward the finish line, crushing bugs and creating features with a highly-focused effort. But like sprinting, it’s impossible to sustain this for long.
I’ve seen large corporate project teams operate in this mindset for months at a time while trying to catch up or meet an important milestone. The team takes heroic measures to hit the date. In the beginning, the backlog of work grows shorter. But eventually, energy and momentum begin to fade, and problems or setbacks become demoralizing. The team grows tired, and quality issues begin to appear. Progress slows. The milestone due date becomes impossible to attain.
People are not physically or mentally capable of operating at maximum effort all the time.
The small releases mindset is more like running a marathon. Marathon runners are great at focusing on the mile in front of them. They manage a sustinable level of effort, aware of the long road ahead.
Small releases allow developers to keep a sustainable marathon pace (with occasional, short sprints before releases). This has two benefits:
- Creating software is a mental exercise. Developers who aren’t sprinting every day will be happier and less stressed. And their work will be of a higher quality.
- It helps makers maintain psychological momentum. Each small release is a success, a milestone achieved. Developers are always building on previous work, creating momentum to push for the next milestone. This is why some teams and companies always seem to be winning.
The Power of Software Is Flexibility
One of the greatest things about software is that it’s, well… “soft.” You can change it easily. If you can manage that change process, you can find success.
Releasing software isn’t about getting it perfect. It’s about getting it out and into the hands of people, using small releases to dramatically reduce risk, and adjusting your product as you get valuable feedback.