Congratulations to Unosquare on 8 straight years on the Inc. 5000 list

Define Your Problem Statement

In 30 minutes, you’ll clarify what has to be done for your software project to be successful.

Webinar Overview

A problem statement in software development gives a developer the ability to understand clearly the issue and then architect a solution.

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.

Download the worksheet by completing the form below and you can watch and listen here.

Problem Statement Webinar Recording
& Transcript

TRENT KOCUREK (TK): What is a problem statement, and what is NOT a problem statement? Let’s do some contrasting there. 

So what is a problem statement? This is a tool, it’s a surgical tool, to help shape an impactful solution. It is a compass to refer to when you’re going to inevitably see more opportunities throughout the solutioning of the problem that you see. And it’s 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. When it’s not, it’s not a well-thought out problem solution. It’s just not, you’re not gonna be building a product while you’re creating a problem statement. Again, this is, what I’m gonna talk about is the How, and that’s at the very end. And too often I think people jump to that and they shouldn’t. So let’s go ahead, and I’m gonna do some like acting here. I’m a terrible actor, but when I say action, we’re gonna jump into a quick case study. And then when I say cut, you’re gonna know it’s me again. So, got ready for it, all right. So let’s talk about a case study. This is a real-world example of how we would approach a problem and how we would dive into a problem statement. So, action. 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.

LINDSAY HANNON (LH): And 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.

AMBER TATUM (AT): And 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.

TK: Perfect, cut. All right, we’re back to playing exactly the roles that we just said we were acting. All right, so at the end of the day, if you saw what just happened there, if you’re just looking at that from an outside perspective, that looks like a big problem to solve. And honestly, it probably looks like three different problems to solve. And I think that’s the point, that’s what often we’re approached with is, it just looks too big, it just looks too big, I don’t know even where to start. 

That’s what’s so, so important about delivering and creating a problem statement, and doing it with a team. Because as you’re about to see, as we dive into this, it’s very apparent how what’s so big can actually be brought down to something small, and that you can consume, and not feel like you’re biting off too much to chew. So again, with so many different problems in there, I don’t want you to get stuck on the symptoms. That’s what we’re talking about now. All of those that look like different things, they could be symptoms of a root problem. Your goal is to find that root problem, and you’re gonna hear that a lot today. 

So, we’re gonna break the problem statement creation into the five Ws. You may have heard, there’s sometimes three, there’s sometimes four, someone created six, they’re just trying to impress you. There’s five or less. So we’re the top, and those five Ws are the Why, the Who, the When, the Where, and the What. So if you see the screen here, Amber’s sharing a slide that kind of goes into the definitions. Don’t worry, if you can’t catch this right now, we’re about to dive straight in to each one of these individually. But then at the end, there’s the how, and I’m gonna speak for like 13 seconds about the how, because that is actually not the most important aspect of this whole thing. And it’s just really in there to show you that that comes at the end, don’t jump there too quickly. So, given our case study, let’s go through each one of these five Ws, and let’s pick apart our problems, and where we are identifying each of these five Ws inside the problems that all three of us have alluded to. So first off, Amber’s gonna start off. Tell us a little bit about the Why, how we should think about it, and how should we approach it?

AT: Absolutely, so the Why is where we start. It’s number one, it’s 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? So we’re gonna start with the Why, and as we do this, and you’re thinking about your own problem, kind of be, start thinking about why is this problem important to my business, to stakeholders, to the people that I work with? And sometimes, you need to ask why a few times to get to that root. So don’t be afraid to ask Why a few times. Try to get down to that root, and that’ll really be helpful. So, as we look at our case study specifically and those problems that we just talked about, we’re gonna pull out the Why there. So, we have problems with productivity, we have problems with job satisfaction, culture aligning with company values. This is, you know, the Why. This is why it’s important, we want those things to be great. We want to dive into those. So, the importance of that Why, and really drilling down and asking yourself a few times: Why are we doing this and Why does it have an impact? It may be really important.

TK: That’s fantastic. Lindsay, talk a little bit about the Who and how that plays a plays a role as well.

LH: Okay, [determining] the Who is really critical. It’s really important to connect your problem with who it’s impacting. So, this is when you’re thinking about your problem, think about who it’s impacting. And it’s good to start with a wide net, think about all the people who are directly impacted, people who are indirectly impacted, and kind of narrow from there, so you can be thinking about the different roles that are involved. And sometimes the way you define who is involved changes who is included. 

