How can you check that the problem you've been handed is really the underlying problem, before you start solving it?

Step back, get outside views, hear the people affected, analyse the usage context, and drill down with 5 Why — anything that stops you from solving a merely-presented problem.

A presented problem is often a symptom or a guess, not the root cause. Concrete moves to test it:

• Question it critically — does the stated problem really cause the trouble, or just describe it?
• Step back and look from a distance — distance breaks the tunnel vision of being too close to it.
• Let others judge it, including experts — outside eyes catch assumptions you can't see.
• Let those affected speak — user interviews or simply observing real behaviour, rather than guessing on their behalf.
• Do a usage-context analysis — Who? What? Where? Map the situation the problem lives in.
• Ask "5 Why" questions — repeatedly ask why to dig from symptom to root cause.

The common thread: resist the urge to accept the first framing. The problem you're given is a hypothesis to be tested, not a fact to be solved.