This morning, my children were arguing over spoons.  At breakfast it is my 5-year-old Finley’s job to get out the silverware for herself and her sister.  My Thalia, in the meantime, is just about to turn 3 and is fully feeling her control issues.  Every morning they use these particular baby spoons to eat their yogurt.  There are only 4 of them, three blue and one pink.  For some reason they prefer these for yogurt over all other spoons.

This morning, Thalia’s bowl was pink and her cup was pink so she was insisting on having a pink spoon.  However, Finley had already claimed the one pink yogurt spoon for herself.  So Finley was ruthlessly trying to convince her sister to accept a blue yogurt spoon so she didn’t have to give up her pink yogurt spoon to her sister.  After several minutes of back and forth, I intervened.  I opened the silverware drawer to find a wide assortment of spoons in all colors and styles.  I plunked out a blue yogurt spoon, a pink and silver spoon, and a plastic red spoon.  I held the three options up for Thalia to choose from.  She selected the pink spoon.  Breakfast continued in peace and I was left to wonder why we had so many spoons if the girls were just going to argue every morning over one.  (Hint if you aren’t a parent, it wouldn’t matter how many spoons we had, they would still argue.)

I hate to compare clients, or myself, to my children, but that is exactly what I am about to do.

Too often when I am working with users to build a product I find myself slipping into the same tendencies Finley did.  I hear what I want to hear.  I don’t listen closely to understand the actual things that are causing pain or would resolve their problem.  I know something and it guides how I approach the discussion.  Also, if I already have a solution in mind, I will press it even as the user tells me it doesn’t solve their problem.  At the same time, users can be a bit like Thalia.  They can repeatedly tell me the solution they want instead of what their problem is.

This is because humans are fallible.  We are terrible at communicating.  Our mind is constantly working within cognitive biases.  Maybe in a different post I will dig into these cognitive biases, but I will just leave a set of them here so we can use them as a foundation for the rest of this discussion.

Fortunately, for us poor humans who operate barely more dependably than a 5-year-old, there are strategies to overcoming these cognitive biases and effectively define the work to be done using problem statements.  Spending time with user to fully understand their problem statement prevents spending sprint time solving the wrong problem or worsening tech debt.  Problem statements do this by

• Separating decision making from cognitive biases
• Establishing a common language
• Creating a shared user-focused context around the actual problem on which to test solutions
• Allowing solutions to be more resilient by putting them in the system context instead of the user context
• Supporting small testable hypotheses
• Separating the signal of the problem from the noise of the technical system we are operating in

Okay, so you are convinced this is something worth doing.  Compelling problem statements unify users and developers together around a common cause and clarify requirements.  So how do we find the problem statement?

To me, good problem statements look a lot like good user stories and they start from a pretty common place: talking to users.  The key is when you are talking to users to constantly refocus them on describing their process, and what about it is frustrating them, instead of trying to brainstorm solutions.  When interviewing a user think about:

• What activities or jobs are they trying to complete?
• What is impeding them from those actions?
• What workarounds are they using to get around the software’s limitations?
• Why do they want to accomplish that action?
• Why do they feel pain with the current process?

All of these are questions of user behavior, not system actions.  If your user starts to tell you how they wished it worked, listen but don’t start to brainstorm solutions.  Don’t forget when you are conducting this interview to watch out for those cognitive biases. Stay open and actively listening for what they are trying to accomplish and why the current software is impeding them.  I will often repeat back to them, “What I hear you saying is X.”  Or “I believe what you are trying to do is Y.”  It’s okay to look dumb.  It’s even better to acknowledge up front that you will ask questions that may seem obvious it’s because you want to fully understand the situation.  You are trying to get to specific, repeatable, user actions.  That will result in knowing an expected, measurable customer behavior.  In some cases, I may even lay out what I am hearing in a customer empathy map format. 

This is an exercise in user discovery but on a micro level.  Practicing this with troubleshooting issues will make it more natural when you are interacting with a feature request.  This can then boil up into customer segmentation or market discovery work.

Now you can formulate a problem statement.  A good format for this is:

• As a type of user
• I want to complete a job
• But limitation I am facing me
• Because description of the system impeding the user
• Which makes me feel emotion

Note that the description of system impeding the user will become part of the solution statement later but should not be a complete recommended solution.  It is the beginning of the solution discovery process.  Also, the emotion aspect will help you in prioritization in combination with the criticality of the job the user is trying to complete and the type of user facing the problem.

Let’s try it with Thalia’s spoon problem as an example.

• As a 2-year-old with control issues
• I want to eat my yogurt
• But I don’t have a spoon I like
• Because I want my spoon to match my plate and cup and Finley has the pink yogurt spoon
• Which makes me feel emotions, so, so many emotions, because I’m two and everything makes me feel emotions.

If you have a good problem statement you should be able to repeat it back to your user and get agreement that it is the problem that they are facing.  Next, you should be able to take it to your developers and talk through solutions to the problem.  Finally, you should be able to validate a solution against the problem statement.  That’s right, a problem statement is a testable hypothesis.

Congratulations, you are now on your way to writing problem statements like a champ.  Next time, we will talk about ways to validate that hypothesis.