Importance of the Problem Statement

What Do You Do?

I have a confession to make... we at Hallpass and Friends have a really poor response to the question, "What do you do?" First off, our answer varies with the audience, and the time we have to respond. But it usually includes something like "We develop web, mobile, and back-end applications." This is true; we spend much of our time writing code, testing solutions, and working with clients on tweaks. However, one of our primary differentiators is our approach to problem-solving.

Design Thinking

We have a strong background in a design thinking approach toward problem-solving, and this begins with an understanding that success is contingent upon a well-crafted, informed problem statement.

Clients often come to us for an app with specific functionality. Before discussing the app's requirements or goals, we ask: "What problem are you trying to solve, and how do you know this is the true problem?".

Inevitably, we step back and develop a strategy for "discovering" the true problem that we are to solve. Many clients see this process as unnecessary as they believe they already understand the problem. Without exception, everyone (including us) emerges from the problem discovery process with a wider understanding of what we need to focus on and how stakeholders are affected by this problem.

Our process is tailored to the client's needs but usually involves an observational phase where we can see the issue(s) in real-time, a discussion phase where we can talk about the issue(s) with a wide range of stakeholders, and a synthesis phase where we break apart and build upon our observations from the previous phases.

Examples...

Instead of giving you theory, let's see how this plays out in real life. Below are a few examples of our problem-definition process with real clients and the effect of the resulting problem statement on the resulting project. And we have included times when we did not get it right!

Online Store

We were approached by a regional plant nursery that was looking to sell their plants online. The owner had been working with a web developer but that relationship fell apart. That is often a red flag (read - difficult client) but we were referred to by a friend so I met with the potential client. Instantly, I connected with the owner. She embraced our suggestion that we spend time defining what we mean by an "online store".

Over a few weeks, we had several meetings with the client where we learned more about her, why she wanted to sell online, and (most significantly) her values.

But our client is only one of the stakeholders here. We met with a few customers including a group that traveled two hours just to visit her nursery. We also interviewed some landscape architects and designers. It was during these interactions that we discovered how revered the owner is in the horticultural world. She is a recognized expert and people look to her for advice in addition to plants.

While our client enjoyed meeting fellow plant lovers and sharing her expertise, all of this takes time. And it was this time that our client really was trying to recover.

The problem turned from "How do we sell plants online" to "How do we optimize our client's time while sharing her expertise?"

Women's Health Center

We worked with an innovative women's health center start-up in Kentucky. The client came to us looking for a web application for their customers. The requirements were a bit vague but would evolve over time. We accepted the problem statement "For years, women's health care has been defined by men. We need to reframe women's health to be consistent with the patient's needs - both physically and emotionally."

One of their solutions was to craft an environment that was familiar and comfortable to the women of the community. We embraced this idea and started interviewing the owner and a few staff with the goal of understanding this environment so it could be reflected in our app.

In our mind, this was a graphic design exercise. We were trying to lock in the colors, mood, and typefaces. After a month of going back and forth with design ideas but not getting anywhere, we all were frustrated. Finally, we agreed that we were not a good fit for the project and to cancel the contract.

The reality was that we failed our client. We did not question the stated problem and most importantly, go through the steps to really understand (empathize with) the issue(s). I suspect the problem would have remained the same but with more clarity. And it is this clarity that would have enabled us to better serve our client.

Employee Status Reports

Our final example involves a construction company that requires its job-site leads to complete a status report at the end of each day. Our client came to us because these reports were not being completed.

The reports were on paper forms - old school - and our client wanted an online app so employees could complete the forms on their phones.

After spending some time with the client and interviewing the office staff in charge of collecting these reports, we met with several employees to talk to them. From the talks, we learned two important aspects that helped inform our understanding of the problem.

What do you do with the forms?

After digging into the question, both the staff and client admitted that they don't read the reports but want them in case their customers ask for them. They said that they would like to use the data to improve operations and strategy, but they just don't have the time now. The problem is more than just the need to collect the data; it includes how to utilize the data once collected.

Why don't you complete the forms?

The onsite leads initially cited excuses like not being able to find the forms in their truck and forgetting at the end of a busy day as reasons for not completing the forms. But the underlying reason was "we really don't like to complete the forms." These were not unreasonable people nor were they lazy. So why don't they like to complete the forms?

After digging, we discovered that their issues were many. All of the questions required a written response.

"I just don't know what to say. The question doesn't apply to my work."

"It is difficult for me to write in English."

"Writing these answers takes time and they never even read them."

Thus, the problem is better defined by understanding why the forms were not being completed and it turns out that while convenience is one factor, it is the content of the forms and the perceived purpose of these forms that are contributing to the issue.

Summary

By spending time to really understand the problem, we were able to better define the problem, and in addition to developing an online app for data collection, we worked with the client to better define the purpose of the status reports and what actual information is really required to capture versus what would be nice to have.