Setting yourself up for failure

Scary, crazy, upside-down truths for the insecure and perfectionistic, found in the practice of Lean UX.

I’ve recently borrowed The Lean Startup (2011) from a colleague. It rattled some rusty cogs (long overdue for some Q20 introspection!) in my daily workflow as an interface designer.

I thought it might be worthwhile to reflect on some of the following areas:

1. My experience with sinking a lot of hours into approaches that are doomed to fail.
2. Why I avoid honest reflection on inherent flaws in approaches / projects.
3. How can I make it easier for myself to ask and face these hard truths?
4. How can I turn the pain of ridicule and failure into something productive?

On novelty and human effort

I want to start with a confession.

I’ve been struggling to find an entry-point into a discussion on Lean and user-experience. Both Lean and user experience touch on so many aspects of work and personal life that there is an overwhelming amount of pathways into its core. However, in the spirit of my position at OpenUp, it might be suited to start this article with a moment of radical transparency:

I’ve always been a strange kid. Extremely self-aware, cautious and insecure. However, I’ve always had a keen interest in the technical things in life. My dad, working as a manager at one of the big South African banks, brought home reams of used dot matrix printer paper. The back of these were quickly filled with drawings of constructions vehicles, 17th-century ship designs, cross-sectional drawings of caves or maps of imaginary cities and landscapes.

As was customary in the early years of primary school during the turn of the millennium, my class was tasked with colouring in pictures of biblical figures. I’ve been colouring in for a while and decided to see if I can experiment with a single yellow crayon to emulate different ‘colours’ via different pressures and patterns. Needless to say, the teacher was shocked when (at the end of the colouring-in session) I handed in several pictures exclusively filled with a single colour. In spite of the strenuous effort that went into figuring out the correct amount of pressure and/or patterns needed to emulate different shades of yellow, my drawings were held up in front of the entire class as an example of an unacceptable low-effort colouring job.

Unknowing, I stumbled into a hidden truth about the human act of creation: novelty nor effort alone guarantee actual value. Or put another way by, Austrian-American management consultant, Peter Drucker:

“There is surely nothing quite so useless as doing with great efficiency what should not be done at all.”

Pain, trauma and wastage

I wish that I could say that this turned out to be a transformative experience for me.

Unfortunately not. Years later as part of my degree in visual arts, I spent several sleepless, early morning hours perfecting just one last part of my work before hand-in. However, to my confusion, it turned out that fellow students seemed to receive similar (or often better) grades with considerably less hours spent in the studio. The solution seemed simple to me: I just need to push myself harder and be more creative.

It was not until I handed in my post-grad thesis (my biggest personal project thus far) that I reflected back on three years of disorientation and insecurities. Primarily in the form of fears that I will be exposed as a fraud or that my work will be ridiculed by others in the field. I was proud of the work that I’ve done, however, I couldn’t help shake the feeling that there has to be a less physically (and emotionally) costly way of achieving the same end result.

In fact, I was by no means alone in my struggle to reconcile the value created from my endeavour with the (personal) destruction that came out of the creation process itself. In The Lean Startup (2011), Eric Ries reflects on The Principles of Scientific Management (1911) (a seminal work by Frederick Winslow Taylor) as follows:

“In the twenty-first century, we face a new set of problems that Taylor could not have imagined. Our productive capacity greatly exceeds our ability to know what to build. Although there was a tremendous amount of invention and innovation in the early twentieth century, most of it was devoted to increasing the productivity of workers and machines in order to feed, clothe, and house the world’s population. Although that project is still incomplete, as the millions who live in poverty can attest, the solution to that problem is now strictly a political one. We have the capacity to build almost anything we can imagine. The big question of our time is not can it be built? But should it be built?”

- The Lean Startup (2011)

In short, we’re overextending ourselves (and our environment) expending resources in order to create/fine-tune/perfect things that no-one needs.

Pursuing failure and ridicule

Where do we even start addressing the above?

Ironically I found an inkling of an answer once I exited the field of visual arts for the world of programming. It came in the form of what is known as extreme programming, a development methodology that attempts to reduce cost (and wastage) in the field of software development by means of four keystone values:

