How to ‘move fast and break things’
LinkedIn co-founder Reid Hoffman interviewed Facebook CEO Mark Zuckerberg and others on a recent episode of his excellent podcast
Masters of Scale
. The discussion centered on the need to launch products quickly: testing, learning and iterating, based on feedback from real users in real time. Zuckerberg says one of the biggest reasons Facebook scaled as quickly as it did was because the company lived by the mantra “move fast and break things.” By this, he meant constantly getting new products and iterations in market, seeing what the users liked and didn’t like, and making changes based on user feedback and data. Hoffman adds that if you aren’t at least a little bit embarrassed about your product release then you probably waited too long to get it out there.
That said, a lot of our clients are established companies, often with a publishing DNA. These companies traditionally have cultural resistance to the concept of testing and iterating in public. And this isn’t surprising. They may have only distributed their product once a year and if there were a mistake it could be fatal to an entire revenue cycle. Processes, jobs, and even company mores were designed to keep mistakes from happening. Established companies also have a lot more to lose from a brand perspective if a launch goes poorly. It is one thing for a start-up to launch a product without a clear sense of how they would support 10X growth. It is quite another for an established player to have a similar experience while risking existing revenue and customer goodwill. No wonder these companies often become risk-averse over time.
Even at a fast-moving, digitally native company like Facebook, the ethos of “move fast and break things” has tempered over time. A new mantra, “move fast with a stable infrastructure”—while not nearly as sexy as the old battle cry—better reflects the needs of a company with billions of users and a market cap north of $400 billion.
What can you do if you work at a company that is risk averse and hesitant to launch “unfinished” or “imperfect” products? Here are a few tips gleaned from our work and client experience.
Fast doesn’t mean unstructured.
It’s important to speak with users and prospective users all the way through the design and implementation phases, and this requires structure, coordination and planning. I don’t know how many times I have heard that a company didn’t have time to engage with users before and during a launch and I have yet to see that end well. Planning for this process upfront and building the structure that is needed to support it is well worth the effort. This definitely gets easier as the team gets comfortable with the cadence.
Set clear goals and timelines.
Project goals and timelines should be clear, transparent and over-communicated, even if all the details of each product feature or iteration are not known. We usually have regular check-ins with the exec or steering team so they see that there is a method to the “madness” of rapid product iteration and design. These check-ins also help evangelize the culture of rapid development and testing throughout the organization.
New take on “mistakes.”
This is a tough one for a lot of established companies. When you are launching beta products and testing in real-time with users, you will make mistakes—a lot of them. Sometimes a feature that seemed really important will turn out to be just nice to have. Or a navigation flow that made sense internally will cause the majority of users to bail in confusion. The whole point of rapid product development is to build hypotheses (hopefully based on user input), test those hypotheses, adjust the product based on user feedback and data and repeat. You’ll make mistakes as you go, but you’ll always learn and improve the product. A lot of time needs to be spent preparing senior leadership to embrace mistakes as invaluable learning rather than problems to be avoided.
Getting established companies comfortable with rapid digital product development isn’t easy, and is much more about the people and culture than the technology. Please let us know if your company has found a particularly innovative way to make it happen.
