Lean Startup Machine Writeup – Munich 2014

It has been a while since I attended the August 2014 Lean Startup Machine workshop in Munich. Still the memory is vivid and I would like to share some of my thoughts and learnings with you.

What is it?

In a nutshell: “The team that shows, through evidence, the most customer validation for a new product or service” wins the Lean Startup Machine Workshop. Where do the teams come from? Easy, stand up and pitch an idea in front of 100 people. After the pitching, a quick people basar happens and the teams form. The next steps are building a common understanding of the idea and then designing the first experiment using a template whiteboard pinned to the wall, called the “javelin board”. The experiments are key to gaining validated knowledge, as they focus the whole group on the most important/riskiest question and agreeing on an objective and measurable goal before starting the experiment.

The whole weekend is organized around going through a series of these experiments, each time evaluating what was learned and deciding as a group to either pivot and change some aspect of the idea or to persevere. In between running the experiments helpful information is provided through talks and handouts and a team of mentors is there to help each team to make progress. The methods taught during the workshop are heavily based on Steve Blank’s “Customer Development” and primarily involve literally getting out of the building and talking to potential customers. Only after it can be shown that customers really have the problem, and that the problem really matters to them, is a potential solution pitched and developed. Each successful experiment gets the group closer to paying and engaged customers.

Why does it matter?

Why would one go through the hassle of locating and approaching potential customers and getting into difficult conversations about their problems? Isn’t that wasting precious time in which the first features of the product could have been developed and marketing materials could have been designed?

It comes from an understanding that a startup is a venture into the unknown, built on assumptions, not facts. The strategy is to learn about the highest risks first so that adjustments can be made quickly and little time and money is wasted on dead ends. And often the highest risk lies in building a product nobody cares for. In these cases, the highest priority becomes validating that customers exist and that they care enough about the problem the product is going to solve for them. Steve Blank explains product risk and market risk in more detail in this blog post .

Speed is achieved by relying on fast feedback techniques. Customer interviews allow for immediate judgement based on body language, landing pages validate interest in a product based on only a description of the product and concierge methods allow serving the first real customers before the product has been designed and built.

Top takeaways

Going into more detail, here are the most important things I learned from applying these methods over the time of the workshop:

Be as explicit about customers as possible

It can be hard to design an experiment for a customer segment that is too broad. “What do bass players in a Munich heavy metal band care about?” is a much easier question to answer than “What do musicians care about?”. The more explicit the customer segment, the easier it is to find the customer and to understand their top problems and needs.

“Currencies” are key to interviews and validation

Is is easy to have an interview that feels good but that did not provide any real validation for an idea. The key is to know the “validation currencies” and specifically dig for them during an interview. Important currencies are time, data, reputation and money. Past experiences count, future behavior and opinions do not.

Hard to stick to vision while staying flexible to pivot

In our and in other teams during the workshop it was hard to strike a balance between holding on to a vision and pivoting after experiments that did not show a strong positive customer response. If you have any hints on this, please leave a comment!

Learning over product completeness before validation

Going as far as providing a service manually (concierge) to learn quickly, shows that executing the experiment is more important at this stage than product completeness. Comparing this to the definition of done (DoD) of a Scrum team shows a different focus. The interesting question arises, when to aim for completeness and when for quickness.

As a software developer, I know that a system developed with quickness in mind will quickly evolve into a system that slows everything down. It might make sense to agree on a different DoD for the initial learning and validation of a product feature and complete the product according to the full DoD only after the learning showed the value and effectiveness of the feature. First aim to learn, then aim for maintenance.

Thanks for reading
Please share your thoughts and experiences on this subject