You Can't Rollerskate in a Buffalo Herd

And You Can't Innovate When You're Afraid

Alex Humphreys

Here at JSTOR Labs, we think a lot about what it takes to create innovative tools and products. In this blog, we’ve touched on a few of the ingredients that foster a truly creative environment, including iterating, iterating again and then iterating still more, creating a deep understanding of the user, and developing open, collaborative partnerships. Today, I’d like to discuss one of the most important ingredients, and one that can get overlooked pretty easily: overcoming the fear of failure.

But first let’s talk about Country & Western music (1), which I just love. These days, when I’m in the mood for it, I’ll turn to the old standbys of Willie, Waylon, Merle and Johnny. When I was a kid, though, the country songs I liked were the completely silly ones with ludicrous names, like “A Boy Named Sue” and “May the Bird of Paradise Fly Up Your Nose.” One of my faves was a silly Roger Miller song called “You Can’t Rollerskate in a Buffalo Herd.” Here, have a listen.

(1) A risky transition! What if it doesn’t work? (Scared, yet?)

It’s a great song. It’s not a perfect country song, though, and not just because it doesn’t have much to say about Mama, or trains, or trucks, or prison, or gettin’ drunk (like the last, perfect verse of this song does). No, it’s not perfect because it never really explores the idea of rollerskating in a buffalo herd, which, c’mon, that’s some rich topical territory to mine, right there. I mean, why can’t you rollerskate in a buffalo herd? The song doesn’t tell you.

Having never tried it myself, I’ll have to conjecture. First, I imagine that the jostling and the horns and the fact that you’re on wheels makes it a bit tough to stay upright and safe. Second, if (no: when!) at some point you DO fall over, the combination of trampling, stampeding hooves and the wearing-rollerskates-thing means you may not be able to get up again. Scary stuff! Better not to do it in the first place. Thanks, Roger, for the heads-up.

Which, you’ll be relieved to hear, brings me to my point. If you fail at rollerskating-with-buffalo, the consequences are severe enough that it’s entirely rational to be afraid to try it at all. And that brings us back to innovation and its mortal enemy, the fear of failure. I’ve certainly heard lots about how you can’t innovate when you’re afraid, but the conclusion I hear most often is a disappointingly unhelpful, “So don’t be afraid.” What that mindset overlooks is that sometimes it’s entirely rational to be fearful. If you’re making major changes to the business model that sustains your enterprise, or if you’re making a bet that will affect your entire career (2), or you’re changing something that’s got thousands or even millions of current users, then you should be afraid. You’d be crazy and heedless to ignore that fear and just upend everything. Thing is, as Clay Christensen tells us, we also can’t get paralyzed by the fear and just not change. So what do you do? You create a space where it’s safe to fail.

(2) For instance, if you’re deciding to forego traditional publications and instead embrace digital scholarship that may or may not help you get tenure or promotion.

That’s the whole point of this post, so I’m going to go ahead and repeat it: You create a space where it’s safe to fail. This can be done in dozens of ways. Let’s explore some of the specific ways that work for JSTOR Labs:

Prototyping: There are many, many different types of prototypes, and ways to prototype. These range in effort required to produce them from napkin sketches and paper prototypes at one end to Wizard-of-Oz-tests and low-fidelity prototypes (i.e. wireframes) in the middle to high-fidelity, live-data prototypes at the other end. At heart, the point of a prototype is to learn as much as possible about your idea while investing as little effort as possible (making it less heartbreaking when it fails). Prototyping is particularly powerful when paired with the next two items on this list.
Rapid iterations: Innovation seldom comes in a single, big Eureka-moment. Instead, it’s the product of a thousand little realizations. The faster you can go through those learning iterations, the faster you can get to something really great, allowing you to make many small, less fear-inducing bets rather than one very large, scary one. Earlier in my career as a product developer, we’d test one or two different designs for a new product. Using various forms of prototyping and the next item on this list, JSTOR Labs tests dozens and sometimes even hundreds of designs in a matter of days or weeks.
In-person user-testing: Big releases are scary because the failure is so terribly public (hello, new Coke). But if instead you’re just showing it to a single person and they don’t like it, it’s just not much of a big deal. In fact, it’s kind of great, because then you can ask questions to better understand what would make this particular person stand up and go, “Wow.” We use guerilla testing when we need short, informal feedback from lots of people, and longer, scheduled tests when we need to dive deeper.
A/B testing and limited releases: In-person user-testing is essentially a very, very small release of the product. This idea can be expanded into still-limited releases through, for example, a pilot program. With a bit of tech, you can also do this programmatically, by releasing, say, to only 1% of your users (this, then, allows for a/b testing). Our colleagues at ITHAKA’s Build Smarter blog wrote about how ITHAKA and JSTOR use these kinds of tools.
Labeling: Setting expectations with users with a Beta label can be very powerful – it makes it easier to release early in order to get user feedback. We at JSTOR Labs tend to marry this label with a “Help us make this better” feedback link. The Beta label changes the relationship your users have with the tool and you; it brings them under the tent. With Text Analyzer, for example, we’ve received feedback from literally thousands of users through this simple form and social media. That feedback has been invaluable to us in finding and prioritizing issues.
Fun: The importance of this one really can’t be overstated. A sense of fun and play contributes to creativity. It also brings people together, making it safer to fail because others will pick you up. During our “design jam” workshops, participants have to come up with eight ideas in eight minutes and then share them. Then participants do it again, stealing each other’s ideas. Participants are encouraged to write down everything, even terrible ideas, because, first, you only have eight minutes, but also because your terrible idea might spark someone’s great one. When we run these workshops, we always send in advance a visual agenda that conveys to participants that they are in for some “serious fun.” For instance, we used this when we held a workshop with the Dante Society:

Fun, right?

Using all these techniques doesn’t mean that there are no risks, or that fear completely goes away. But they do make that fear manageable. I’m still a little nervous, for example, that you’ll think it’s silly to organize this whole post around country music and fifty-year-old Roger Miller song. But at least I had fun writing it. And if it didn’t work? I can deal with that failure. It’ll help me write a better post next time.