Build a Better Problem Statement for Software Development

Recently, our CEO, Trent Kocurek, along with one of our project navigators, Amber Tatum, and builder, Lindsay Hannon, worked through the specifics of defining a problem statement in software development during a 30-minute webinar.

The discussion was so insightful and included such a valuable, real-world example built during the webinar, we had to share a recap.

Here are a few key lessons on building better problem statements and an example of putting these methods to the test.

Jump to Section:

• What is a problem statement in software development?
• Start with "Why?"
• Connect your Problem with "Who?" it's Impacting
• Think of "When?" and "Where?" the Problem Occurs
• "What?" is the impact on your business
• Avoid "Solutioning" within your Problem Statement
• Example Problem Statement and Case Study

What is a problem statement in software development?

First, let's define what is a problem statement in software development.

A problem statement in software development gives a developer the ability to understand clearly the issue and then architect a solution. But problem statements aren't just built by developers, for developers.

Put simply, a problem statement clearly defines - in a concise but comprehensive way - a key business problem that needs to be solved.

In software development, the problem statement says, “What has to be done” for a project to succeed - to meet the needs of its stakeholders who are external to the development. When you do not have a well-thought problem statement, you risk building a product that solves the wrong problem.

The problem statement is a tool for the stakeholders and developers to communicate in concise, plain language, about what tasks are being paid for, and what must be accomplished conceptually for the project to be a success. The problem statement forces all parties involved (including the development team’s leaders), to reach an agreement about what they are doing.

Start with "Why?"

There are different methods for building a problem statement, but the most popular is breaking down the problem statement creating into the 5 W's.

The Why is the first thing that we really want to dive into because if we don’t know why we’re solving a problem, then what are we even doing?

Think about why is this problem important to my business, to stakeholders, to the people that I work with?Sometimes, it helps to ask why a few times to get to the root cause of a problem and not just uncover the symptoms of that root cause. So don’t be afraid to ask Why a few times.

Connect your Problem with "Who?" it's Impacting

Defining the Who in our problem statement is critical because it connects our problem with who it’s impacting.

As you're thinking about your problem, think about who is impacted. Start with a wide net: think about all the people who are directly impacted, people who are indirectly impacted, and narrow to the different roles that are involved. And sometimes the way you define who is involved changes who is included. 

Think of "When?" and "Where?" the Problem Occurs

Now that we have our Who in mind, we dive into the When and the Where. As you think back to defining your Who, you naturally start finding clues to defining the Where and When.

Ask yourself, "When are we experiencing this problem? When does this problem occur?"

But for the Where (and this couples with When), we want to think about where people are when they’re experiencing this problem. Where is your defined Who experiencing this problem?

Understanding the Where and the When is not just about attaching and empathizing with the Who: It’s also understanding how technically, we may need to approach that problem because of the potential constraints when and where that happen.

"What?" is the impact on your business

Now that we’ve defined a lot of the specifics of the problem, we have a clearer picture of the problem.

Defining the What requires you to jump ahead to the future. Ask, "What is the impact on my business if I solve the problem?" So you’re imagining a world where this problem is resolved, and what is the impact? Think about your ideal scenario and reflect on what that looks like now with the problem solved.

Avoid "Solutioning" within your Problem Statement

It's important to remember that our problem statement does not say, “How that has to be done,” unless those external stakeholders say so.

You want the problem statement to be a tool for the development team to envision architectural choices. You do not want to limit your options for solving the problem by making solution assumptions in the problem statement.

Example Problem Statement and Case Study

During the webinar, our team used a real-world case study of how we would approach a problem and how we would dive into a problem statement. Our presenters each played the following roles (below) that would help them build the example problem statement at the end.

• I’m Trent, I’m the CEO, and at Airship, I’m noticing our crew members not working efficiently together, which has led to missed expectations and slow decision making.
• I’m Lindsay, I’m a developer here. And as a remote worker, I just don’t know my teammates well enough to know who to ask questions to about what, and sometimes I feel stuck.
• I’m Amber, I’m a product manager. And in past jobs, I’ve worked in an office, and it was easy to build meaningful relationships. But as a remote worker, I feel disconnected, and I’m missing those relationships with my teammates.

Finding our Why

Our first step is to look at our case study problems above and pull out the Why.

In our example, we have problems with productivity, we have problems with job satisfaction, culture aligning with company values. We want to dive into those and really drill down by asking a few times: Why are we doing this and Why does it have an impact? It may be really important.

Finding our Who

Using our case study example, we had the three roles presenting problems. The CEO that’s directly impacted, developer, and product manager. Indirectly, there were, you could think of lots of people that are impacted, our customers and the employees’ families.

From there, we're trying to find who is actually bearing the brunt of this problem. And listening to those problems, you can kind of pull the thread that the remote worker is the single Who that's really impacted most. Therefore, we define our who as the remote employee.

Finding our When

In our case, it’s across multiple time zones. We have people in 16 states, so it’s, there’s different time zones. But there’s also different ways that we structure our days just based on how we work best, or the things that we’ve got going on in our personal lives as well. Meaning different work schedules and any time because we are able to work remotely. The When is anytime we’re doing work.

Finding our Where

If you look at our case study, we know the problem for remote employees occurs in remote workspaces. And that actually can be anywhere. It doesn’t have to be in an office, it can happen anywhere, anytime. We have to also keep in mind technical constraints of where and when remote work can happen. For example, rural areas where there is n Internet service.

Finding our What

For our case study, we’re looking at a future where the remote worker now is feeling engaged, connected to other employees, knows who to go to when they’re stuck, knows who to rely on for their strengths, feels connected to the company and our values, is efficient because the worker is able to get help from their co-workers, and is more productive for their customers.

Defining the What is taking the basis of the other W's and moving it forward to the future that we're anticipating in this example.

The Final Product

Our final problem statement draft is ready to craft! Here is what we came up with as we worked through this problem statement exercise:

“Airship is a remote-first company that has employees across multiple states and time zones. Airship is experiencing lower morale and slow decision-making resulting in missed expectations for our clients and decreased productivity for the entire organization. To improve collaboration, reduce turnover, and generate more revenue, we must find ways to connect more meaningfully.”

Conclusion

The key lesson for building effective problem statements in software development is remember the five W's.

The Why, when you’re thinking about the Why, think about why is this problem important to stakeholders and my business? Keep that in mind, why? Who, think about who does this problem impact and involve? Don’t stop with just who it impacts. Who does it involve? When you start reaching outside the norms, that’s when you start actually bringing in more perspectives, and you start identifying things that you would have never thought about on your own. 

If you're interested in viewing the full webinar recording and/or transcript, as well as our worksheet download where you can complete your own problem statement, click here.