Behavioral economics is, ultimately, about how we think of people. The assumptions we make about people change how we approach problems related to their behavior. If we assume that their actions follow their intentions, we will design programs that attempt to change intentions. If we think that people take an action if they are informed of the consequences, we will design programs to educate them. However, if we take people as they are—fallible yet clever, short-tempered yet patient, the paragon of animals and yet the quintessence of dust—we can design interventions that work.

This approach makes defining a problem (that gets to the core issue at hand and that can be addressed by behavioral diagnosis and design) really hard. Crafting a problem definition is as much an art as a science. As such, there are no step-by-step set of instructions to follow. However, we will share a few of our favorite tips and tricks that have proven useful in the BETA Project.

Tactic #1: Change the Scope

A problem statement often starts off as a piece of a bigger problem or as a collection of smaller problems. When a problem is defined too broadly or too narrowly, a change of scope is necessary. A problem statement that is too broadly defined often falls beyond that project’s scope of work and can feel overwhelming and daunting. In the BETA Project, to check for this, we would ask ourselves, “What are the components of this problem? Of these, what is the highest priority and achievable?”

A narrow problem statement, on the other hand, limits investigators from exploring other areas that may ultimately prove relevant. It feels like solving it won’t actually get you to the desired goal. To check for a statement that is too narrow, we would ask, “Is this part of another problem? Would fixing this problem just be one of many other fixes necessary to solve that other problem?”

While there isn’t one right answer to any of these questions, reflecting upon them in the BETA Project often helped us detect a hazy problem definition. It also set us up to practice the following two problem definition tactics.

Tactic #2: Remove Assumptions

In April, we posted a summary of the 99 problems presented to the BETA Project. It was really interesting to see how these problems looked from the applicants’ perspectives, but the problem statements often contained hidden assumptions about the challenge posed.

For example, some applicants reported that they experienced low take-up of their program because their promotional materials are not well designed. This assumes that their problem is bad advertising and that low take-up is due to a lack of knowledge about the program. Looking at the problem with these assumptions sets someone up to try to fix the advertising, without thinking about whether or not there could be other reasons for the low take-up. Assumptions limit the exploration of possible solutions in many domains, from the field of asset building to Antarctic exploration.

Consider the classic behavioral problem of getting people to save more for retirement. For decades, human resources professionals have tried to encourage employees to save more for retirement. They typically used one of two approaches: either increasing the employer match, or encouraging employees to attend seminars. They rarely thought about how the problem was defined and instead focused on costly incentives and time-consuming education as potential solutions.

These approaches have built-in assumptions about why people were not saving. They assume that people are not saving because of a lack of motivation (which would be solved by increasing the employee match) or education (which would be solved by classes). Incentives and education are powerful tools for a program designer, but they should be considered two tools among many.

By removing these assumptions and asking “How can we get people to save more?” we open up the range of possible solutions to try out. New possible diagnoses (such as limited attention) present themselves, and they imply novel solutions (such as “opt out” 401(k) programs).

Tactic #3: Change Representation

Another useful tactic for problem solving is changing how the problem is represented. Imagine that you and a friend are playing a game. In the game, you lay out nine cards (an ace and all the numbered cards, two through nine), and you alternate turns picking up cards from a table until one person has three cards that total exactly fifteen. You start by laying out the cards in a row and start to play.

How should you even start? It’s really hard to determine the best way to play when the cards are laid out this way. More likely than not, you’ll end up with a game that looks something like this where there’s no way you can win—or block your friend from winning.

How could you avoid this situation? What if you went back to the beginning of the game and re-thought the problem? You realize that the object of the game is to lay out the cards and be the first to get three cards totaling exactly fifteen. There’s nothing that says the cards initially need to be laid out in a row. By laying out the game and representing the problem that way, you made it hard for you to play. So, you rethink the layout of the cards and position them in a square where each row, column, and diagonal totals 15.

With the numbers arranged in a “magic square,” the problem becomes simple because it’s set up like a tic-tac-toe game. As long as you pick a corner card first, you can’t lose (watch “How to Win Tic Tac Toe Every Time” if you don’t believe us). Changing how we represent the problem makes it easier to see the path towards solutions. For practitioners designing programs, changing representations can be done by thinking about the situation from a different perspective. For example, you could ask yourself, “How does my client view this situation? Would they think there is a problem? How would they define it?”

Next BETA Project Post: Defining Problem Statements in the BETA Project

By using each of these tactics in the BETA Project, we were able to refine the problem statement at each site to arrive at problem statements that are not defined too broadly, too narrowly or tangled with hidden presumptions. Our next post on the BETA Project will look at the original and final problem statements for each site and how we refined them. This post and other helpful insights from the BETA Project are available on CFED’s Behavioral Economics blog and BETA Project website.