RSS
 

What is your problem?

The other day my husband and I were in the middle of a long drive when we started discussing one of his business ideas. When described verbally, it was one of those ideas that was very complex and difficult to explain. We started thinking about how to simplify the explanation of the business model enough that people hearing about it would not get overwhelmed.

This was the perfect scenario for a problem statement.

For anyone who doesn’t know what a problem statement is, it is the basic problem that the market is experiencing which you feel you can solve with a product.

Writing a problem statement is not an easy task. I have found that it works best as a very simple statement without caveats or descriptions.

Good Problem Statement: “Traffic into Cambridge can come to a standstill, usually in the mornings.”

When I ask someone to write a problem statement, they invariably try to use their solution as the problem.

Bad Problem Statement: “Cambridge needs to create a congestion zone and charge drivers for driving within that zone.”

By using their solution as the problem statement, they have not only avoided acknowledging the actual problem they are trying to solve, but they have essentially ended any discussion around how to solve the core problem. If the audience doesn’t agree with their solution, there is no empathy remaining around the need to solve the problem that still remains.

Using Google as an example, chances are that the makers of Google didn’t sit down and say “lets build a search engine” just for fun. They probably first identified a problem in the market such as “finding anything on the web is difficult.” Their solution was “build a search engine.”

Now that the problem statement and solution statement have been sorted out, it is a good time to begin listing the features and benefits of your solution. This is another situation where people often mistake one concept for another. Your feature is not inherently a benefit, and the benefits that your solution provides don’t count as features.

I prefer to list the features and benefits in table format with features in the left column and benefits in the right column, each benefit aligned with a specific feature. The hypothetical Google features and benefits might read:

Problem: “Finding anything on the web is difficult.”

Solution: “Build a search engine.”

Feature #1: Robots scour the internet for words and phrases
Benefit: Website owners do not need to submit their sites for inclusion into search results
Benefit: The latest versions of website are always searchable

Feature #2: Words and phrases on the internet are indexed into a database of results
Benefit: Searches can occur fast and results displayed almost immediately

If you take this example and use it as a template, keep an eye on how often you find yourself writing a solution in the problem field or a benefit in the features field. After a bit of practice, you can get your product idea clearly defined and communicated.

Share
 

Tags: , , ,

Leave a Reply

 

 
  1. Zoe Rose

    October 20, 2010 at 7:30 pm

    Agreed, very much! I think a lot of this also comes down to templating – both in the written/document form (is there a field for ‘problem statement’?) and the mental (is there a brain-space called ‘problem statement’?)

    It’s interesting that the document can create the brain-space, as well as vice-versa.

     
  2. Tim Walker

    October 28, 2010 at 3:26 pm

    Yes – they teach this as part of an Engineering Masters course in the UK. The first stage is creating a solution is to revert the problem back to a ‘Solution neutral problem statement’ which then allows proper exploration of all possible solutions. Sadly lots of Marketing types take offence at this as it usually results in the binning of most of their technical input.