I was on a call last week with the Head of Digital for a very large global telecom company, talking about how they approach the development of innovative new products. “With any startup or new product there are 99 paths to failure and one path to success”, he told me “so I encourage our managers to use a process like Lean UX as a way of increasing their chances of launching a successful product”. 

Lean UX is a term coined by Jeff Gothelf and Josh Seiden in their book of the same name published last year. It’s not really about User Experience (UX), per se, just as Design Thinking is not about design. Rather, it’s about a process to use in developing products that are more likely to succeed. 

For me, the Lean UX process is sort of a unified field theory, a way to combine “Agile Development”, “Design Thinking”, “Lean Startup”, and “Agile DevOps” one well-articulated set of values and methods for building great digital products. Or, as the authors of the book put it, “Lean UX is a process inspired by Lean Startup and Agile Development. It’s the practice of bringing the true nature of a product to light faster, in a collaborative, cross-functional way.”

Software product development was once a process framed by requirements and deliverables. It was a linear process that went from Silo A to Silo B to Silo C, and then eventually the software was released and then Version 2 would begin its path along the same linear process (unless customers hated Version 1, in which case there wouldn’t ever be a Version 2). Over the past few years Design Thinking has changed the way we think about designing products and Agile Development has changed the way we make them. Meanwhile, we’ve seen DevOps emerge as a way of unifying the whole software development lifecycle, and we’ve seen Lean Startup become the bible for launching products and companies in a way that shortens cycle times and creates products that are better informed by real-world customers. 

The common threads that run through these frameworks and practices have to do with breaking down the silos that once existed between marketing, product management, engineering, test and QA, and ops managers, and instead creating a results-driven iterative process. Lean UX unifies these threads into a single book.

Lean UX is a process inspired by Lean Startup and Agile Development. It’s the practice of bringing the true nature of a product to light faster, in a collaborative, cross-functional way. 

The book begins with the sentence “The greatest lie in software is Phase 2” (which may be my favorite opening line since “Call me Ishmael”). If you’ve been involved with software development projects before, you know that inevitably there ends up a list of features and ideas that you can’t get to this time, but everyone agrees they should be in Phase 2. And then usually that list gets lost and never again sees the light of day. Lean UX proposes a process based on experimentation, rapid iteration of ideas, and evolutionary processes that render the whole idea of Phase 2 moot. Because software today is about continuous development, not versioning. Amazon pushes new live code to its customers every 11.6 seconds. Think about that for a minute. It’s a whole new world in 2017. 

With all of this in mind, the authors of Lean UX suggest the following principles to use in developing digital products and platforms today:

• Favor collaboration and conversation over fixed deliverables and rigid process.
• Always favor working software over comprehensive documentation.
• No rock stars, gurus, or ninjas. A team-based mentality always yields the best outcomes. Fire anyone who doesn’t get this. 
• Value making over analysis. Don’t waste an entire day in a conference room with 10 people debating what customers want. Build a prototype and find out what customers want. 
• Get out of the deliverables business. Documents don’t solve customers’ problems, good products do.  
• Minimum Viable Products (MVP’s) are for learning (see my previous post on this topic). 
• Prioritize ruthlessly. Apply a simple 2-dimensional rubric where proposed features are assigned a importance value and a difficulty value. Prioritize the ones that have high importance and low difficulty. 
• Reframe design conversations in terms of business objectives. 
• Small, agile, and self-sufficient teams are what develop great products quickly (Amazon uses what they call the “2-pizza rule” – a team should never be larger than two pizzas can feed). 

All of this maps pretty well to the Innovation Engineering process that we use at Tivix. The values articulated in the Lean UX book are the same values that we bring to client engagements at Tivix. What we care about is delivering successful digital products and platforms to our clients, and the principles of Lean UX are core to our Innovation Engineering process for getting there.