On his drive back to the office, Steve can’t help but replay his last conversation with Mary in his mind.
Is it possible to build what customers want (what Mary described as a mafia offer) just by interviewing customers? He ponders.
Sure enough, when he returns to his office, he finds an email from Mary waiting in his inbox. As promised, she had sent him an extensive list of resources for navigating the problem/solution fit stage.
Front and center was this high-level roadmap, along with a checklist:
The rest of the links in the document were tactical how-to guides for attracting prospects, running interviews, testing offers, and designing MVPs. Steve quickly scans them to get a big picture. Then gets to work.
Taking the First Business Model Snapshot
“Set a timer for 20 minutes and take the first snapshot of your idea on a Lean Canvas.”
The instructions say to start with the Customer and Problem boxes, but these are the boxes that stump Steve the most.
He wants to put down “everybody” under customer segments but sees a warning against defining “too broad a segment.”
“When you’re trying to market to everyone, you connect with no one.”
Instead, he lists several starting customer segments: college students, marketers, gamers, startup founders, and enterprises. And decides to focus first on the customer segment he thinks he knows the most about startup founders. He manages to complete the canvas just as the timer goes off.
He notices that he couldn’t fill in all the boxes and, other than the Solution box, he guessed at everything else.
“I guess that’s what Mary meant by the Innovator’s bias for the solution,” he thinks to himself.
Steve goes on to repeat the process for the other customer segments. Two hours later, he has five canvases done and reviews his work. Over the next day and a half, he refines his models further, tests their viability on paper using a back-of-the-envelope metrics modeler tool that Mary sent him, and selects his top 3 most promising business model candidates.
A Quick Stab at Business Model Validation
“The top starting risks in any business model stem from your customer and problem assumptions. You get those wrong, and it’s easy to see how the rest of the canvas falls apart.
…the best way to validate your customer and problem assumptions is through face-to-face problem interviews.”
“Face-to-face interviews? That will take an eternity!” Steve thinks to himself. He decides instead to use a survey.
He finds an online service that can target his specific audience for a fee and spends the rest of the day designing the survey. He launches it the next day.
Results start pouring in almost immediately, and a few days later, he has over a hundred neatly tabulated responses and some fancy charts. He beams as he discovers that over 85% of the respondents ranked his top problem as a “must-have.”
He immediately drafts Mary an email:
I know you said the problem validation stage could take up to 4 weeks. I used a survey to speed things up and got a strong signal that validated my problem (85/100). Am I missing something, or should I move on to the solution-testing phase?
He gets a text message 2 mins after he sends the email:
“Let’s meet tomorrow at noon to discuss — usual spot.”
Meeting 1 — Mary bursts Steve’s Bubble (Again)
“I know the engineer in you craves efficiency. I was the same way. But surveys aren’t the right tool for problem discovery.”
“Why not?” Steve asks.
“For several reasons... For starters, surveys assume you know the right questions to ask. And because surveys are multiple-choice, you also need to know the right possible answers to list on the survey. At the earliest stages of a project, we don’t know what we don’t know….”
She pauses for a second and then goes on:
“…sure, surveys can be used for problem validation once you know the right questions and answers to validate, but until then, you have to start with a more open-ended approach to problem discovery. Remember that it’s all about discovery before validation.”
Steve interjects: “Wasn’t the goal validating the problem assumptions on the Lean Canvas?”
“Yes, but most of the problems entrepreneurs initially list on their canvas usually don’t turn out to be the right ones.”
“Why is that?” Steve inquires.
“Because most entrepreneurs already have a solution that they can’t simply shut off. Instead of asking: “What are my customer’s top problems?” many entrepreneurs ask: “What top problems can I solve with my solution?”
Steve gets a puzzled look on his face. Mary goes on:
“When you have already decided to build a hammer, everything starts looking like a nail, and you fake the problems on the canvas to justify your solution.… When you put those same problems on a survey and ask people to rank them, sure, they can rank them relative to the other choices on your survey. But if their top problem isn’t there, they have no way of letting you know, and you never discover it.”
Mary lets that sink in and then adds:
“Even if you get people responding that they have a problem, you don’t get to the real “why” on a survey. The real “why” is often several levels deep, and getting to it requires a conversation. You don’t know what they have tried so far, why it didn’t work, etc. Knowing these details is key to building a mafia offer later.”
“I see what you mean…So what’s the point of starting with a Lean Canvas, then?” Steve asks.
“The point is to create a mindset shift — from viewing your solution as the product to viewing your business model as the product. Our ideas seem crystal clear in our minds until we deconstruct them. It’s only then that we realize just how much we don’t know for certain.”
“So is the point getting people to see their own bias for their solution?” Steve asks.
“In a way, yes. The concept of the Innovator’s bias is easy to understand, but it requires acute self-awareness to spot it. You must hone this self-awareness over time because it’s sneaky and operates unconsciously. I promise you’ll see the Innovator’s Bias rear its ugly head a few more times before you’re done.”
“At this stage, finding evidence of monetizable pain is your top priority, and running one-on-one problem interviews is your best course of action. One-on-one interviews may not seem efficient, but I can tell you from experience that they pack more learning per unit time than anything else you could be doing. You also don’t need as many data points as you might think to start finding actionable patterns.”
“How many interviews are typically enough?”
“When you can start predicting what people will say before they say it, that’s when you know you’re done. We found it took a minimum of 10 interviews and sometimes up to 30 interviews to get there.”
“I better get cracking then….”
Meeting 2 — More Problems With Problems
It’s been two weeks since their last meeting. Steve has managed to run 23 interviews and is meeting with Mary to give her an update.
“As you know, I’m testing three different canvases, and so I interviewed three different customer segments. I’ve got some great insights that I’m still digesting, but I also ran into three challenges I’d like to talk to you about. ”
Mary nudges him to go on.
“With the first group, right after I set the problem context, I had several interviewees immediately acknowledge the problem, which I took as a positive sign. But when I asked them what they were doing about it, they said ‘nothing yet. They then started to tell me what I should build, which is when I told them a bit about my product — which I know the script said not to do….”
Steve pauses to see Mary’s reaction…then goes on:
“They encouraged me to keep working on the product, gave me a bunch of feature ideas, and asked to let them know when I have something ready for them to beta test. The problem is that I now have a long list of features — which, while easy to promise, will take me over a year to build...”
Mary cuts in: “These aren’t your early adopters. These are what we would call “soapbox conversations.” Give anyone a soapbox, and they’ll become a critic. As well-intentioned as these conversations might be, these interviewees aren’t in the best position to tell you what to build because they haven’t yet attempted to solve the problem before themselves. Early adopters, by definition, need to have been triggered by a problem that drove them to some tangible action. This action could range from researching possible solutions all the way to buying or even building a homegrown solution to the problem.”
“So I should discard these feature requests?” Steve asks.
“At this stage, yes. Customer’s too have a solution bias. Just take a look at any feature request backlog, and you’ll see a bunch of solutions disguised as problems. Just think back to our last startup together. Even when we gave our customers everything they asked, they still didn’t use them…and we kept perpetually having more feature and roadmap discussions.”
Steve looks at his notes and goes on to issue #2.
“The next issue I ran into was trying to get the interview back on track after missing the mark completely on the problem. With this group, I started by stating my problem hypotheses using a back story following the script, but my back story drew a blank look. It was really uncomfortable. I’m not sure if they didn’t have the problem or if I put them on the defensive, and they didn’t want to tell me they had the problem. After that, I lost control of the interview and didn’t know where to go next. I fumbled along for a few more minutes, but it was a complete waste of time for both of us.”
Mary pulls her phone out and starts looking something up... She notices Steve stops speaking and nudges him to keep talking.
“I guess the third issue is similar to the last one. This was the video game customer segment. I struggled to articulate a clear problem with this one, even on the Lean Canvas, and also drew blank looks from this audience during the interviews. Many of the interviewees sensed my unease and, probably feeling sorry for me, asked if I could show them a demo. How does one run problem interviews around desire-driven products like video games, fashion, or a movie? It’s awkward to ask: ‘So, what problems do you have with Angry Birds or Fruit Ninja?”
Mary lets Steve finish and then responds:
“First, it seems like you’ve been busy, Steve. This is great work. Getting out of the building is hard, and kudos to you for getting outside your comfort zone. But I’m most impressed with how quickly you encountered these problems. It took us far longer to run into the limitations of this problem interview script.”
“What do you mean?”
“This Problem Interview script was modeled after the Scientific Method. You start by stating some problem hypotheses, look for resonance, and then explore further. It works well when you are within striking distance of a problem worth solving…By getting the customer talking about their workflow, you get to explore their particular worldview, and that’s where problem discovery happens. The problem, of course, is that if you are off base with the initial problem hypotheses, it doesn’t resonate, and you have nowhere to go next — just as you found out.”
“So you ran into similar issues?” Steve asks.
“Yes, but not at first. Because our entire founding team came from the telecom industry, we all had first-hand experience with many of the problems that we set out to solve. Our problem list certainly got refined, but we started with some good ‘hit-the-nerve’ type of starter problems that we got to test against friendly contacts we’d known for years. They were our perfect early adopters and helped us refine the problems further. We did run into issues once we moved into accounts we didn’t know so well. There was little trust, and whenever we led with problems, it put our prospects on the defense. Just as you described...”
Steve interrupts: “So what did you do?”
“Well, there is this newer version of the Problem Interview script that we have started to use. And it’s working. It is a bit more complex than the first version, so I didn’t share it with you sooner. I also felt it was more applicable once you move beyond your first round of early adopters. But I’m not so sure anymore…
I can clearly see how this newer script would address
- the surface-problem issue,
- the defensive interviewee issue, and
- the desire-driven segments issue you described.”
“So what’s different about this script?” Steve asks.
“Well, for starters, it doesn’t lead with problems at all but instead uses a backdoor approach to problem discovery.”
“A back door approach?”
“Yes, the core premise of this newer framework is that new problems worth solving are created as by-products of old solutions. This is the Innovator’s Gift.”
Steve gets another puzzled look on his face: “I don’t get it.”
“Did you watch Steve Jobs's keynote on the first iPhone launch?”
“Sure — I even stood in line for when it went on sale for 6 hours to get one. I had never lined up for a product launch before or since then.”
“Do you remember the problem he used?”
Steve thinks for a few moments…
“Wasn’t it about combining three devices into one: an mp3 player, a phone, and a PDA?”
“Exactly. And do you remember how he started his demo?”
“Sure, he showed a bunch of existing phones and pointed out how hard they were to use — especially the keyboard.”
“And what did you think when he unveiled the iPhone next to those phones?”
“I thought it was magic. Even though I’m in tech, I didn’t even know multi-touch interfaces like that were even possible.”
Mary goes on: “Yes, but tech aside, the real effect was amplified because of Steve Jobs's storytelling ability — He was a master at communicating problems and solutions. I’d recommend rewatching the keynote and paying particular attention to how he doesn’t invent new problems for you to solve with the iPhone but rather highlights existing problems you already have — with the oversized keyboard or having to carry three separate devices in your pocket. And then he reveals his solution.
Your ‘smartphone,’ which was perfectly ok five minutes ago, now starts to look like a dinosaur… and it’s riddled with problems…You don’t want it anymore, and soon enough, you find yourself standing in line for hours to get the new iPhone.”
“Wow…I had never viewed it that way.” Steve remarks.
“That’s the power of great storytelling…He did this with every product he launched — you’ll see the same pattern with the iPad keynote.”
“So you’re telling me that I shouldn’t be inventing new problems but rather searching for existing problems with what people are already using?” Steve adds.
“And this approach leads to breakthrough innovation?” Steve asks skeptically.
“The key to breakthrough innovation is causing a switch. People switched from cassette tapes to CD players to MP3 players to streaming music services. Each of these switches was anchored and marketed against problems with prior solutions. Show me a breakthrough product, and I’ll show you an old product people switched away from. The corollary is also true: Show me a product without an existing alternative, and I’ll bet that product fails.”
“I’m not 100% convinced yet…but I can’t think of any exceptions to that rule now,” Steve muses.
Just then Mary turns over her phone and shows Steve this image:
“This image is the key to understanding this framework. It describes the science of how people buy anything — yes, there is a science to it. People don’t impulsively buy stuff or switch products, they are driven to it by four forces — push, pull, inertia, and friction. Uncover those, and you uncover the why, how, and what for designing and building products your customers cannot refuse.”
“And there is a script to go along with this customer forces canvas too?” Steve asks.
“Yup. I’ll send you what I have.”
Meeting 3 — Breakthrough
Three weeks later…
Mary starts with: “I see you have a big smile on your face. I take it the interviews went better this time around.”
“Who would have thought interviewing customers could be this much fun? Thinking of products in terms of these customer forces is a game changer! It’s even made me more aware of how I buy products.”
“Yes, it’s powerful stuff… so what happened with the interviews?” Mary asks.
“For starters, pre-qualifying my interviewees by triggers, as you suggested, made a huge difference in the quality of conversations. I also found problems in every interview — even with the gamers.”
“Isn’t that just a little sad?” Mary quips ironically.
“Not at all…I’m loving the Innovator’s Gift!”
Mary laughs: “I see you catch on quickly.”
Steve continues: “But not all the problems I found are worth solving given my goals for the company. I refined my models using new pricing inputs from the interviews and re-ran the back-of-the-envelope calculations using the metrics modeler… I’ve narrowed down my most promising business models to these two: marketers and enterprise.”
“They are quite different segments which isn’t a bad thing at this early search stage. Who are the users and customers in the enterprise model?”
“The users would be DevOps teams. Their managers would be the initial customers. Eventually, we’d like to make an enterprise sale once we can demonstrate enough traction within the organization. A classic bottoms-up SaaS approach.”
“Cool — So what are the next steps?” Mary asks.
“The neat thing is I can quickly repurpose my platform and launch an MVP for both these segments simultaneously. I can be ready for a pilot in 3 weeks….”
Mary leans in and signals Steve to stop:
“Steve, do you see what’s happening?”
“What?” Steve looks cluelessly around the room.
“You’re falling into the Innovator’s Bias again.”
Steve shifts in his seat, and before he can say anything, Mary goes on:
“I get it that you’re excited. Finding monetizable pain that you can solve is exciting! But simply building a solution isn’t enough. Remember, the business model is the product. With your problem and solution assumptions in check, your next priority should be validating your pricing assumptions. In other words, go make a customer.”
“You mean, make sales?” Steve asks.
“Yes. Remember, the old way was Build-Demo-Sell. The new way is Demo-Sell-Build. You can test and iterate on the promise of your solution much faster with a demo than with a working product. You and I have been in the industry long enough to know that there is no such thing as a quick launch. There are always details and always delays….”
Mary pauses, and Steve nods his head.
“So take your problem/solution findings and first build a demo. The art of the demo is showing the smallest thing possible to convince a customer you can solve their problem. Then turn that into a mafia offer and go make some customers. Remember the process.”
Steve concedes: “You’re right again, Mary… Does this Innovator’s Bias thing get any easier to deal with over time?”
“It does. But it takes practice — lots of practice…like anything worth doing.”
“Well, I’m glad I have you then to call B.S. and keep me straight.”
Mary laughs: “So we meet again in 3 weeks?”
“You’ve got a date!”
Want to Learn More About the Innovator’s Gift?