A venture builder's take on the the "Why" and "How" to fail quickly for traditional companies.
“Failing fast” has been at the core of wattx, the venture builder I work for, since the very beginning and has influenced how we’ve structured our teams, culture, and processes. We take on traditional companies as clients, complementing their industry expertise with our knowledge of the latest technologies, new skill sets (such as those in the areas of user experience and data science), and new methodologies (including user-driven design and agile prototyping) — all in a fast-paced environment.
But I admit that the “fail fast” mantra can seem as ambiguous and trendy as “driven by artificial intelligence,” “disruptive tech,” and “innovation by design.” While “failing fast” might come more instinctually to a startup that is used to lean structure and can quickly adapt itself and find a product-market-fit, it’s usually not as clear for a 100-year-old business that has a niche product with a majority market share. So, why and how should an older, traditional business adopt the “fail fast” value?
The Why: You’re telling me to fail?
Incremental innovation has been a focus for industrial companies, with many having successful R&D departments. While incremental optimization of your products or services within your core business might be more comfortable and has generated guaranteed outcomes in the past, it won’t anticipate opportunities for new business models, technologies, or data-driven solutions — opportunities that new entrants will certainly take advantage of. To anticipate these key new drivers, you have to start experimenting outside your core. And the “fail fast” mantra can be a guiding philosophy.
Google is creating solutions to predict both the demand and the ability of a homeowner to generate solar energy, while also helping to manage the ensuing transactions. Airbnb and Facebook could leverage their respective user bases and the knowledge about them to purchase carrier mileage from traditional airlines, effectively turning Lufthansa, Emirates and company into commodity logistics providers.
Instead of simply thinking about flying their customers from City A to City B, Lufthansa and Emirates will be forced to think more holistically about their customer: whether it be thinking about the larger mobility value chain (getting Person X from Point A to Point B, where a flight is only one component of that journey) or better anticipating the needs of customers based on their travel priorities and history.
Given the deep expertise of many of these technology-driven traditional companies, they are in a unique position to leverage their knowledge and experiment with new technologies and business models. It’s these traditional manufacturers that will lead development as we enter the Age of Automation (which I argued in my last post). An Age that will require connecting existing infrastructure and machines to become smarter and optimize functionality. A system for quick experimentation and failure will be crucial to accomplishing just that.
The How: Baking Failure into Your Company
Build teams with a flexible mindset
Your team should be small, nimble, and built to adapt to changing and challenging circumstances. It should have a diverse set of experts with complementary skillsets and experience. And each team member should feel confident enough to navigate ambiguity, work autonomously, and be independently driven. While you might have sub-teams that have a “team lead” at the helm, a non-hierarchical approach allows for greater flexibility and for individuals closest to relevant information make decisions quickly.
Nurture a culture of feedback
Give a lot of feedback. And do it frequently. Regular, team-wide retrospectives can provide leadership a high-level understanding as to which new processes are working, which ones aren’t, etc. Requiring upwards feedback to managers encourages transparency for both managers and employees. Encouraging direct communication ensures that information flow occurs, that people feel like they are heard, and that people have the information they need to make the right call — and feel empowered to kill a project when it makes sense. You can also clearly reference culture in your values: “We challenge content, not people.”
Make failure part of the process
Ingrained in your process should be constant validation of problems and proposed solutions. Your processes should enable your team to quickly learn from and move on from failure. Since “Process” warrants more than just a bullet, I’ll dive a bit deeper into the steps of a process that constantly keeps “fail quickly” in mind.
The Process: 3 Phases to Enable Failure as Early as Possible
Say a client approaches us and says, for instance, “We have decades of experience building smoke detectors but we want to expand our core product offering: we’d like to build on our basic fire detector, developing a new one with expanded and smart functionalities and that would actually assist firefighters that arrive with a laser. Can you tell us whether it’s worth pursuing?”
So, the client has identified an idea they want to pursue and wants us to validate it. In order to do so, we’ve defined three phases that are setup to filter projects — and kill the ones that are not likely to succeed as soon as possible.
1. Discovering a Good Problem
“Forget about the lasers for a minute — what is the problem problem you’re trying to solve?”
To start, it’s important to actually validate the problem that this idea solves — because it’s important to confirm the identified problem is, in fact, a problem. This means that you start with a “Discovery” phase, spending time speaking with potential end-users and stakeholders of the product about their pain points. Meanwhile, you also want to understand what is already in the market — are there any competing products already out there? Are there products that solve a similar problem? Or those that solve the same problem in a different way than originally thought of?
At the end of this “Discovery” phase (and this might take a few months), it’s about synthesizing the top findings — is the original problem, indeed, a problem? If not, or if the problem was poorly defined, it means the solution itself is poorly constructed and is largely not set up for success. The top findings from “Discovery” can be translated to opportunity areas and design principles, which will be essential to setting up ideation sessions to come up with informed solutions.
…if the problem was poorly defined, it means the solution itself is poorly constructed and is largely not set up for success.
2. Informing Good Ideas
“Now that we have a problem, how can we create a solution that will actually be desired and purchased by the end user?”
The problems identified during the “Discovery” phase will trigger the next phase, “Ideation.” During “Ideation,” sessions made up of individuals from across the team, from different backgrounds and skillsets, participate to generate ideas and solutions. Following traditional methods of design thinking, and empathizing with the user, these sessions are about generating as many ideas as possible and ensuring divergent thinking.
After these ideation sessions, ideas should be fleshed out into more elaborated concepts, before being evaluated based on criteria relevant to your contexts, such as technical feasibility and market potential, before converging on one (or two or three) solution that is worth prototyping. During this process, ideas are both killed and shelved for later pursuit.
3. Building Adaptive Prototypes
“Now that we have a product idea that users want, let’s make it real and tangible in order to test it in a pilot scenario — and then work out the kinks.”
Of course, prototyping at its core is about building early iterations of technologies, testing, and adapting them based on what didn’t work. Early failings allow engineers and user experience designers to iterate on the product based on learnings. This “agile” method means that at any point the code or wireframe can be tossed out in an effort to ensure that the work going into the MVP is built for the longer term (maintainable, sustainable, and user-approved).
Outside of these phases, two other features might be helpful for your pro-failure operations:
DoD (Do or Die) sessions are what we call regular meetings to present all current project insights and progress with the CEO and CTO. These are important to reflect on the validity of the project, identify pitfalls, and set time-oriented goals (because you can research, cold-call, and prototype forever). A more formal way to challenge ideas, these DoD sessions egg on failure in order to create a more robust product that will survive in the market.
The post-mortem is what we call the report that is written after a project is killed. The report contains a thorough explanation of what worked well, lessons learned, technical capabilities acquired, insights that might be useful for other projects. The example smoke detector idea is actually not too dissimilar from a project we actually killed at wattx. Lesson learned? Heavily regulated industries (like firefighting protocol and equipment, which are managed at the state level) move TOO slow for our model.
wattx: A Hybrid Approach for Traditional Companies
We understand that this kind of “experimentation” will be not only with new technologies but also with new kinds of employees and culture. And for many companies, implementing this sort of change will be like turning a barge. That’s why we at wattx provide services to Mittelstand companies with an appetite for change and experimentation.
We act as an external SWAT team that can move and fail quickly with and for our clients.
We dive deep into research, understanding their customers and stakeholders to identify real problems; these problems prompt vetted solutions, that we then prototype, with agile development, until we reach a pilotable MVP. And in the end, we build technologies that jumpstart their experimentation with a new, vetted business model, product, or startup. But our clients are also in it for the ride, with the chance to familiarize themselves with setting up flexible systems; stay up-to-date on relevant, new technologies; as well as the user-first methodologies that will give them insights they need to lead development in the Age of Automation.
I hope this insight into the process of sustainable failure sheds some light on your own systems and goals. And that you, too, might feel more excited to experiment. If you’re interested in our model or validating an idea your company is considering, give us a shout at firstname.lastname@example.org.