Chapter 28: Magic Wand Theory

Learn how to reverse engineer your ideal user experience to better execute your product features.


What you will learn

  • How to use the "Magic Wand Theory" to guide important product decisions

What do you want your users to do?

I want to take a moment and explain a concept that is often overlooked when brainstorming products and more specifically, product features. While this concept can be applied to all applications in some capacity, it becomes increasingly relevant in applications that require high engagement to succeed (i.e. a social network vs a utility application).

The Magic Wand Theory was coined by BJ Fogg, a behavioral scientist and innovator from Stanford University (I can't take all the credit for this!).
His wisdom on the relationship between user engagement and products are definitely worth checking out. I encourage anyone who is creating products in technology to check out his work. I will also reference tid-bits of his work throughout the rest of the chapters in this book.

The "Magic Wand Theory" basically asks, "If you could wave a magic wand, and have your users do exactly what you want them to do, what would it be?"

Sounds simple right? Almost too simple. Many people overestimate the power of approaching their products this way. If you have ever worked with a product team, or even brainstormed product ideas with a colleague, you've probably encountered a conversation like this in some shape or form:

Person 1: "We need the users posts to be visible to all users." Person 2: "But, what if that user only wants it to be seen amongst a certain group of people?" Person 1: "Well do you think it is fair to the other users that have signed up to access exclusive content?" Person 2: "Well then we'll have specific features tailored to those individuals." Person 1: "OK, then maybe we should have a tiered payment system for each level of membership."

I hear these types of conversations far too often. They are largely abstract, and turn into debates of theory and "what if's." Without creating more context to the situation, you can gather the following:

  1. Person 1 and 2 have a theoretical disagreement. It is basically a disagreement on privacy.
  2. Person 2 is creating a scenario with an unknown frequency of occurrence.
  3. Now both people are compromising by creating a solution to a problem they have created, and in turn creating a potentially useless features and payment system predicated on false assumptions.
  4. It's difficult to justify any features because it is still unclear what the user should be doing.

Basically by going down this rabbit hole without addressing the ideal user experience, many product managers end up fabricating features based on false pretenses. This gets passed on to developers and designers who will spend months building the product, only to find that users are not using it as it was originally intended. Instead, you can open up the conversation by using the "Magic Wand Theory":

You: "But wait! What should the user be doing the second they open the application? I think it should go straight to the post page, where the user would post a startup idea they had. Other users in the community will up-vote or down-vote their idea, and the user will comment and discuss pros and cons."

Getting straight down to what the user should do, turns abstract ideas into concrete, actionable features, and gives you a goal post to strive for. Now every feature, interaction, and discussion will hinge from what the user should be doing. This will make conversations more focused, less abstract, and actionable.

Now we can go back to the first conversation, and re-evaluate the ideas discussed:

Person 1: We need the users posts to be visible to all users You: Great, because our goal is to have people interact with that persons post, that seems to make the most sense. We can always make minor adjustments post launch.

Done! Nothing further needs to be discussed. No added features or membership tiers etc, and now you and your team have a "true north" for every discussion thereafter :)

This is just one mock scenario of many real ones. I encourage you to think about this whenever discussing product features and ideas, and always ask yourself "What do I want the user to do?"

Wrapping up

Make sure to constantly ask yourself in each design decision, "Ideally, what would we have the user do?" This will help navigate the clutter of possible features and allow you to hone in on the most optimal experience for your users. It will also serve as a chopping block for many unnecessary conversations which can dilute the mission of your product or company.