Do You Have Faith in Lean Startups?

I’ve watched Eric Ries’ blog grow from 5 subscribers to 60K+ subscribers in two years, which is great for the Lean Startup movement. And as with any fast-growing movement, Lean Startup has picked up its share of evangelists, believers, fanatics, skeptics, atheists, and heretics.

Unfortunately, these roles are primarily defined by levels of faith which is a problem.

Faith versus Belief

While entrepreneurs need to hold strong beliefs, there is a difference between faith and belief.

faith = blind belief i.e. not based in proof

I believe there is no room for faith in a Lean Startup — not even in the methodology itself.

Decouple faith in yourself with faith in your beliefs

The one exception for faith in a startup is the duality Jim Collins describes in his book “Good to Great” as the Stockdale Paradox:

“You must never confuse faith that you will prevail in the end — which you can never afford to lose — with the discipline to confront the most brutal facts of your current reality, whatever they might be.”
- Admiral James Stockdale

The key takeaway for me from this quote is that most entrepreneurs tend to be optimists who build their reality distortion fields as a survival tactic. Reality eventually catches up. It is less wasteful to embrace reality upfront.

Faith in yourself manifests itself in different ways. In Silicon Valley, for instance, it is not uncommon to see serial entrepreneurs tackle the same problem domain over multiple years, teams, and even companies.

Crossing the Chasm

So far, the Lean Startup movement has been mostly driven by early adopters who had a visceral reaction to the problems/solutions surfaced by Steve Blank and Eric Ries, and who were willing to do something about it (i.e change behavior, run meetups, start a google group). My rough characterization of these early adopters is second and third-time entrepreneurs who have had their reality distortion fields challenged by reality.

But as the Lean Startup movement starts to move beyond early adopters, there will be more resistance to behavior change which will result in even more faith-based snap judgments and debates.

Agile faced this chasm and, much to the dismay of its early adopters, fell into it to appease the mainstream market. But I believe there is hope for Lean Startups.

Lean Startups are fundamentally about building continuous learning organizations. So, at least in theory, we should be able to learn our way around this chasm.

But we must stop blindly chasing tactics and start asking why and measuring results. The same meta-pattern used to vet product hypotheses can and should be rigorously applied to the methodology itself.

The Lean Startup Adoption Cycle

Judging by the number of Lean Startup events, cumulative blogs/readers, book purchases, tweets, etc., I would say the acquisition and referral triggers are healthy. But as with any “product,” the key to success is ensuring a great first user experience (activation) and a compelling reason to keep coming back (retention).

I recently started a “Running Lean Chat” experiment where I invite my book readers to talk with me one-to-one about how they are applying these techniques to their products.

What has come out of that is a recurring activation flow for first-time Lean Startup practitioners that I’ll describe below:

How to Run Your First Lean Startup Iteration

The key to a good activation flow is demonstrating the unique value proposition as quickly as possible. In the case of Lean Startups, the UVP is “validated learning from customers.”

Last time I introduced an iteration meta-pattern which was built up of several smaller Build/Measure/Learn experiments to validate a bigger initiative such as an MVP, feature (MMF), and in this case, the adoption of the Lean Startup methodology.

Understand Your Problem

The first step is confronting your brutal reality. You need to understand the stage of your product and identify your most immediate problem(s).

The best way to do that is to:

  1. Build a one-page business model diagram documenting what you currently believe to be true (hypotheses). I am biased towards using Lean Canvas for this but use whatever format works for you.
  2. Arrange a meeting with your co-founders, advisors, and investors to review your current model
  3. Identify the riskiest untested hypotheses prioritized by the stage of your product

Define Solution

Lean Startup is chockfull of techniques, but what technique you use is driven by the stage of your product (Right Action, Right Time). Implementing wrong tactics is a form of waste.

Most founders incline to start with shiny objects like running an A/B test, instrumenting their app, or implementing continuous deployment (we love building more stuff). The advice I’ve given almost everyone so far is to put down the keyboard and get out of the building first.

What you think you need to test is only the first step. Talking to customers helps validate if these are indeed the right problems to tackle and, more importantly, helps uncover possible solutions and techniques for testing them.

Not only does getting out of the building yield the most “validated learning” (UVP) per pound of effort, but it is also the riskiest part of the Lean Startup adoption cycle (behavior change).

  • If you have no users, take whatever you have (hypotheses, screenshots, demo) and run a few problem and solution interviews. Validate Problem/Solution Fit.
  • If you do have users, do you know who is using your product and who isn’t? Arrange meetings with both. Ask how they found you (channel), why they are still using your product or not (UVP), and what is missing from the product.

Validate Qualitatively

Speed is key which is why I advocate starting with smaller experiments and implementing a two-phase validation — first qualitative, then quantitative. Your first objective is to get a strong signal.

Lean Startups are not cheap and not free.

Instead of talking to customers, you could have been building more stuff. Review the learning from the interviews with your team. Was it worth it? Did it yield actionable learning? Did you learn something new? Did it stop you from going down the wrong rabbit hole?

Verify Quantitatively

If yes, implement a few small experiments and measure the results. Start running more experiments, track your macro metrics, and gradually introduce other techniques only when needed.

While the end goal is to see a positive correlation between the usage of these techniques and an improvement in your product’s macro metrics, that correlation probably won’t be immediately apparent. The path to product/market fit is largely flat initially, requiring several course corrections driven by good judgment.

What you should measure instead is:

- How long does it take to judge what to do next (pivot)?
- Are your judgments getting more informed (by customers, by data)?
- Are you saving time elsewhere (not building unwanted features, reducing integration debt, etc.)?

Lead with Skeptical Optimism, Not Faith

It is too early for dogma. Lean Startup itself is a collection of bold hypotheses. Separate meta-principles from tactics. Test both. Rather than debating, run a few bold experiments instead. And above all, share your learning.

Do or do not… there is no try.
- Yoda
You've successfully subscribed to LEANSTACK Blog
Great! Next, complete checkout to get full access to all premium content.
Error! Could not sign up. invalid link.
Welcome back! You've successfully signed in.
Error! Could not sign in. Please try again.
Success! Your account is fully activated, you now have access to all content.
Error! Stripe checkout failed.
Success! Your billing info is updated.
Error! Billing info update failed.