There’s a term my dad use to describe what it feels like to be an entrepreneur. He says it’s like “riding a tiger”. I think it’s a pretty good analogy. Life in the trenches of entrepreneurship is always confusing, often threatening. The root cause of these feelings of course, is uncertainty. By definition, you create something brand new, and a lot of the time you’re neither sure what it is exactly, nor whom it’s meant for.
(After hearing about the tiger ride for decades, now that I google for it I realise that dad borrowed it from a Chinese proverb, which says that ‘He who rides a tiger is afraid to dismount’. The full sentence makes it even more fitting to describe entrepreneurship, where once you’ve gone all in, it’s often impossible to pull out).
Entrepreneurs aren’t the only group that have to deal with the stress of daily uncertainty. This is true for doctors, fire fighters, active duty military personnel, police officers… The list could go on, but if there’s one thing these professions have in common, it’s the focus on creating frameworks.
A framework is different from routines or habits, which are cognitive shortcuts to get you through the day without over-thinking. In contrast, a framework provides you with a heuristic tool box; a pattern recognition aid that helps making sense of a messy and chaotic environment.
A framework can be opinionated, meaning that it has a certain built in bias. In my view, that’s a part of the point; if you want the truth, the whole truth and nothing but the truth then science is probably a better option. The fact that a framework is opinionated however, doesn’t mean it has a ready answer for every situation (if it did, we’d call it a religion or an ideology). It will just try to give you a rough idea of where to start looking for answers.
I’m often dreaming up frameworks of my own. Very few of them spread beyond my mind, but here’s one that I think has stood the test time. Every good framework needs a name, so let’s call this one Straddle, in reference of that tiger.
According to Straddle, there are four patterns of validating a startup idea. They are titled:
- Just-Do-It
- Build-Measure-Learn
- Immerse-To-Understand
- Test-Driven
Straddle is opinionated in the sense that most of the time it’s probably a good idea to pick your strategy from the bottom of the list, since the top alternatives are often slow and risky. That doesn’t mean however, that one size fits all. Let me go through the different approaches, with examples of how and when they may be appropriate.
The Just-Do-It approach means putting all your eggs in one basket, but can nevertheless be your go-to strategy. This is especially true when the venture in question is of a more artistic nature. There’s no way to validate that you’re on your way to write a great novel or paint a master piece. In fact trying to, would be counter-productive, since what you want to achieve is and should be defined by your own artistic vision, rather than what people say they want. Back when I was a documentary film maker, this was the only possible approach. Building a startup is very different from that of course, but nevertheless I think there are cases – and perhaps they’re more numerous than common wisdom dictates – where the Just-Do-It approach is the most appropriate way to go, also for entrepreneurs.
The Build-Measure-Learn approach needs no further introduction. Since it was coined by Steve Blank and then popularised by Eric Ries, it has become the default mode for everyone who want to try the startup thing. According to this school of thought, the central goal is to build a Minimal Viable Product; introduce it to prospective users; measure their reactions, and then go back to the drawing board for the next iteration. In a perfect world where the sun always shines, you can run through every iteration at dizzying speed, meaning you beat the rest of the pack because you learn so much faster than they do. In a less than perfect world, this approach often gets dragged in the dirt and bastardised until instead of iterating you get a swelling team working on a growing code base shipping gradual improvements on what has long ago solidified into the fixed DNA of a product that will always, at its core, remain the same. (I’ve written before about how hard it is to get your MVP definition exactly right, and about the closely related challenge of defining done. Both post keep getting traffic, probably because this is where most entrepreneurs stumble).
The Immerse-To-Understand approach doesn’t really involve validation per se. Instead, it’s a structured way to walk mile after mile in the shoes of your target audience. I once slid into this mode without even realising it. The whole thing started with me noticing how lots of librarians were pissed off with publishers (an industry I happened to be in at the time) over how ebook lending worked. Everyone agreed that the current way of doing things were deeply dysfunctional, but few could define what a better alternative might look like. I let myself be pulled into this “design space” (which is how I came to think of it much later) and met with hundreds of people, went to conferences – initially as attendee, eventually as keynote speaker – and even ended up writing a book on the subject. Only years into this process, it finally dawned on me that there was a startup waiting to happen. Once I then put the shovel in the ground, that company was up and running in six month time, and acquired in about a year. The process might have seemed a lot like Just-Do-It (there were no iterations, we just got the thing exactly right at the first try) but of course in reality the startup building part was just the tip of the proverbial iceberg, made possible only through a lot of open ended exploration. This approach is sometimes referred to as customer development, a methodology which leans heavily on cultural anthropology, which revolves around keeping your bias in check and just observe the world without preconceived ideas. Sometimes, and especially when the problems you’re interested in tackling are complex, this is clearly the way to go. It does however tend to be painfully slow.
The Test-Driven approach, lastly, will be familiar to any programmer. This is where you start by defining your key conjectures about how the world works, and then go into the field to validate them. Now this is a fantastic method since it allows for accelerated learning without building stuff. In theory that is, because a chief challenge here is to formulate your assumptions in such a way as to make real validation possible. Here’s what I mean by that: If you expect to validate high concept ideas, all you’ll “find” is false feedback (be that false positives of false negatives). People simply aren’t any good with abstractions, they need to have something very concrete pushed into their faces in order to say what they think about it. Which means you have to go from verbalising your assumptions (which is often hard enough to begin with) to shape them into something crisp and tangible, preferably a high-fidelity prototypes. The fact that you mock these using some kind of prototyping tool (I’m a fan of pen and paper) rather than build them, is what makes this approach faster than the MVP-centred one. The real challenge however, is often in translating your fuzzy assumptions into something concrete which feels true enough to your vision, while still being quick-and-dirty enough to keep the validation wheels spinning at high velocity.
So there it is, the Straddle framework in all its glory. It might not bring anything new to the table, but then frameworks seldom do. Instead their job is to pave a way for the mind, making it easier to grasp a reality which will always remain chaotic in its essence. Or as my dad would have it: to keep riding that tiger.