Jeff Gothelf

Can Lean Principles Change the Software Development Process?

Author Jeff Gothelf thinks moving faster and breaking down organizational silos will produce better products.

by Kate Pavao, March 2013

How can company leaders streamline software development to keep up with the speed of business and customer expectations? Jeff Gothelf, managing director of global innovation company Neo and co-author of Lean UX: Applying Lean Principles to Improve User Experience, says one secret is smart collaboration. Here, Gothelf explains the principles of Lean UX, why cross-functional teams build better software — and how to get workers out of their comfort zones so they can contribute the best ideas.


Profit: How does Lean UX differ from traditional user experience?

Gothelf: First of all, the design process itself is not limited to designers. It becomes a collaborative cross-functional effort the entire product team participates in, including engineers, marketers, product managers, business owners, designers and copywriters. Whoever is involved in the project takes part, because the conceptual and consenting phase of the product is a hypothesis, as opposed to a requirement. Your goal as a team is to prove or disprove your hypothesis as quickly as possible. This is classic Lean startup stuff applied to design specifically.

To be effective, managers need to focus their teams on business outcomes, rather than outputs. That means “Increase the number of registrations to our website,” rather than “Build me a new landing page.” You want to get the whole team together brainstorming around ways to solve a business problem, then validating and invalidating their best ideas as quickly as possible.

By including the entire team in the design, they become part of a project a lot sooner than they would have. Their opinions are considered and they see real-time customer feedback help drive some of the decisions. Also, there is a much bigger feeling of ownership throughout the whole team around what you’re doing, why you’re doing it, and why you’re making decisions that you’re making.

Profit: What kind of techniques does Lean UX use?

Gothelf: Lean UX seeks to take the team through the design phase very, very quickly in order to spend less time designing the wrong products, more time designing the right products. Teams can use a lot of the same techniques that user experience designers have been using for decades: Brainstorming and game-storming sessions, customer research and collaborative sketching. Anything that get ideas out of people’s heads and onto some sort of whiteboard or piece of paper starts a much more effective conversation.

The difference with Lean UX is you are doing all this design in collaborative groups and at a lot more rapid pace. When the team finds a solution that it thinks will achieve its business goals, the team members don’t have to wait to start building stuff. They don’t have to wait for specs, wire frames or visual designs. They can start building, because they have been part of the process from day one and know what to build. While designers are refining the sketches into wire frames and then into visual designs, engineers are starting to build the infrastructure to support this feature at the same time.

Profit: Who is leading these cross-functional teams?

Gothelf: In my experience, the most successful teams practicing any kind of Lean startup or Lean UX in the enterprise are led by a triumvirate of a tech leader, a design leader and a product leader. There’s a level of democracy in the brainstorming and concepting, and everyone feels represented. I advocate for teams of roughly 10 people, but you can’t make fast decisions with a team this size, no matter how well they work together. When it’s time to actually pick ideas and move forward, it’s the triumvirate that decides how to prioritize.

Profit: How do you make sure team members feel comfortable participating?

Gothelf: There are some folks who are so ready for this and are so sick and tired of silos and the rigidity of job titles that they want to be involved in the process. They want to contribute and they want to hear what other people have to say. But a significant number of individuals in every discipline — engineering, design, UX, product management — are not ready to make this transition. And the reason for that is the process itself values competencies over roles. There are folks who are very concerned that their role will be devalued. But, the goal is not, for example, to get engineers to design. The goal is to get them to voice their points of view and participate in the process.

At Neo, we lead a lot of workshops to kick off these teams on Lean UX adventures. If these teams have never worked together, we definitely do some icebreakers. One tool we use in almost every workshop these days is a game called “Telepictionary.” You start off with an idea or phrase, like “An apple a day keeps the doctor away.” You write down the words for it, and ask your colleague next to you to sketch a picture of that phrase. Then, they hand the picture to the person next to them and they have to guess what phrase it is. And the person next to them sketches the guessed phrase. This goes around the whole circle until you end up with something bizarre like, “I’m an apple salesman.” This exercise does four things: it’s an icebreaker; it’s fun; it gets people drawing; and it teaches a subtle lesson about the risk that comes with explicit handoffs.

Profit: What are some of the common misconceptions teams have about Lean UX?

Gothelf: The first one is that this is lazy UX. Actually, you are doing a ton of UX work. When you remove the heavy documentation piece out of the process — which is what Lean UX does — all of the sudden it feels like you are doing less work, but what you actually doing is approving and disproving your design ideas more often and more successfully.

The other big misconception is that it is design by committee. And that can be easily conceived because all of the sudden you are opening up the design process to all these other people. This can be intimidating for designers. But what they’re actually doing is gaining validation for design ideas just earlier in the process. The designer still must pull out the best ideas, incorporate them, and push them forward in ever iteration.

Profit: What are you hoping to change with your book?

Gothelf: I hope for the busting of corporate silos because that will bring greater cross-functional collaboration. I want it to be OK for an engineer to attend something called a Design Studio, to formally work on design problems with other team members rather than being told, “You better write code.” By breaking down silos and increasing cross-functional collaboration, we’re going to see a lot better software in the world.