How To Write A Problem Statement: My Opinionated Template

Tad Whitaker
4 min readJul 5, 2020

If you find value in this story, please consider making a donation to the [HS]2 program. It prepares a group of first-generation and/or low-income students of color to succeed in college by empowering them with STEM-based skills, a family of driven peers, and a space to see the light and power in their own voices. Even $1 helps by demonstrating broad support to larger institutions considering donations.

A few months ago, I had a nebulous problem that affected multiple stakeholders on multiple teams. A hot potato causing problems for lots of people. Nothing burning, but definitely irritating. The VP who oversaw all of us said, “Write a problem statement and book a meeting.”

Great idea until I went looking for a template. We didn’t have one internally so I turned to Google, which produced lots of templates that all felt out of date. Gahk. Yak shaving. Guess I’d have to learn how to write a problem statement before I could start solving my own problem.

As a former newspaper reporter, I sorted through the verbose and stilted templates out there. They were like reading against the grain of a cheese grater. All of them were useful, though, because each one informed what I did and didn’t want my to be like. It was easy to copy/paste the sections or ideas I did like. But noticing what I disliked in the templates was more important to building because that helped me keep mine clean, simple and to the point.

What follows is my Problem Statement Template. You can copy/paste this directly into a Google Doc. My security team has used it for about a dozen other projects/issues and it feels pretty hammer tested.

Problem Statement: Title of Issue

Author

Date

Outcome: A simple summary of what this document is trying to achieve. This should be no more than one sentence describing the outcome everyone wants.

Problem Statement: Define the current situation in 1–3 sentences. Stick with the basics of who, what, when, where and why. The scope of your problem should be a simple like an elevator pitch. Create lists defining what is and isn’t in scope. Start first with Out of Scope and wield it like a billy club on distractions.

  • Out of Scope: State explicitly what you are not solving. These issues might be related, but they are separate to the current problem. Say no to lots of ideas. You might even generate other problem statements from here.
  • In Scope: Specify what is in scope in order to solve the current problem. You can’t get the Outcome (above) without addressing what’s in here.

Affected: Specify the teams, people and customers this problem affects. Error on the side of sharing this document with them. More eyeballs will result in more feedback and more shared understanding.

Background: Stick to five paragraphs and no more. Paragraphs should be 3–5 sentences, preferably three with a beginning (1), middle (1) and end (1). Link to other documents, Slack threads or Jira tickets if more information is available. Don’t. Provide. It. Here. Keep this document dead simple and show people where they can go there if they want more information. Here is what each of the five paragraphs should cover:

  1. How did this problem start?
  2. What made it complex?
  3. What was done to solve it quickly and why didn’t that didn’t work?
  4. Is anything specifically blocking a solution? (Be careful not to blame others.)
  5. Are there open questions or dependencies?

Proposed Solutions: Present all possible solutions to the group. This should not be a paragraph but a bullet list. White space improves readability. Add as many bullets as you want.

Conclusion: Get on your soap box and preach. You’ve thought the most about this so explain what you personally think is the best method to get the desired outcome. This should be one paragraph, 3–5 sentences and no more. Start with “I think bullet point N will is the best path forward because…” If one bullet point is a strong and popular counterargument to yours, address is directly and explain why it will fail.

And that’s it.

Your Problem Statement isn’t meant to be an exhaustive catalogue of everything on earth related to the matter. Its purpose is to collect historical facts/data, summarize why everyone is struggling, list ways forward and generate discussion. An excellent Problem Statement is two pages.

If your Problem Statement bleeds over to three pages, you’re not done. According to www.ryrob.com, the average reader spends 37 seconds reading the average 1,000-word blog post. Be a vicious editor. My favorite editor back at the newspaper told us his job was to take our final draft (what we’d worked days, crafting each word) and cut it by 20%. Keep that in mind.

--

--