Introduction
A Tale of Two Entrepreneurs
I’m going to start by telling you a story about two entrepreneurs. Let’s call them Steve and Larry. Both of them studied at the same university and got good grades, and after graduation, both worked at a high-tech startup where they quickly grew into key roles.
After a few years, they both got hit with an idea for a startup and decided to quit their jobs and venture out on their own. Even though I’ve given them names to make them more personable, I want to emphasize that what makes them similar isn’t their age, gender, or geography, but that they both were struck by a “big idea” and decided to act upon it.
Now, what differentiates them is how they look a year later (Figure I-1).
Figure I-1. Steve and Larry look quite different a year later
A year later, Steve is still building his product. He has no product revenue and relies on part-time freelancing work to fund his product development. And he works alone. Larry, on the other hand, has a growing customer base, growing revenue, and a growing team. How did they end up in such different places?
To answer that question, let’s travel back in time.
One Year Ago…
Steve is at his desk, lost in thought. Earlier that day, his manager told him that their parent company (following on from a recent acquisition) would be shutting down their offices in a couple of months. And Steve was given the choice to either relocate to headquarters or take a severance package.
Steve reads this as a sign.
He had always planned on starting his own company when the timing was right. After graduating from university, he made a conscious decision to join a promising startup, in order to gain some firsthand experience before venturing out on his own. Even though this startup had a few bad product starts, they did eventually manage to get acquired. Steve felt really proud to have been part of the core team.
“This may be as good a time as any,” he thinks to himself. He decides to take the evening to think things over.
Steve estimates that if he keeps his expenses in check, the severance package and his savings will provide him with a year of runway to get something off the ground. He does have this one augmented reality/virtual reality (AR/VR) idea that he’s been noodling around in his head for a few months already…
The next day, he decides to take the plunge and accepts the severance package.
Off to the Races
Steve wastes no time getting to work. He anticipates that if he stays focused and works full time without distractions, he should be able to launch the first version of his product in three months (Figure I-2).
Figure I-2. Steve in the metaphorical garage
He wants to go about things the “right way,” so like a craftsman, he meticulously begins designing and building his product.
But little things start taking longer than expected, and the delays add up—weeks quickly turn into months.
Six Months Later
Steve is starting to get nervous. The product isn’t up to his standards, and his revised estimates put the launch date out at least another three months, or maybe even six.
He’ll be out of money by then.
He realizes he needs help.
Steve hits up some of his close friends and tries to recruit them, offering up generous equity in exchange. But they don’t see what he sees and find it hard to justify leaving their secure, well-paying jobs (Figure I-3).
Figure I-3. Nobody sees what Steve sees
Steve attributes this setback to a “lack of vision” on his friends’ part, and is even more determined to find a way to finish his product.
He decides to hit the pitching circuit and raise money.
He starts by contacting his previous startup’s founder, Susan, who readily agrees to meet with Steve. Susan likes the idea and offers to introduce Steve to a number of investors.
She leaves him with this advice: “Make sure you put together a bulletproof business plan first.”
Steve has never written a business plan before. So he downloads a few templates and picks one he likes. As he starts writing, he finds that he doesn’t know the answers to many of the questions being asked, but he does his best anyway to complete the plan.
He’s especially encouraged by the financial forecast spreadsheet. The more he plays with the numbers, the more he’s convinced that he’s on to something really big. He decides to tweak a few numbers downward, though, to downplay the fantastic model he has created—it’s so good, people might not believe him!
He knows a lot is at stake, so he spends many more days developing his elevator pitch, outlining his product roadmap, and polishing his 10-page slide deck.
He reaches out to Susan a few weeks later, who helps him set up a half-dozen meetings with investors. Steve is a nervous wreck during the first few meetings, but thinks they go okay. He starts to get more comfortable with practice and feels a lot better about his later meetings.
He doesn’t get an instant “yes.” But at least he doesn’t get an outright rejection either. He debriefs Susan later, who reluctantly bursts his bubble: ”Sorry, Steve, but ‘you’re too early for us’ and ‘let’s touch base in six months’ are code for ‘we’re not interested, but we’re too polite to say no!’” (Figure I-4).
Figure I-4. Investors have mastered the art of the polite “no”
Catch-22
Steve is in a classic catch-22. He can’t make people see his vision until he completes his product, but investors won’t give him the resources to complete his product (Figure I-5).
What is he to do?
Steve still believes in his product and is determined to build it.
He retreats back into his metaphorical garage and decides to self-fund his idea with part-time freelancing.
Figure I-5. Steve is in a catch-22
Progress is slow, but at least he’s still working on his product nights and weekends, moving his idea forward.
Now, let’s turn to Larry. He too was hit by an awesome idea a year ago, but unlike Steve, he doesn’t start with a build-first or investor-first approach. That’s because a build-first or investor-first approach is backward.
A Traction-First Approach Is the New Way Forward
Larry recognizes that a build- or investor-first approach used to work at a time when building products was really hard and expensive, but the world has changed.
Investors used to value intellectual property and funded teams that demonstrated they could build stuff. But this is no longer the case.
Also, because building products often used to be prohibitively expensive, teams that managed to raise funding used to have a significant unfair advantage over others, because they could get to market faster and learn faster than their competitors. Even if they got the product completely wrong the first time around, they could still manage to course-correct and get back on track because there were very few competitors nipping at their heels.
But the world is quite different today… (Figure I-6)
We are living through a global entrepreneurial renaissance. Today, it is cheaper and easier than ever to build a product, which means that there are many more people “starting up” all over the world. While this explosion in startup activity represents an incredible opportunity for all of us, it comes with a dark cloud: more products translates to more choices for both investors and customers, making it harder to stand out.
Figure I-6. We are living in a new world
Investors today don’t value intellectual property, but traction. Traction isn’t about being first to market, but first to market adoption.
Traction is evidence that people other than yourself, your team, and your mom care about your idea—aka customers. More importantly, traction is evidence of a working business model.
Investors today don’t fund solutions that work; they fund business models that work.
But how do you demonstrate traction without a working product? Aren’t we back to the catch-22? Not really, because Larry knows that customers today are constantly bombarded with a multitude of product choices. When customers encounter a half-baked product, they don’t turn into beta testers and give you feedback; they leave.
Without customer feedback it’s too easy to fall prey to the “build trap,” where a breakthrough always seems one killer feature away but remains ever elusive. You end up spending needless time, money, and effort building something nobody wants, until you run out of resources.
Larry has experienced this build trap one too many times before with his startup’s past products, and he decides to level up his game and start with a better foundation for his product. A fundamental mindset shift for doing that is starting with problems before solutions.
Customers don’t care about your solution; they care about their problems.
He understands that if his product doesn’t solve a big enough problem for his customers, no amount of technology, patents, or giveaways can save his business model.
This leads to a number of epiphanies for Larry:
Larry spends half an afternoon sketching out a business model design for his idea using a 1-page template (Lean Canvas) that was recommended to him by one of his trusted mentors.
He then tests the viability of his business model using a quick back-of-the-envelope calculation, and from there builds out a traction roadmap that highlights his key milestones. This helps him map out a bottom-up go-to-market validation strategy (Figure I-7).
Figure I-7. Larry does some quick business modeling of his idea
A key difference of his validation strategy from Steve’s is that he prioritizes testing what’s riskiest versus what’s easiest in his business model.
Larry correctly recognizes that in the new world what’s riskiest for most products has shifted, with customer and market risks outweighing technical risks.
The challenge question today isn’t “Can we build it?” but “Should we build it?”
This is why he decides to take a traction-first approach versus a build-first or investor-first approach.
And here’s the really counterintuitive bit: you don’t need a working product to uncover problems worth solving, or even to land your first batch of paying customers.
Unlike Steve, who is still perfecting and polishing his product a year down the road, Larry manages to define his minimum viable product (MVP) in less than eight weeks, with a growing customer pipeline.
A minimum viable product (MVP) is the smallest solution that creates, delivers, and captures customer value.
Following this approach, Larry avoids spending needless time, money, and effort building a product he hopes customers will buy and instead builds a product he knows customers will buy.
This puts Larry’s idea on solid footing, and he spends the next four weeks building out a first version of his solution which is aimed not at everyone, but at his ideal early adopters. Once his MVP is ready, he doesn’t do a big-bang marketing launch, but rather soft-launches his product to just 10 early adopters and starts charging them from day one.
His logic for starting small and making a bold promise is putting his money where his mouth is. He thinks to himself: “If I can’t deliver value to my first 10 handpicked customers, what makes me think I’ll be able to do that with thousands of customers trying the product on their own?”
A nice side effect of starting small is that Larry can afford to provide a high-touch customer experience. This lets him sidestep a few shortcomings of his MVP and still overdeliver on value, while maximizing learning from his customers.
His first batch of customers is blown away by Larry’s attention to detail and responsiveness to their needs. He manages to convert all of them into true fans while continually refining his MVP.
Even though Larry is a jack-of-all-trades, he recognizes that he can’t scale his business on his own. So he invests a third of his time in pitching his vision to potential cofounders. He doesn’t look for people just like him, but rather searches for people with complementary skill sets to his. He knows that:
-
Good ideas are rare and hard to find.
-
Good ideas can come from anywhere.
-
Finding good ideas requires lots of ideas.
The fact that Larry already has happy paying customers (early traction) and a growing customer pipeline enables him to attract and recruit his dream team.
Too many teams take a divide-and-conquer approach to testing their business model, where they split their focus based on individual team member strengths. For example, hacker types typically focus on products, and hustler types typically focus on customers. This spreads the team thinly across many different priorities and is suboptimal.
Larry instead harnesses the full potential of his team by getting them to collectively focus on what’s riskiest rather than what’s easiest in the business model. As the risks in a business model are constantly shifting, he establishes a regular 90-day cycle in order to maintain a sense of urgency and keep his team externally accountable.
Each 90-day cycle is broken into 3 key activities:
- Modeling
- Larry’s team kicks off each 90-day cycle by updating and reviewing the business models (using a Lean Canvas and traction roadmap). This helps the team constantly realign around a common set of goals, assumptions, and constraints.
- Prioritizing
- The team then collectively prioritizes the riskiest assumptions and proposes a number of possible validation strategies (campaigns) for overcoming these risks.
- Testing
- As it’s hard to know which campaigns will work at the outset, instead of making a few large bets, the team makes many small bets on the most promising campaigns using fast iterative experiments. The learning from these experiments helps Larry’s team identify and double down on the best campaigns (Figure I-8).
Figure I-8. The Model-Prioritize-Test cycle
Each 90-day cycle ends with a cycle review meeting where the team reviews what they did and what they learned, and plans for what’s next.
This Model-Prioritize-Test flywheel allows the team to systematically search for a repeatable and scalable business model. The journey isn’t a straight shot to success. There are twists and turns, dead ends, and backtracking. But because Larry’s team is moving fast and constantly learning, it’s able to avoid huge big-bang failures by making many small course corrections along the way.
By the end of the year, Larry’s customer base is growing, his revenue is growing, and so is his team. His business model is on track to achieve product/market fit.
What Determines Success Isn’t Differing Skill Sets But Differing Mindsets
The difference between Steve and Larry is not differing skill sets but differing mindsets.
Steve is operating like an Artist and is primarily driven by his love for his product (solution).
You can easily substitute Artist with Software Developer, Designer, Creative, Maker, Writer, Author, Hacker, Inventor…
He takes a build-first approach, which in today’s world is highly risky.
Larry, on the other hand, is operating like an Innovator.
Innovators turn inventions into working business models.
He recognizes that we are living in a new world where the rules have changed. Today, it is no longer enough to simply build what customers say they want because, by the time you build that, you’ll have learned that what they really wanted was something quite different.
In this new world, the only way to ensure you build what customers want is to engage them continuously.
The Stakes Are Much Higher This Time
The old way of building products used to work at a time when there were huge barriers to entry and few competitors. Even if you got the product completely wrong, you had time to course-correct and get back on track.
But fast-forward to today, and it has become cheaper and faster than ever to introduce new products, which means there is a lot more competition than before—both from incumbents and from new companies starting up all over the world.
In the old world, failing to deliver what customers wanted led to failed projects. But in the new world, continually failing to deliver what customers want leads to total business model failure.
This is because customers today have a lot more choices than they did before. If they don’t get what they want from your product, they simply switch to something else.
At the other end of the spectrum, the most successful companies today realize that good ideas are rare and hard to find, and that the best way to find the next big idea is to quickly test lots of ideas.
While the early adopters of this new way of working were high-tech startups like Airbnb and Dropbox, over the years continuous innovation has been increasingly applied in many different domains, and it works even at massive scale. Some of the most valuable companies in the United States, like Google, Netflix, Amazon, and Facebook, all practice a culture of Continuous Innovation.
Speed of Learning Is the New Unfair Advantage
Companies that continuously learn fast outlearn their competition and get to build what customers really want.
This is the essence of Continuous Innovation, and it’s the approach that Larry takes. When you’re going really fast under conditions of extreme uncertainty, you can’t afford to spend long cycles analyzing, planning, and executing your idea. You need a more iterative approach that involves continuous modeling, prioritizing, and testing.
Succeeding in the New World Requires New Mindsets
Too many people fail at Continuous Innovation because they start in the wrong place, cherry-picking tactics without first internalizing the underlying mindset behind them.
Mindsets define how we perceive the world around us.
If you believe that we are indeed living in a new world, then it should naturally follow that a new world requires new mindsets. Here are the 10 mindsets that power each of the 3 activities in the Continuous Innovation Framework:
-
Model
-
Prioritize
-
Test
We’ll touch on each of these mindsets as we move through the book.
You Can’t Afford to Wait for an Idea Whose Time Has Come
It’s been a little over 18 months since Steve quit his day job and ventured out on his own. Even though his savings ran out six months ago, he has hit a comfortable groove using freelance consulting to keep his product development going.
He’s come to terms with the fact that bringing his vision to life is going to take time, but he’s not in a hurry. Rome, after all, wasn’t built in a day.
It’s a Tuesday morning, and Steve is in line waiting to order his coffee before heading to a client site for a meeting. He gets a text message from an old buddy of his: “Have you seen what Virtuoso X just launched? It’s your idea, Steve!!!”
Steve clicks the link, scans the page, then goes white.
Virtuoso X’s product does look very similar to what he has been working on for the last year and a half. They just got covered by TechCrunch and announced a big fundraise.
He starts feeling sick to his stomach and leaves the coffee shop. He reschedules his client meeting from his car and heads back to his home office instead.
There, he spends the rest of the day poring through Virtuoso X’s site, trying out their app, and searching online for anything he can find on them. After several hours, he concludes that while the idea is indeed similar, Virtuoso X’s implementation of the product is quite different from his.
Steve feels a bit relieved because he believes he still has the more elegant solution. But that relief is short-lived, as new anxiety sweeps over him: “What good is a better solution if I launch too late or never get to launch it?”
He needs to kick things back into high gear.
Maybe now he can get the support of his developer friends who failed to see his vision earlier? Or maybe now he’ll have an easier time raising funds from investors?
A million ideas start racing through his head. Where should he start?
He decides to reach out to Mary for advice.
Steve used to report to her in his previous startup. Like him, she too had taken the severance package after their startup got acquired and then shut down. He had run into her at an event a few months back and learned that she had also started a new company with a few other former coworkers. And by all accounts, they seemed to be doing quite well. They already had over 30 employees, paying customers, and venture funding.
He shoots her an email, briefly outlining his situation, and asks to meet for lunch.
He gets a near-instant reply: “Let’s meet for tacos tomorrow at noon — usual spot.”
Steve Learns About Minimum Viable Products
Steve gets to the restaurant a few minutes before noon and grabs a quiet table in the back. As he settles in, he notices a text message: “Sorry, running 10 minutes late— deployment day. Please order me the usual, and I’ll get the next one.”
He takes the extra time to organize his thoughts and doodles out a high-level plan in his journal:
-
Secure seed funding.
-
Hire three developers.
-
Finish and launch the platform in three months!
Just then, Mary walks in.
“Sorry for being late, Steve. We have a big rollout this week and we’ve been fighting several production issues all morning. I would normally have rescheduled, but your email sounded urgent. What’s up?”
Steve pulls out his phone, hovers it over the table for a few seconds, and then asks Mary to take a look. A bewildered expression flashes across Mary’s face and she stretches out her hand as if to grab something on the table, but her fingers just wave through the air. She bursts out laughing.
“This is the most realistic AR app I’ve ever seen. This Coke can and glass of ice sitting next to it are so inviting. It’s making me thirsty.”
“I’m glad you think so. I’ve developed a way to render any real-world object as a 3D model inside an AR or VR application without having to write any code or use complex modeling software. All you need to do is take a few pictures of the object using the phone’s camera, and the rendering engine builds the 3D model in a couple of minutes. I generated these models while I was waiting for you.”
“Neat. What’s the name of your project?”
“Altverse—as my ultimate vision is creating an alternate virtual universe as rich as the one we currently inhabit.”
Mary nudges Steve to go on.
Steve takes the next five minutes to summarize what he’s been up to over the last year, describing the Virtuoso X launch and his high-level plan for moving forward.
Mary listens patiently and then asks him a simple question. “Would you rather spend the next six months pitching to investors or pitching to customers?”
Seeing the puzzled look on Steve’s face, she goes on to explain that even in the best-case scenario, raising money without traction is typically a six-month process and a full-time job. “And during that time you’re not going to make much progress on your product. So given your estimates, you’re probably looking at nine months to a launch.”
“I can’t afford to wait nine months!” blurts out Steve. “Virtuoso X has the first-mover advantage. By then, they’ll have cornered the entire market!”
Mary adds, “I know this will sound like a cliché, but competition is a good thing. Competition helps validate a market, and most first movers really have a disadvantage, not an advantage. Facebook, Apple, Microsoft, Toyota—I can keep going—weren’t first movers. They were all fast followers.”
Steve isn’t convinced, but nods his head anyway.
“Okay…but I still need to launch something in less than nine months.”
“That, I definitely agree with. Yes, you do.”
“But for that, I need more developers. And I can’t hire more developers without money—”
Mary cuts him off. “You need to get to an MVP that customers want.”
“An MVP?”
“A minimum viable product.”
“Sort of…but not really. A minimum viable product is the smallest solution you can build that delivers monetizable value to your customers. I know you have a big platform vision in mind, but customers don’t care about platforms. At least, not at the beginning. They care about solutions that solve their immediate problems. You need to find the smallest solution that solves a big enough customer problem and deliver that. To do that, you have to really narrow down on your ideal early adopters first and not go too broad. When you’re trying to market to everyone, you reach no one.”
Just then Mary’s phone pings, and she glances at the screen. “Sorry, I’m needed back at the office. My best advice for the moment is to read everything you can find on MVPs. Investors today don’t fund ideas, or product development, but traction. And you need customers to demonstrate traction.”
Steve interjects, “How much traction is enough?”
“If you can demonstrate any traction at all, it sets you apart from the pack. That’s what we did before we spoke to any investors. Having just five paying customers gave us leverage and completely changed the dynamics of fundraising for us. Today, we have 10 times that number of customers, but without those first 5 our pitch would have just been a bunch of promises. Let’s meet again once you’ve defined your MVP.”
Steve thanks Mary for her time as she takes one last bite of her lunch and then sweeps out of the restaurant.
Don’t Start with an MVP
It’s been three weeks to the day since Steve’s meeting with Mary. He’s meeting with her again to give her an update.
“I followed your advice. I read up on MVPs, and since I had already built out quite a bit of the product, I was able to launch my MVP within a week…but I don’t think it’s working.”
He pauses for a second, then goes on. “I’ve got lots of users signing up every day, which is great, but no one has upgraded yet, and retention is quite low — most users never come back after the first day. I’ve been running all kinds of A/B tests and even pivoted a few times. I’ve concluded that my MVP isn’t good enough. The product is still missing several core features. Though I think I’ve finally figured out the killer feature, and I’m planning on building that next—”
Mary cuts him off. “Let’s back up a bit. Who are these users? And where are they coming from?”
“I announced my product launch in a few online communities, like Product Hunt and Hacker News. That announcement generated some buzz. Some of the traffic is still coming from there. The rest are coming from online ads. I set up a small budget of $25/day.”
“Okay. And who are these users? Have you talked to them?”
Steve looks a bit surprised. “Talked to them? No. But I’ve been measuring everything they do using analytics. That’s how I know retention is really low.”
“I see. We made a similar mistake after our MVP launch. We stopped talking to our customers and relied solely on metrics to guide us. The problem with metrics is that they can only tell you what’s going wrong, not why. We kept guessing at what the problem was, but nothing we did worked. It was only when we started talking to our customers again that we were able to truly understand why things weren’t working, and turn things around. You have to keep talking to your users, Steve.”
Steve clears his throat. “Keep talking to my users? I’ve never talked to any of them.”
It’s now Mary’s turn to look confused. “Huh? Then, how did you define your MVP?”
“Well, I had built up so much of the platform already that I was able to quickly launch a small reference application that showcased its power. You said I needed to ship something. Isn’t the premise of the MVP to rush to ship a first release, which kicks off the learning cycle…then use fast experiments to iterate and refine the product?”
Mary sighs. “Sorry, Steve, I should have warned you that MVP is quite a loaded term with many different definitions and approaches out there. Yes, a lot of people subscribe to that approach. And to be fair, it’s still a better approach than spending a year building out a more complete product, only to find out that you’ve overbuilt—or worse, built something nobody wants.”
Mary notices that Steve blushes a bit at her last comment. She chooses to ignore it and goes on. “But simply throwing your best guess at a solution, no matter how small, over the fence, and calling that an MVP, doesn’t guarantee any better results.”
“Doesn’t the Lean Startup Build-Measure-Learn loop help you iterate and refine the MVP?” Steve asks.
“In theory, yes, but a lot of teams just get stuck. Think of the Build-Measure-Learn loop as a fast idea validator. If you put a reasonably good idea in and manage to attract early adopters, it is possible to iterate and refine your MVP as you describe. But if you start with a bad idea, all you learn is that your idea sucks. And then you’re stuck.”
“Why is that?” Steve asks.
“Because customers today have lots of choices. If your MVP fails to resonate with them, they don’t turn into testers and patiently deliver you feedback on how to improve your product. They simply leave — a lot like your low-retention users. You’re then left guessing why things aren’t working, which kicks off the search for the mythical killer feature — the one that always feels like it’s just around the corner. Sometimes you get a lucky break, but more often than not you find yourself going around in circles, trying out one idea after another, and are never able to break through. The build trap ensues.”
Steve’s eyes widen, as Mary has just succinctly summarized his situation.
He then asks her the obvious question. “If success is predicated on the quality of the starting idea, how does one start with a reasonably good idea?”
“That is the right question, Steve. You do that by focusing on problems before solutions. The challenge today isn’t building more features, but uncovering what to build.”
A puzzled look comes over Steve’s face, so Mary adds, “Think of it this way…starting with a solution is like building a key without a door. Sure, you can build a great-looking key quickly, but then you spend a whole load of time searching for the right door to open. You might get lucky or brute-force your way in, but where you end up is usually not where you expected to be.”
She waits for a nod from Steve, then goes on. “If you simply flip this around and start with doors, or problems worth solving, key-building becomes a lot easier. You start building keys to doors that actually take you places.”
“And there is a process for doing this?” Steve inquires.
“Yes. That was what I was hoping you’d find in your research on MVPs. We didn’t start with building an MVP in our startup, but an offer. We first sketched out several variants of our idea on a Lean Canvas, which is a rapid idea modeling tool. That helped us identify and home in on several promising customer-problem-solution possibilities. We then set up some two dozen customer interviews to validate our customer and problem assumptions. Once we did that, defining the solution was a piece of cake. But even then, we didn’t rush to build out an MVP. We built a demo instead and assembled an offer that we delivered to prospects over many more interviews. Only when we got enough customers to buy into our offer did we start building out the MVP. What we eventually built looked very different from what we thought we’d build.”
Mary pulls out her phone and looks up an illustration of the concept of problem/solution fit, which she shows to Steve (Figure I-9).
Figure I-9. The problem/solution fit process
“Ah, so that’s what you meant the last time by ‘defining’ an MVP?”
“Exactly. You raise your odds of success significantly by spending the requisite time first defining the MVP, then validating it using an offer, before building it. Think of it as Demo-Sell-Build versus the more traditional Build-Demo-Sell approach.”
“And how long did all of this take you? It seems like a lot of steps.”
“It took us about 90 days to go from just a napkin sketch to problem/solution fit, where we secured our first 5 paying customers. And yes, there are more steps than simply rushing to build an MVP, but if you follow the process and stay disciplined, you end up with a mafia offer.”
“A mafia offer?”
“Yes—an offer your customers cannot refuse. You know, from the movie The Godfather. Unlike in the movie, you don’t strong-arm your customers, but instead show them something so compelling they just can’t turn it down. At the end of the eight weeks, we ended up with five paying customers who were pushing us to deliver them the MVP quickly, versus the other way around.”
“Hmm…this is a very different approach to product development than I’m used to, but I’m starting to see the logic of it. But I’ve already launched my product and have users. Can I still apply this process to my product, or do I have to start all over from scratch?”
“You can definitely apply this process to an existing product, provided you’re willing and open to trying a new way. As you just pointed out, this approach is different, and different often feels uncomfortable. The biggest obstacle for us was unlearning old product development habits and instilling new mindsets across the entire team. The good news is that the learning and results come quickly, so you don’t have to run on faith alone.”
“I still have a hundred tactical questions on how to actually do any of this. How do you get users to talk to you? How many people do you talk to? What do you say to them? You’ve been very generous with your time, but can you guide me a little further?”
“Definitely, Steve. This process, like any, has its fair share of sand traps and pitfalls. The biggest one is our own bias or love for our solution—our Innovator’s Bias. We selectively, and even unconsciously, choose to only pay attention to what justifies building the solution we’ve already envisioned. Shifting to a problem-first mindset sounds simple, but it isn’t easy.”
“Are there any tools or resources you can point me to?” Steve asks.
Mary smiles. “Oh yes. I’ll send you a list of resources, tools, and actual customer interview scripts we used and continue to use to train our team. Uncovering problems worth solving isn’t limited to just the MVP phase…it’s key for everything that comes next also. I’ll warn you again that this will feel a bit weird and even uncomfortable at first. The key is to be patient and follow the process, and the results will come.”
“At this point, I’ve spent 18 months doing things my way and it hasn’t worked. I’m open to trying—no, testing—anything.”
Mary smiles again. “Great! Let’s plan on talking again soon.”
There Is a Systematic Approach to Entrepreneurship
On his drive back to the office, Steve can’t help but replay his last conversation with Mary in his mind.
Is it really possible to build what customers want (what Mary described as a mafia offer) just by interviewing customers?
When he gets back to his office, he finds an email from Mary waiting in his inbox. As promised, she has sent him an extensive list of resources and a high-level roadmap (Figure I-10).
Steve quickly recognizes product/market fit on the roadmap, but a lot of the other terms are foreign to him.
Figure I-10. The Continuous Innovation roadmap
He then reads Mary’s email:
Hi Steve,
As promised, here are the links to the Continuous Innovation Framework and the step-by-step playbooks we use.
There are lots of dots to connect, so be patient.
The Continuous Innovation Framework uses 90-day Model-Prioritize-Test cycles, so be sure to start at the beginning, with the modeling work. Then work your way through the other stages.
Lastly, remember that learning anything new often requires unlearning old habits. Apply and test the framework rigorously.
If you get stuck, you know where to find me.
Mary
Steve gets to work, and over the course of several weeks, he learns:
-
How to deconstruct his idea into a business model
-
How to test whether his idea is worth pursuing
-
How to identify and prioritize the riskiest assumptions in a business model
-
How to stress test his riskiest assumptions using small and fast experiments
-
How to use customer interviews to learn from customers
-
How to achieve traction without a product
-
How to pitch to customers so they buy
-
How to operate and make decisions under conditions of extreme uncertainty
Over the next several months, Steve manages to bring his product back on track with paying customers, growing revenue, and a growing team.
About Me
Hi, my name is Ash Maurya and I’m the founder of LEANSTACK and the creator of the popular business modeling tool Lean Canvas. I too used to be a Steve. I too was hit by an awesome idea. An idea so good I never told anyone but close friends sworn to secrecy.
I spent a year building out my “big idea” in stealth. And, like Steve, I too struggled to get other people to see what I saw.
It took me roughly seven years to transition from Steve to Larry, and there’s been no looking back ever since. This is my personal mantra: “Life’s too short to build something nobody wants.”
I attribute all the success and attention I’ve received over the years with my books and tools to this new way of thinking about and approaching products.
LEANSTACK was founded to help the next generation of entrepreneurs avoid these same mistakes.
From here on out, this isn’t a story of two entrepreneurs, but just one entrepreneur: Steve.
Steve, not Larry, is the hero of our story.
How This Book Is Organized
One of the most significant milestones for a startup is getting to product/market fit (aka the inflection point in the hockey-stick curve when a product’s traction starts rapidly growing). The reality, of course, is that 80% of products never get there.
Operating under conditions of extreme uncertainty is the reason often cited for this low rate of success, and also why the journey prior to product/market fit is often described as aimless wandering (Figure I-11).
Figure I-11. Aimless wandering
But it doesn’t have to be this way. Yes, the early stages of a product are riddled with extreme uncertainty, but they don’t have to be messy. With the right mindsets and thinking processes, the early stages can be systematically traversed much like you would a labyrinth (Figure I-12).
Figure I-12. The idea labyrinth
The objective is to get out of the maze with a business model that works before running out of resources. Yes, there will be twists and turns, dead ends, and backtracking, but this process is systematic, unlike the tangled mess of aimless wandering.
This book outlines just such a step-by-step systematic process for taking an idea from an initial spark to product/market fit, breaking the journey into three parts.
Part I: Design
A key mindset for putting the ideas in this book into practice is viewing your business model, not your solution, as the true product of your startup. As with any product, the first step is design.
Part I walks through the process of deconstructing your initial vision (or Plan A) into a business model. I’ll then show you how to stress test your business model design to avoid the most common pitfalls that trip up early-stage products. Finally, you’ll learn how to communicate your idea clearly and concisely to others and get them to see what you see.
Part II: Validation
While a starting business model blueprint is key for driving clarity and focus, it’s important to recognize that all models are abstractions of reality, not reality themselves. In other words, they must be validated with evidence, not taken on faith.
Part II shows you how to iteratively test your business model in stages using 90-day cycles, starting with the first validation stage: problem/solution fit. You’ll learn how to use the Demo-Sell-Build process to test demand for your product and secure paying customers without having to first build out your product.
Part III: Growth
Achieving problem/solution fit sets you up for building a product you know customers will buy, rather than just hope they will buy. The next step is launching your product (MVP) and iterating your way toward product/market fit.
Part III shows you how to maximize your product launch for speed and learning while constantly focusing on what’s riskiest. Rather than launch your product to everyone, you’ll learn how to use a stage-based launch to first test your business model at a small scale and establish repeatability before pursuing growth.
Is This Book for You?
The principles covered in this book can be applied to launching a new product either at a startup or a large company. While tactics may vary, the principles are universal.
Throughout this book, I’ll use the term “entrepreneur” to refer to anyone charged with bringing a bold new product to life.
Running Lean is for:
-
Aspiring and serial entrepreneurs
-
Corporate innovators and intrapreneurs
-
Product managers
-
Makers and visionaries who want to level up and build the next generation of products that matter
Does It Work for Services and Physical Products?
In this book, a product refers to anything that delivers value to customers. This can be a digital product, a physical product, or a service. So yes, all the concepts in this book can be readily applied to any type of product.
Practice Trumps Theory
Everything in this book is based on firsthand experiential learning and experimentation on my own products, and across thousands of other products built by teams I have advised and coached over the last 10 years.
I encourage you to rigorously test and adapt these principles for yourself.
No framework can guarantee success. But a good framework can provide a feedback loop for making better evidence-based decisions in the face of extreme uncertainty.
That is the promise of this book.
Let’s begin.
Get Running Lean, 3rd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