• Communication
• Simplicity
• Feedback
• Courage

My takeaway from extreme programming might be summarised by a statement known as Cunningham’s Law (interesting enough, Ward Cunningham on several occasions mentioned that the axiom didn’t actually originate with him). It goes as follows: ‘The best way to get the right answer on the Internet is not to ask a question, it’s to post the wrong answer’. This is further echoed by Eric Ries’ experience in The Lean Startup:

“At this point in our careers, my cofounders and I are determined to make new mistakes. We do everything wrong: instead of spending years perfecting our technology, we build a minimum viable product, an early product that is terrible, full of bugs and crash-your-computer-yes-really stability problems. Then we ship it to customers way before it’s ready. And we charge money for it. After securing initial customers, we change the product constantly — much too fast by traditional standards — shipping new versions of our product dozens of times every single day.”

- The Lean Startup (2011)

However, this proved to be a bitter pill to swallow. The problem is that myself (and most of my fellow humans) are pretty insecure; desire affirmation and scared to death of putting something we are ashamed of out in the wild.

This is especially true when building digital interfaces. In my experience, user experience seems to be an unholy sweet-spot where both aesthetic critique (‘This looks gross!’) and usability critique (‘This is so confusing!’) overlap. The above effectively increase the pool of potential avenues for ridicule several-fold:

“Personally, I was worried that the low quality of the product would tarnish my reputation as an engineer. People would think I didn’t know how to build a quality product. All of us feared tarnishing the IMVU brand; after all, we were charging people money for a product that didn’t work very well. We all envisioned the damning newspaper headlines: “Inept Entrepreneurs Build Dreadful Product.”

- The Lean Startup (2011)

However, the tragedy seems to be that our neurotic fear of criticism during the phase where we are most vulnerable (by not being able to fully articulate what we are doing or our creation hasn’t been refined enough) seems equally dangerous. Eric Ries highlights the catastrophic effects of avoiding criticism until one has a polished product in a personal example:

“Perhaps you can sympathize with our situation and forgive my obstinacy. After all, it was my work over the prior months that needed to be thrown away. I had slaved over the software that was required to make our IM program interoperate with other networks, which was at the heart of our original strategy. When it came time to pivot and abandon that original strategy, almost all of my work — thousands of lines of code — was thrown out. I felt betrayed.”

- The Lean Startup (2011)

There are several examples like the above in his book. He argues that our inability to face our fears when our vision and product is still unclear (but malleable) increase the risk of even worse pain down the road:

“Ironically, this fear drives up the risk because testing doesn’t occur until the vision is fully represented. However, by that time it is often too late to pivot because funding is running out. To avoid this fate, entrepreneurs need to face their fears and be willing to fail, often in a public way.”

- The Lean Startup (2011)

However, in spite of all the apocalyptical implications, the courage required to face criticism when we are unable to articulate or meaningfully defend to our vision seems overwhelming. This seems to be a courage exclusively bestowed on the rare entrepreneurial visionaries, ego-maniacs or those with nerves of steel:

“Third, many entrepreneurs are afraid. Acknowledging failure can lead to dangerously low morale. Most entrepreneurs’ biggest fear is not that their vision will prove to be wrong. More terrifying is the thought that the vision might be deemed wrong without having been given a real chance to prove itself. This fear drives much of the resistance to the minimum viable product, split testing, and other techniques to test hypotheses. […] In fact, entrepreneurs who have a high profile, either because of personal fame or because they are operating as part of a famous brand, face an extreme version of this problem.”

- The Lean Startup (2011)

A structured approach to failing

Luckily the Lean methodology has an approach that softens the sting of critical feedback. This approach, called the build-measure-learn cycle, is driven at its core by accepting (and even pursuing) failure:

This is the pattern: poor quantitative results force us to declare failure and create the motivation, context, and space for more qualitative research. These investigations produce new ideas — new hypotheses — to be tested, leading to a possible pivot. Each pivot unlocks new opportunities for further experimentation, and the cycle repeats. Each time we repeat this simple rhythm: establish the baseline, tune the engine, and make a decision to pivot or persevere.

