Customer Development as Bearing Witness

While Henry Ford likely never have said, “if I had asked people what they wanted, they would have said faster horses,” the ethos of this quote is pervasive in tech today. We worship the mythology of the brilliant founder who single-handedly conceived of some big breakthrough. Moreover, we look down on the people using our technology as ill-informed users. This notion is misplaced because the people using the technology I work on are often experts at their own lives and problems.

In the Henry Ford example of the automobile, people may not have been able to articulate the desire for the automobile but they identified the problems with the horse. They might have talked about the limited distances they could go or the need to constantly care for a living thing. They might have expressed a desire to go to a different city within a day. But no, they likely wouldn’t have requested a car directly. But they knew the ways that horses were currently failing them.

So let’s reject the notion that folks using our technology have no expertise. Building tech as an act of love asks us to treat people not as users but as true collaborators. It requires that we respect and value the expertise of people using our technology as much as our own. We invite them into conversation with us. And we are genuinely curious about their lives.

To do this, I borrow from human centered design. I start with the people I am building for. I am extremely specific about the audience. When I knowledgeable about the people using the tech I build, I start to identify “users” as they identify themselves. So in the past, it has been software reliability engineers rather than developers or user. With this specificity, I start to emphasize their expertise and life experience beyond the product I happen to be building at the time.

But no matter how specific or precise I am with identifying the audience, my first guess is often wrong. So I spend time validating the audience. At a previous company where I built a data course, I assumed that they audience would be people without any data experience. And I quickly learned, it was junior analysts who were looking to improve their data skills. While this often bruises my ego, this has happened often enough that I now expect to have to iterate and refine the audience I’m building for.

Then I go find these folks and talk to them. I ask them some variation of “tell me about how you do x?” While I come with a script, I just let them talk. I ask probing question. I follow detours. I let the person I’m talking to lead me where they want to go.

One such instance was when I was asking a customer about their software development environments. And they mentioned the expected production environment that customers interacted with, the testing environment that developers tested new features, and a quality assurance (QA) environment where testers would ensure that new features met the quality requirements. But they then mentioned a QB environment.

Confused, an engineer on the call asked what is QB. They responded like QA but B because they were releasing so many features concurrently, they needed to another quality assurance environment for their monolithic app. This led our team to understand that environment management is big pain point for this particular person. Following these kinds of breadcrumbs often leads to some of my most valuable insights.

While traditional user researchers often follow a form of ethnographic research that requires stoicism. I believe this reinforces the power differential that already exists. And if you know me in person, you know that my face is incredibly readable. So I practice meeting folks where they are and respond naturally to what they are saying. I reassure them that they are providing me with valuable insight.

Are my results less valid? Probably but again, I’d view my role as a technologist as more of witness rather than a scientist observing a subject. I view the folks I’m building with as collaborators in the work of determining the problem to solve and the technology to build. And my role is to simply uncover their expertise.

“The line which separates a witness from an actor is a very thin line indeed.” James Baldwin

After a few conversations with folks I hope will use my technology, I start to be able to predict the answers to my questions. While I might not know the exact detours we take, I can generally forecast the direction. And this is the moment where I and my team bring all the notes together and start mapping the trends. We begin explicitly connecting these folks stories together to create themes and a shared language to talk about the audience, problems, and context.

But this is just the beginning. Because the collaboration does not end when I’ve gained these insights. I return to folks who I hope will use my technology with insights, ideas, and eventually the product because they are truly collaborators. As technologists, we are in relationship with the folks that use our technology.

As with all meaningful relationships, the goal is not perfection but presence. And I recognize that many of us do this work in the context of paid work which often leads these kinds of relationship to be transactional. So building a relationship in this structure requires us to stay in connection though discomfort. In doing so, I hope we can build technology that can feel more joyful and full of love and care.

Acknowledgement

Thank you to Michael Dimitras and Rye Castillo for helping me talk through the ideas in this piece.

Resources

These are resources that inspired this piece

• Lean Customer Development by Cindy Alvarez - This is a wonderful book that helped me let go of the idea that my research needed to look like anthropological research. It helped me think of the goal of research as insight. Also, this book has so many actionable tips on how to find and talk to customers.
• User Research script - Here is an exemplar script for user research. This includes prompts and example and is based on a template from Gen Singer. Feel free to use this script as a jumping off point to create your own.
• “I am Not Your Negro” - This Raoul Peck documentary stayed with me for much longer than it’s showtime. Hearing James Baldwin describe his role as a witness for the leaders of the civil rights movement helped me see my role as a technologists as bearing witness and creating technology that embodied this understanding
• “Exterminate All the Brutes” - This miniseries helped me see that the way anthropological research is formally done with an amount of emotional distance mirrors the colonial era research. Watching this forced me to interrogate why we do research with that emotional distance. Also this is one of the most incisive pieces of work I’ve ever watched.