A Beginner's Guide to Lean Practices and Lean Startup Methodology

Lean Methodologies Lean Start Up Strategy

By Tricia Cervenan

Product development has had many methodologies over the years. We’ve seen waterfall, XP, Kanban, Scrum, “Scrum-but,” “Scrumfall,” and so on. Each one was created to compensate for a process that worked for some, but didn’t work for others. Since developing products can be costly, particularly if the wrong product is taken to market, teams have worked to mitigate that risk by iterating on how they get from idea to finished product. One such way is the concept of “lean.”

Lean was popularized by Toyota in the 1940s in an effort to increase the quality of its products for customers, while still maintaining the efficiency of the company’s assembly line. The idea was that as it continued to optimize the process for quality, anything that was unnecessary in the process would naturally be eliminated. So, when a team utilizes a lean methodology, it is working to achieve some value, with the least amount of waste.

The Lean Startup: Build-Measure-Learn

Lean became part of the software development lexicon thanks to entrepreneur Eric Ries, who in 2008 began teaching his own methodology to software startups. In 2011, he published the book The Lean Startup.

The Lean Startup was innovative and popular among startups because it came at a time when distributing software was no longer about spending two years developing something, packaging it in a box, and selling it on a shelf for the next four years. Since software is now easily deployed over the web, today’s teams can constantly push out new tests, ideas, and architectures that reach their entire user base in seconds.

The book’s main premise addressed this shift by introducing the “build-measure-learn” process to test a hypothesis. Essentially, you start with a problem that you think exists in the market (your hypothesis), build just enough of something for you to measure its success among customers, and use that learning to build something new, add on, or scale. Then repeat. Continue repeating this until the product has reached a steady state and proven that the product is valuable enough to users to have a team of people continue to develop it.

What’s great about the Lean Startup model is that you don’t worry about scale until scale matters. Why build for 100 million users when you haven’t even gotten one yet?

In The Lean Startup, Ries talks about several startups that had success utilizing his methods. One of those companies, Food on the Table, tested out its ideas by providing concierge meal planning for users. Rather than building software first, the founders went to grocery stores, recruited a single user, and provided meal plans to that user for several weeks. The experience allowed them to quickly and easily make changes to their feature set because they simply changed paper forms and how they provided this concierge service. After testing their new plans with a few more users, they went on to build software to reach thousands more. In 2014, Scripps Networks Interactive went on to buy the product and eventually turn it into what is now Food.com.

Skills for Lean Teams

Not all teams are able to function in a lean environment. Some companies have a lot of necessary risk they need to mitigate that generates a need for more process, documentation, and predictability. But for those who are able to cut out unnecessary process, there are a few skills that can be beneficial.

Be comfortable with change.

Since the idea of lean is to adjust based on learning, teams can only function leanly if they aren’t married to their ideas or dogmatic in their processes. This is why lean practitioners love simple tools like whiteboards and sticky notes — what they write or draw on them only takes a few moments to create, and that content is so easy to erase or throw away that it helps keep emotional distance from the idea. That way, they can determine honestly whether they’ve proven or disproved their hypothesis.

Google has popularized the concept of design sprints by utilizing some lean techniques. In a design sprint, participants use letter-sized paper to sketch out ideas and collaborate with one another with the goal of creating a simple paper prototype (though sometimes they use software) that they can then test with users by the end of the week. Teams using design sprints allow ideas to come from all over the organization and uncover answers about product direction. In the process, many ideas are discarded, and the user feedback drives the next sprint’s work.

Communicate well, and often.

Teams that cut out documentation and processes can only be effective if they fill the void by talking to one another, either virtually, in person, or both. It’s helpful to ensure everyone is using similar definitions for words, especially jargon or acronyms, to ensure that there’s a common understanding of how the team is using those words.

Collaborators also need to talk about the things that are and aren’t working for them. To mitigate waste in the work the team is doing, the processes used will constantly need to be evaluated. The most efficient way to do that (without adding more processes) is to do quick check-ins for understanding. This cultivates an environment where colleagues are comfortable speaking up when something isn’t working.

Talk to users.

The only way the build-measure-learn feedback loop works is to put something in front of users and talk to them about what’s working and what’s not. Some might say that quantitative data is sufficient in measuring success, but that view is quite short-sighted, especially when it comes to developing new products. Quantitative data tells you there is a problem, while qualitative data tells you what that problem is and why it exists. It’s only then that teams are able to know how they should iterate on their product.

Lean at General Assembly

As an instructor at General Assembly, I implement lean methodologies in my classroom with each lesson. At GA, we don’t create droning two-hour lectures and then send students on their way; rather, we share many short lectures followed by monitored activities, then check in with the class to ensure students are achieving each lesson’s learning objectives. This way, we can determine who isn’t catching on to what we’re teaching and what types of teaching methods are effective for this cohort of students, and then adjust the current lesson and future lessons accordingly.

We explicitly teach lean skills and concepts during the Lean Startup section of our part-time Product Management course, for which I’m an instructor at GA’s Seattle campus. Namely, we cover hypothesis development, minimum viable products (MVPs) and experiment testing, and the build-measure-learn cycle. And we implicitly practice lean concepts in the way we quickly move from idea to testing with users, to planning future iterations. In a 10-week course, there isn’t time to worry about scale, so students get the opportunity to practice lean skills, giving them the most amount of value from the course with the least amount of waste.

Meet Our Expert

Tricia Cervenan is an instructor for General Assembly’s part-time Product Management course in Seattle. She has been developing products for over eight years and currently helps clients solve software problems at the product agency L4 Digital. You can find Tricia on Twitter at @triciacervenan.

"In teaching GA's Product Management course, my goal is to jump start your understanding of product management, so you can be successful while you refine your skills on the job."

Tricia Cervenan, Product Management Instructor, General Assembly Seattle