There has been a lot of attention and talk of late on the process and practice of innovation. The topic is not new, and tomes have been written by people in ivory towers all the way to people with practical chops and the scars to show for it.
As someone who’s perennially curious, and always interested in finding better ways to do things, whether through “innovation”, or “entrepreneurship” or otherwise, I’ve been studying and testing various approaches starting with “The Lean Startup” all the way to more recent methods.
And I have always stumbled because of limited resources, not being a “disruptive innovator”, or simply because I was looking to find a sustainable solution to a problem outside of an entrepreneurial construct.
My attention was caught late last summer when I stumbled across a new book thanks to Amazon’s all-knowing recommendation engine. “Innovating: A doer’s manifesto”, by Luis Perez-Breva, Ph.D., intrigued me on sight. The last eight months of testing the process have proven that the approach more than delivers.
It’s early days yet, but my experience has shown me that I have learned a lot more from this process about the problem, its environment, the right solution and everything else, than I have from any other approach I’ve used so far.
And at far less cost in terms of time and money to acquire those defensible learnings. Best of all, it can be used by anybody seeking to solve a problem, whether an entrepreneur or an artist, or anything in-between.
At the core of this mindset and approach is the practice of prototyping. Briefly stated, prototyping is the practice of starting with what you have at hand, and building a low-fidelity, table-scale working version of whatever part of the problem you have the means to capture at that moment.
There’s a lot more to the practice, but taking an immediate and hands-on approach with whatever knowledge and materials you have at hand, to flesh out any part of the problem you are trying to understand, is the heart of the practice.
At first, “prototyping” was hard to grasp. I am slightly familiar with the concept from what I have read about and learned though the product design and development domain. However, it took me a while to appreciate and truly leverage the depth and power of this new view of prototyping:
First, the key to learning and progress is to replicate function as much as possible through the prototyping process. This is a big challenge, at least in my experience, and forces you to think through the exact aspect of the problem or solution you are trying to better understand.
For example, let’s say you are building a website to help your users answer a financial question. Forcing yourself to prototype the function of a solution are building may help you understand the time it takes the user to use some specific capability on your site.
You may discover that there is more data needed to use it than a user is likely to have access to, or even know where to get. The product prototype construct may miss key insights if you’re not looking to replicate the totality of the function. And you can do this even if you’re not a “product designer”.
Second, the concept is much broader and more versatile than my understanding of prototyping in the product design construct. This is because in the innovation process, you seek to prototype virtually everything about the problem, its impact and its potential solution through your attempts to gain a deeper and clearer understanding of the problem. This led to breakthroughs in understanding that hadn’t occurred previously to me, and for far less cost and effort.
For example, let’s say you’re trying to solve the problem of poor customer usage of a financial app. In the product design construct, your prototyping efforts would be limited to features or attributes of the app itself.
Things that are outside of the actual boundaries of the product (for example how they find out about the app, or how a friend can refer it to them) may at best be addressed by other teams, or at worst, ignored because there is typically no self-contained check to ensure those are looked at and understood.
They may also occur at a later stage in the process when more money and time has been spent, and errors are therefore much harder to fix.
In contrast, when you’re prototyping the entire problem, you will create some model of the entire system of the problem and its solution, no matter how rudimentary it is, at the beginning. What this does is to force you to see disconnects, inconsistencies and other problems that may be causing your app to fail.
And you will stumble into these insights even before taking any actual materials or parts to string a simple prototype together, resulting in much better solutions.
In my view , this is the single biggest benefit of using this method because it forces you to do the hard mental work of understanding the ecosystem of a problem in its entirety, but in a way that is precise and surgical, and very economical of time and money. It’s difficult to do but more than worth the effort.
Third, it helps you to intelligently gain critical outsider perspectives beyond just a design or development team. This is because your scope and objective extend well beyond the product itself, and you are setting yourself up to gain unsuspected insights by exposing all aspects of the problem or a solution to your potential audience.
These may be on your internal team, or well beyond, and extend even to casual acquaintances. This way, you are maximizing your chances of a successful and feasible solution without a lot of expense upfront.
For an individual or organization that’s interested in most insight and learning for least money and time, that’s a golden recipe.
There are many more benefits and nuances to this approach than I can describe here. At a high level, though, it feels like there is finally a mindset, a practice and a discipline anyone can follow even with limited resources, to realize their ambition of creating impactful solutions to real problems they care about.