The Problem With Problems

The Problem With Problems

By Discovery Lean Six Sigma

0/5 stars (0 votes)

When Steve gets back 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 a 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.”

He instead lists out a number of starting customer segments: college students, marketers, gamers, startup founders, enterprise. 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 wasn’t able to fill in all the boxes and, other than the Solution box, he really 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 5 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 can take up to 4 weeks. I used a survey to speed things up and got a strong signal that validates 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 a number of 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 in mind which 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 let’s 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 really know for certain.”

“So is the point getting people to see their own bias for their solution?” Steve asks.

Mary smiles.

“In a way, yes. The concept of the Innovator’s bias is easy to understand, but it requires an acute self-awareness to spot it. You have to hone this self-awareness over time because it’s sneaky and operates at an unconscious level. I promise you’ll see the Innovator’s Bias rear it’s ugly head a few more times before you’re done.”

Steve laughs.

“At this stage, finding evidence of monetizable pain is your number one 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 possibly 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 are going to 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 2 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 3 different canvases, and so I interviewed 3 different customer segments. I’ve got some great insights that I’m still digesting, but I also ran into 3 different challenges that 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 a number of 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 sort of 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 be 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. I lost control of the interview after that 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 pull 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, or 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 really 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?”

Problem Interview Script 1.0 (source: Running Lean)

“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 really 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, which is why 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 keynote on the first iPhone launch?”

“Sure — I even stood in line 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 storytelling ability — He was a master at communicating problems and solutions. I’d recommend rewatching the keynote and pay 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 3 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 any more, 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.

“Bingo.”

“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 were 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 a 100% convinced yet…but I can’t think of any exceptions to that rule at the moment” Steve muses.

Just, then Mary turns over her phone and shows Steve this image:

The 4 Customer Forces that Drive People to Buy Anything

“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

3 weeks later…

Mary starts off with: “I see you have a big smile on your face. I take it the interviews went better this time around.”

Steve laughs.

“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 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 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?

Check out my latest project

.

.

image


The Problem With Problems was originally published in Love the Problem on Medium, where people are continuing the conversation by highlighting and responding to this story.




Original: https://blog.leanstack.com/the-problem-with-problems-50dd364ccb2b?source=rss----8a472b45761d---4
By: Ash Maurya
Posted: June 7, 2018, 11:58 am

comments powered by Disqus

Discovery Lean Six Sigma

Dummy user for scooping articles

I'm a dummy user created for scooping  great articles in the network for the community.