Don't get it right - get it moving: How to build your prototypes

  

Prototyping can be one of the most exciting parts of concept development. Yep, getting those pent up ideas finally out into the open can be pretty cathartic, a sweet/salty release.

But wait, is your original idea cut from the exactly the same cloth as a million others in the sector? Is your idea recycled from something you yourself were part of 5, 10 or 15 years ago?  

These ideas tend to be the ‘go-to’ options for a reason, they are tried and tested. 

We reached this conclusion for some ideas in our latest wicked problem: fuel poverty.

The only thing is, if it was a truly good solution why is everyone talking still about it and not doing it. 

Why have you got to revisit it years after your first attempt?

Without dedicated time to research innovative solutions, your solutions will never be innovative - you’ll never break the mold and never solve the problem for good. If you’re on easy street or if you’re just looking for a stopgap then OK, but I’ll see you here again in another 5 years...


Collecting inspiration, the first step of prototyping, means casting the net as wide as you dare. Plunder the influential others for directly relevant material, sure, but true skill lies in stealing ideas from industries you’ve barely heard of....

You’ll need a solid grasp of the fundamental problem, something you should have pinned down in the earlier exploratory phase of concept development. Conduct a root cause analysis, deep dive, collaborative questioning - whatever you have to do to get to the crux. The further you dive the more issues and ideas become transferable. Take a look at the example below I’ve paraphrased from Sticky Wisdom (Allen et al.):

A printer company is sending out lots of engineers because it’s machines keep getting blocked. Now think about this - what else gets blocked?
Noses. Noses get blocked. And if getting a blocked nose is critical, we’d all be dead. Fortunately both nostrils don’t tend to get blocked at the same time and even if they did we’ve usually got a mouth available to pick up the slack. Redundancy. Could we add another feed tray?

But what else? Pipes. Pipes get blocked. We overcome this by increasing the demand on the pipes, using a plunger or object to move the blockage through the machine. Force. Can we load enough paper in one go to push the blockage out?

Tunnels. Accidents happen and tunnels get blocked. Operators may set up a system that allows the other lane to be used, managing traffic each way. Intelligent design. Can we set the out-tray to accept paper until the blockage is cleared up?

Biology, plumbing and road traffic management - all to fix a printer jam. Some of the ideas don’t actually look too bad - though I’ve blown my intellectual property rights to the out-tray in-tray idea... Allen and co. call this technique the ‘lateral step’ and it works by taking our minds out of the paradigm we’re all used to thinking in - ‘social’ (bleurgh). Think instead from the perspective of someone who’s already solved the problem, just in a different context. It’s brilliant, and it also takes care of step two, generate/transfer ideas.

Being social, lots of housing associations face people problems, that is colleagues or customers not behaving as you’d like them to, for whatever reason. Fortunately for us, pretty much every industry has people - so the possibilities are endless. Though this isn’t an invitation to start replacing everyone with robots just yet!


Obviously, some other companies would seize an opportunity in exactly the wrong way for your business, so the ideas still need some filtering. It may be that there aren’t any directly useful solutions out there. But what you can do now is spruce up your ‘sector thinking’. Take lessons from those other fields and apply them to a ‘run of the mill’ original idea. 

pipeline-prototype.png

Finally - you’ll need to draft up a proposal for each idea you want to keep. I call them test plans and include a list of draft measures (again, the explore phase will help you identify what success looks like). How to design a test plan is a post in itself - but for now I’d suggest keeping it purely academic. If you can’t write the pertinent points up in a few lines, you’re not doing it quite right.

Don’t bulk it up, don’t try and include everything else under the sun. Keep it simple, keep it light and add features incrementally as and where it makes sense. But more on this in our next pipeline installment: testing.

Tom