Launching a business -- especially a tech start up or SaaS business -- is a risky endeavor. The numbers don’t lie: According to a Harvard Business School study, roughly 75 percent of all startups fail. So when something comes along that promises to stack the odds in your favor, it’s natural that you’d jump on that sparkly bandwagon of promises. And that’s exactly what has happened with the Lean Startup movement, popularized by Eric Ries in 2008.

The appeal is obvious: Instead of spending a ton of time and money coming up with shot-in-the-dark business plans and creating a fully-formed product that may flop, the emphasis is on rapidly iterating through a series of hypothesis, gathering feedback from potential customers, pivoting quickly based on the results of the feedback, and launching an MVP as quickly as humanly possible. If you fail, the thinking goes, at least you fail fast and you’ve saved yourself a lot of trouble (in the form of time and money) in the end.

Whether they’re aware of it or not, most people are actually practicing a Lean/Agile hybrid. Agile predates Lean, and while the idea of iteration is common to both schools of thought, Agile specifically applies to the rapid iterative development of the product software. Iteration can be a great, product-saving process, but with a caveat: It only works if you’re iterating on the right things. Unfortunately, that’s usually not the case with Lean as it’s practiced.

The truth is, no matter what you call it, the widely-practiced permutations of the Agile/Lean hybrid have some fatal flaws, which we will break down in a moment. Despite the many carrots that this methodology dangles in front of hopeful founders, the stick of failure remains very real. And turning failure into a virtue doesn’t change the fact that in the end, it’s still failure.

One reason for this myopic procedural breakdown is the dot com implosion of the late nineties. Although it happened nearly two decades ago, it still exerts an influence on the collective unconscious of tech founders. As Peter Thiel outlines in Zero To One, while Silicon Valley has definitely learned some lessons from the tech implosion, sadly, they haven’t learned the right ones. Two of the misguided lessons are an adherence to incrementalism and an incorrect application of flexibility. Thiel explains the rationale:

• Make incremental advances: Grand visions inflated the bubble, so they should not be indulged. Anyone who claims to be able to do something great is suspect, and anyone who wants to change the world should be more humble. Small, incremental steps are the only safe path forward.
• Stay lean and flexible: All companies must be “lean,” which is code for “unplanned.” You should not know what your business will do; planning is arrogant and inflexible. Instead you should try things out, “iterate,” and treat entrepreneurship as agnostic experimentation.

Unfortunately, Thiel goes on to jump the shark and posit that the opposite of this tentative lean incrementalism is to embrace the idea of the Grand Visionary. This visionary can supposedly see into the future, and magically spin world-changing products out of whole cloth. Thiel stops just short of deifying well known innovators like Steve Jobs, and in doing so misses the point. No one can see into the future. These misguided internalized lessons combined with Lean/Agile as it’s practiced add up to one thing: Lots and lots of failure, albeit quick ones. The opposite of sloppy Lean practices isn’t to create a new mythology. It’s to embrace science, logic, and a sound process.

So let’s back up. Ask yourself: What is your goal? It’s probably some variation of this: “To make a product people will be crazy about. To make a product that people will adopt. To make a product that people will engage with. To have a customer base of highly engaged, avid users.” Avid users after all, regularly engage with your product, and they’re your best cheerleaders. They’ll help you achieve longterm success. But to create such users, you must be providing value and filling a real need -- otherwise why would anyone keep coming back to your product over and over again?

So how do you methodically set out to create these adoption-centric products? Adoption-centric products take a needs-based approach to crafting a solution that eases customer struggles and obstacles while ensuring that you continuously drive adoption and engagement. Well, the name of the method sounds a lot like the goal: It’s called the Knurture system. Here’s how it compares to the less scientific, imprecise Lean methodology you’ve probably been following.

Knurture vs Lean 

Iterate on a Sound Premise

Lean: Ideas-Based Innovation

Knurture: Needs-Based Innovation

There’s nothing inherently wrong with iteration. It’s great, in fact. But not if you start from a shaky premise. If you keep iterating on a bad idea, you’ll only end up with more and more bad ideas. And that’s exactly what’s happened with Lean.

Lean begins with ideas-first innovation, which leads to ideas-first hypothesis and then to ideas-based iterations. In other words, the general practice is to brainstorm as many ideas as possible, and then rapidly iterate through each idea to find the one that sticks. What’s the problem with that? Well, for starters, it isn’t grounded in the actual real-word needs of your customers. In contrast, the theory of Jobs to Be Done, pioneered by Harvard Business School professor Clayton Christensen, shows us that every successful product fills a real need for the customer, better than any other product or method out there. As Anthony Ulwick, a proponent of JTBD theory puts it, “Generating more ideas that don’t meet customers’ needs is misguided, and doing something bad faster does not lead to better results.

