Sketching with Code

Hack, Play, Learn

Hack, Play, Learn diagram

Build, Measure, Learn. It’s the new mantra adopted by many a tech startup thanks to Eric Ries’s influential The Lean Startup.

I’ve spent a good deal of time over the last few years involved in (more than one) startup. In many ways I’m very grateful for this simple, shorthand phrase to describe the process of taking an idea, seeing if it works, iterating and building a product in an agile way. It’s a useful encapsulation of a lot of the processes you go through in a (in my case media/web/software) startup, where code is relatively easy to create, but it’s hard to know what the right code to write might be.

The essential process is that given some kind of user problem, you propose a hypothesis or a number of hypotheses around what might be a solution. Then you build as minimal an intervention as possible to test it - it might be a little web app, or making a video to express the idea, or a landing page to see if people might like a product even though it doesn’t exist. Then you measure the success of the intervention, and from that measurement you learn about what’s working and what isn’t. Then you iterate - build, measure, learn, and repeat.

It’s a strong idea, and I know a fair few companies who are using this to build digital products - in fact it’s almost becoming a dogmatic thing. “What are our learnings?”, despite the wince-inducing word-crime, is becoming something of a catch-phrase.

However, looking at the way that I do things, I think that “Build, measure, learn” doesn’t fully encompass what’s going on when I’m building something.

If the purpose of a startup is to “learn”, then of course you can go for the “set a hypothesis, test it” approach, but at the very beginning of a project, way before you have users, I don’t see how you can measure anything with any kind of significance.

Also, if you’re making a “Minimum Viable Product” (MVP), I’m seeing that a lot of companies, not least ones I’ve been involved with, spend several months getting to that crucial “put it in front of the users” point. And that leaves plenty of room for startup stories that have a chapter beginning with “it turns out we’d spent all that time building the wrong thing”.

Perhaps that’s a case of those companies doing it wrong? In the case of the project I’m working on this Summer with a sports brand, the impulse is to hold back on “just get out there” until the app we are building has a decent feature-set that covers a fair amount of what we think users will want it to do. There’s a fear that we could damage the project by getting reactions like “this is rubbish” or “it’s broken”.

The crucial part here is “what we think users will want” - and herein lies the danger. We’ve run events to talk about our ideas with our target users, taken a sketchy version of our iphone app down to the local skate park (it’s a BMX app!) and so on. But we’re talking handfuls of users - not the several hundred you’d need to get any kind of statistically relevant results.

It seems to me that much of the lean startup process is based on the idea of applying scientific principles to startups. But I would argue that anyone with a science background would point out that there is far, far too much noise at the beginning of a project to be able to conduct a proper study and gather anything near a “scientific” conclusion.

On talking through that problem I realised that I have a phase that I use that could be usefully applied before you get to that point - “Hack, play, learn”.

I like to think of the early days on a project as a sequence of hack days. The idea is not that you will not be able to do anything “scientific” in this phase, but rather that a period of play and experimentation occurs before you can get to the “build, measure, learn” phase.

Children learn through play, and I’d argue that so can adults (in the right conditions). I often think about what I’m doing when I’m hacking on a little idea as play. I’ll look at a problem, have some conversations, and often be joking around about what we should do to solve the problem. I’ve been often surprised that something that starts out with an element of humour tends to lead to very interesting results.

In hack day parlance that’s a “comedy hack”, and at Rewired State hack day events you often see that the hacks using a bit of technology with a core idea of something humourous are often the best.

It’s this playfulness I try to channel at the very early stages of a project. No, I’m not going to write any tests, or follow Test Driven Development, because what I’m doing is sketching out ideas very quickly (hence “Sketching with Code”), playing with stuff on a screen, and getting something that partially works in front of the other folks on the team to play with, maybe run it past a few “users”, but in the main it’s just to see what the solution might look like.

I’ve found that I iterate rapidly around hacking up an idea, playing around with it until I’ve got something to show, and then taking what I’ve learnt and applying it to the next iteration. And these iterations are often measured in hours, not days.

The result is a joyful process with rapid results, a team that feels enthused and an accelerated project. But also, I think it means you get to learn a lot right at the beginning that can save a lot of time and money down the line because you’re building and failing on things that just aren’t right much more rapidly than if you’re trying to get something acceptable in front of users and measure their responses.

The “hack, play, learn” phase is often short-lived, and I use it to evaluate project direction. Then, once you’ve settled on what you’re supposed to be doing in the next phase (with a long user journey on post-it-notes on the wall, perhaps), it’s time to segue over to “build, measure, learn”, throw away that hacky code and build it right.

And “building it right”, might include other moments where you need to sketch and evaluate the direction for a new feature or product, in which case jumping back into playful mode is, for me, a good way of achieving it.

I’d be interested to see if other people follow this kind of approach, and hear about anyone who’s learnt lessons about the upside and downside to playful approaches to making things.