In “Back to Future”, Marty finally convinces the Doc Brown of 1955 to help him get back to 1985 by telling him he knows how he got that bump on his head. Having heard the story from Doc in 1985, Marty tells him how he was running an experiment and hit his head, giving Doc an epiphany for the “flux capacitor”, which is what makes time travel possible (or at least three movies possible).

Back to the future (1985) clip

What Doc Brown in Back to the Future comically describes is the inspirational moment. A retelling of the apple falling on Newton’s head. I am glad that hitting your head to generate ideas never caught on – Doc Brown and Isaac Newton are the only two examples I can think of. However, the light bulb going off, eurika, shower philosophizing, head slapping epiphany* seems to be a natural part of our cognitive processes. I assume we all have these experiences, yet it is not always easy to know what impact such moments will, or should, have during our development process.

The development process and best practices give us a reliable model to map the journey we should take from product inception to final delivery. Having been applied so many times, for so many years, we could assume that there is little room for surprise, or for the process to fail us. After all these years, from the industrial revolution onwards, shouldn’t we expect the design and development process to be so refined that it would always lead us to create commercially successful products, and presumably, the outcomes we intend? 

Yet, not all products succeed at their stated benefits once deployed to users. Dissecting where, along the chain events, the product development process failed can be difficult. What are the root causes? Could some activities have been done differently? Were the wrong people in the room at critical decision points? Did the needs of the users/marketplace shift under our feet mid-stride? Did we misinterpret the needs? Likely there is no one thing that goes wrong. Perhaps an idea was assumed to be worthwhile, and momentum grew right from the beginning, such that stakeholders and other team members with their own distinct responsibilities didn’t have the time, energy, or expertise to spot a flaw in the concept, to employ the full methods that would have revealed such a flaw, or worse yet, to trust their instinct that they did spot a flaw. 

Doggedly pursuing an idea can be dangerous. Companies can risk a lot of time and money assuming they have the right idea, assuming they know their customers. Confirmation bias is a strong force. Teams might develop a skewed perspective on feedback from potential users, and even their own teammates, on the desirability, performance, and feasibility of a new product idea. Such biases are propagated, perhaps, in proportion to the leverage those that have the bias hold within the organization. We can imagine a strong-willed CEO envisioning a product idea and aligning all the necessary resources to pursue this vision. The other people on the team might be looking sideways at each other, “this is not a good idea, is it?”, but are not able to convince their boss to change course. I don’t want to name names, but George Lucas and Jar Jar Binks? We shouldn’t feel bad, given Lucas’ galactic success overall. Moreover, it’s informative to consider that the opposite dynamic was occurring while George Lucas was struggling to get the original Star Wars not only completed, but developed to the standard of his unique vision, despite the doubts and concerns from some of the production’s stakeholders. 

Such stories are not unique. Upon introspection, moments of inspiration (ill-timed, or well-timed depending on your point of view) might be more like the rule than the exception to it. Similarly, devotion to an idea by one or a few people in an organization is often the linchpin of ultimate success, even when those people are seriously doubted by others, even when they have good reasons. How do you defend ideas that are illogical, even risky? On the other hand, what good is a “process” if it does not embrace, and facilitate such opportunities for inspiration, from the potential users, the core team, or extended team? 

So, which is it:

1. Do products fail because we did not adhere to our process as strictly as we should have and thereby did not place our biases in check? Or, 
2. Do products fail because we did adhere to our processes so strictly that we create a bias against ill-timed, divergent thinking that could yield the deciding innovation, or inconvenient truth upon which success turns? 

Let’s assume there is not one answer or globally applicable rule as to why a particular project fails, completely or partially. That said, most of this discussion will be looking at the benefits of #2 above and integration into #1 above. As stated earlier, given the amount of time and experience we have with the design process working well for us, it is not my intent to dismantle it. The nagging feeling that there was something wrong with the design process was in large part due to this inclination for the methods and diagrams to imply a high degree of linearity, and thereby risk biasing us against non-linear thinking. We are not victims of a poorly thought out process. If anything, we might be victims of a very successful teaching method (i.e., there had to be an easy way to communicate the basic steps and methods we should employ). But, ask anyone who has worked in product development for any length of time and they are likely to admit how often things do not go as planned despite our best efforts. It is because of this, not in spite of it, that we have to fight the urge to dismiss, to ignore, to devalue points of view, evidence, and alternative solutions because they come too soon, too late, from the “wrong” people, or question the “right” people. Whether you are the one who believes so strongly you work harder than anyone else, or you are the teammate who is skeptical, perhaps we should not burden ourselves with the notion that our “process” is intended to manage this dynamic at all.  If we rely on our processes for what they are good at, generally speaking, generating evidence, reducing uncertainty, operationalizing validity, assuring quality, and not assume they “generate” innovation, we can free ourselves up to move between non-linear and linear thinking as needed. Hopefully you can count on your design process, your SOP’s, your quality process, etc. to tell you if an idea is ultimately viable. However, this assumes you give those ideas a chance to face that gauntlet in the first place. 

Perhaps the biggest challenge is taking the time to communicate and persist when there are no “rules“ in place for managing inspiration. Whatever the inspiration is, whatever you saw that no one else did, whatever instinct seems to be raising a red flag, despite not quite knowing why, wherever or whenever it comes, take it seriously. It could be the start of something incredible, it could be the difference between success and failure. The following are a few stories of messy processes, happy accidents, and inexplicable insights.

If reading in order, next is Four design stories.