- The Lean Startup (2011)

1. Inevitably our product fails to deliver the value needed to sustain user growth.
2. This failure provides the motivation for spending resources on research.
3. In light of research gathered, we make changes to the product.
4. Our product fails once again, starting the cycle again.

While in more traditional UX workflows several steps are taken to prevent a team from shipping a product that provides no or limited value to users. This is done through various traditional UX techniques (but not limited to):

• Market studies and user analyses.
• Speculative user personas and journeys.
• Wireframes, design scamps and mockups.
• Focus groups and questionnaires.

However, Ries names several example where adherence to the above were not sufficient to shield teams from shipping failed products. Furthermore, not only did the above not guard against failed user experiences, but it resulted in demoralised teams, wasted hours and empty bank accounts.

Lean takes quite a radical approach to the above. At its core it not only assumes that we will most likely ship a failed product, but that we will ship several releases of said product before we truly understand what we should have built in the first place:

“Finally, it helps to prepare for the fact that [first attempts at a solution] often result in bad news. Unlike traditional concept tests or prototypes, they are designed to speak to the full range of business questions, not just design or technical ones, and they often provide a needed dose of reality.”

- The Lean Startup (2011)

By keeping the build-measure-learn iterations as small as physically possible, we are (at the very least) able to mitigate the inevitable wastage and pain associated with shipping a failed product. Eric Ries even goes as far as to say that resources not spent in the services of speeding up this build-measure-learn cycle is wasted:

The lesson of the [first version of the product] is that any additional work beyond what was required to start learning is waste, no matter how important it might have seemed at the time.

- The Lean Startup (2011)

In order to speed up the build-measure-learn cycle we should do two things

• Create smaller, independent, multidisciplinary teams that have built-in authority to make changes to a specific scoped area of the live product.
• Define progress not in terms of technical deliverables, but in terms of concrete answers to assumptions underlying the product itself and its users.

In the words of Eric Ries:

For example, consider the recommendation that you build cross-functional teams and hold them accountable to what we call learning milestones instead of organizing your company into strict functional departments (marketing, sales, information technology, human resources, etc.) that hold people accountable for performing well in their specialized areas.

- The Lean Startup (2011)

Eating the Lean dog food

The above lead me to an interesting question in eating my own dog food:

What if I’m able to determine the viability of a Lean approach to user interface design by turning the Lean methodology on itself?

In other words:

1. Select a real-world problem.
2. Build two separate web-based products to solve the same problem:
   - A control following a traditional UX workflow.
   - A Lean example adhering to a radical build-measure-learn and pivot cycle.
3. Run both of these at the same time, however under different names, and closely track the following:
   - Time spent on both to ensure there is no discrepancy in work effort on one over the other.
   - Page hits to ensure that both receive the same amount of public exposure.
4. After a set amount of time reflect on both products to determine the version that had the most success in:
   - Delivering the more/better real-world outcomes/value to users.
   - Has the clearest road-map/actionable steps for the product going forward.

It’s tempting to assume that the outcome will inevitably point in favour of the radical Lean approach. However, it’s important to note that (to Eric Ries’ own admission) there is no real/optimal form of Lean and that each team should discover for themselves which parts of Lean are beneficial and what parts are detrimental:

Ultimately, the Lean Startup is a framework, not a blueprint of steps to follow. It is designed to be adapted to the conditions of each specific company. […] As a movement, the Lean Startup must avoid doctrines and rigid ideology.

- The Lean Startup (2011)

The irony being that (according to Lean) I should expect my first implementation of Lean itself to be a failure! This means that I’m heading into the experiment not with expectations of wild success, but of spectacular failure and learning from that failure.

I would love to hear whether you found the above useful, or have feedback!. Please send me an email to venterschalk@gmail.com or create a pull request to this article on my Github account

Follow me on Github, I’m always curious as to what everyone in the tech field is working on — so I’ll probably follow you back! 😊

schalkventer - Overview