How many times have you sat in a conference room, sifting every last detail of the proposal? And how many times have you spent hours (or weeks) building consensus? Oh, and how many times must an executive approve before they call it a plan? The answer, my friend, is not blowing in the wind. But I bet it is blowing your budget. And draining your profits. And frustrating everyone no end.
The Tyranny of Doing It Right
What causes seemingly sane people to work this hard to get every last thing right before trying something new? Many reasons are possible, but two dysfunctional corporate cultures head the list.
In some corporate cultures, the herd mentality rides supreme. “Don’t attract undue attention.” “Be a team player.” Yes, the competition picks off another member of your herd every day, but the herd survives by sticking together.
In other corporate cultures, whenever a project fails, the “blame hunt” begins. Someone must be scapegoated. If you work at a place where people get fired for making mistakes, but no one gets fired for bumbling along with the status quo, it’s no wonder you spend hour after hour in that conference room. It had better be right, whatever you do. And, the more people in the conference room, the less likely you will be the one blamed if it all goes wrong. So you can hide in the herd at the same time that you tirelessly go over the plan one more time for any “showstoppers.”
Your company may even suffer from both of these cultures. And, the bigger the crowd, the safer you’ll feel, which is why some big companies can be so conformist. Any company can break out of this mold—yours can, too. But it has to start with you. Fight the fears that stop you from trying something or from being different. There’s a better way.
The Freedom of Doing It Wrong
Do it wrong quickly.
No, not on purpose. You’re not setting out to do it wrong. You’re setting out to do the best thing you can, just like always, except you’re just not going to obsess about it in one huge departmental group grope to wring every last problem out before you even start.
Instead, you take your best shot at it. You do it wrong, quickly. You know that it will be wrong—but by the way, many of those projects you obsessed over were wrong, too. Oh, a few were really good, but most of them missed the mark, at least somewhat. A few were wildly off, despite all those meetings.
Now, if this was the end of the advice, you’d have learned something. You’d probably do projects that weren’t quite as good as the ones you used to do, but you’d do them faster and cheaper, which would be good. But there’s more.
If you know that you’re doing the project wrong—you just know it—then you will undoubtedly do the project a bit differently than if everyone sat around arguing until they reached consensus. Why? Because it is really embarrassing to tell your execs that this project that you planned for six months and that everyone agreed to might be wrong. It could miss the mark. Despite how much we spent, and all the smart people who worked on it, and how hard everyone worked, we might lay an egg. You can’t get people to work that hard for that long and defend the plan that many times unless they’ve talked themselves into it. Your team really has convinced itself that this will work.
But if you haven’t spent all your time convincing each other how smart you are, if you are in fact sure that this project will miss the mark in some ways—perhaps major ways—then you will take a different approach. Instead of indulging in the groupthink that everything will be OK, you will instead spend your time thinking about what might go wrong. And asking yourself, “And if that goes wrong, what will we do about it?”
What Happens After You Do It Wrong?
You fix it, that’s what.
Do it wrong quickly, then fix it.
It turns out that it is frequently much cheaper to do it wrong quickly, figure out the few things that are actually wrong, and just fix them, rather than over-engineering it so that nothing goes wrong. But you’ll gain much more than cheaper projects—your organization will do more projects, both because they are cheaper (so more projects can return their investment) and because you suddenly have time to do experimental projects—that’s the “quickly” part. But, it’s even better than that. Because you fix the things that actually go wrong, more of your projects end up being successful, not because you were brilliant out of the gate, but because you kept tweaking each project until it was good.
The key question, though, is how you know what parts of each project are wrong. The answer is found in your metrics.
If you know that some things will be wrong, then you will build early warning systems. You’ll make sure that you can measure everything that could go wrong so that you’ll know as soon as it happens. And you’ll be prepared to respond. You’ll expect some things to go wrong and you’ll be ready to correct them. You’ll build your projects so that you see what is broken, and then adapt to use alternatives that might work better. And then you’ll keep trying them until you lurch into the right answer for each one.
Take an example. Suppose you are changing the home page of your Web site. You could spend months of expensive testing, showing test subjects different alternatives, and then choose the one that tests best. And when you do, you will undoubtedly find out that part of the design did not work that well, just because you can’t test everything up front.
But suppose, instead, you did only the amount of user testing required to avert disaster—just enough to be sure that you aren’t changing your home page to something really dopey. And then you instrumented your site so that every link on the home page, every piece of content, every image is measured. Which ones get higher clickthrough rates? Which ones get higher conversion rates? Keep those and change the rest to something else and measure them again. Change them every day until you have weeded out the things that don’t work and kept those that do.
With user testing, you not only find out something did not work, but you found out why, which is useful. But measuring what happens every day on your site is important, too. Which project would you rather run? The one with scads of user testing that doesn’t measure clicks after the fact, or the one that measures and adapts every day? The heavily-tested project might launch with a better home page than its alternative, but the metrics-laden project would eventually surpass it just by experimenting. And the metrics-happy project might have launched months sooner and cost a lot less, too.
Now, don’t take this to the extreme. Sometime risk mitigation is important, even critical. You can’t do every project wrong quickly. Who would want to take a plane’s first flight where they did it wrong quickly? But redesigning your home page does not have the same danger as a plane crash, and we should not run that project as though it does. Resist treating every project like it has to be perfect on Day 1, and start treating your Web site as an experiment that you make a little better every day.
