Say just about any technology catchphrase or buzzword – agile, AI, big data, Blockchain, the cloud, IoT, augmented reality to virtual reality – and you’re bound to get one of two reactions: ugh or aha. While some get tired of hearing about the hot technology topics of the day, others love to get into theoretical discussions and talk for hours about how these tech trends are the coolest things ever.
Luckily for you, I don’t have hours or enough space in this article to go on and on, but I would love to talk about a popular tech topic: fail fast.
Contrary to how it sounds, fail fast is not about failing. None of us wants to fail. And despite an entire conference for startup founders dedicated to embracing failure, it isn’t what we’re striving for. (Don’t believe me about the conference? FailCon went global (http://thefailcon.com/–see for yourself).
Fail fast is about succeeding, just in a different way. Fail fast is the philosophy that embraces incremental development, testing, review, and change. It doesn’t necessarily make for faster development. It might. But then again, the results can be the opposite. Why? A tech company that embraces fail fast develops a product, service or feature to a certain usable point and releases it to customers for testing. If they’ve met expectations to that point, they can continue, developing to another set point and releasing again for testing. In practice, the process is always linear, even when you fail. Instead of failing and starting over, you fail forward, make your next decision based on the information you now have, and do it more quickly.
Fail fast acknowledges that no matter how much research and investigation you do on a product, service or feature, there will be things that change along the way: A developer has a late, great idea. Another feature interacts badly. Your customer prefers a different functionality. You’ll want to react. You’ll need to possibly pivot to make a change. But you’re going to reflect on what you’ve already learned, improve and fail forward.
Let’s look outside of technology for a minute at other companies or individuals that failed forward (even if they didn’t think of it in these terms):
• A Post-it Note was originally conceived as a bookmark, which it might still be without its “failed ultra-strong adhesive” and great development team.
• Kleenex was originally marketed as a makeup remover (or cold cream kerchief) and became a tissue once women began complaining about their husbands blowing their noses into them.
• Thomas Edison failed 9,000 times before succeeding with the light bulb.
I asked Jason Zubrick, our new CTO who was leading the digital transformation at GameStop before joining defi, about his experiences with fail fast and how the idea impacts traditional technology organizations.
“Historically, teams would gather requirements, go off in opposite directions, build their interpretation of what the requirements describe, and come together at the last second to hopefully give their business users some semblance of what they originally asked for. This is the project methodology, and from my tone you can probably guess that I’m not a strong believer in project-based delivery. Project methodology works well for roads and buildings, but provides very little value in software deliverables.
“Project methodology doesn’t allow for miscommunication or rapidly changing requirements without injecting severe disruption. Using the approach, projects typically take a long time to come to fruition, which equates to business sponsors not seeing any value until the project is complete. Projects can’t fail. Projects are too risky and expensive. Fail fast doesn’t relate to projects.
“Fail fast is about delivering the smallest increment of value to your customer or business user in the shortest amount of time. However, failing fast won’t work without the proper feedback loops. Feedback is about knowing whether the customer or company is getting value from the feature. Does the customer like it and are we making money from them liking it? The “fast” in fail fast is not only about determining whether to pivot on a feature or continuing to build on an existing feature, but also about being able to quickly deliver on decisions from the feedback.
“Without feedback loops and without teams structured and tooled to execute quickly, fail fast has a strong probability of devolving into just failing. The two success factors in fail fast: 1) build in feedback and 2) empower your teams.”
How does fail fast impact you or your organization?
If you’re dependent on a technology company to develop features, products and services that keep your business in operation, you should know how they go about the process. Are you going to suffer long waits and then not get exactly what you want in the end? Will you get a chance to test things out along the way? Change your mind? Offer new insight once you’ve had an opportunity to see the thing in action?
If you’re a technology leader and your boss or business counterpart says we need to “fail fast,” first confirm they’re talking about the fail fast philosophy, and then I recommend, at the very minimum, you do the research, set aside the idea of failure as a bad thing, negate the stress of setting a long-term goal that doesn’t allow you the flexibility of determining the route to success, and see what it would take to transform your team and your entire organization, mindset and all.
Failing fast does not mean you go for short-term craziness to hit a short-term goal. I personally love speed. I think quickly. I respond quickly. I work quickly when I’m being tactical. But when it comes to strategy, I slow things down quite a bit. I prepare to practice the fail fast philosophy of calm, intelligent iteration, and of building, learning, testing, and tweaking. Restarting sooner than later. Thinking. Adjusting. Transforming a business by moving it forward.