Building in Community
“Everything Worthwhile Is Done With Other People” - Mariame Kaba
When I first started my career, I desperately wanted to be described like Steve Jobs or Mark Zuckerberg or Bill Gates. Those men are heralded as tech visionary who single-handedly saw innovation when no one else did. I wanted to be that kind of wunderkind. On my most delusional days, I still want this kind of single-handed accomplishment. But now, I recognize that my best work happens in a community of other technologists.
But much of our standard practice is based on the idea of a solo genius who creates brilliant innovation, designers who design beautiful UIs, and the developers who code. And if any user research is done, it’s the sole domain of the product manager or designer or maybe a user researcher. There is an expectation that the product manager or designer will return to the development team with fully codified user stories, PRDs, and designs.
But this process doesn’t work. Much is lost in translation. We often miss important insights because developers aren’t in the room with users. Developers have different skill sets and experiences so they are more likely to ask different kinds of questions. And these questions spark interesting conversations that lead to insight. Also, if we are working with diverse groups of users then different technologists will make different users comfortable. By putting users at ease, we are more likely to learn more about the problems they are having.
Moreover, other people notice things I miss. For instance, users rarely directly say “I’m frustrated.” Most often, it’s the nervous laughter when we ask about an issue they are having or the sarcasm that suddenly shows up when we ask explicitly about the problem. Having more people in the room ensures that we notice these subtle changes.
And of course, I have done the research alone. I’ve even formed interesting insights. But after I’ve sat with folks and heard their stories, my findings were simply not believed. A single engineer or senior leader can cast doubt on this research when it is contrary to previously held beliefs.
One such instance happened a few years ago when I did research with open source maintainers. Open source maintainers are technologists who keep public software projects running smoothly. After speaking to dozens of open source maintainers, I found that problems managing the influx of community contributions outweighed many security concerns.
Security simply was not their number one priority. When I brought this finding to my manager, he responded by asking me to bury the research because the company had invested tens of millions of dollars in that particular security feature. I was disheartened by this outcome but understood the rationale. When research violates our previously held beliefs or investments, it often takes time to internalize that new finding. Building in community helps mitigate this.
By bringing other technologists with me, I let them hear directly from the users. They hear and see the frustrations firsthand. We create insights together. And when we learn something that invalidates our previous beliefs, we process this discovery together. We ideate as a team. We ultimately create better solutions.
Prevailing wisdom is that it is a waste of developer time to talk to users. I reject this notion because so much nuance is lost when product managers act as translators. Frameworks like personas can capture some of these insights but it will never be the same as hearing the frustration in someone’s voice. Most importantly, if building technology is being in a relationship with people using our work, then we need to start that relationship by engaging directly with real humans.
Acknowledgement
Thank you Rye Castillo for being a brilliant editor and partner in bringing developers along in the research journey.