Enough With Failing Fast Already

Screen Shot 2015-01-08 at 2.46.17 PM

This perpetual talk about failing fast is kind of driving me crazy. Of course we can and should learn from our missteps, but all the “failing fast” rhetoric misses a crucial point.

We shouldn’t be failing, we should be experimenting. Maybe I’m being a stickler for nomenclature, but to me there is a big difference between failing and experimenting.  Failure is when you’re sure you know the answer, invest in building something, launch it, and then realize you were wrong. Experimentation is when you think you know the answer, go test it before you invest heavily in it, and then iterate based on what you learned.

We fail when we over invest our resources in something that’s unknown without testing basic assumptions. We fail when we don’t turn a thoughtful eye towards learning until we’ve run into a brick wall. Preaching failing fast sets us up for a much longer and more expensive learning cycle than is necessary.

Instead of creating a culture where failure is permitted, we should be creating a culture where experimentation is expected. When starting to invest in a new idea, we should ask ourselves, “what assumptions we are making that are necessary for that idea to succeed?” We should ask ourselves, “why is a certain variable in our idea (e.g. mode of input, distribution channel)  what it is?” and consider exploring alternatives. We should develop experiments (at the d.school we call them prototypes) to explore these critical unknowns, and feed our learning back into a new iteration of the idea. Working with this mindset, one invests more and more in each experiment, and they morph into the implementation of a well-tested idea.

When we experiment instead of fail, and start talking about our process and lessons, our learning curve really starts to hockey stick.

Google vs. Facebook: The Ebola Giving Edition


About a month ago, I signed in to Facebook to discover a banner at the top of the page. “Jenny, you can help stop Ebola,” it read. I clicked on the link and was confronted with three options: the American Red Cross, International Medical Corps, and Save the Children. Three massive international health NGOs. Though I’d worked in Liberia multiple times, I didn’t have a sense for which had better capabilities on the ground. I paused, thinking of how those organizations were likely flooded with donations, dubious about the efficacy of their use. I hit the back button and went about my business.


Days later I opened a new tab in Chrome and found a similar, though critically different message on the Google home page. Google would match a donation I would make to Ebola that day, 2 to 1. It felt irresponsible of me to ignore the opportunity. I clicked. I was further pleased to discover that my donation would go to Network for Good, an organization that would allocate the funding where it was needed. I donated a couple hundred dollars without hesitation.


Facebook: 0; Google:1. Of course, having a donation matched is a big motivator, but what made the difference for me was the absence of choice and the presence of a trusted intermediary. I felt better about where my money would go when ceding control. Makes sense though, right? It’s kind of crazy to think you’ll get anything less than tragically inefficient allocation basing choice on little more than brand recognition and ordering.

Getting Back on the Mat


I used to be a pretty intense ashtangi. I’d be in the studio at 6am at least a few days a week, typically practicing for nearly two hours. I even went to India to study at the source. Yoga provided an important space where I could grow as a person outside of my professional trajectory. It became a part of my identity.

Then I had my first child. I kept trying, and kept failing, to “get my practice back.” I’d manage to find a few days a week to start building myself back up, and inevitably drop off again, only to start from a familiar set of stiff limbs weeks later. I never came remotely close to the place I’d left off.

Something shifted when I had my second child two years later. I gave up trying to retread a familiar path to see what I’d missed around the next corner. Instead, I aspired to just get on my mat, every day. A mom of two might not be able to find two hours a day to indulge in yoga, but twenty minutes was surely doable.

Inevitably, twenty turned to thirty more often than not. Nowadays, forty five is the norm, with an occasional sixty-minute indulgence. Though kapotasana is still a distant memory, I’ve reclaimed a personal space that I value highly.

That same mentality applies to most anything, I suppose. In the past year and a half, I’ve written a single blog post. Time to get back on that mat too. I may not have the most profound things to say at first, but at least I’m saying something.

Surface Your Assumptions. ASAP.


I’ve been using a design method called assumptions storming lately, and I’m finding it incredibly valuable for both ideation and prototyping.  You start with an idea, or an existing product.  Invariably, that idea or product rests on a big long lists of assumptions: about the value proposition, about the system, about constraints, about user behaviors, etc.  More often that not, teams aren’t even aware they made the assumptions in the first place.

So the first thing you do is pull all of the assumptions to the surface. Get a few people in the room with a bunch of post it notes and throw them up on the wall with an assumption on each one. Sometimes I find it helpful to overlay the assumptions on some visualization of the product or user experience. Journey maps (blog post on them coming) are particularly useful, and they force you to think end to end about the idea.  From there you can identify the critical or most interesting ones vs. the more tactical ones.

This exercise is usually pretty eye opening. You start to see the opportunities you ignored because arbitrarily assumed things had to be one way vs. the other. You might identify a huge assumption that, if incorrect, sinks the entire effort. Just having awareness of what is based on evidence vs. hunch is a huge step.

From this list there are a number of directions you could go, depending on whether you think any given assumption is likely to hold:

  • You think it’s wrong: Brainstorm around the assumption being false. I’ve seen this be a great way to get teams into new territory time and time again.
  • You’re not sure: Back away from the assumption and explore alternatives in addition to the original idea (note this is often an aspect of an idea, not the entire idea itself).
  • You think it’s right: Acknowledge the assumption and move forward, with an eye towards whether usage and user feedback gives evidence to that end.

Assumption storming is fast becoming one of the most powerful methods in my design toolkit, well worth the hour-long exercise at any point in an idea’s lifecycle.

