Thomas Goetz Why “good enough” often isn’t
Sure, you’re going to fix it later—if you can get to later
GOOD ENOUGH” MAY BE the most invoked cliché of startup life— especially in tech. You hear variations on this theme constantly: Perfect is the enemy of done; move fast and break things; launch it now and fix it later. Like a lot of things in startup land, it’s a cliché because it’s true.
What you don’t hear is that, for most of us, next year never comes. Many startups are just gone. Out of business. Their “good enough” wasn’t good enough, it turned out. And for those exceptional others, they’re so busy fanning the flames of success that there’s no time to go back and fix things.
In software, there’s a notion of “technical debt”—the debt a company accumulates by using sloppy, get-us-there code in the short term that really should be rewritten at some point. It’s like roofing a house with a tarpaulin and duct tape instead of proper shingles. And this notion goes beyond code; most startup products accumulate design debt that should be remedied as soon as possible.
But in the era of minimum viable products— MVPs, products that aren’t fully baked but work well enough to acquire some growth and traction— pausing everything to repay your debt is exceptionally hard to do. It’s like getting that new roof on your house: You know you really need to do it, but since there’s no immediately visible benefit, it’s easily postponed.
At our startup, Iodine, later is now. Two and a half years after launching Iodine.com, we’re finally getting around to fixing a few things that have bothered us since day one. It’s a rare opportunity to reassess and rebuild, with the purpose of making things a little less minimally viable. This isn’t merely adding more features to the product. We need to be wary of feature bloat— adding functions and tools that people will never discover or use. Rather, it’s about understanding how customers are actually engaging with our product, and making that experience more efficient and rewarding. In our case, since Iodine provides health information online, we can do some of this by analyzing our web traffic through Google Analytics, some through services like UserTesting.com, and some with old-fashioned focus groups, people you invite in and then watch as they click away.
At times, this takes a thick skin. We’ve found that a few of our favorite features—like some fancy natural language processing to personalize information—are, sadly, rarely used or too darn confusing. Out they go. Other discoveries are happier, as we’ve identified needs that we haven’t yet addressed—such as better drug-interaction data. These aren’t always easy fixes. Slack, the team messaging company, knew its users wanted threaded conversations, but took a while to figure out how to build that function productively before finally launching it a few months ago.
We’ve had to withstand the temptation to fix everything at once. Instead, we’ve put different invisible, technical improvements into different releases and pushed them out in small batches or individually—to determine if they are, in fact, making things better. We’re careful to pinpoint a target variable and measure the difference to know whether each change is meaningful.
We’re not gunning for a big reveal, as we did with our launch. This time, the aim is a steady and frankly sometimes ponderous iteration. Not every industry gets second chances. You wouldn’t buy a car that’s merely an MVP. Maybe, though, we should try to build our apps more like autos are built.