Programming/Design Docs/Problem Statement

What is a Problem Statement?

A problem statement is just that: a sentence that introduces the problem you are trying to solve. Often the problem statement is prefaced by some background, so the reader has adequate context for your document. Again, there is no required syntax, but I like to draft my problem statement in the following format:

• "As <x>, I can <y> because <z>."

<x> is the user and usually a job title for internal-facing solutions or a type of customer or client for external-facing solutions. <y> is the action the user should be able to do when this problem is solved. <z> is the 'why': why the user should be able to do that action and why not being able to do this is a problem. The last part is really the most important: there's no point in designing a solution for something that isn't really a problem!

You may recognize this format as a "user story," which some companies use to determine and communicate requirements at the management level. If you have been given user stories for your problem, that's great! (And consider adding them as a subsection in Requirements or Testing!) However, a problem generally has many user stories, as each one represents a use case. If you are given user stories, try to summarize them.

For example, let's say you are working on a new feature for a blogging platform that exports blog posts into either Word documents, PDFs, or plain text documents. You may be given the following user stories:

• As a blog owner, I can export a single blog post as a Word document.
• As a blog owner, I can export a single blog post as a PDF.
• As a blog owner, I can export a single blog post as a plain text document.
• As a blog owner, I can export all blog posts as Word documents.
• ...
• As a blog owner, I can export all blog posts in a tag as Word documents.
• ...
• As a blog owner, I can export a custom subset of blog posts as Word documents.
• ...

Okay, I abbreviated the list a little. But as you can tell, this would be a lot to give the reader right off the bat. (Especially since it's so repetitive!) You can summarize this list in the following way:

• As a blog owner, I can export some or all of my blog posts in multiple formats.

Don't worry about being too specific in your summary. All of the nitty-gritty details should be outlined in your Requirements section. The problem statement just introduces the overall problem. However, our problem statement is still missing a crucial part: the 'why'!

The 'why' of any problem may not be immediately apparent. I've had to chase down the 'why' before. Once, I discovered that there was no 'why'! (This made for a short document.) But that happens sometimes: someone gets what they think is an improvement for the users when really the users don't think it's a problem at all. It's also essential that you feel empowered to push back if the answer from upper management is "because I said so." A healthy upper management team wants you to use your time wisely, not just be a "yes man." There is usually too much to do and not enough developers to do it, so minimizing throwaway or low-impact feature development is paramount. If it comes to light that there is no good reason to work on a "problem," that's fine; go dig into the next problem (or identify another "problem" to discard!).

Example

Let's back to our blog post export example. There are many reasons why this might be useful, but let's assume this feature came up from user feedback. Most users want to have some sort of easy backup. Some users want to be able to download a Microsoft Word backup to preserve formatting and styling. Other users just want to download the text to minimize the size of each blog post file. Another set of users want to send a PDF to a printing company to make nicely formatted hard copy backups. Regardless, the overall theme is backups. We can incorporate this into our problem statement:

• As a blog owner, I want to export some or all of my blog posts in multiple formats because I want to have an external backup should anything happen to my blog or the blogging platform.