Three little words: Tell me about…
First of all, you’re right. It’s incredibly easy for customer conversations to become a discussion of which features your competitor has and how long is it going to take for you to build feature X. It’s the default pattern that customers expect and we can easily fall into if we aren’t mindful. It’s also not a pattern for learning.
How can we create learning conversations?
Set expectations from the start
Humans are very good at forming internal expectations – often unspoken – and we notice when a situation or interaction violates them. Oh wow, do we notice. It’s very difficult to change the course of a conversation as it’s going on. So we’re going to make it easier on ourselves by clearly communicating, in advance, the goals and structure of the conversation. For example:
I’d like for us to use this call to dig deeply into the problems that [your team] needs to solve. I know that using our product is only a part of the process and outcomes that your team is working on and I want to make sure we understand your ‘big picture’ needs more clearly.
I am sure there are things that have changed where we haven’t updated our working assumptions. We can spend 20 minutes on that, and we’ll reserve time at the end for covering status updates and anything else that’s top of mind for you.
If it’s a team you’ve been working with for awhile, you may need to add an explicit disclaimer / explanation of why you want to do this:
I’d like for us to step back and confirm that we’re still aligned on some of our working assumptions and desired outcomes. I know we’ve been working together for awhile, and also I know that goals and constraints can drift over time. If there’s anything we need to correct, I’d like us to do that now to ensure we’re not wasting your time or getting your needs wrong.
When you’ve set expectations, you’re more likely to succeed in redirecting the conversation when it slips into “but what about feature X?”
Use the three little words
Tell me about…
Every time a customer mentions a solution, every time the customer speaks and you can envision a solution, say those three little words.
- Tell me about… how that would help your team move faster…?
- Tell me about… what workaround you’d see that replacing…?
- Tell me about… when was the last time you could’ve really used this capability…?
During your conversations, it can be hard to separate problems from solutions. In fact, your customer will often start with “the problem is…” and continue with “we need [feature]”!
If you’re feverishly taking notes, they may have moved on to the next topic before you even realize that you didn’t learn the root problem.
You’ve got to break into the conversation. Interrupt them. This feels rude, and also, humans love affirmation. When you repeat or summarize their words back to them, it reduces the perception of rudeness.
Here’s what that sounds like:
Customer: “The problem is that we’re really slowed down by not having [feature]. We need—”
You: “OK, I hear that you’re asking for [feature]. Let me confirm that I’m understanding what your team is experiencing: you’re getting slowed down because you’re unable to…”
Customer: “We can’t [complete needed action] because we don’t have [feature].”
You: “And if you had [feature], could you tell me about how it would enable [needed action]?”
Obviously this wouldn’t work if the feature and action are the same – to use a simple example, a delete button. A delete button obviously allows your customer to…delete. You’d sound silly asking “what” instead of “when”:
Customer: “The problem is that your product doesn’t have a delete button!”
You: “You’re right, we don’t, I’m sorry. I’d like to clarify one thing – could you tell me about example of when that has been especially frustrating for your team?”
You might add some additional ‘verbal padding’ like “I know that might sound silly. I really want to make sure we are addressing the most painful use cases first”.
Why this works
Tell me about. It’s asking for a story. Stories are the key to discovery.
A different part of our brains lights up when we are describing something that has happened in our past, versus confirming or repeating something. Stepping back into that experiential memory triggers us to remember the feelings and the ‘why’.
If a customer complains that “X is slow”, they often can’t articulate beyond that. What’s the problem to fix?
Is the problem that it’s taking 4 seconds for the page to load? Or is the problem that there’s so much information that the customer has to read through a bunch of useless stuff to find the info they need? Or is the problem that this interaction flow is error-prone so they frequently have to try it multiple times in order to successfully complete it? Someone who talks through a story is more likely to share which of the above ’causes’ the slowness.
Tell me about. Those words are what separate “discovery” from “backlog”. You’ve already got a backlog. And quite honestly, customer feature requests are rarely unique. They usually already exist on the backlog somewhere.
What you don’t know – what you need to learn – is why, when, how. Why does the customer believe they need this? When did they last need it / are they likely to need it again? How severe will be the impact be on the customer if you don’t build it?