There are those that believe a problem is a gap between the way things currently are, and the way you or your customers believe they should be. The bigger the gap, the bigger the problem. I like the formality of this type of thinking, I mean many people don't even try to define what a problem is. Let's look at a few examples of this:

1. "I keep forgetting how to view a subset of components within a part structure. I believe this software application should be easier to use."
2. "When I call tech support for my phone, I want someone competent to answer and help me, not some goof with an ego problem."
3. "My teenage son isn't preparing for adulthood like he should be."

The gap in the first statement is between how complex the software interface is now, and how complex the user would like it to be. In the second statement, the gap is between the competency level of tech support and the desired competency level. The third statement's gap is the distance between the level of preparation currently being accomplished by a teenage boy, and the desired level of preparation (I suspect the gap is between reality and the father's lost grip on that reality, but the statement is still a problem by our definition of a problem).

For me, these statements don’t define problems at all, but define a type of enhancement request. The reason is that it doesn't go far enough to be called a problem until it identifies a conflict. As soon as these conditions (called a gap) are identified, they are quickly solved unless there is conflict. If I had to work with this kind of stuff, I'd place them in my "maintenance and utility" portfolio of problems and find a quick answer with no innovation required, or I'd start looking for the conflict (in the case of the father, I'd buy him a drink and send him on his way. I mean, the conflict is really a big one, and if I told him the truth he'd hate me and I'd lose a customer!).

I like identifying the conflict with a "but". In the examples above, we might have:

1. "I keep forgetting how to view a subset of components within a part structure. I believe this software application should be easier to use, but I don't want to lose all of its capability."
2. "When I call tech support for my phone, I want someone competent to answer and help me, not some goof with an ego problem, but I don't want to pay more money for a more qualified person."
3. "My teenage son isn't preparing for adulthood like he should be, but if I talk with him about it I lose what little influence I have on him."

Now, using the "but", I transition from focusing on the gap to focusing on the conflict in context of closing the gap. The size of the gap really doesn't matter, it's the size of the conflict that's the difference between a ten cent problem, and that billion dollar one.

I'm wondering what others do, either in terms of definitions of standardized formats to help clearly identify the problem? Maybe you could drop a few hints in the comment section.