Part 1: The value of a Problem Statement
A Problem Statement is an incredible and underutilized tool. It will help your team gain focus, feel a sense of ownership, and reach a successful outcome. But before I continue let me ask you a question:
Are you working on something? Writing code for a feature? Working on the MVP of an app? Working on a marketing campaign?
If so, do you know what problem you are solving with that feature, app, campaign or whatever? (Let me add: With crystal clear certainty? Without thinking about it? With a clear goal in mind?)
The truth is, many people work towards solutions without a clear picture of the problem in mind.
Perhaps you have a Project Manager who is familiar with the problem, spends time seeking the appropriate solution, and then tasks you with implementing it (maybe you are that PO). I propose that understanding a problem but not bringing along the people who are solving it introduces risk to their success.
Or perhaps you are working on a side project, or your team works a bit more in the “Wild West” style. Sometimes things come up that would just be cool to implement — no problem in mind. I challenge that there might actually be a problem you are trying to solve with that cool feature. By not taking a moment to identify that problem, your implementation won’t be as successful as it could be.
Finally, customers will often say, “I wish it did x.” Here the need is to ask why (Learn about asking “Five Whys”). By going past a proposed solution to seek a deeper understanding, you gain insight that will help you reach a successful outcome.
A problem statements gives your team
Often it is the case that, when working on something, other issues come to light. I find this to be true in the enterprise world where large applications interconnect in surprising ways. Though this can be just as true in a start up.
So what happens when the additional issues arise?
“Feature Creep!”
It has become a knee jerk reaction, and it is understandable why. Adding more work compromises your ability to deliver even what you already have on your plate.
But what if you don’t focus on the items you deliver and instead orient on the outcome you’re after? If this new thing helps to reach that outcome then look at that impact and see if it can happen. If not, either we aren’t working on the most important problem, or we shouldn’t worry about this issue right now.
With a problem statement, there is no feature creep. There’s a problem and a measurable outcome. If we believe something will get to that outcome and we can create an experiment to prove it, we should work on it. If not, we recognize that it isn’t the problem we are trying to solve and keep our focus on the task at hand.
So here is the final point: Problem statements value outcomes over outputs.
Outcome > Output
Let’s define those terms. By Output I mean anything completed, packaged, or deliverable. That might look like a design, specs, or even deployed code. For output oriented teams, success looks like deploying to production.
Outcome oriented teams do need output, but they also require another essential: measurement. We know when we are successful by utilizing measurement with our output to know that we reached our desired outcome.
Since you decide what your output is, success is a bit arbitrary. As such I imagine running a race by picking two random cows in a field as the finish line. Knowing you are successful isn’t ever reached just by deploying to production. You succeed when you can measure the impact your code has toward reaching an outcome!
Thank you for reading Part 1 of What’s Your Problem?
- Next, Part 2 will cover What a Problem Statement looks like.
- Finally, Part 3 will cover How to introduce Problem Statements into your work life and process.
Read on with Part 2. I will update this article once Part 3 is published, but you can also keep up to date by following me here on Medium and on twitter @MattPLavoie.
Thank you to:
You — the reader, PowerDMS where I have the opportunity to experiment and learn, Code for Orlando, BarCamp Orlando, OTA and Orlando Tech Week, and Jeff Gothelf (Get his book Lean UX).