So I’ll give you an example with our case study. We had the three of us presenting our problems. There’s 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. And so, then from there trying to think about what the role is that you’re defining, that 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 one Who is really impacted most. So we’re gonna go and define our who as the remote employee.

TK: That’s really, really great. And those two right there, the Why and the Who, at the end of the day those two are the most important. Those are the most important that you need to articulate and have in your brain. ‘Cause as Amber said, that Why, that’s what drives you. That is what is keeping you up at night. This is that white-hot pain that you feel and the reason for you even taking the brain space to try to attach it. 

And linked really closely to that Why is typically a Who, like Lindsay talked about. It’s not maybe the first Who that pops into your head. It’s all of those ancillary folks on the outer ring that actually are impacted as well. So having those two in mind really, really help you then build out the rest of the Ws, which we’ll go into now. So Amber, talk a little bit about those next.

AT: Now that we have our Who in mind, we are really gonna dive into the When and the Where because those will affect that Who. So when are we experiencing this problem? As you think about your own problem, consider when [your problem] this occur. 

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. 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 Who experiencing this? 

And if you look at our case study, we know it’s in remote workspaces. So, as you can see, I’m live here from my remote workspace. This is where I’m experiencing these problems as a remote employee. And that actually can be anywhere. It doesn’t have to be in your office. But the beauty of remote work is it can happen anywhere, anytime. So, that’s what we’ve got for our case study. Trent, what do you got?

TK: Yeah, that’s really great, Amber, and I think that you just solidified that Who. Because if you can, as you think back to when we’re defining that Who, you’ll naturally start coming out with the Where and the When a little bit. 

And Amber made a great point — it’s not always an office space, it’s not always a building. Sometimes it’s rural Alabama. Sometimes it’s back in the woods, and I don’t have internet service. 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. That was amazing, Amber. Yes, that’s exactly what building off of that Who, the When, and the Where, how those attach, and how, and why, and they’re so important. Lindsay, talk about the last W, the What, and why that’s important.

LH: What is gonna transition a little. So we’ve defined a lot of the specifics of the problem, and we have a real clear picture of the problem. What is going to jump ahead, when we ask ourselves, What is the impact on your business if you solve the problem? So you’re jumping into the future, and you’re imagining a world where this problem is resolved, and what is the impact? And so, you can be thinking about your ideal scenario, what does it look like now? 

So 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. So, What is kind of taking the basis of the other Ws and moving it forward to the future that you are anticipating.

TK: That’s fantastic. As you can see, what Lindsay just explained there is not possible to articulate without the ones that we talked about above. That’s, again, why it’s so important to look at these Ws in a very intentional way because they belong to each other. They allow you at the end to imagine that future. Because when you’re imagining, you’re typically imagining people, places, things, something that is an environment in which you would be more happy, or your success would be apparent. And that typically has faces, that has names, and you have to make sure the right faces, the right names, the right roles, the right stakeholders are in that imagination. And without doing the Ws above, it’s just not gonna happen. It just can’t happen. So, thank y’all both, let’s go through that real quick. 

So again, I want y’all to remember the five Ws: 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. 

We had a similar experience with this. Finding that root cause and even going through that exercise is very important. Then when you think about the When, again, put yourself and empathize with the Who, where are they experiencing and running into this problem? Where are they running into this opportunity? And then the Where, again, think about where they’re at? Where are they sitting? Where are they located? Are they in an office? Are they on a cell phone? Are they in the woods? All of those things help you articulate what that future looks like. And I think that that is the most important aspect there at the end.

Building on to all of that to make sure you know, now we can look at what Lindsay just looked at… the engagement, the efficiency, the productivity. And if you look back at our case study, it really covers all of our issues across all three of those sectors. And so what we just did, we were able to take what seemingly look like several disjointed problems and bring them into one very succinct problem statement. 

And with that, we do have one more step, and that’s the How. But I told you, I’d only give you 13 seconds, I don’t have a timer in front of me so I can’t guarantee that. But I will tell you that the How is very intentionally placed after all of those five. If you do not have a very clear, well understood problem statement, the How is gonna cost you time, money, energy, and likely frustrations because you’re gonna find yourself potentially solving the wrong problem. Most of the time it is. So, leave the How at the end, we’ll talk more about the How later. 

But the five Ws are the thing that goes in front of it, and that’s what I really want you to know and take away today. So with everything that we’ve got, we actually have enough now to create a problem statement for the problem identified by our team. The problem statement that we have come up with as a team is… 

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.”

