I would like to share a new technique useful for PM’s I learned in the past week: how to use a whiteboard to validate a customer problem statement.
Part 1: The whiteboarding technique
The whiteboarding technique I learned is quite simple to describe: you write your problem statement on a whiteboard, and really put each word under a microscope by asking yourself for clarification on it. This way, you dissect a general idea into tangible parts which you can validate by data.
Let’s take an example! Say you are a PM at a pharmaceutical company, and you believe that customers find your cough drops too tasteless, so you are thinking about making them sweeter. Write your initial problem statement down.
Now, stare at this problem statement and try to ask yourself to clarify any part of it. For example, you may be looking at the words “some customers” and find your mind asking, “who exactly?” Trace this thought to get an unambiguous understanding on who the impacted customers are. It may look like this…
In this case, digging into the “some customers” part led to a few action items that may help us observe the symptoms better before we rushing into prescribing any treatment! Of course, tracing your chain of thought on the other parts of that problem statement sentence could also yield a lot of interesting findings, but I will just give this one example for now.
As you can see, there really isn’t a standardized format in which you must draw and write. Do whatever feels the most natural for you to deploy your chain of thought — after all, it is your whiteboard.
Once you have answered every question you asked yourself, chances are you are ready to modify the problem statement to better describe customer needs however necessary, and to proceed to the actual design phase of your new feature!
Part 2: Why is this important?
In my experience working as a pm so far, almost all problem-solving begins with idendifying the problem clearly and precisely. This is why validating customer problem statements are so important: you can only begin to make progress for your customers once you truly know what they need.
Boy, did I learn that lesson the hard way. I must admit there were times in my career so far, where I ignited the design process of a new feature by having no clear answer to “what’s this new feature good for?” Not knowing the problem statement like the back of my hand could make me ignore key customer data, or even worse, clog up my interpretation of that data with bias, making me taking a lot of unnecessary turns before heading the right direction — after having validated the problem statement.
(If I didn’t know what problem is my idea solving, what DID I have in mind? Well, admittedly, usually a vivid imagination of this awesome new feature. That means I got so excited about an idea that I forgot to validate its value for the customers! That practice should be avoided. As I have learned, healthy problem-solving should start with a problem and result in a solution, instead of starting with a solution looking for a problem.)