Tips for Defining a "Good Problem" 🍯

Bad vs. Good Problem Definitions: A Case Study

2

Thinking about thinking.gif

They say defining the problem is important...

When studying product management, you often hear that defining the problem is the most important step. Whenever I heard that, I'd nod along, thinking, "Ah, right, problem definition is key." But if someone actually asked me, "So what exactly is a good problem definition?", it wasn't easy to give a clear answer. 🥲

This struggle continued even after I joined DelightRoom. During my three-month probation period, I figured that even if I didn't pass the conversion evaluation, I'd still walk away with something valuable if I just learned how to define problems properly. So, I constantly pestered CEO Jay and the other POs about it.

Even now, a year later, crafting a good problem definition is still tough. But at the very least, I've developed the ability to distinguish a good problem definition from a bad one. In short, a good problem definition is universally "simple and clear."

From here on out, I'd like to share how I reached this conclusion and the lessons I learned the hard way. I'll also be sharing some tips for writing good problem definitions, so don't miss out! 👏

Examples of unclear definitions and how to fix them

At DelightRoom, we write our product specs in a WWH (What/Why/How) format. We structure them by defining what the core problem behind a phenomenon is, sizing up how big that problem is, and then drafting a solution to solve it.

The most crucial part is defining the "Problem" right at the start. After all, product planning is ultimately about finding the fundamental issue causing user friction and solving it. That's why we put a ton of effort into clearly defining the problem in a single sentence under the "Problem" section of our spec documents.

Sadly—or rather, embarrassingly—I always hit a wall during this process. I tried really hard to define the problem, but people often couldn't understand it. It was pretty frustrating for a while. However, thanks to the comforting advice from other Delighters who assured me that it's hard for everyone at first, I was able to improve.

The most frequent feedback I received was that I was defining problems too abstractly. It took me the longest time to get the hang of this and fix it. So today, I'm going to walk you through some of these examples, tweak them, and give you some tips along the way.

Example 1: Abstract Words

Looking at this problem definition, you can grasp the general idea, but it feels unclear. First of all, the part about "what is mental and what is physical" is abstract. For instance, does raising both arms count as waking up physically? If you sit up for a moment and go back to sleep, you moved your body, so does that mean you woke up physically?

Also, the phrase "when waking up" is similarly vague and unspecific. For example, your mom might wake you up saying, "It's 8 o'clock, time for work," or a hungry cat could climb on your face, causing you to wake up. You probably get the gist of what I mean.

Honestly, you can usually sense during the writing process when your defined problem isn't going to be very persuasive. That's why we often spend extra time padding the background section with theories or research papers to bolster the logic and explain the problem further.

But we shouldn't forget that spending that time polishing the sentence itself is actually the faster route. Let's refine the problem above. First, we'll swap out the ambiguous words.

By changing just a few words—from "when waking up" to "when the alarm rings," and from "mental/physical" to "because they open their eyes but dawdle and don't get out of bed"—you can feel how much clearer it becomes. We've all experienced opening our eyes but dawdling instead of actually getting out of bed.

As for the background, you can just write down the immediate questions that pop up when reading the problem, or remove it if it's unnecessary. When a problem is defined this well, it's highly relatable, which reduces the cost of persuasion. Let's look at the second example!

Example 2: Abstract Expressions

This problem definition feels muddy because of its abstract phrasing and lengthy sentence structure. The expression "cannot feel that it is being measured" doesn't explain exactly what cannot be felt, and there's an unnecessary extra clause attached at the end that prevents it from being read in a single breath. Let's tidy this one up too.

I changed "cannot feel it on the screen" to "there is no change on the analysis screen" to make it easier to understand, and I boldly deleted the unnecessary clause, "so trust drops regarding whether the analysis is actually happening." You can see how much sharper it gets. Just like the saying "less is more," it's crucial in problem definition to strip away everything but the essence.

Also, if your problem definition ends up being one massive run-on sentence or takes multiple sentences to explain, you should suspect two things: either it's a problem most people will find hard to relate to (low impact), or it's a problem definition that just hasn't been thought through enough.

Tips for defining a good problem

Now, let me give you some 🍯 tips for crafting a good problem definition.

First off, a good problem definition is easy to understand even if you just skim it. If you can't sum it up well in a sentence or two, odds are the problem isn't properly defined. Therefore, when defining a problem, you should use "simple and familiar words" instead of abstract terms, and cut out any "unnecessary modifiers." In other words, keep it simple and clear.

I tasted a lot of failure at this stage myself. It's easier said than done. So, I'll share a pro tip I learned from CEO Jay that I use every time I define a problem: try explaining the problem to someone else in one or two sentences and see if they understand and empathize with it.

When you define a problem alone, you tend to try too hard, which can result in something either overly specific or, conversely, so oversimplified that it's hard to understand. Right after writing it, you might think, "Finally, I nailed it!" only to look at it the next day and beat yourself up thinking, "What does this even mean?"

At times like this, if you refine it with the mindset of explaining it to someone else in one or two sentences, you'll eventually develop an intuition for whether you've defined the problem well or not. Finally, by actually explaining it to someone and checking their reaction, you can confirm if you've got a good problem definition. I guarantee you'll see what I mean once you try it.

Wrapping up

So far, we've looked at examples of poor problem definitions to see what went wrong and how they can be fixed.

Some might look at this and think it's just playing with words. However, "defining a good problem is closely tied to writing a good sentence." Just as a good sentence is easy to read and clear, a good problem definition has to be simple and straightforward.

In the next post, I plan to introduce the actual benefits you gain from a good problem definition. Since this is also a practical lesson I felt and learned through firsthand struggles when defining problems wasn't easy for me, I hope you look forward to it!

To be continued in Part 2!