This is the only thing I learned from my master degree. Asking the right question is half way done to get the right answer. In fact asking the right question probably more important than getting the right answer. Once you stated the question correctly, things magically fall into place and you can outsource the work to someone else.

Finding the right problem is half the solution
By Robert W. Lucky, July 2011, IEEE Spectrum

A problem well stated is a problem half solved.
– Inventor Charles Franklin Kettering (1876–1958)

We’re all fairly good at problem solving. That’s the skill we were taught and endlessly drilled on at school. Once we have a problem, we know how to turn the crank and get a solution. Ah, but finding a problem—there’s the rub.

Everyone knows that finding a good problem is the key to research, yet no one teaches us how to do that. Engineering education is based on the presumption that there exists a predefined problem worthy of a solution. If only it were so!

After many years of managing research, I’m still not sure how to find good problems. Often I discovered that good problems were obvious only in retrospect, and even then I was sometimes proved wrong years later. Nonetheless, I did observe that there were some people who regularly found good problems, while others never seemed to be working along fruitful paths. So there must be something to be said about ways to go about this.

Internet pioneer Craig Partridge recently sent around a list of open research problems in communications and networking, as well as a set of criteria for what constitutes a good problem. He offers some sensible guidelines for choosing research problems, such as having a reasonable expectation of results, believing that someone will care about your results and that others will be able to build upon them, and ensuring that the problem is indeed open and underexplored.

All of this is easier said than done, however. Given any prospective problem, a search may reveal a plethora of previous work, but much of it will be hard to retrieve. On the other hand, if there is little or no previous work, maybe there’s a reason no one is interested in this problem. You need something in between. Moreover, even in defining the problem you need to see a way in, the germ of some solution, and a possible escape path to a lesser result, like the runaway truck ramps on steep downhill highways.

Timing is critical. If a good problem area is opened up, everyone rushes in, and soon there are diminishing returns. On unimportant problems, this same herd behavior leads to a self-approving circle of papers on a subject of little practical significance. Real progress usually comes from a succession of incremental and progressive results, as opposed to those that feature only variations on a problem’s theme.

At Bell Labs, the mathematician Richard Hamming used to divide his fellow researchers into two groups: those who worked behind closed doors and those whose doors were always open. The closed-door people were more focused and worked harder to produce good immediate results, but they failed in the long term.

Today I think we can take the open or closed door as a metaphor for researchers who are actively connected and those who are not. And just as there may be a right amount of networking, there may also be a right amount of reading, as opposed to writing. Hamming observed that some people spent all their time in the library but never produced any original results, while others wrote furiously but were relatively ignorant of the relevant literature.

Hamming, who shared an office with Claude Shannon and knew many famous scientists and engineers, also remarked on what he saw as a “Nobel Prize effect,” where once having achieved a famous result, a researcher felt that he or she could work only on great problems, consequently never doing great work again. From small-problem acorns, great trees of research grow.

Like a lot of things in life, it helps to be in the right place at the right time. Sometimes all the good and well-intentioned advice in the world won’t help you avoid working on a dead-end problem. I know—I’ve been there, done that