Consider the following scenarios.

One, you vote for the government to reduce spend on education by twenty percent which results in ten thousand kids not being able to afford to go to school. Two, you reduce the salary you pay your maid by twenty percent, which results in her not being able to afford to send her kid to school.

One, you find out that thousands of pigs and cows and chicken are all trapped in cages that are not even big enough for them to turn around, so that the food processing industry can be more optimized and reduce food prices for thousands of people who would otherwise go hungry. Two, you are asked if you'd like to treat your pet cow the same way to get more milk out of it.

One, you accept as inevitable that millions of people born in poor countries have no access to basic food and healthcare needs. Two, you are incensed when a much smaller number of people are deprived of these facilities in a rich country that you happen to be a citizen of.

In each of these cases, we feel much more guilty about the second case than the first. We tend to take action in order to set right the second case rather than the first.

This is the trap many product managers tend to fall into as well.

Something that we see in front of our eyes and something that we can associate with a person we know triggers us into action in ways that mere statistics simply cannot. Yet, the bigger impact is had when we address the statistically significant problems rather than what a handful of people face.

When we conduct user research, or have brainstorm sessions, or read user reviews, we are focusing our attention on what one person or a handful of people feel when they interact with the products we ship. True, these problems might be real and important for these people. But unless you ensure that that is also true for a significant majority of the user base, you will be spending time and resources building a feature or a solution that will have negligible impact on the wider scale.

This is the difference between building a product with few users and millions of users. Startups can be nimble and quick because they only have a small number of users and a quick conversation with a few of them can highlight the major problems that they can solve in their product. But that is not the case with a mature product that has a big user base.

As your user base grows, you will have to move the basis of your decisions and prioritization away from conversations, user reviews and user research where you talk to a handful of people and towards statistical data analysis.

As your user base grows, user research is merely a tool to identify a list of problems, and needs an additional step of estimating the size of the audience that could be affected by it.

Like in the scenarios I highlighted at the start of the post, product managers tend to get attached to the information that is close at hand (coming from user research and user interviews) and fail to look at the bigger picture of the entire user base.

And it takes conscious effort to overcome that bias.