The Problem Statement

The Problem is just the beginning. How the H4D course and teams dive deeper into solving them

The following is a case study that is used in the H4D course and an example in the NEW textbook Hacking for Defense, a graduate-level course taught at more than 70 colleges and universities worldwide and on three continents. More than 2,000 students have successfully the course. 

What Is The Problem Statement

The Problem Statement is the 1-page document outlining and explaining the problem from the Hacking for Defense problem sponsor’s perspective. It provides each team a clear focus to begin their work by specifying issues the Problem Sponsor would like to be addressed – and sometimes explicitly requests for improvement. While the Problem Statement is a beginning point, it only represents a single perspective of the problem. As the Hacking for Defense teams begin to identify and interview other stakeholders, each team will change the Problem Statement to incorporate a wider range of perspectives. Consequently, the Problem Statement is not meant to be a restrictive document that must be answered. Rather, it simply provides guidelines to help the teams align with the Sponsor and get started in the class.

Testing Hypotheses

Focusing on the problem statement and testing a hypothesis that supports it will lead to each teams’ problem statement potentially changing. Historically, H4D teams shift away from their original problem statement as they learn exactly which Beneficiaries to support and which of their problems to solve. These modifications are often the result of learning that although the original problem statement is indeed a problem, the modified problem statement is better suited for the team to tackle and/or better scoped for the course and/or presents the team with better post-course commercial opportunities. 

Albert Einstein famously stated, “If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and five minutes thinking about solutions.” The point he makes is important: Identifying the best problem to solve is the foundation of problem-solving. 

Like Einstein, each team’s H4D journey begins by thinking about the problem statement. Each problem statement is a real problem, and the problem sponsor (the government organization’s representative) is someone that directly experiences the problem regularly. Therefore, analyzing the problem statement and talking to each team’s problem sponsor is the first step to be taken.

The goal of each team is to hold off on pursuing a solution to the problem statement until the team truly understands the problem. Trying to solve the first (or second or third) problem encountered during interviews is alluring. Many teams look for quick fixes or off-the-shelf solutions. Several teams have fallen into this trap only to learn that the problem they heard or the solution that was requested is only experienced by a handful of stakeholders, and therefore, not worth solving. Rather, each team must understand the multiple perspectives of the problem statement by turning assumptions made by the problem statement into hypotheses that are tested during the interview process. Teams that avoid the temptation to focus on a solution only will avoid wasting time like so many Hacking for Defense teams have done before.

Creative Solutions

The ancient Greeks believed that there was an interplay between creative and analytical thinking which is why “inventory” (i.e., the things you know) and “invention” (i.e., the things you create with what you know) shared the same root word. One must develop a sufficient foundation of knowledge or inventory about a subject before novel approaches can be devised. In the H4D course, creative solutions aren’t precomputed. Rather, teams create successful solutions after generating a deep understanding of the problem through discovery. Developing an “inventory” begins with framing the problem and then the assumptions that underpin it. Therefore, each team must begin the problem-solving process by pulling out the problem’s underlying assumptions, creating hypotheses and testing them.

Types of problems

Boil the ocean problems: Boiling the ocean, in a literal sense, is impossible because the ocean is too big with too much water to make boiling feasible. Similarly, a boil-the-ocean problem is a massive problem with a scope so large that it is difficult, or even impossible, to solve. These problems encompass such a wide area that a team will not be able to make any meaningful progress during an academic term. The famous stoic Seneca captured the problem with boiling the ocean in his famous quote, “Our plans miscarry because they have no aim. When a man does not know what harbor he is making for, no wind is the favorable wind.” Per Seneca, boil-the-ocean problems inhibit teams because they are so broad that teams have no specific aim in solving them and, therefore, are unable to gain any traction. 

A boil-the-ocean problem in Hacking for Defense is a problem statement that is trying to accomplish too much. For instance, Navy personnel need better cyber security tools to secure their shipboard communications from a cyber hacker. While the problem seems reasonable enough, it is a boil-the-ocean problem for at least two reasons. First, it is unclear exactly who needs the solution. The Navy is a huge organization and any student team attempting to tackle this problem would be hard-pressed to solve the problem for the entire Navy. Second, there are a number of various cyber security tools that could be brought to bear on this problem. In fact, there are so many types of tools that it would take an entire academic term to list all of those tools and understand their relevance to the problem.

Rather than tackle the entire problem, students finding themselves working on a boil-the-ocean problem should conduct discovery to understand the problem, and specifically understand the narrower component parts of the wider problem (e.g., who specifically is afflicted by the problem and what precisely do they need to solve it). Once the teams have broken the problem down to smaller parts, they can select 1-2 of those parts to focus their attention making problem-solving a more manageable task.

Solutions expressed as problems: These problems are written with a solution (e.g., software, hardware, and/or policies) in mind. Solving these problems as written will lock the team into a narrow solution space from the beginning. 

As an example, Team AquaLink, a H4D class team, was given a Navy SEAL problem stating that Navy SEAL divers face adverse health consequences from diving. Creating a wearable “FitBit-like” sensor will inform Navy medics which divers are at risk of facing health problems and, therefore, decrease the health risk divers face. 

While AquaLink’s problem statement speaks to a problem, it is already assuming a FitBit-like sensor is the solution. The key thing to remember is that a problem statement is just a starting point. Throughout the course, each team will have the opportunity to refine and reframe the problem statement as interviews with stakeholders are completed. It is important that teams are open to shifting their thinking about the problem statement as they learn more about what the problem is, who faces it, and what they need to solve through the Beneficiary Discovery process.

Team AquaLink—from left, Hong En Chew, Rachel Olney, Army Maj. Dave Ahern and Samir Patel—originally set out to develop wearable sensors to warn Navy divers when they were at risk of hypothermia or the bends. Photo Credit: U.S. Army

Band-Aid problems: Sometimes problem statements focus on the symptom of a problem rather than the underlying root causes of the problem. In other words, the problem statement is searching for a quick fix and quick fixes rarely result in sustainable improvement. 

An example of a Band-Aid problem statement might be to leverage artificial intelligence to better enable intelligence analysts to make insights relevant to decision-making. While using AI to help the analyst comb through ever larger sets of data might be just what is needed, there are likely root causes that need to be addressed to ensure that the AI solution is more than just a Band-Aid. For instance, the AI solution would do little to solve the problem if data necessary to decision-making was absent from the data set or if the communication stream between the analyst and the decision-maker is fractured. 

One issue that teams face in working on Band-Aid problems is that they immediately jump to creating solutions. These teams ultimately fail because they solve the symptoms of the problem. The solution may work in the short-term but, ultimately, the pain experienced with the problem will persist because the team has failed to address the root cause. 

Unfortunately, Band-Aid problems are not evident until the team develops a deeper understanding of the problem statement. The purpose of the Beneficiary Discovery process is to get students to move beyond Band-Aid solutions by getting to the root causes of their problem statement. Encouraging teams to focus on root causes will open up several options for how they can add value to the wider problem which will lead to a more sustainable and positive outcome.

TO LEARN MORE ABOUT THE NEW HACKING FOR DEFENSE TEXTBOOK, VISIT h4dtextbook.com AND SIGN-UP FOR UPDATES