{"id":103,"date":"2021-02-10T23:19:08","date_gmt":"2021-02-10T23:19:08","guid":{"rendered":"https:\/\/bak.me\/blog\/?p=103"},"modified":"2021-10-11T04:24:47","modified_gmt":"2021-10-11T04:24:47","slug":"problem-context","status":"publish","type":"post","link":"https:\/\/bak.me\/blog\/problem-context\/","title":{"rendered":"What is a Problem Context?"},"content":{"rendered":"\n

A problem context<\/strong> is a specific situation that occurs frequently enough, or is painful enough, to warrant solving. Coming up with a problem context is likely to be the most difficult part of preparing for your customer development<\/a> interview. It\u2019s extremely nuanced. And it\u2019s equally important.<\/p>\n\n\n\n

If you haven’t read my article about the problem hypothesis<\/a>, start there first.<\/p>\n\n\n\n

The problem hypothesis consists of three parts:<\/h2>\n\n\n\n
  1. Who you think the customer is<\/strong><\/li>
  2. What their problems are<\/strong><\/li>
  3. What benefits they get from solving this problem<\/strong><\/li><\/ol>\n\n\n\n

    Whereas the problem context focuses specifically on the problem:<\/h2>\n\n\n\n

    The problem context relates specifically to #2 in the list above — truly understanding what their problems are<\/em><\/strong>. It represents the likely situation that a user finds themself in when the problem occurs. So looking at the made-up example of the quick dry clothing idea. We came up with this user story:<\/p>\n\n\n\n

    \u201cAs [an athlete], I want [wear clothing that dries quickly] so that [I don\u2019t feel sticky and uncomfortable when I sweat].\u201d<\/strong><\/p><\/blockquote>\n\n\n\n

    So in that example, the problem context is the situation an athlete is likely to be in when they experience sticky clothing.<\/p>\n\n\n\n

    What situation could that be? Well it\u2019s likely to be different for each specific user segment. Let\u2019s try \u201cbackpackers\u201d first.<\/p>\n\n\n\n

    Imagine a backpacker on mile 7, the terrain is getting tougher, the sun is directly overhead and it\u2019s hot, you\u2019ve got water, but it\u2019s not cold anymore, your pack is feeling heavier than when you started and you\u2019ve still got miles to cover before setting up camp.<\/em><\/p><\/blockquote>\n\n\n\n

    That\u2019s a problem context. It\u2019s in that situation that a backpacker is likely to feel the pain of sticky and uncomfortable clothing. And it’s a situation that happens just about every time they go backpacking.<\/p>\n\n\n\n

    Let\u2019s look at a few real world examples:<\/p>\n\n\n\n

    Udemy<\/strong>‘s Problem Context<\/h4>\n\n\n\n

    You are teaching yoga but you only have one client — your problem is that you need to reach more customers<\/em>.<\/p><\/blockquote>\n\n\n\n

    Zoom<\/strong>‘s Problem Context<\/h4>\n\n\n\n

    You have a meeting but you’re not in the office – your problem is that you need to see your co-workers<\/em>.<\/p><\/blockquote>\n\n\n\n

    Etsy<\/strong>‘s Problem Context<\/h4>\n\n\n\n

    You make beautiful crafts but you live in Alaska — your problem is that nobody is around to buy your products<\/em>.<\/p><\/blockquote>\n\n\n\n

    Dropbox<\/strong>‘s Problem Context<\/h4>\n\n\n\n

    You are on an airplane with no internet connection — your problem is that you need access to your files from anywhere<\/em>.<\/p><\/blockquote>\n\n\n\n

    Those examples are fairly curt. It\u2019s better to tell a bit of a story with your problem context. The more your customer can visualize the situation, the more likely they are to resonate with it. Take the Dropbox example. <\/p>\n\n\n\n

    I might something like say:<\/p>\n\n\n\n

    \u201cLast week I went to visit some friends in San Francisco. It was a weekday so I had a presentation to work on for my job. I thought I had downloaded the files before I left but realized I had forgotten to. With no internet connection on the plane I was out of luck.\u201d<\/p><\/blockquote>\n\n\n\n

    By putting the customer in a problem context like this, they\u2019re more likely to give me some insights about your idea or even validate whether the problem even exists for them.<\/p>\n\n\n\n

    And I\u2019d probably end the story with a question like \u201cHas that ever happened to you?\u201d<\/strong><\/p>\n\n\n\n

    In other posts<\/a> about the benefits of founders solving their own problems. Many startups have begun that way. A founder has an itch they simply can\u2019t find a way to scratch — so they build their own solution. This can be helpful when coming up with a problem context because it will be a situation you\u2019ve found yourself in many times. But this isn\u2019t critical. I\u2019m not a backpacker, but I can imagine a situation where a backpacker would feel sticky and want a quick dry t-shirt.<\/p>\n\n\n\n

    The trick here is to develop a problem context for each customer segment you may interview. So in the \u201cquick dry\u201d example, you would need to come up with a problem context for each different customer: runners, cyclist, etc. This takes some prep work, but it\u2019s essential for setting up a successful customer interview.<\/p>\n\n\n\n

    Now, just so there\u2019s no confusion between the problem hypothesis<\/strong><\/em> and the problem context<\/strong><\/em>, let\u2019s recap.<\/p>\n\n\n\n

    Problem Hypothesis<\/strong>
    Is your attempt to state who the customer is, what their problems are, and what benefits they get from your solution.<\/p>\n\n\n\n

    Problem Context<\/strong>
    Is a situation that the customer is likely to find themselves in when they experience the problem.<\/p>\n\n\n\n

    The two go hand in hand. Here\u2019s how I look at it. We use the problem context<\/em> to get users to validate the problem hypothesis<\/em>.<\/strong><\/p>\n\n\n\n

    \n