Creating a Problem Statement

As developers, we spend a lot of our time solving problems. Some of those problems are local and have a fairly narrow scope. A bug in a specific piece of your UI, for example. These small, focused problems are the type of thing we tackle regularly and can typically work through by reading the code, using debugging tools, logging values to the console, and asking for help from a teammate.

Larger problems with a broader scope such as those related to system architecture, or organizational inefficiencies, however, can be a bit tougher to tackle.

These problems tend to be difficult to resolve and have a much large blast radius if things go wrong in your attempt. They typically require both coordinated effort, and broad agreement to address. Fixing architecture or process problems is going to take time, so it's an investment. These efforts, because they take time also run the risk of losing steam if not properly managed.

Part of the difficulty with these large problems is that they are often poorly understood and loosely defined. Lack of clarity is a recipe for failure when trying to affect large scale change.

So how do we make sure our problem is well defined, clearly understood, and properly prioritized?

I've found that writing a "problem statement" creates a great starting point for everything that goes into making large scale change in an organization.

The Problem Statement

I'm sure there are many takes on what one of these should look like. I'll be going through the version I've been using effectively now for quite a few years.

We'll create a short document with the following sections.

Ideal State
Current Practice/Process/Tools/Architecture/Whatever
Consequences of the Current State
Proposed Solution

Let's dig into each of these before we look at an example and talk about what you do with this thing once you've defined it.

Ideal State

We lead off here succinctly describing the ideal state of the world within the context of the problem you're trying to solve. This could be improved system performance, more efficient delivery of new features, a series of practices and processes that lead to a more relaxed workplace, etc. While all of this is highly contextual, the idea here is to paint a picture of a scenario that everybody can agree would be a good thing. This ideal state is where you hope to take things as an alternative to the current state you'll describe in the next section.

Current Practice/Process/Tools/Architecture/Whatever

Here, we'll talk about how things currently work. Focus on the processes that are in place, how decisions are made, the tools that are in use, etc. The idea here is to lay out the foundation of what the current state of the world is. This should be clear and fact-based. This one should lead people to a "Yup, that's what we do" conclusion.

We'll get into why this current state isn't ideal in the Consequences section that we write next.

Consequences of the Current State

If you've gotten the first two sections right, the outcome of sharing those should be agreement. Agreement that we're all on the same page about how we do things today and agreement that the ideal state as described would be great!

Now it's time to draw a line between the current state of things and how that runs counter to the ideal state you opened with. This is were you point out the areas that could stand to be improved, where the current thing falls short. This is the first time where you might face some resistance, depending on the audience and their level of emotional investment in the current state of the world. It is what it is, you can't solve problems if can't admit you have them. You don't have to cast blame, but you should paint an unfiltered picture of the down sides of the current state.

Proposed Solution

The old adage, "bring me solutions, not problems" holds true here. If you bring someone a problem, they might tackle it for you. If you lay out the problem and provide a solution, you're far more likely to get permission to fix it. If you're willing to take that on, getting the investment comes down to the appetite for the change and how compelling your "ideal state" vs "current state" argument is.

Example

This example comes from my somewhat recent past. I saw an opportunity to create a team to help accelerate UI development across many teams and to drive consistency across products.

Spoiler alert: It worked!

Ideal

High functioning teams build performant, accessible, and consistent user interfaces.

Current

Products have inconsistent UX, poor performance, and accessibility gaps. Tribal knowledge and complexity slow the delivery of bug fixes and new features.

Consequences

Poor customer experience, legal liabilities, damage to our reputation, high development cost, and challenges with recruiting and retention.

Proposal

Build a capability-centric team with a 3 part mission

Build and maintain front end infrastructure
Provide tactical support for teams facing front end challenges
Provide education via reference implementations, documentations, and coaching

Drive this team's priorities based on organizational needs arising from product pain-points and the combined product and architecture roadmap.

As you can see from this example, these can (and should) be incredibly concise. The idea is to capture where you are, why that's bad, and how you think it could be fixed. This isn't the entire plan, and it isn't intended to be. This is an elevator pitch or executive summary that captures the core of the problem and your solution.

Now What?

So you have a problem statement, now what?

You've made a huge, and important first step. You've captured the essence of the problem you're trying to solve, now is the time to let that simmer for a period of time, I find overnight or over a weekend is typically enough time for the first pass to roll around in your head. Now we should revisit it, hone it, and then use that to take further action.

Try to anticipate questions and concerns. Have you covered those items, and do you have plans to address concerning items? The problem statement doesn't need to have all the answers itself, but you should be prepared to address these concerns along the way. You might find as you anticipate questions and address those, you might want to refine the problem statement.

Once you've taken this as far as you think you can on your own, it's time to reach out to a trusted peer or two and have them ask questions and share concerns.

This is an iterative process. New questions will lead to new answers. Those might feed back into your problem statement, and they will frequently lead to more questions and answers. You should iterate, but not too much. You don't want to spend all eternity refining your problem statement. At some point, you need to accept that good enough is good enough and start taking the next steps.

Jumping Off Point

Now, you have a clearly defined problem and an idea for how you might solve that problem. In my experience, the act of creating one of these documents is a good way to clarify the problem for myself. Sometimes, this will help me realize that there is a better approach than what I started with. So, I update the proposed solution.

Now, you can use this as a jumping off point for more detailed discussions, plans, documents, slide shows, whatever it is you need in order to convince the powers that be to make an investment in your idea.

You have a framework to use in your explanations and in your own decision making along the way to solving the problem. Sometimes, it's important to revisit the problem to make sure you're not veering off course from the original goal.

This is also a good starting point for the next critical piece

Make It Happen, or Don't

At this point, it's time to act on this. As mentioned earlier, there will (probably) be others who get to weigh in on the ultimate decision to either implement your proposal or not.

Red tape, bureaucracy, and corporate politics are not going to fall to the way side just because you have a problem statement. There is always the possibility (a strong one in my experience) of things dragging on over a series of meetings. You might even end up with a committee or two along the way (big companies gonna big company). This framework for discussion you've created can help you endure through the trials and tribulations of "the process", whatever that looks like for you.

In my example from earlier, the end result was the creation of a new team. The journey to get there was filled with presentations and discussions with leaders in various parts of the organization. They could have ultimately decided that it wasn't worth the investment, or that it had value but couldn't be prioritized. I wholeheartedly believe that forming the problem statement and then using that as a springboard was the factor that ultimately helped me win over those who needed to be convinced.

It helped me think through the objections, garner support, kept my presentations and longer form documents focused and generally kept me anchored on the core idea as others tried to reframe and water down the original idea.

Conclusion

The first step in fixing a problem is admitting you have one. In a business setting it can take a little bit of selling to help others recognize that a problem exists. Often "the way we've always done it" is good enough or the problem has developed over a long time and like frogs in water, they didn't even notice that it hit the boiling point.

Working through this problem statement definition is a great way to clarify the problem and help you articulate it. When forced to convince others, having a focused way to present it provides some much-needed ammunition.