As engineering leaders, our ultimate goal is to deliver exceptional products that improve the lives of our users. Too often, teams fall into the trap of building products for themselves rather than articulating user needs, resulting in features that fail to gain traction.
The Hidden Pitfalls of Uniformity in Product Engineering Teams
At Spotify, I inherited a team that built social features into the Spotify experience. The roadmap the team had been working on included collaborative playlists, advanced playlist-sharing controls, and the ability to organize your playlist library. Being a music lover, I personally was super excited about this roadmap — these were all features I would use and appreciate!
As I got to know my new team, I learned that a lot of their projects from the last year had failed to gain traction. Features would launch, users (broadly speaking) wouldn’t engage and adopt, and the features would get rolled back. As I listened to story after demoralizing story of “we built it, but it never succeeded,” a few glaring problems became apparent:
- The team was building for themselves (tech-savvy music-loving power users) and not for the general public with established user needs
- Related to the above, product requirements were not being vetted with research (early concept testing, competitive analysis, user research sessions)
Debugging why the playlist-sharing feature wasn’t successful, I surveyed the team: how many playlists have you created? The answers ranged from tens to hundreds. I surveyed the team: how many playlists have the average user created? Nobody knew.
Turns out the average answer was 0.
This stat gobsmacked the team, and it slowly became obvious why many of their features never gained mass adoption — they were building power user features for themselves (tech-savvy music-loving power users) and not for users. They were developing products in an echo chamber, from ideation to leadership reviews to launch.
I started to bring in diverse perspectives into early product thinking — less “advanced” users from other parts of the company, as well as paid research participants. This was the early days of Spotify, so this meant scrappily posting on Craigslist and paying people with gift cards to spend 45 minutes with us.
I started weaving research more deeply into our product development cycle. Being based in NYC, a great research lab was nearby in Jersey City. The first time we did some product concept testing, we could chat with a diverse (at least through the New Jersey lens) set of Spotify users — Bon Jovi lovers, Bruce Springsteen fans, and a bunch of casual music listeners.
This research helped us to understand better that users needed help understanding and building playlists—especially their first playlist. This research was slow and costly—even better would have been to have these user needs understood and embraced earlier within the team.
Diverse product engineering teams make the best consumer products
At Facebook, I built a team from the ground up to evolve the News Feed user experience. Ten years after its creation, the front page of Facebook was somewhat stagnating, especially as innovation was happening across many other apps (at the time — Instagram, Twitter, WeChat, Snapchat).
As I built out our team, I worked hard to create a team that mirrored the people we were trying to serve with News Feed — current, future, former, skeptics, novices, and power users. I hired people who “used to use News Feed but don’t really like using it anymore.” I hired people who “would rather use Snapchat/WeChat/Instagram than News Feed.” I hired people who have family members who are new to the internet or new to social media. I hired across backgrounds and ages, which, among other benefits, allowed us so to leverage perspectives from differing social circles.
Having this diversity present within the team was invaluable as we created products to serve all of these cohorts. We built with well-articulated, validated, and embraced user needs in mind. Rather than building for hypothetical users, we were able to hone in on specific opportunities to help users along their journey of understanding and using our products.
In many cases, this meant focusing more on reducing clutter, reducing friction, and simplifying the user experience rather than adding additional complex features. The diverse team intrinsically understood the opportunities, which allowed us to experiment and iterate quickly to improve the user experience.
Diversity-driven innovation leads to truly exceptional products
Not only does a diverse team understand a wider range of users, but they’re also more likely to challenge each other and think critically. It’s this diversity-driven innovation that leads to truly exceptional products.
Be open and honest within your team around deliberately building diverse teams. Celebrate diverse points of view (especially product skeptics), and embrace how your product fails to meet user needs.
How Diversity in Product Engineering Teams Leads to Better Products was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.