This is a little post about some ways to convince a reluctant development team that experimentation is A Good Thing.
In our New Year’s morning stupor over a restorative cup of tea, my friend Luke was bemoaning how difficult it was to impress upon his development team the benefits of experimentation.
Being the binary-minded bunch of people we all know and love, his developers wanted to do things The Right Way™ from the outset. All very commendable, except Luke knew his team didn’t yet have enough context to truly know what the right approach truly needed to be.
He wanted to get them to experiment with a few different approaches as straw men intended to be knocked down, but through which he would help his team to gradually uncover greater truths about the context of the problem they were trying to solve. The problem was that his team saw doing the ‘wrong’ thing as a waste of time, and so were kicking back against any experimentation.
Luke was despairing slightly as he was struggling to convince his team and didn’t want to resort to pulling rank and just telling them to get on with it regardless.
I didn’t have any magic bullets to solve his problem, but I did have a couple of suggestions for Luke.
Provide more context #
My first suggestion was simply that Luke should try to share some more of the product context (scaling requirements, other design constraints) he clearly knew about with his team. Was there some way he could show his team more directly how and where the product would be used?
Do examples speed up a build? #
The second suggestion was to play a little game with his development team. I suggested that he split his developers into two groups. One group would be put in a room with nothing on the walls, no pictures, ideally no view outside; the metaphorical blank sheet of paper. The team would have a big box of Lego and be instructed to construct an object to be used for a specific purpose. The other group would be set the same task, but would have the benefit of lots of pictures of similar objects being used in different contexts as examples. Both teams would be timed and ideally videoed.
We reckoned that the first group starting from the ‘blank sheet of paper’ would take longer to agree on a design and build the object than the second group, and that the first group’s object would be less effective than the second group, which had the benefit of several examples as inspiration.
The idea was that the examples available to the second group are like the results of experimentation, namely that it’s easier to build something for a particular purpose if you already know a bit about what works and what doesn’t, hopefully demonstrating empirically to Luke’s developers why experimentation is worthwhile.
Benefits of rapid prototyping #
A good talk I keep returning to on the topic of rapid experimentation is one by Tom Chi at Mind The Product conference back in 2012. The whole talk is worth a view, but this bit from about halfway onwards (at 00:13:49) is useful:
Essentially Chi points out that, since you have a small chance of success of being right first time with your product idea (about 5% for most startups), by trying lots of different approaches as quickly as possible you will dramatically increase your odds of success.
Luke may or may not give my suggestions a try. Personally, I’d also think twice before taking product advice from a moderately hungover Jock. I’ll report back if he does.