Another way you can embrace the product mindset is by considering the use of problem statements as well as learning objectives. At their best, learning objectives tend to lean towards what the business wants to see and can, at times, fail to take into account the real-world performance implications. In contrast, problem statements focus entirely on the user and help us clearly define precisely what we are trying to resolve.
Whenever L&D is asked to intercede in the business, you’re trying to solve some kind of problem. That problem could be an impending change or an existing performance issue, as well as many other things. Regardless of the specifics, at the centre will be a problem you want to solve. A problem statement, or a collection of them, allows you to clearly define the problem as it pertains to your specific users. It allows you to understand the needs of your users better and, through this increased understanding, improve the effectiveness of whatever intervention your design. The process of creating problem statements can also enlighten your team about both the user base and the real problems that exist within the wider organisation.
Creating a problem statement
A good problem statement is made up of five key components. All five components must be present for a problem statement to be as valuable as possible.
1. Who
The first part of any problem statement is identifying the user, the person you’re trying to help. This does not go down to the level of personas but focuses on groups or roles within your business. Perhaps the target audience for this intervention will be the C suite, a very specific group of users, or new line managers leading teams for the first time. The more specifically you define the user group at this stage, the more effective your problem statement will be.
The general way to do this is to say, “I am…” Followed by the label you have attached to your chosen user group.
2. Action
Next, we must define what the user group is trying to do. Once again, the more specific you can be about the desired action or performance, the more effective your problem statement will be. For example, are those brand-new first-time line managers trying to complete their very first annual reviews? Or is the C suite looking to inspire its middle management to work more collaboratively across the business?
The convention at this stage is to say, “I’m trying to…” Followed by the desired action or performance.
3. The problem
The third step is clearly defining the obstacle or problem. What is explicitly stopping the specified group from completing the defined action? For example, is there a lack of knowledge about how to conduct an annual review? Or is there a lack of confidence in having challenging conversations with underperforming team members? Regardless of the problem, ensure it’s stated as clearly and directly as possible.
The convention here is to say, “But…” Followed by the obstacle, challenge, or problem.
4. Root Cause
Step four is all about the root cause. During your analysis, you must dig past not only what’s needed, who needs to do it, and what the existing blockers are but what’s behind those blockers. Is the root cause within the control of your defined user base? Does another group of users have control over this particular situation? Is an organisational or budgetary limitation preventing peak performance from the defined user group?
The convention here is to say, “Because…” Followed by the root cause of the problem.
5. Empathy
The final step of defining your problem statement is to apply empathy. Having defined a group of users, a desired action, the challenge that faces them, and the root cause, you must now consider and define how that situation makes the user group feel. Are they motivated to take on this challenge? Do they feel dejected, downtrodden, and disengaged from the business? Do they feel valued by the organisation in this situation? Do they need, already have, an advocate within the organisation to help drive this change?
The convention here is to say, “Which makes me feel…” Followed by the way your users currently feel.
As an example of a completed problem statement, let’s look at those first-time line managers again. The full problem statement might read:
I am a first-time line manager. I’m trying to complete my first set of annual reviews, but I’m struggling to have challenging conversations with some underperforming members of my team because I have no experience in having this kind of conversation and do not believe I can do so competently. This makes me feel like I am underperforming as a team leader and not supporting my team as I should.
It’s fair to say that this looks very unlike a learning objective but is arguably far more helpful in designing a solution.
A special note here: I do not advocate putting problem statements in front of end-users during your solution. Whether or not you choose to put learning objectives in front of your users is up to you, but a problem statement is just designed for your internal use.
