Overcoming Fundamental Attribution Error
On how to move past the “pot vs kettle” phenomenon in product teams
[Source: Fundamental Attribution Error: Why You Make Lousy Life Choices, Nir and Far]
An inherent dichotomy exists in how we understand the actions of others and how we justify our own. If we have issues using someone else’s product, that’s because of a poor user interface; if someone has issues using our product, then they are to blame. If we fail to deliver a spec for a new feature in time, it’s because we got pulled into some emergency; if an engineer is late with delivering their feature, it must be because they are inexperienced or tardy. Internal conflicts on a team are put down to incompatible personalities rather than organizational incentives to compete instead of collaborate with one another. Sales teams that exceed product quotas get lauded as talented “A players”, when in reality it might have more to do with selling the right products to the right market at the right time.
A cognitive bias called the “fundamental attribution error” better explains these relatable experiences on any product team. The fundamental attribution error essentially describes how observers over-attribute their explanations of other people’s behavior to the person and under-attribute the causes of their own behavior to the situation. In other words, when the going is good, our personal success stems from the fact that we are inherently talented, while others are merely beneficiaries of good fortune. And when the going is tough, we tend to cut ourselves a break while holding others 100% accountable for their actions.
There is good reason why we see this pot-vs-kettle phenomenon play out so often. If the personal attributes of individuals get credited or blamed for performance, then performance that doesn’t meet expectations does not raise tough questions about whether culture, product, strategy, incentives, or technologies might be misaligned with one another. In high performing product teams, it is convenient to downplay the impact of inertia, luck, early product decisions and the overall direction of the market. In struggling teams, it is often politically expedient to underestimate what people can personally impact and overestimate the impact of the broken system and/or management.
Fundamental attribution error can easily lead product teams to unfairly scapegoat individuals who are not performing well (often in no small measure because of the constraints of the systems they operate in) and justify perpetuating the status quo in teams. Taking a broader, more open, less biased and less political approach can help minimize the impact of fundamental attribution error in product teams over the long term.
1. Try to understand the situation in which your users find themselves, beyond just understanding the users themselves.
The fundamental attribution error directly applies to product design. When trying to find product-market fit for a new offering, a very natural inclination is to segment the existing market based on personal attributes or demographics. For example, a wedding planning app or website like Wedding Wire could choose to segment the market into hip Gen Z-ers and people getting married later in life, and subsequently target one of these segments. But to look at the wedding planning market from a traditional marketing and product lens (of segmenting by personal attributes) is to fall prey to the fundamental attribution error.
Target customers can be dissimilar on personal attributes but still have the same basic needs when it comes to your product (in this example, wedding planning). In this example, a 45 year old woman and a 24 year old man are likely both doing very similar activities with respect to their current situation (i.e., completing paperwork, finding venues, hiring a caterer, inviting guests and directing them to a registry as part of their wedding planning). Fundamental attribution error would lead you to believe that these two people seem really different. But from a product design standpoint, their needs overlap considerably. When designing products, it is helpful to emphasize the situation in which our users find themselves to begin to see the broader patterns.
2. When things go wrong, shift the lens from “who did it” to “what happened”.
First order-reasons for why things go wrong typically end up identifying “who did it” (e.g., Engineer X did not deliver on the feature spec document). Reframing the blame game to dig into second and third-order reasons (e.g, The spec document was delayed because it did not have well defined user stories because we’re still zeroing in on the target customer) could help pivot the focus more constructively to “what happened”.
Moreover, as humans, our brains are wired to sort people into “us” vs “them” categories. When we have people in the “us” world (yourself, your family and friends, or favorite colleague), they get treated differently than those in a “them” category (people different from you, people on a team that is always at odds with your own, that person who made you feel inadequate during a meeting) - especially when it comes to assigning blame when things go wrong.
One way to mitigate fundamental attribution error when it crops up in this manner is to debrief failures in an interdisciplinary context with diverse skills and perspectives. Failures on a product team are usually a consequence of multiple cascading events that occur across different disciplines (Engineering, Finance, Marketing, Sales) or at different levels of the organization. Understanding what happened and how to prevent it from happening again requires detailed, team-based discussion and analysis across the “us” and the “them”.
3. Reframe thinking of mistakes and progress as opposites to viewing mistakes as a big part of progress.
If failures are truly avoidable and due to a lapse on an individual’s part, it is important to respond constructively to avoid setting precedent for an anything-goes attitude. But there are also several situations where product teams would benefit from shifting to a culture of psychological safety in which the rewards of learning from failure can be fully realized.
For example, new features often have a preview phase before they launch more broadly for the general public. Product managers typically have an urge to do whatever they can to make sure that the preview is perfect right out of the gate. In an effort to do so, product managers in charge of pilots design optimal conditions rather than representative ones only too often. Ironically, this hunger to succeed (and fear of the blame game if things go wrong) can later inhibit the success of the official launch. Thus the pilot doesn’t produce knowledge about what won’t work, and only limits collective organizational outcomes. Celebrating both successes and failures in an experimental course of action can help drive better outcomes for individuals and product teams, by minimizing the tendency to fear the stigma and blame associated with failure.
(Hustle Fuel represents my own personal views. I am speaking for myself and not on behalf of my employer, Microsoft Corporation.)