📖 Nudge: Why Product Managers Should Become Proficient Choice Architects

This blog is relying heavily on Nudge by Richard H. Thaler and Cass R. Sunstein. While I highly recommend this book, this is not a review of the book, and you do not need to have read the book to enjoy this article.

In this enjoyable read, with a lot of humour, the authors present the impact of choices and decision-making on critical economic and societal issues: healthcare, loans, subprime, student loan, education, marriage, etc.

With a lot of humour, the authors present two key personas: The Econs and the Humans.

The Econs

On one side, the Econs: These folks are pure analytical brainpower. They are spreadsheet experts, and before making any decision they will review thoroughly the options, survey the market for the best possible solution and come up with the best possible choice architecture for their own situation. Imagine a spreadsheet with 20 columns and more, some type of future projections and then all the weighted criteria based on their own situation and problem.

To give you an example, an Econ friend of mine was looking for a new microwave. He built a spreadsheet with 20 interesting models for his use case and then came up with 30 criteria (each in its column!). All in all, he filled in 600 values. He used online product descriptions, reviews, and local flyers, visited some stores, and took pictures of the micro-wave he found. He also ordered a special consumer report edition dedicated to home appliance reviews in order to complement his analysis. Then he made his choice with a scorecard formula weighting all the various criteria. He finally purchased the selected microwave based on this thorough analysis.

The Humans

On the other side, the Humans. Humans are not as rational as the Econs. When faced with lots of choices, they do not come up with a spreadsheet with 600 values. They prefer to enjoy life and are quite happy making decisions without a formal model and a formal analysis. They rely on other signals to make decisions in particular feelings (beauty, trust, etc.), quality of the pictures and social proof.

For most of us, Humans, if your microwave is broken, you will most certainly look at the flyers in your mailbox (if you still accept them!), define a budget and browse online your two or three favourite places where you had good customer service. Then you will commit to the purchase and buy it.

Choice Architecture and Choice Architects

Each time your product gives a choice to your users, you are implementing a choice architecture. Most of the systems are designed by experts, and experts tend to be of the Econ type. They are well aware of the context, have deep knowledge of the problem space, and want to maximize their users’ possibilities. A typical flow in product development is that we are developing our product for the CEO or any high-pay person. Moreover, we often assume everyone is like us and will behave like us when faced with these choices (especially in teams lacking diversity or trust).

We, as product managers, are often in this category: we are subject-matter experts in an area (we are in love with the problem space, after all!). We also have goals for our products, for instance, objectives and key results. We also love to measure things and behaviours and supplement our qualitative research with hard evidence.

User testing and UI design are robust anti-bias processes that help the team realize this mistake: nothing is more enlightening than watching a user struggling to make a choice that seems effortless and evident for the product team…

A Neutral choice architecture does not exist!

The Nudge authors demonstrate that there is no neutral choice architecture. Let’s see why!

Your users will most certainly trust your defaults. That said, because Humans are change adverse, they will stick with the default for a long time even if it is detrimental to their long time success (or health, financial independence, etc.).

If you refuse to have defaults, you are forcing your new users (with minimal context!) to choose from a list of options. In this case, the first option listed (the default option!) will become the most used one! This has been proven to have consequential decisions: for instance, being listed first on a ballot give this candidate roughly 7% more vote compared to other candidates who have a similar level of popularity!

If you randomize the list, you are also choosing your users: you are choosing to distribute each option equally. Once done, you will realize that it will most certainly cause a great disservice to your users as they will stick with this random default for a long time for no good reason (your users do not have random needs!).

As you can see, it is impossible to “not decide” and to implement a “neutral” choice architecture in your product!

PMs most crucial responsibility should be to set up a correct choice architecture for all their users as their needs evolve.

Your users are not static personas. As they start using your product, the choice architecture should support their growing understanding of your product. Thinking about your users with a video game analogy may be helpful.

1. Newbies/New users have little context and lots of trusts. They decided to purchase and use your product after all! They should not be overwhelmed with a complex choice architecture. The default setup will remain the most prevalent option for these users. If no default is possible, radio buttons and simple high-level selection with a wizard and in-context help sounds like a great idea. In most video games, we have a tutorial mode where every choice is very limited but easier to make and understand than the “real game” with helpful contextual help and a safe zone to experiment and learn.
2. As users better understand your product, they learn more about their needs and what your product can and can not do. They will be very interested in certain areas that are very important or relevant to them. This would be the “main quest” or “main gameplay” for most players in a video game. As a PM, you make these controls/setups readily available and discoverable as your users become more proficient with your product.
3. Power users’ needs differ: they have mastered the fundamental principles and are experts in their domain. To continue the video-game analogy, these players require “add-ons”, “plugins,” or even “mods” to be satisfied. They are also exploring all the options, quests, and sub-quests to ensure they have a complete experience with the game. A platform approach with API, partners and apps can play a considerable role in pleasing these experts. They tend to be Econs, happy to learn and read hundreds of documentation pages, advanced tutorials and developer docs to meet their needs. The PM must carefully determine these functionalities: what is not directly doable in your product but can be extended via third-party and partnerships?

Conclusion

The choice architecture for your product is essential to remove friction and ensure the adoption and usage of your product for new, experienced, and power-users. As a product manager, you should consider how to help user graduate from newbies to experienced users to power-users and not overoptimize for one type of user experience.

1. Awareness: A first important step is to be aware that most of the product team (and even, at a certain level, your company!) tend to think like “Econs.” They know all the complexities, subtleties, competing implementations, trade-offs, possible success metrics and features required to implement a new product (or functionality).
2. Acceptance: You cannot solve the Human’s and Econ’s problems simultaneously. Try to divide your use cases/job to be done for new users (mostly Humans, great default/straightforward choice, tutorial mode), experienced users (more functionalities, less need for contextual help — a mix of Humans and Econs) and your power users (mostly Econs with lots of context, lots of expertise and an exact need)
3. Action: Make sure you test your choice architecture with all types of users (newbies/tutorial mode, experienced users, power users). Validate the content and information architecture that support these choices with each user type. Based on this discovery, define carefully what need your product will not fulfill and whether or not you want to enable third parties to solve this need (meeting and validating your ideas with potential partners is also a great way to ensure this will happen!).

In general, it is easier for new product teams to focus on new users because:

1. They don’t have a lot of contexts/face the same challenges as new users.
2. They focus on acquisition as this tends to provide more immediate value.
3. Once the team gains experience and context, they can focus on the power users (harder /more challenging problems).

Once a team has the expertise, there is no turning back: this is the curse of knowledge bias (at the team level). We tend to lose our Human nature and become increasingly Econ-like with sophisticated mental models, tools, and holistic understanding of the problem space. Two useful tactics to look at things with a beginner’s mind:

1. fresh eyes either from new team members, interns and other specialties
2. testing with non-users

Feedback is a gift 🙏: Please do not hesitate to share your thoughtsts

• via the contact page form
• via a LinkedIn connexion or message

• Book
• Choice