We’ve heard them both before. They’re givens in the tech world:
Sounds easy enough, but even seasoned software teams know both are much easier said than done, even with our growing awareness of the “build-measure-learn” methods promoted by lean-minded practitioners.
But how do you actually get to the root problem and understand it’s worth solving? Similarly, how do you actually validate a solution before investing in building it? What tools do you use? What techniques do you employ?
On the Mingle team, we consistently seek to bring more rigor to our process. We believe this helps reduce waste, minimize churn and better deliver more value to our customers.
We have found problem and solution interviews to be strong catalysts of continuous improvement. In this two-part blog post, we’ll share our story about their impact on our process (in relation to development of our WYSIWYG editor) and some tips to implement them on your own team.
"If I had an hour to save the world I would spend 59 minutes defining the problem,
and 1 minute finding solutions." -- Einstein
For well over a year, we had heard clamoring for a new editor from multiple stakeholders. With the noise of so many requests, we couldn’t hear the signal of the underlying problem. How and where were we supposed to start? We experimented with a new interviewing method suggested by our UX lead that, looking back, proved to significantly improve our ability to deliver valuable functionality to our users.
A problem interview is an interview focused on a problem. It’s talking to people who have expressed pain, identifying and understanding their problem within their unique activity and context. I like to say it’s root-cause analysis in interview form.
While problem interviews are about talking to people, they’re really about how you talk to them. They’re about asking the right questions and, most importantly, listening with care and attention. They’re also great at helping you validate whether a problem is actually worth solving.
(Hint: it’s not just talking to your customers, but how you talk to them)
We were greatly influenced by and used Giff Constable’s “12 Tips for Early Customer Interviews” to implement our problem interviews. Below are some of his tips with our own learning, as well as a few additions from our experience.
Preparation is essential for a successful problem interview. Capture your assumptions about the problem and identify the riskiest. Use the problem interview to (in)validate them. This will help direct you to the “right” problem and its root cause.
Don’t capture assumptions that aren’t worth validating or don’t speak to the problem you’re focusing on. Capture only the most important and riskiest assumptions that, if not (in)validated, would result in great potential waste (i.e. solving the wrong problem). Also, make sure your assumptions are concrete and specific to the problem space. Just as stories should be testable, your assumptions should be "validatable".
Try your best to avoid more than one interviewee on the call. You need to dive into one person’s activity to get a clear picture of their problem context. Having more than one person will likely cause you to lose focus and receive diluted, mixed messages, but no real insights.
As my fantastic teammate says it, “Try to shut up as much as possible.” Keep your questions short and unbiased. Don’t rush to fill the silence when the customer pauses. She might be thinking or have more to say, especially at the start of the conversion. Don’t cut yourself or your customer short. Listen with patience, care and attention.
Ask questions that prompt your customer to describe their activity. Even if you start with “yes” and “no” questions, make sure to follow up with open-ended questions. The age old question “why?” is an oldie but goodie. Don’t underestimate its power in eliciting revealing insights. And if that doesn’t work, ask your customer to tell you more about a particular experience or environment they mention.
Product feedback is welcome, but make sure to park it and focus on behavior. Most people talk about your product too early in a conversation, such that you end up with a laundry list of feature requests.
People’s behavior, mindset, and motivation are the most important components of their activity and can help point you to the source of the problem. Start there, and then follow your nose, again using “why” or “tell me more”. When you return to the product, you’ll have a much richer context.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.