So as you see right there, I’ve got those sections highlighted, we’ve highlighted the areas of the five Ws. You got the Who with the remote-first employees. You’ve got the When and the Where with the multiple states and time zones. You’ve got the resulting in missed expectations for our clients and decreased productivity for the entire organization, that’s the Why. Gotta have that improved to be successful. And find ways to connect more meaningfully is the What. 

You’ll notice those aren’t in the same order in which we went through the five Ws. They shouldn’t be. You want to make this as fluid as possible. You want to be able to tell the story to someone, and the story should just include these five pieces. And as long as those five Ws are somewhere in that story, you’re gonna know when you write that on the wall, when you write it in a MURAL document or Figma, when you’re working through a solution, you’re gonna know and ask yourself, does what I’m doing actually get us to better expectation setting and increased productivity? That is how you use a problem statement. And based on those five Ws, I think this is a fantastic one that we’ve come up with. 

So again, I hope you kind of see how you can just take what’s seemingly such a large thing and break it down and follow those very intentional steps. The Why and the Who, don’t skip past those, give them a lot of thought, and then trail into the others. Because again, they all build on to each other. Now, there’s still a lot of best practices when you’re creating this, and we’ll pick some main ones out. So Lindsay and Amber, y’all mind kind of going through what are some just general best practices to take away, for them to keep on their minds, as they’re developing their own problem statement?

LH: This is something we referred to based on the H coming last. But when you’re creating your problem statements, try to avoid references to possible solutions. That can come in another phase with the discovery and the solutioning. But when you’re creating a problem statement, just try to stay agnostic and not solution, just clearly define your problem. A lot of times when you have a solution in mind, you pigeonhole yourself, and you are potentially scoping yourself out of a better solution. So try to avoid references to the solution in your statement.

AT: We really want to be doing problem statements as early as possible in a project. And so, for example, at Airship we do this in our kickoff calls for our services. We start out with this problem statement, and we don’t just commit to it right there at the beginning. We use it to guide discovery and conversations, and in the questions that we’re asking. But, we’re always open to refining it, because we might learn new things, we might, you know, have new ideas, or drill down even to a different root problem. 

So, you always have to be revisiting it, kind of just assessing if this is really where we are, and don’t be afraid to refine it. Actually, I’ll just let you in on a little secret. As we were preparing for this webinar, this team here had a whole different problem statement. And as we were just working through how we were going to present this information, we refined it. And by the end, we had a different problem statement and a better problem statement. And so that’s just a real-world example, that’s how it happens, that’s the magic. So, and another important part of that is, and I can’t stress how important this is, is getting perspectives from a lot of unique, different backgrounds, different people, different ideas. We all have different experiences, different, you know, things that we bring to the table. And you know, that’s important in general in business, but it’s really important in this process because you just don’t know what other people know. And there’s so much value in being able to do refine that problem statement, as you hear other ideas and other voices that are different than your own. So that’s really key.

LH: And another tip is just something you’ve heard over and over in the last 25 minutes, is trying to address your root problem rather than the symptoms. You will likely notice the symptoms first, and so, you know, being aware of what they are is how you work back to the root. So the iterative process that we do when we’re developing software is useful in lots of different ways. Definitely, in thinking through what your problem is and refining what that root problem is. So you may start off with these symptoms, but hopefully, you’ll keep at it until you get closer to a root problem. And then, just along that same line, you sometimes will have problems that are coming from the current solution to an original problem. And you can get a little tied up thinking about the current solution and the problems that are coming with the failing current solution. So if you have… Try your best to step back from the problems that are arising from the current solution to a problem and trail it back to the original problem. So I think that is, it’s just kind of a principle that we run our company by, and the way we develop software is, there’s always, you know, you start somewhere, and you keep iterating until you get closer and closer to what’s going to benefit you. So that is a great principle for this exercise as well.

TK: Lindsay, fantastic knowledge bombs there. So to summarize, try to avoid referencing possible solutions too early. Don’t get steered away by solutions. Remember to focus on that problem statement. Get perspectives from as many people as possible that are impacted, not just the ones that come to mind, but the ones that are impacted by those as well. So perspective matters. Be okay with being a little wrong about your first problem statement. Like Amber said, it’s sometimes gonna start off a little bit different ’cause you’re gonna identify (again, what Lindsay said), the symptoms first most of the time. Make sure you’re okay with us turning that symptoms, and digging further in. If you have a problem statement that looks different than when you began, you actually probably did it a lot better than you thought. So, just be okay with that, be comfortable with that. And as Lindsay said, and as we’ve all alluded to, root problem is what you’re after, not a symptom. Root problem. Because too often you’ll spend time and money band-aiding a system, or a symptom, and then it’s a waste of time, it’s a waste of energy. We still have more problems to compound onto that. So, focus on the root. 

