I recently finished reading Thinking Fast and Slow by Daniel Kahneman. Having done that, I am more convinced of a recently formed belief. Building great products is all about understanding people.
Behavioral economics and psychology of judgement is everywhere. Understanding your customers and their behavior. Working with your stakeholders to convince them of something.
Learning about your own biases while making judgements under uncertainty.Humans are full of flaws.The wiring of our brain makes flaws in decision making both inherent and pervasive.
We use poor heuristics to make decisions. We recognize patterns when there are none. We tend to have strong convictions when there is little to no data.
So is there not much hope then? Here is whats suggested:The best we can do is a compromise: learn to recognize situations in which mistakes are likely and try harder to avoid significant mistakes when the stakes are high. How this applies to product buildingAs I read the book, I ended up recollecting past experiences of my own.
How could I have avoided my past mistakes? Could I have done differently? A few things stood out:1.
Falling victim to the planning fallacyThe planning fallacy states that when we plan for projects, we do so with delusional optimism. Whats needed instead is a rational view of the world. And this conviction stems from very little data.
How often has a stakeholder pounded the table for a specific feature? How often are projects stretched because of poor time estimates?Last year, we were expanding our product into a new market.
To do so, we needed to get approvals and make product changes. The estimated approval time from the business side was a month. Engineering estimated product changes to take a similar time.
In the end, approval took 6 months and making the product changes took 2 months. Furthermore, the project didnt have the initial traction that everyone expected. Our planning fallacy put us in an embarrassing situation.
How to address this: Avoid this optimistic bias by evaluating how and where your product plan can go wrong.Carry out pre-mortems as a part of product kick-offs. Identify potential risks and failure modes.
Use the past and comparable timelines for regulatory approvals. Watch for aggressive timelines that are out of your control.Push engineering to check where things can go wrong.
Get an upper bound on timelines (in addition to the lower bound).2. The availability heuristic and the bias of whats on our mindThe human mind creates illusions and uses heuristics to evaluate the limited data we often have.
The availability heuristic is one of them. We judge the frequency (and thus the importance) of something by the ease with which instances come to mind. Im amused that I could be writing about the availability heuristic because of its availability.
:)The availability heuristic substitutes Whats more significant? , with What do I recollect more?.
In product , you might focus on addressing feedback given by an infuriated customer. Instead, the more impactful investment might be an issue that people arent as vocal about.This same thing was happening on my product teams when it came to working on small projects that were user-feedback driven.
We seemed to be working on projects for which we got feedback from the user the previous week. Were we working on the most impactful features? Probably not we were not sure!
Another mistake that I was doing in stakeholder teams (ex. Sales meetings) is asking the question Whats top of mind for you?.
Looking back, I used to equate top-of-mind items as being the most important.The availability heuristic is also why we overweight the urgent over the important in our work. The urgent is top-of-mind i.
e. its more available. And the focusing illusion makes it seem more important that it is.
How to address this: Remember that top-of-mind != importanceBe diligent about tracking different pieces of feedback and their level of importance. Have a sense of global importance of issues.
(I recently started using Productboard for this)Recognize this bias and when you make decisions. Take a global view of the feedback to judge importance for actual importance.3.
Formulas trump intuition in low validity environmentsIn uncertain environments, even the simplest algorithms match or exceed expert views. Predictions of outcomes of football or soccer games is one common example. Product building (especially at early stage startups) also happens in highly uncertain environments.
Why dont we use simple formulae more?Experienced radiologists who evaluate chest X-rays as normal or abnormal contradict themselves 20% of the time when they see the same picture on separate occasions.Over the past year, Ive been growing the product team at my current startup.
After candidate interviews, we de-brief and discuss the hire/no-hire decisions. In such de-briefs, I noticed that the feedback was in the form of I liked/disliked the candidate. Interviews are a particularly curious case where biases are rampant.
Furthermore, interviews based on such guesses have shown to be poor predictors of future success. Thats where a simple formula would be ideal.The fallacy of intuition also affects product prioritization.
Typically there are a lot of subjective judgements on a projects importance. Is investing in a project driving better user experience more important? How does that compare to a project that directly influences our bottom line?
These decisions are hard. Our team faced a lot of churn in deciding and making quarterly product plans. How to address this: Institute simple formulae when opinions could cloud judgement:When interviewing for your team, decide skills to be evaluated.
Come up with a simple scoring system. It eliminates poor intuitive guesses.Try to build simple formulae for how projects impact your bottom line .
Having a simple equation for how your business works can be very useful. (Ex. How does your company generate revenue?
What levers go into it?)4. Cognitive ease matters for product experiencesOur brains have 2 systems (called system 1 and system 2).
The system that allocates attention to effortful mental activities is lazy. It also gets depleted quickly. There is a natural tendency for the brain to desire cognitive ease over cognitive strain.
What does cognitive ease mean and what does that cause?When we were building Dropbox Extensions, we werent sure how to word the CTA. Thats when years of repetition and user priming came to the fore.
We called the CTA Open With, given that users had been primed for years from their desktops (and thats what the action basically did). A quick A/B test confirmed our suspicions.If you look carefully, cognitive ease is employed in tons of products.
Why does Wikipedia plaster an ad on every single page? Because repetition primes people to donate. Why do pithy meme-style tweets on Twitter get the most engagement?
The answer is cognitive ease. This also directly links to the Trigger, Action, and Reward model proposed by Nir Eyal in his book Hooked: How to Build Habit-Forming Products. How to address this: Identify where your product presents cognitive strain to user users.
Where are they applying more effort than they need to?How can you get users to cognitive ease by employing causes such as priming and clear displays?Want to understand psychology to build better products?
Here are my top book recommendations:Thinking Fast and Slow by Daniel KahnemanInfluence, the psychology of Persuasion by Robert CialdiniHooked How to build habit forming products by Nir EyalThe Power of Moments: Why Certain Experiences Have Extraordinary Impact by Chip Heath