Best Design Advice? “Just Make It Up”


As part of the d.school fellowship program, we bring in experienced designers to provide feedback on issues we’re grappling with in our work.  Two weeks ago we were lucky to be joined by David Kelley, founder of both the d.school and IDEO.

I asked him about the challenge underlying my recent blog post “What Problems Are Design Thinking Useful For?”  How to rapidly increase sophistication of one’s design capabilities across two dimensions: building a robust design toolkit and integrating design with other approaches?

While I’ve been learning a lot about using my economics training and management consulting skills alongside the design process, I’ve been frustrated with my limited design toolkit.  I know there are many methods for empathy, synthesis, etc. that I haven’t been exposed to.  If the Governance Collaboratory is about teaching local innovators design thinking to apply it to their work, I’d need to understand how to better support others in acquiring these skills as rapidly as possible.

I drew a graph with design sophistication on the y-axis and integration with other methods on the x-axis, identifying where Jeremy and I have moved from nine months ago to now.  “How to get up and to the right?,” I asked.

David’s answer?  “Mileage.”   Ok, yes.  I get that.  Over a dozen design cycles in the past few months has taught me a tremendous amount about integrating design with traditional social science approaches, yet I feel stunted in my acquisition of a toolkit.

“But,” I pushed back, “I just don’t know what tools are out there, someone has to teach them to me.  Should I look to coaches?  Or read books?  Are there case studies?”

“Just make them up!” David answered.  “We just made up the empathy map at IDEO a few years ago.  You’re out in new territory.  Figure out what works best for the problems you care about.”

What might seem like a frustrating answer has turned out to be quite liberating, but only when coupled with the mindset shift that design thinking affords.  Making it up makes perfect sense, because a designer’s mindset gives you the creative confidence to experiment and quickly learn what works.  So, off into uncharted territory I go…

A Small But Profound Mindset Shift

We talk so much about celebrating and learning from failure.  True, we should understand and share what doesn’t work.  But merely using the words “learning from failure” implies an underlying mindset that reduces the speed at which we learn.

It implies that we approach our work in the following way:

  1. I take a lot of inputs about what I know in the world and come up with a new intervention
  2. I go do that thing and believe that it will work
  3. If it fails, I reflect on why and share my learnings

What if instead we approached our work with the following mindset?:

  1. I take a lot of inputs about what I know in the world and come up with a new intervention
  2. I ask myself what I don’t know that is critical to the intervention’s success
  3. I go try that thing with an eye towards learning about what I don’t know
  4. I constantly reflect on what my work reveals about what I don’t know
  5. I continually update my approach based on what I’ve learned

This shift from “know –> do –> learn if fail” to “believe –> try –> learn constantly” sets us up for continual improvement through a much faster learning cycle.  It’s a small shift in mindset, from what you know to what you don’t know, but it has profound implications for the speed at which we learn and improve.

What Types of Problems are Design Thinking Useful For?


Upon beginning my fellowship at the d.school last September, one of the biggest questions I wondered was “Which problems are design thinking good for and which are not, and why?”

When I asked around, I got pretty underwhelming or only slightly helpful answers, like:

  • “Design thinking is good for everything.” (not helpful)
  • “Problems that aren’t technical in nature” (a little helpful)
  • “Problems relating to human experiences with subjective answers.” (slightly more helpful)

Surely there must be some challenges involving human experience that are more amenable to the process than others, I thought.  I started to feel like the only way I’d get a good answer to my question was to start applying design thinking to different problems myself.  A dozen turns through the human centered design process later, my understanding is starting to take shape.

In retrospect, the question itself was a naïve one.  It presumed that human centered design was a process that you applied to different problems (which is how we generally describe it at the d.school).  But I’ve come to believe that it’s less of a process than it is a mindset empowered by a robust toolkit.  Yes, most design teams move and iterate through steps which include understanding users and context, distilling insights and abstracting design directives, conceiving of novel solutions, then experimentation to learn what works.  But a truly sophisticated designer understands how to adapt the principles and tools of design thinking to the problem at hand.

I’ve been thinking about human centered design sophistication along two dimensions: the design methods themselves (toolkit) and integration with other approaches.  A robust design toolkit would include a plethora of research methods, synthesis instruments, ideation techniques, and prototyping approaches.  The experienced designer can draw from a wealth of tools to adapt high-level design “mindsets” (i.e. empathy, prototyping, testing) to a wide range of problems.

The second dimension of integration with other approaches is equally critical, particularly in my world of taking design best practices into governance innovation.  I’ve always been suspicious of professionals from the private sector (be they management consultants or designers or whatever else) bringing their tools into the social sector and believing they alone can move the needle on the world’s most intractable problems.  As we’ve experimented with design in governance, we’ve always had an eye towards complimenting rather than replacing existing approaches.  We’ve already begun to see where our social science backgrounds tend to dominate over our design skills.  My suspicion is that for some types of problems we might rely largely on other approaches, with design tools sprinkled in here and there as appropriate.  For example, for macro level policy questions that rest on philosophical beliefs, insights about citizens could inform debate rather than lead to policy design directives.

Bottom line is, I no longer think it’s a question of “Where human centered design is useful and where it’s not” but rather one of “How to draw on human centered design for the problem at hand.”  The hard part is building sophistication as a designer.  I asked David Kelley for his advice on the matter last week.  His response? “Mileage.”

No more posts.