The Lean Startup Trap
The Big 3 ‘Lean Startup’ Mistakes Companies Still Make
Are you spending a ridiculous amount of time working on a product, and getting nowhere? Spinning out release after release, but gaining no meaningful traction?
Do you feel like you have no time to think? You’ve got backlogs to prioritize, design meetings to facilitate, Scrum meetings to run, and velocity charts to review.
Is your MVP (Minimum Viable Product) turning into a BFHP (Big Fat Honking Product)? Does it always need “just one more thing” to make it all work?
If this sounds like you, you’re probably stuck in the lean startup trap. And you’re not the only one. The Lean Startup, a book promoted by Eric Ries (and his mentor Steve Blank), has become the de facto methodology for anyone building new products & features.
Everyone is ‘running lean’ these days. Iterating from idea to idea. Throwing up landing pages. Setting up Facebook ads. Building MVPs …and experimenting like it’s the 60s all over again.
The generally spouted rhetoric is this: successful innovation is a numbers game. The probabilities are tied to the number of ideas you generate, and how many experiments you run.
Fail-fast, and fail-cheap, they said.
As many have started to notice: in practice, those failures are neither fast, nor cheap.
So how did this happen? And how do we fix it?
1. The root of the problem — The idea
The problem in lean startup originates right at the first step. Most projects start as an idea.
Think about the last time you worked on a startup idea, innovation project, or added new features to your product. In most cases, what you decide to build starts off as an idea that someone on the team had. This is the problem with most new products and feature ideas: the lack of effort to understand if customers need your idea.
When teams try to get market validation on their idea, the validation often tends to be biased. That’s because, they have anchored on understanding the value of this one idea versus understanding the greater set of needs the customer has.
If your idea is X and you ask your customers if they want X, they may say yes. They’ll say yes, even though ‘Feature Y’ is a much bigger need for them.
At best case, this leads to innovation efforts that hit a local maximum in terms of customer value: The idea. In the worst case, you’re building something that your customers don’t need or care about.
2. The Runaway MVP
The allure of lean startup is its simplicity: take an idea, build an MVP. Then throw it out into the market and see how the market reacts, and finally, iterate. It sounds like good logic, but there are multiple challenges with building an MVP:
Most teams over-engineer their MVP. This is natural. “It’s my idea so I have to stand by it.”
What started off as a couple of features morphs into a bloated product release, without a proper understanding of what your customers even wanted. Because of this, most MVPs take a lot longer to complete than initially expected.
An MVP is supposed to help you test a product or customer hypothesis in the world of lean startup. But most teams do a poor job of constructing hypotheses, or laying out their expectations of what the product release is meant to get them.
Launching or demo-ing your MVP is usually the first attempt at getting customer feedback. In many cases, the feedback received is unclear and misleading.
At times you hear: “oh yeah this makes sense” or, “this is a cool product”. The challenge here, once again, is that you’ve anchored the customer on your solution without even understanding if they have that problem.
You launch, no one uses it, and you assume it must be the UX. People don’t get it. Or a customer tells you: why don’t you add this one feature. And along you go. Anchored to your solution, iterating from product release to product release, hoping to discover the missing piece that will make your vision come alive.
Ironically, in startups, you get some reprieve and a hard stop when you run out of money. In larger enterprises, this hunt for the missing piece can take years, and tons of $ flushed down the drain.
3. Agile Software Development
Once innovation teams start down the path of building an MVP, they usually employ Agile methodologies (particularly Scrum) to iterate along.
For teams that don’t have a clear understanding of their customer needs, Agile is like adding gasoline to the fire.
Many product owners are waking up to the challenge of using Agile: it’s like a dumb machine. Garbage in — garbage out. And once you’re on the Agile train, it’s like a never-ending treadmill going nowhere.
It feels like you’re doing a lot, because the data in your velocity and burndown charts show how much progress you’ve made. Right?
But (without even knowing it), you’ve shifted your focus from understanding customer needs. You’re now focused on ensuring your Agile train is moving efficiently. People are depending on you to make sure they have work to do in the next sprint. And for a little while, it feels good because you’re getting s**t done!
You launch your product to major fanfare. There’s lots of excitement, congratulations, and pats on the back …for the first few weeks. Slowly, that excitement wanes, as you come to the painful realization that the one group you wanted a pat on the back from, your customer, doesn’t really care for your product. Your output was strong. But the outcome, not so much.
The Fix:
Alright, so what does all this mean? Do we give up on Lean and Agile, and go back to the days of Waterfall product development practices?
Nope.
Here’s how we get back on the right track:
If we think about our lean product development efforts as layers of a cake, we see something that looks like this. Idea -> Build MVP using Agile -> Get feedback to validate customer needs.
There’s something fundamentally missing here: a good foundation. A foundation should start with a deep understanding of customer needs, and specifically, teasing out under-served needs. We need a cake that looks like this:
The lean startup movement is significantly more efficient when the ideas you’re working on are pulled from a list of prioritized customer needs. When you get in the right ballpark of customer needs, lean startup becomes a more effective way to determine how to solve those needs. Lean startup sucks at discovering your customer needs.
You can discover customer needs more efficiently and accurately by conducting customer interviews. Or doing ethnographic research into customer behaviours. There’s tons of great material on how to do this effectively on the web, so I won’t reiterate how to conduct good customer interviews, but I highly recommend getting into a practice of continuous customer discovery. More specifically, invest in any means you can to get in front of your customers on a regular basis. From there you can understand the challenges in their lives, and where you can add value with your product. You should continue to have these discussions as you are building out your product.
Customer Needs: Choosing the Right Ones
Now that you’ve got the order right, and are focusing on understanding your customer needs first, it’s important to ensure that you’re picking the right customer need(s) to address.
To do this well, you can leverage a technique created by Tony Ulwick and the team at Strategyn. This will uncover your customer’s underserved needs.
Map out the feedback you’re getting in your customer interviews into a two-dimensional graph. On the x-dimension, is the importance of the need, in the eyes of your customer. On the y-dimension, is how satisfied the customer is with their current solution that addresses that need.
Looking at your customer needs through both dimensions enables you to quickly identify the underserved needs in your market.
This is where you want to focus your time and efforts.
Innovation teams intuitively understand the ‘importance’ dimension when looking at customer needs, but often overlook the current satisfaction dimension. Current satisfaction should not be ignored, as the push in getting customers to use your product is inversely correlated to the pull (current satisfaction) they have with their existing solution.
For example, I’ve repeatedly seen teams build products that are trying to replace Excel for their customers, and fail to gain traction because the customer was already satisfied with the Excel approach to solving their problem.
Let’s map out a few of Google’s products to see the power of visualizing customer needs through both the importance and satisfaction dimensions:
Google+ was a social network product built by Google to compete with Facebook. The customer need Google was addressing here was to help people stay in touch with their friends. Not surprisingly, they didn’t get much traction, as people were already satisfied with how Facebook handled that need.
Google Glass, once dubbed the computer you wear on your face, was another product built by Google. In this case, Google believed that customers wanted a digitally augmented view of their day-to-day lives. Google quickly found that this was not an important customer need, as early users complained that they did not find much use in the product. Even though there was nothing like it available (pointing to a low satisfaction in addressing this customer need), it failed to gain any traction outside a few Silicon Valley pundits.
Google Maps is a navigation service used by many people on their smartphones. In this case, Google hit the mark. Navigation is not only an important customer need, but it’s also a need that is unsatisfied for customers without dedicated GPS units. These customers would gladly replace their paper maps with the convenience of a navigation service that’s always in their pockets.
By now, I’m hoping you see the value in a two-dimensional view of customer needs. It represents a good proxy to understand customers motivation to use your product.
If your customer need is under-served, their motivation to try, engage, and even purchase your product is high. If your customer need is over-served, everything gets harder. This is how some products build a cult-like following (e.g. Craigslist), with a basic looking product, whilst others struggle to gain any traction with a feature-rich product.
This all highlights why understanding and addressing the right customer needs is critical for lean startups to get right.
I often ask teams to objectively map out the customer needs they are targeting on these graphs. It’s an incredibly eye-opening exercise, give it a try and post your thoughts in the comments.
