The Problem Statement should always be written with the least viable product in mind. That's not to say you should be addressing the solution when writing the problem. Before presenting an example, I want to provide a little background into the problem statement so there's no confusion.

I'll start with a Use Case: 'The application processes a customer's credit card when given the correct information.' This same Use Case might have been written as a User Story this way: 'A company can pay for a job posting with one credit card to avoid waiting to talk with someone on the phone'. Notice that these two sentences are slightly different besides the Use Case being system-centric, and the User Story being user-centric.

The Use Case is focusing on the system and information processing. The User Story adds an additional concept by introducing the number of credit cards being valid. Apparently if I need to split costs between two credit cards I'll have to go elsewhere. Both the User Story and Use Case include some concept of a solution.

Let's assume that a customer sends in a enhancement request that states: 'I'd like to be able to split payments for placing a job posting between two or more credit cards'.

Now the product management team gets a hold of this enhancement request and writes a problem statement (always in the voice of the customer), here are a few examples of what could have been written.

1. IF I pay for posting a job with two or more credit cards THEN I can use cards with lower available credit, BUT this additional functionality adds to processing time and complexity of the interface.
2. IF I pay for posting a job with two or more credit cards THEN I can use cards with lower available credit, BUT then the price must be adjusted because the vendor must pay two or more minimum premiums to each credit card company.
3. IF I pay for posting a job with two or more credit cards THEN I can use cards with lower available credit, BUT then I might increase the risk of identity theft.

First, notice that the problem statement is about the conflict between transitioning from a current state to a desired state, not directly about the user nor the system. Second thing to notice is that the desired state is considered, but not how to get there, nor even what needs to be done to get there, just the destination. The problem statement can also be about not transitioning, as an example,

IF I can't use multiple credit cards to pay for posting a job, THEN I won't be able to pay until I have more credit available, BUT I need to let the public know about this open position immediately.

In Part Two we'll look at controlling levels of innovation with the problem statement, And in Part three, we'll look at how this was used in a few case studies to create a Blue Ocean.