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:
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.
"A problem statement is shaped by varying perspectives. It’s not one single person’s point of view. It is actually a problem that’s looked at from several different perspectives, so that you know that you’re getting to the root cause."
Trent Kocurek, Airship CEO & Co-founder
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.”
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.