When Entrepreneurs Talk to Users

Increasingly, Business Leaders, particularly Product Managers, are getting out there and talking to users. This is GREAT news. If possible, they should be joined by a researcher or designer to facilitate shared learning. But some teams don’t have anyone experienced in research, or the researcher doesn’t have bandwidth for all the demand. (I see this all the time. Good research teams drive demand, demand outstrips their resources, and the teams never “catch up”.)

Of course, Product Managers can talk to customers on their own. But we need to consider the garbage-in, garbage-out phenomenon. Product Managers, Founders, and CEOs usually are successful specifically because they’re charismatic and persuasive; they’re true believers. Something as simple as holding a warm drink can impact people’s responses to research – so imagine what your brilliantly charismatic personality can do.

When teaching people to do research, I use Beatrice Warde’s “Crystal Goblet” analogy (you can read the whole essay here, which is brief but lovely). Warde compares typography to a simple crystal wine glass. The purpose of the goblet is to be nearly invisible: to reveal as directly as possible the wine it contains. Similarly, the purpose of typography is to convey the writer’s ideas clearly, cleanly, and openly.

You can easily extend this analogy from typography to design, or even technology writ large. But for now, I’d like to use it as a model for how to conduct research.

A researcher’s job is to be a crystal goblet. They should be “there” as little as possible, and make space for the research participant to fill. This philosophy grounds all our fundamental rules about facilitating research:

• Ssssshhhhhh. Seriously. Just listen. Evaluate yourself by getting a transcript of your research session. Good researchers say a sentence, a few words… and elicit paragraphs of response. They create space for that person to fill. 

• Embrace uncomfortable silence. Breathe, count to 5, wait. Research participants will be moved to fill the silence with that thing they weren’t sure they would share, the thing beyond their pat answer. Listen to what they really have to say.

• Use incomplete sentences… This creates an immediate uncomfortable silence and keeps you from introducing bias. Instead of asking, “Would you say this experience was good?” (terrible technique!) or even “Would you say this experience was good or bad?” (also, not good), allow users to finish your sentence themselves: “Would you say this experience was…?”

• Use their words. Steve Portigal talks about this in his iconic TiVo story. If they say “TIE-vo,” you say “TIE-vo.” If they say “wirey thing-y,” don’t say “dongle”; say “wirey thing-y.” Remember, you’re trying to be there as little as possible. Using their words means you’re not asserting your presence.

• Don’t ask them to be crystal balls. Data show that people stink at predicting their future actions, and attitude is a terrible predictor of behavior. A user telling you they’ll buy your product in the future has almost nothing to do with whether or not they actually will. You can, however, ask them to buy it, and check later to see if they actually did. If you must ask for predictions, it’s better to ask what your research participants think other people like them would do.

• Be invisible after research. When you’re considering what you’ve learned, be careful not to insert your own ideas. Confirmation bias is impossible to avoid entirely. But being aware of your biases, even explicitly listing them, can help you limit them. It also helps to consult with other people who don’t care as much about the outcome.

When I teach this to CEOs, Product Managers, and Founders, I find that it either really clicks, or it doesn’t. If they’re not pretty tuned-in to how other people respond to them in conversation, then they’re also not tuned-in to how they’re not great at getting good, useful learnings from customers. As a fail-safe to address, I propose that entrepreneurs test one another’s ideas or products, something similar to the way engineers ask someone else to test their code. It’s not always easy to find someone on the same schedule, but the upside is solid, dependable learnings — versus risking a garbage-in, garbage-out situation.

I write much more about this, and about how to leverage the value of design, in the book. Please grab a copy for yourself or a friend, or get in touch.