BY TOM HARTLAND

My post on the differences between tests and pilots was well received despite being humblingly short on actual examples of it working. Captivating writing aside, it sought to make the following common sense argument:

A pilot is not the arena for designing a product or service.  

The post framed the ‘test stage’ as a precursor to piloting. A place where all manner of implementation chaos, inconclusive evidence and confused colleagues are actively encouraged, weeded out and remedied. The test stage is an acknowledgement of ignorance, a nod to “We don’t know what we don’t know”. Better yet, you can wield tests a bit like a crook, hooking bad ideas back from the ‘pilot precipice’.  

We’ve used it extensively across a number of smaller ideas, but we knew we’d need to lure in a rockstar concept if we were really going to challenge our innovation pipeline. Enter our Starting Well Engineer (SWE) - the idea that an engineer visits customers early on in their tenancy to coach them through some basic repairs, seeking to reduce engineer call outs to minor works.   

The SWE concept is exceptional in that we’ve retained creative control of it for a full six months, despite a glittery profile and voracious appetite of the business to “have it now”. Doing so certainly entailed a healthy mix of diplomacy and fighting talk - but it was worth it, because throughout testing so much went wrong it would’ve sunk, hands down, if rushed to implementation or pilot. But we were watching with a magnifying glass,if there was a slip up we’d noticed it. Any deviation from the plan, we stopped to explore what caused it. We built up our knowledge, not solely on the value of the idea, but our ability to run it efficiently, inevitably eliminating a chunk of uncertainty for the team we’re collaborating with.

So now we’ve got some hype and plenty of people (within Bromford and outside too) are extolling the virtues of testing.  Problem is, some things can get lost in translation…

'Testing' can be woefully misconstrued. People can get the wrong end of the stick.

I know at times Labs can seem free from the ubiquitous dread and panic associated with running large pilots. I know for certain we avoid all the unnecessary preamble of project management. However we can only appear (and generally be) quite placid, while running a high profile test because:

  • We're impartial - if a test fails to generate any value it’s not a reflection on a Labs ability to run them. It’s a necessary step to finding out what IS worth investing in.

  • We've set ourselves a solid foundation - we know what the plan is and accept we might need to tweak, change or overhaul the model in the process. But you can’t just do this out of the blue, it needs a level of justification based on your findings.

But to the casual observer, it might just appear that running a test is a cakewalk - not noticing the raft of problem definition, design and documentation that’s gone on behind the scenes... 

And therein lies the problem - if you make innovation and design look really easy it can inspire a raft of what we’ll call here "Dicking About".

This phenomenon is almost identical to the blind piloting, albeit chewing up fewer resources in the process. Some progress then. However the principles of testing seem to be largely omitted. See how they compare:

To back-peddle *slightly*, I don’t actually have any issue with dicking about per-se. I’ll go as far as saying dicking about forms a key part of designing a test model. However, it’s a very early stage process, that is soon followed by more divergent and convergent thought cycles, growing and refining an idea over and over until something that looks about right pops out.

The threat, as it always has and always will be, is that dicking about jumps straight to implementation, or as bad, is used to dismiss a golden egg of an idea.


It may seem that I’m making the case for ‘specialist’ designers, and in a very small, biased way I probably am. Although - anyone can do this, none of it is rocket science. Simply taking an analytical view of the idea - rather than forcing a success and telling everyone how great you are - will put you halfway there.

Besides, diligent design is a great thing to practice, because let's face it - most of us don’t know which ideas become runaway trains until we’re on them and can no longer hit the brakes.

I’ll propose one more rule for the cannon before I go:

Dicking about is not a substitute for actually designing a product or service.

 

Comment