Building for Intersectionality in Tech: Intersectionality and Product Management
By Nicole Thayer & Tiffany Wong
Note: This is the fourth post in this blog series on intersectionality in tech. Check out the first, second, and third posts.
Welcome back to our ongoing series about how employees at Carbon Five approach intersectionality in tech. For more information on why we’re doing this and what we’re hoping to accomplish with the series, read the introductory post.
How might we make checking our own bias as much a part of creating a product as a standup or retro? Today we’ll be talking about how to make intersectionality a priority over the entire product lifecycle and offering tips for having conversations about the topic during client work. We’ll also cover risks associated with common rituals like personas and how accepted wisdom in building early-stage teams can create bias down the line.
The product managers (PM)s we interviewed had great insights on when to start talking about assumptions and risks with team members and how to push back when bias gets baked into the development cycle. For this interview, we talked to Jen Skene, formerly a senior product manager at Carbon Five who is now a product manager at Segment, and Allie O’Connell, a former director of product management at Carbon Five.
Prioritizing Intersectionality
Though designers and developers can have an impact, it’s ultimately up to product managers to make the decision on final functionality, implementation criteria, and the order in which intersectionality concerns get addressed. So when’s the right time to start, and how much should you do?
“[Prioritize intersectionality] from the beginning of exploring a problem and potential business models to solve it! Prioritize it in your time, and prioritize it in your research,” said O’Connell.
For Skene, kickoff is the right place to start building culture—and addressing bias. For folks who haven’t participated in one, kickoff is the intense first week at the beginning of a project where the team learns why a product is being built, who it’s built for, and what the company hopes to achieve by building it. It’s a great time to establish a working relationship with space for difficult topics.
“Ask the hard questions: who is this product for right now — and in future,” said Skene. “Do you ever want to serve an audience outside of Bay Area millennials? Do you have any goals around social impact or equity?”
But not every problem gets exposed that early. Features with concerns around inclusion and intersectionality can appear later, but creating a culture of calling out bias during kickoff can help address potential issues in the future.
Seeing Bias
The first step to effectively addressing bias is acknowledging its existence.
“It’s about asking who we’re building for and what our assumptions are about our audience,” Skene said.
A company with the best of intentions might fall back on unconscious patterns that create bias. Skene recalled a story about a client with two user bases — one in the Midwest, and one in Latin America.
“The product owner made comments to the effect of ‘If we build it for the [Midwest] group, the [Latin American] group might not know how to use it’ — with the assumption that the [Latin American] users are not as smart and capable, and that we would need to build a different product if we focused on them.”
She admitted that it can be hard in moments like these to call out bias on the spot, and that it can be interpersonally difficult to do in a constructive way.
“I am better at confronting someone after their second infraction — for the first, I am [usually] shocked or confused or not sure what to do,” Skene said. “Once I have time to think about how I could have done better, I come up with a game plan for how I can deal with it next time.”
Skene recommends building a framework for course correction and implementing it early on so that no one ends up on the spot. Product teams at Carbon Five use the word “jellyfish” as a codeword to gently let a team member know they’ve strayed from the topic at hand during a meeting. Perhaps there’s a similar codeword that could be used to flag biased assumptions without shaming anyone.
“Let’s acknowledge that [bias] is a thing, and continue acknowledging it throughout the project,” she said. “I think most people might like the opportunity to make the right choices, but they might not know how best to do it.”
Of course, this involves some social capital and may not work in all cases. As Skene puts it, “Some people are fine being jerks, and I don’t think we need to solve that.”
Talking to the Right People
User research is a huge opportunity to correct biases with direct quotes and real data, but designing user tests can be tricky. Balancing speed of results against diversity of responses is key.
“When we need user input quickly, it can be easy to ‘hallway test,’ or ask the network for people on the team. This can limit the perspectives we get in short feedback cycles,” said O’Connell. “The more diverse our team and network, the less blindspots we have. It’s important to reach out to a broader group to get user input or do user research when the product is used by a large audience.”
Confirmation bias is another common trap. It’s easy to look for patterns in user research that align with what you were already hoping to do. Both O’Connell and Skene mentioned the value of being surprised by user research.
“In user interviews, I try to ask open-ended questions — especially at the beginning and at the end. I let my rainbow spreadsheets have a lot of rows, so I don’t seek to confirm the first research subject’s responses. I try to let myself be surprised, and make a point to listen,” said Skene.
“It is OK to be wrong in your hypothesis. Listen to teammates with differing opinions and take time to ask them ‘why,’ and get to the root of their ideas, even if your knee-jerk reaction is not to go deeper because it doesn’t align with your current thought,” added O’Connell.
Tools & Rituals
In an ideal world, we would have a diverse and representative group of people on the product team who wouldn’t need to guess how our product affects our customers. While we build towards that world in our diversity, equity, inclusion, and belonging (DEIB) efforts, we need tools and processes that work as proxies for the customers we hope to serve. Though they’re intended as a way to avoid centering ourselves in the product we build, personas can be fraught.
“Personas are used to humanize the product, which is good, but the problem is that we bring racial bias in along with personas,” said Skene.
In the rush to start building, teams often rely on clients who understand the product requirements to flesh out personas rather than basing the face of their product on real research and real people.
“Do some research about who your users are and make sure to surface some traits in your personas that aren’t only the dominant background, culture, race, gender, or family structure,” recommended O’Connell.
Skene wonders if there’s a way to start from data even when we don’t have the time or connections to interview customers directly. Starting from statistics for the demographics you’re hoping to reach may be a different, interesting approach.
“Maybe there’s another activity or another way of thinking about getting the drone shot of the population before zooming in. Maybe there’s some other way of visualizing the broadness of who we’re trying to capture,” Skene said.
Some teams have moved away from personas and towards behavioral archetypes as a means of bringing the end user into the decision making process. But nothing beats actual observation.
“Seeing a person and observing how they use your product does a lot to increase developer empathy. Maybe read a profile on someone — see how their salaries compare with tech people. Use data points, but really try to humanize the people who use [your] products,” added Skene.
Finally, Skene mentioned trying to break out of her comfort zone and mimic conditions outside of a tech environment built to maximize comfort and productivity.
“Sometimes I’ll do things on my phone instead of my computer to test what I’m working on without fast internet and my giant monitor. How can you experience the world differently when you don’t have all the luxuries and newness? It’s honestly not something I think about enough,” she said.
The Uphill Battle
A lot of these strategies and processes assume you’re working with a receptive client who’s interested in checking bias and building towards intersectionality. But that hasn’t been our experience with every company.
“When I think about the clients and tech companies that I have worked with, most of their company values do not involve supporting a diverse user base. They tend to care more about treating coworkers with respect — not treating all humans and users with respect. I think changing this mindset will require companies to think more about their place in the world and the impact they want to have on society. VCs want to make money — not change the world,” said Skene.
While we can do our best to challenge existing perspectives and bring new perspectives into the product development process, more diversity among employees is key to helping enact change.
“Founders often build their initial team with close friends, but often those close friends have extremely similar life experiences,” said O’Connell. “They went to the same high school, same college, are from the same area of the world. This is tempting when you have a vision of working in a garage and every night is a work-hard-fun-times-with-your-best-friends hackathon. But starting off this way makes it more difficult to grow your team. You lose out on the ability to shine a light on opportunities or missteps that having a team with a variety of life experiences will bring to the table.”
“Intersectionality could be used as a lever for recruiting and employee retention and marketing. It could become necessary if society shames a company into caring. But caring about intersectionality with a purely altruistic or ethical goal? That is a tough sell for an established company,” added Skene.
Additional Resources
Thinking in Triplicate, Erika Hall
Previous post on intersectionality and design
Previous post on intersectionality and software engineering
Click here for more information on Carbon Five’s internal efforts around diversity, equity, inclusion, and belonging (DEIB). If you’re in the tech industry and interested in exploring DEIB issues, we’d love to work with you! We’re always taking on new projects and hiring folks who are interested in making the tech industry a better place to work.
We’re hiring! Looking for software engineers, product managers, and designers to join our teams in SF, LA, NYC, CHA.
Learn more and apply at www.carbonfive.com/careers
