Are Your Lights On?

---

In their excellent (and fun!) book, Are Your Lights On, software pioneers Donald Gause and Gerald Weinberg offer the following scenario. There is an office building with a deluge of complaints about there being too few elevators. What are some possible ways to address this? They start listing some possible solutions.

• Cut new shafts to add more elevators.
• Add elevators by constructing outside shafts.
• Advertise the building as a leisurely place to work.
• Raise the rent so fewer occupants are needed to pay off the mortgage.
• Get faster elevators.
• Promote taking the stairs to increase health.
• Provide more services on each floor to decrease floor-to-floor traffic.
• Move more occupants to the same floors to decrease traffic.

What might some other solutions be?

Now pause….

Did you start solutioning? That’s right—it’s a trick.

Solutioning without exploring the problem frame is a trap. But notice how normal it feels. We don’t even think twice about it. All we know in the example above is that there are complaints. We don’t know anything about the larger context, who the various stakeholders are, or what their various needs might be. Perhaps most damning, complaints about there being too few elevators does not necessarily mean that the elevators are even the issue.

But we love diving into solutions, don’t we? We’ve been trained to think anything else is waste. As a result, the work we do is often confined to whatever was top of mind. We end up delivering the obvious stuff. We deliver, and, if ROI is considered at all, it is considered in terms of the return on an obvious solution relative only to its own cost. That’s a small picture.

Let’s consider my favorite example. Someone asks us to make a certain dashboard more customizable. They say they need it because they want to be able to make better slides when presenting to executives. So, should we scramble and hammer the thing out and claim it as a big win? Maybe. That, after all, is the easy thing to do. That might even get us the most kudos. We could also, however, dig into the framing a bit…but this can be dangerous. We might surface larger problems than whatever the original request solves for.

For example, if there is a dashboard where anyone can go see the latest data for themselves, then why in the world are people curating it in PowerPoint to then “present” to executives? There are answers, of course, and none of them are probably good ones. (In this situation, it’s often because someone wants to “manage” the narrative, perhaps by cherry picking or even massaging the data.)

In Are Your Lights On, Gause and Weinberg stress some key questions we should always ask ourselves when doing product work.

1. What problem are we trying to solve?
2. In this context, what is a problem? (This is a very different question.)
3. Who has the problem? (Who all needs to be included in this process?)
4. What can be done about it?

These in turn imply other questions. What is the current problem definition? Where did the current problem definition come from? How good is it? What could be wrong with it? What are two alternative problem definitions, allowing us to explore the value framing a bit? And notice that answering these questions requires discovery. Again, we’ve been trained that discovery is waste. Our job is to shut up and deliver. So we skip discovery, ignoring that to intentionally solve a problem, any problem, we first must define it.

In research, what is “found” is relative to how variables are operationally defined. In product work, what is considered a “solution” is relative to the problem definition. How we define a problem “frames” or locks down our interpretation of the problem space. A frame is a conceptual ecosystem in which only certain solutions are suggested. The solution choices we then make are bound by our problem framing. When marketers talk about “choice architecture”, that’s also just framing.

When we focus on THE SOLUTION to the neglect of problem framing, we leave assumptions hidden. We leave value behind. When we don’t bother with framing, that doesn’t mean there isn’t one. There is—call it the “ghost frame”. It’s unseen but still there, haunting our decision making. We can’t think outside a box we’re not aware we’re in. Framing is impacted by our backgrounds, biases, assumptions, what we’re told about the matter going in (the “facts”), who the stakeholders are we try to make happy, and, even, what we think will get us promoted.

How we define the problem at hand creates our gold standard. If we don’t optimize this, then we’re left with fool’s gold. This is the main reason we make incorrect decisions, not stupidity, not a lack of information. It’s what psychologists call “cognitive sloth”, the conviction that our initial take is the right one. In product work, we too often ignore that first frames are suboptimal. Discovery, therefore, isn’t waste. Discovery optimizes frames.  

---

---

Imagine the “obvious solution” in the image above is “1D” below. We hear the “facts”, go with the first presumed frame, the ghost frame, which makes salient only certain solutions. In the image below, the optimal solution is highlighted in green. This will never come to mind if the framing needed to get us there isn’t bothered with. When the problem definition is improved, the solutions made possible will also change.

---

---

In Are Your Lights On, Gause and Weinberg emphasize that any sufficiently complex issue does not have a single, objectively “correct” problem definition. This means problem frames will vary…and so will the resulting value created (or not created). It also means—and this is a point we too often ignore—that the problem as handed to us is always to some extent ultimately arbitrary.

There is also Question 3 above: There is probably more than one group of people impacted by whatever the issue is, and they will probably have competing agendas and preferences. If we proceed with business as usual, then these various parties will campaign for their preferred ideas. As each competes for their own pet solution, each will perceive the others involved as being “difficult” and “problematic” instead of realizing they’re all just bringing different frames. The “winner” will be the loudest person winning, the best networker, the most senior manager, the HiPPO.

We get out of this trap by switching from the singular to plural. Remember, there is no unambiguous and unique problem statement—there are only variants; and, because of this, there will always be various competing proposals, plans, and strategies. Rather than simply advocating for one of them we should instead explicate alternative frames and plans and put them up against each other. Expecting such conflict—and indeed hoping for it—should in fact be a part of our process. If we don’t, then we’re asking small questions. To paraphrase Jess McMullin, when we ask small questions, we create less value.

---

---

In research, we cannot derive our hypothesis from the same data we use to test it. Similarly, in product work, the problem should not be determined by the preferred solution. Instead, we need to collaborate with stakeholders, users, and customers and link and raise their issues and interpretations. The inherent contradictions in any problem space should be welcomed and used as fuel for better framing.

Find a process and start experimenting. For instance, in Presumptive Design this is handled under the guise of the Creation and Engagement Sessions. By collectively driving early solution ideas to fail the team quickly comes to a cohesive framing of the problem; and, after only a few sessions, they often learn it isn’t quite what they had formerly assumed. To create more value, we should not deliver our first, best guesses faster—we should sacrifice our early solution ideas to climb out off suboptimal framing.

---

---