I was recently going through an interesting challenge where I was developing a product intended for all developers in an organization that spanned multiple verticals and hundreds of teams. It made me think of an important question: how do we treat everyone equally? Is it even possible to meet everyone’s needs and be fair? How do we manage trade offs while remaining principled?
This is an urgent question for any product manager. In such a role you hold a unique position of influence, shaping the experiences of diverse users; this is why recognizing and trying to address this tension is crucial. But how can that be done convincingly?
The challenge of defining "equality" in product management
Equality is problematic in product management because you’re building for diverse users. They have different aims, needs, abilities and levels of access. Pretending everyone is equal — as if you’re just building a product for a single idealized user — will not only exclude many people but is also likely to fail.
Indeed, although it’s true that targeting a given persona or user group can be helpful if you’re trying to quickly get something to market, continuing on that path — as if there are no other options or no other groups of users currently excluded — can create a lot of issues, ranging from the technical to the commercial. You might well, for instance, have to spend more time or money as you build new features or refactor down the line, or even miss out on potential revenue by missing a wide segment of other users.
In my particular case it was all to easy to just look at the developers with the right level of experience and build for them. However, while that might have been the right approach in the short term, contexts change, people leave and new people join the organization — building the product for an idealized user in a fixed context that would never change would only diminish the product’s effectiveness over time.
So, how did I go about trying to tackle this? First, I had to think about the inherent diversity of the user group: in other words, what were all the ways the developers I was building for different?
For example, the developers all belonged to different verticals inside the organization and to different teams with different goals. Some of their projects were small, some large, and they all also used very different technology stacks. Even within a single vertical team there were different levels of knowledge and experience. Also they varied in terms of experience from juniors to highly experienced veterans of the product. This meant there was a real need to move beyond a reductive understanding of equality where you treat every user the same and instead embrace a nuanced approach that acknowledges and caters users’ diverse needs.
To try and do this I conducted a few introductory interviews to better understand my user base. Once I had done that, I focused on building tailored ways of getting the information from them. This included additional interviews with smaller, more experienced groups, as well as surveys and targeted workshops. This helped me better understand the needs of each group and how I could split the work that needed to be done to provide long term value to each group.
Moving beyond the false dichotomy
Instead of framing the issue as a binary choice between absolute equality and complete inequality, it’s important to adopt a framework that acknowledges individual and group differences while striving to create a level playing field for participation and access. This framework, often referred to as "equity," focuses on providing individuals and groups with the resources and support they need to overcome their own specific barriers and thrive.
In the context of product management, this means:
Understanding user diversity: conducting thorough user research to understand the diverse needs, abilities and perspectives of potential users.
It’s usually really hard to get the information about your user diversity. Most of the time people don’t know what they don’t know. Focusing on a few well-placed interviews to build that initial understanding is critical. After that, I just had to tailor different user research techniques for each group.
Identifying accessibility gaps: Proactively identify potential barriers to access and usage within the product, considering factors like the technical stack, project context and various knowledge limitations.
In my case, once I had a solid understanding of the organization’s ecosystem, I was able to dig deeper into each group and each vertical, to understand their knowledge levels and how they use the current product. Based on this I was then able to identify a few barriers in access and usage that were translated to points on the roadmap. What was hard was to understand the behaviors that needed to be changed in order to move forward towards better outcomes.
Building inclusive products: Designing and developing products that are usable and cater to the diverse needs of various user groups, ensuring everyone has an opportunity to benefit from the product's value proposition.
We all want to build a product that works for everyone from the start. I think the hardest thing to acknowledge is that we often can’t do that — or, more often, by the time we can, the product is obsolete and replaced by another one. So, what I usually do here is try to understand what the journey is to actually get to that point. By planning the journey correctly and making sure each user group is included in it, I can do a much better job at ensuring everyone will benefit.
Promoting equity in data and algorithms: Recognizing the potential for bias in data collection and algorithms and actively taking steps to mitigate these biases to ensure fair and equitable outcomes for all users.
Data can be really valuable. I know everyone collects data — a lot of it. The challenging part is collecting the right data that helps you make the right decisions. What I really focus on here is understanding my own needs: what data do I really need and, most importantly, why?
Don’t let perfect be the enemy of the good when it comes to product value
Even by applying all of the above, there’s no guarantee that a product will deliver value equally. However, we can acknowledge that that is okay: focusing on equity is trying to be fair and impartial; it’s a goal. That is why you need to build your roadmap with these principles in mind.
This being a journey, it needs to be transparent where we are going. By letting my users know what the target is and how we are getting there, I can more effectively build trust with them. They understand what are the short term, mid term and long term priorities. As such, the users also know when they can expect their share of equity in the product.
Embracing the paradox: A call to action
Striving towards equity and addressing existing inequalities within product management space is a crucial and ongoing pursuit. But it ultimately requires a shift in mindset and a commitment to:
Continuous learning: regularly engaging in self-reflection and actively seeking out diverse perspectives to challenge our own assumptions and biases.
Continuous discovery: regularly talk with your users, understand their context, and how this context evolves over time.
Prioritizing empathy: cultivating empathy for users and understanding the lived experiences of individuals from different backgrounds.
Advocating for change: Using our positions of influence to advocate for diversity, equity, and inclusion within our teams, organizations and the broader tech industry.
By embracing the paradox of equality and adopting an equity-focused approach, we, as product managers, can create products that are truly inclusive and accessible and empower a wider range of users to participate in and benefit from the digital world.
Remember, navigating the complexities of this issue involves an ongoing learning process, a willingness to challenge the status quo, and a commitment to creating products that contribute to a more equitable and inclusive future. It is a journey.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
