The Official Story and the Actual Story

Here’s the scenario: everyone has agreed across the board that it’s important to talk to your [choose word: users/participants/customers/students] in order to understand their needs and the problems that you need to solve. Some people you work with have bought into it grudgingly, so you need to show why this part of the process of building a great product is so important. So...what do you do?

Maybe let’s start with what you don’t do: don’t tell the person you’re interviewing your idea about how to solve their problem and then ask them for feedback. (Even worse: don’t put the fully built product in front of them and ask for their feedback). Here is what will happen: people will basically tell you that it’s fine and maybe make some cursory suggestions of tweaks, and you will fail great like you totally nailed it, and then no one will actually use it, and you’ll feel bewildered, and the people who grudgingly bought into this process will point their fingers in your face and be like, “See, we should never have done this in the first place.” And then they’ll open up the lions’ den and throw you in, where you will be devoured.

Right...so that much is obvious, and none of us would ever imagine doing such a thing anyway. In my experience, though, we often engage in the discovery process in a way that gets us to the Official Story, when what we want to get is the Actual Story.

First, some terms:

•  The Official Story is the thing that the person being interviewed knows they’re supposed to say. They’re familiar lines, and they can sound good because they give us so much confirmation that we’re headed in the right direction. The Official Story brings us comfort and reassurance. The only problem with the Official Story is that it isn’t the Actual Story.

•  The Actual Story is what’s really going on. It’s the skeletons in the closet that people don’t want to bring out, the actual obstacles they’re facing that they don’t want to own up to. It’s the real problem, and it’s often messy. To make matters worse, because it hasn’t been translated into the Official Story, when you talk to a dozen different people they might talk about the same Actual Story in a dozen different ways. Getting to the Actual Story is messy and hard. The only good thing about it is that the Actual Story is the thing you should actually be working on.

Wood-paneled table? Check. Microphones and cameras (plural)? Check. All set to get the Official Story...

Why do we so often end up with the Official Story? The short answer is: because we ask the wrong kind of questions. Let me give you some examples of question stems that lead to the Official Story:

•  Can you tell me about a typical...?

•  What is the average  like?

•  How do you [do thing x that we think is related to the problem]?

•  What do you think of [thing x that we think is related to the problem]?

On the surface, these don’t seem like bad questions. They seem like they should be informative and useful. The problem with them is that they ask people to remain at the most superficial level, and so the insights you’ll get will remain superficial. In the best case scenario, they will help you understand the functional requirements you need to fulfill (but probably not - instead they’ll tell you what the interviewee thinks the functional requirements are, even if they aren’t). What you won’t get - and what you need - is an understanding of the emotional requirements for your product.

Reworking those questions to get to the Actual Story isn’t a monumental uphill battle though. The main factor to keep in mind is the word “story” itself; to get to the Actual Story, you need to task the interviewee to tell you stories about real, actual experiences. Some question stems that start to get you there:

•  Can you tell me about the most recent time you...?

•  When did you feel the most [excited, frustrated, confused, confident, etc...emotional adjectives] about...?

•  The last time you needed to [do thing x], how did you go about it?

In each of these question types, you’re asking the person to provide real, tangible details about an actual instance of something of interest to you. These stories will be rich and provide ripe opportunities for follow-up questions and deeper probes. They will reveal at least the contours of the skeletons in the closet, and if you make the person feel comfortable and safe and probe delicately you might get to meet those skeletons face to face. And when you hear a lot of people talking about the same skeletons, that’s when you know you’re onto a valuable problem to solve with your product.

The mechanics of how to do those interviews, distill insights, and translate that into problem statements is a whole other can of worms, so here’s what I’m going to do: Substack just debuted a “thread” feature. Let’s take it for a test drive. I’ll follow up with a thread for anyone interested to either pose questions or share some of their own effective tactics for great customer discovery. If it seems like an itch worth scratching, I’ll synthesize and edit it into a follow up post within the next couple weeks.

Need some good links?

AltSchool closing down - on the one hand, it was an ambitious approach to ecosystem building. On the other hand, they never really had the education & learning expertise that they needed, instead building what I would call the surveillance school model of collecting and analyzing troves of data. They aren’t going away entirely, but with this move they are becoming more of a pure educational software company while jettisoning their physical schools.

Interviewing for Empathy - you can never go wrong with the Stanford d.school for this stuff. This handy one pager gives a quick conceptual overview and provides some very practical tips.