What this means is that two time-honored traditions of the startup world, whiteboarding and brainstorming, actually do more bad than they do good. Product teams love to whiteboard. Even more than whiteboarding, product teams love to brainstorm. Want to make a product team happy? Give them three colors of Expo markers, a nice clean wall covered in dry-erase paint, and three packs of sticky notes. They'll be overjoyed. Brainstorming. Whiteboarding. All. Day. Long. Better yet, they'll stay entertained all by themselves. They won't bother any stakeholders nor will they seek out any customers. You could launch their conference room into space and never hear from them again.

Rather than whiteboarding and brainstorming all those ideas in a vacuum and hoping for the best, you need to turn your gaze outward and sniff out those unmet needs. One great place to find these unmet needs is by observing workarounds. Where are people cobbling methods together, or trying to create their own solutions to problems because those solutions don’t exist already? Where are people encountering struggles and obstacles in their drive to make progress with the jobs they need to do? Therein lie your golden opportunities to create a winning product. Have you ever seen someone deep inside a grocery market who is carrying 12 items all precariously stacked on top of a larger item? That's a workaround. By observing this workaround, grocery store managers have realized that they needed to put baskets deeper in the store and not just at the front door.

The Knurture system, in contrast to Lean, starts with observations of customer behavior in order to craft needs-based solutions. The solutions are then expressed in the form of needs based hypothesis. Now, instead cycling through faulty ideas, you can iterate on the best way to present your needs-based product to your customer.

The widespread tendency to cleave to ideas-first innovation probably stems in part from the Thiel-approved myth that to innovate, you must be a visionary like Steve Jobs. But the truth is, Steve Jobs was no mystic. He was a razor-sharp innovator who able to discern unmet needs in the marketplace, and fill those needs better than anyone else. Think of the iPod. Jobs didn’t pull that idea out of visionary thin air. He saw the job people were trying to do: listen to music. The ipod -- with its storage, convenience, and customization -- did that job better than anything else in its time. The result? An army of avid adopters of the product.

Go Big

Lean: Incremental Improvements; Underwhelming Products

Knurture: Drastic Improvements; Adoption-Centric products

As we’ve seen, the dot com bubble burst has caused many entrepreneurs to adopt a timid and incremental approach to product improvements. It feels safer to make small improvements on already-existing products than to take what feels like a gamble and make that big leap.

But the truth is, if you start with needs-based innovation and iterate on your sound needs-based hypotheses, it’s less of a gamble than trying out a bunch of ideas that may seem great but aren’t enough to tempt anyone to switch to your product. Jobs to Be Done theory teaches us that in order to hire your product to do a job, people first have to fire something else. And if you expect them to do that, your product has to be leagues better than what they're currently using. 

As global strategist Pip Coburn points out in The Change Function, it also needs to have a low perceived pain of adoption. In other words, the pain of adopting your product needs to be lower than the pain of whatever users are currently struggling with. That means you must clearly convey the value of your product and make it relatively easy for users to adopt. As a general rule, your product should be 20-30 percent better -- not a mere 1-2 percent -- than what’s on the market if you expect anyone to switch.

In the Knurture method, rather than relying on customer feedback as Lean does, you iterate and observe real measurable behaviors in the Sim Lab to determine your best approach. Feedback is not as valuable as observation. Customers may know what they need, but they don’t know how to solve their problems. Relying on suggestions and feedback is another way to end up with a marginally better product that no one really wants. 

That’s what happened to the-market leader Kawasaki Jet Ski in the 1980s. At the time, standing jet skis where the only models available on the market. Kawasaki asked customers for feedback on how to make their product better. Users said they wanted padding so it was more comfortable to stand for a long time. Kawasaki obliged with this incremental improvement. Meanwhile other companies were busy assessing unmet needs and came up with the drastically better seated model. You can probably guess what happened next: Customers abandoned Kawasaki and adopted the seated models in drives.

The Right MVP

Lean: Minimally Crappy

Knurture: Minimally Awesome

Lean’s obsession with quickness and flexibility often translates into poor quality. The race to rush out an MVP often means rushing out a shoddy product. .. and failing fast. But how can you learn anything from a substandard product? If your objective is to gather data and tweak your product to remove any existing struggles and obstacles, why not instead deliver what author and venture capitalist Sean Ammirati calls a minimally awesome product? As he puts it, concentrate on “Building the least amount of product possible (in an awesome way) that delivers the maximum amount of validated learning.”

As Andy Budd wrote:

In the rush to deliver a minimum viable set of features ... we often ignore the elements that make the product really great … As quality gets stripped back in preference for functionality, we slowly see our products become ever more minimal and ever less viable. It’s very rarely one thing that does it. Instead MVP often turns into death by a thousand paper cuts.

In the Knurture method, your MVP will be based on solid needs-based hypotheses, and with a great MVP you’ll be well positioned to understand how to iterate even further to make your product a success. In other words, we believe in making sure you're building the right thing, not just anything.

So, instead of iterating on faulty premises, think like Knurture and start with needs-based innovation. Then your iterations will be grounded in a solid premise. You’ll be knocking out real user struggles and obstacles and creating adoption-centric products. And instead of getting stuck in the swamp of fast failure, you’ll be well positioned to succeed quickly.