So, we are at our 25 minute mark. I want to go ahead and leave some time for questions and answers. So, for those of you that are joining us in the webinar, there is a section, a Q and A section within Zoom. Feel free to throw any questions in there. We’ve got a couple here that we’re gonna answer now. And if there’s any that come about as we’re talking, we’ll try to follow up with an email, answering those as well if I need to. So anyways, let’s jump right in to the first question on our docket. Lindsay, you’ve got that one.

LH: The question is “how do developers use problem statements to architect solutions?” So, I can just speak from the way we use it when we’re working through, we’ve got, usually start with a problem statement, and in our mappings, and then we go into solutioning. And one of the things that helps with the problem statement is that it usually exposes what kind of tool set we need to use technically. So, it may be obvious from the problem statement that the solution is gonna involve a lot of data rich computational number crunching, and that will give us a clue about the tech that we’ll need to use to solve that. Or maybe it needs some real-time communication or interfacing, and so, you know, that puts us, takes us in a different direction. So we’re trying to gather some of those clues out of there. And then a problem statement will define the core purpose, which can help us when we’re architecting the solution to decide which things need to be extendable, and flexible for growth in the future and which things are pretty cut and dry, and simple to achieve. So, that’ll help us focus our efforts when we’re developing. And then another way in which it could be useful is that it can signal how a solution may need to scale in the future. So it may be obvious from the statement, you know, what, where this is headed in the future. Is it going to be a lot of users, and we need to work on scaling the load? Or is it gonna be a lot of data, and we need to work on the processing? Those kind of things can be drawn out of the problem statement as well, so.

TK: Fantastic points from an architect herself, so don’t take it lightly. She knows what she’s talking about there. Great answer, great question, thanks for asking, everyone. There’s one other question that came through: “What if you have multiple problems?” So, that’s a great question. 

One of the things that you’ll find is as you’re solving this one white-hot pain, and you’re going through the process of discovering the five Ws, you’re going to find so many other opportunities, and so many other problems that are gonna appear. Because again, you’re peeling an onion in a very intentional way. So you’re bound to say, “Oh, wow, I’m noticing this, this could be…” And these are things that are, first off, it’s natural, it’s gonna happen. And I want you to think of it this way. A problem statement is really how do we define the next step of a solution? A solution is a broad term. So think of a solution, it could be a SaaS product. It could be an entire business that that problem statement is associated and the business itself is the answer, is the solution to that problem statement. But, a problem statement, and a business, or a service, or anything else that you build a solution, can actually have smaller problem statements within. So think of this for you project managers and product managers out there, a feature could be defined in a problem statement way. It could help you prioritize what’s that next thing that we can be doing to have more impact, help our customers be more, or add more value to our customers, help our team be more productive. So don’t think of a problem statement as this thing that you have to like, have this giant outcome of a SaaS product, or a SaaS business, or a services business, or whatever. It doesn’t have to be that big. You could actually use the same approach to breaking down features in an application, to breaking down service level offerings that you have. You can use it in several different ways. This is really just if you break it all the way down, it’s a very, very simplistic view of these are the five things that have to be available to you to make sure that you’re solving the right problem. So, if you have multiple problems, write multiple problem statements. Don’t try to find one that’s gonna encompass every single problem ever. Start high, break it down lower, and then use those to go. But always have that one that is kind of the parent that it breaks down from. That’s that main level goal. So, that’s a great question. 

For now, I just want to say thanks. We had a really great time with y’all today. There is a lot that’s involved with just understanding how to approach a problem. But once you do it a couple times, you’re gonna be brighting problem statements for how to mow the grass and everything else in your life. It’s just a really great exercise that helps you identify that.

And if you come up with some problem statements based on what you learned today, send ’em over to us. We would love to see, and we’d love to give you input on ’em. We just, we’re really excited, we’re really passionate about solving people’s problems and helping them do the same. So, again, thank you for your time today.

Meet Your Hosts

Trent Kocurek is CEO and Co-founder of Airship. As a developer, he understands the issues and opportunities involved in building custom software. He created Airship to design, build, and maintain custom software for organizations of all sizes. Airship’s vision is to create transformational change through remarkable experiences.

Amber Tatum and Lindsay Hannon are experts in software product design + development and project management. They understand the importance of a seamless online and digital experience and have worked with start-ups and established businesses on web and mobile applications.