Innovation engineering — Dial back the crazy

Last week's post talked about generating ideas to tackle your challenge or solve your problem. That gave us a lot of ideas, most of which are probably crazy, impossible, and beyond imagination. This week we’ll focus on filtering out the actual impossible ones and find the space between crazy and impossible, where the actual innovation happens.

This is part of the Innovation engineering blog series.

After any creative session, most people will likely be jumping to start shooting down impossible ideas. Or the ones they perceive as impossible, anyway. This is where the danger of falling into the same old solutions lies. Try stimulating your team to see the possibilities, rather than the impossibilities. Simply dropping ideas under the guise of “it’s impossible” will kill your creative process, and prevent actual innovation. So how do you prevent eliminating potential innovation, and still filter out the garbage?

Kill your darlings, but not really

In the first step of the process, we drafted requirements. These requirements are your only criterium for eliminating ideas at this point. Only drop an idea if it is verified that the idea will not meet the requirements. Spoiler alert, most ideas will not be eliminated using this method. At this point, you just don’t have enough data to definitively eliminate an idea. Some ideas will very clearly not meet requirements at this point. These will usually involve things that are simply not physically possible.

Research time

The ideas from the brainstorming session will not be defined enough to be able to eliminate or validate ideas. Researching the ideas through desk research will provide you with enough information to eliminate the bulk of the ideas. Desk research involves anything from an extensive internet search to gathering expert opinions. Anything that doesn’t involve building anything. Solid desk research will limit the time and material investment during the next step.

On to the next step

Eliminating ideas based on requirements is a short, but very necessary step. The next step is prototyping and testing, these steps will provide more data. You can use this data to either validate or eliminate your ideas. More on that in the next post!

If you would like my help with your development process, please reach out in the comments below.




Huibert is an innovation engineer, prototyper, maker, 3D printing nerd. He thinks anyone can be an inventor with the right mix of attitude and time investment.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Musings about Istio with mTLS

What is the difference between frontend and backend development?

Running GitHub Actions locally using nektos/act

A free public API providing Cash Flow Forecasting for Funds in Illiquid Alternative Asset Classes

ToDo App in Flutter

Kubernetes — Static Pod

Serverless “Hello World” in AWS

Breaking down the Monolith. Considering Serverless!

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Huibert H

Huibert H

Huibert is an innovation engineer, prototyper, maker, 3D printing nerd. He thinks anyone can be an inventor with the right mix of attitude and time investment.

More from Medium

Fall in love with the problem, not the solution?

Amazon This: Building a Business Case for AI in Ecommerce (+ Sample Executive Summary)

How can custom software solutions provide superior customer service in the healthcare industry?

Minimum Viable Product does not equal Minimum Product.