Innovation and Necessity

So many people want “innovation.” It’s almost — or maybe it is — a buzzword. Something people say they want but have no idea how to attain it. Innovation doesn’t just magically appear from thin air. No, if you want innovation, you must desire something and a solution must be necessary.

Let me back up a second. Several weeks ago, my company had an ‘innovation workshop’ where we were given a general direction and told to come up with something. Our team was the only team to really come up with anything significantly innovative, and it was driven by a single need or pain point. From there we went with an ‘anything goes’ attitude to fulfill that need and backtrack from there.

The remainder of this blog post has been floating around in my head for quite some time, but this little story was the first time I ever attempted to apply it in a team setting. This approach to innovation is how I ended up building the PHP Dapr SDK, Swytch Framework, and Durable PHP. One thing to keep in mind: you don’t need the whole team’s buy-in. This is simply a template of questions and reasoning… the rest simply requires some open-mindedness.


Every innovation on earth doesn’t magically appear from thin air. Every innovation is driven by a necessity, a need to exist. From this necessity, an infinite number of projects can be borne.

This necessity can be anything: “I want to sit on my couch and have the groceries come to me” to “I want to write React-like components in PHP.” They grow from a want into a necessity and it must be treated as such. It starts with the simplest of questions: “What is something our coworkers|employees|customers|customer’s customers|friends tell us they want? and maybe we’ve ignored them because we can’t deliver it to them?”

You’ll get some pie-in-the sky responses, to be sure. Then you have to ask, “ok, so if we solved that problem, what would happen?” Maybe you’d have the world throwing money at you, or you’d get to actually use some bit of software. Who knows, the point is to pick one. Any one of them.

Then make solving it a necessity.

Solving the Problem

This is important: anything goes. You probably can’t solve world hunger, but maybe you can open a soup kitchen, arrange deliveries of goods via drone, invent a new crop, hire homeless people, or who knows! The point is, anything goes. Don’t hold back and keep iterating. Maybe hiring homeless people sounds interesting, so you start thinking about how that might work, how you might set up a small housing project for them or something, so they can shower. Then you might think about what you’d do with a random assortment of employees, what kind of work they would do. Maybe you could contract them out to other people…

I’m literally just making this up as I type them, but you should get the idea. Anything goes, but start iterating towards actual execution, making it more and more realistic as you go. Each problem or roadblock you run into must become a necessity to resolve and keep resolving them.

Also, feel free to ignore the existence of a problem if it is unresolvable at the moment. For example, in my example above, “creating a housing project” is an unresolvable problem while we are sitting here trying to solve world hunger.

Allow me to elaborate:

If someone were to stop the discussion with the question: “How would a housing project work?” Then you absolutely must think about whether or not it is a “side-quest” and then not take it. In other words, once the problem is solved, do any of the other problems lend towards solving our core problem? If no, you answer with, “Let’s pretend that the problem is solved because it could be solved in other ways if doing that is a dead end. Solving it now is just an implementation detail or a distraction from our core problem.” Redirect the conversation back to the core problem. Momentum is important.

However, if our problem were something more like “how can we get homeless people off the street” then maybe this is a more valid side quest. In that case, your goal is to help them find a place to live, not food to eat.


At some point, you’ll have a pretty good mental picture of what the project looks like. Everyone will have a different picture, but that is okay (and probably for the best) during this next phase. Now, we need to discuss the repercussions of introducing our “innovative idea” to the world.

Does it actually solve any part of our original necessity? Probably not, to be honest, and this is okay. What’s more important is whether you think people will use it. If you don’t believe people will use it, then start over. Are there any unforeseen capabilities now that you have a new product? Can this new product drive new sales channels? Would you use the new product?

If any of the answers are yes, it is probably worth building a prototype.

A Prototype

The next day, create a commercial, write a blog post, whatever, about this new product. Just try to sell it to yourself. In the hype of dreaming, sometimes really bad ideas can sound like good ones. If it still sounds like a good idea, then do it.

Build something simple, with no side quests. Iterate, iterate, iterate.


This is more-or-less the format I use when I get bored and want to create something the Earth has never seen before. It works, for the most part. It isn’t perfect, by any stretch of the imagination, but sometimes you get something pretty cool. Actually, most of the time you get something pretty innovative … but whether you want to actually build it, is a whole different story.

Want an inside scoop?

Check out PHP Shenanigans for only €5/mo or €30/yr