For some reason, in the past few weeks I have talked to more than a few PhD students and researchers about various ideas. It is striking how often fundamentally very smart people have a problem in articulating just why what they are doing is useful, relevant, and potentially commercially interesting. Of course, we all know that this is hard, and all PhD students get some kind of training in presentation and selling their ideas. It is also unfair to expect a fresh graduate student to be able to put on a show like a Simon Peyton-Jones.
However, this did get me thinking some about the articulation of problems.
Reflecting over my experience from almost a decade in industry following my decade in the university, one thing that does stand out is a certain shift of focus in how I think about products and solutions. When I was an undergrad and grad student, the natural focus was on the solution. How did it work? Now, I tend to look for the problem. What can it do, why is it relevant?
To go back to the experiences that prompted this post: If someone cannot give me a good description of the problem they are trying to solve with their work, I have a hard time motivating myself to listen.
To be fair, there is usually a real and relevant problem behind most research. It is just that it might be implicit in the mind of the researcher, rather than explicit and part of the design and planning process. I sometimes find myself having to ask a series of fairly tough questions to try to pry out the problem from underneath the layers of assumptions about problem domains and what’s important.This can make people uncomfortable, but I hope that it is all for the best in the end.
Bringing out the problem into the open and making it explicit makes it much easier to discuss about it and consider the direction and potential value of research. Is the problem relevant for one or one million people? Is there some other problem that can be solved with the same methods, with a small shift in focus? Making the problem explicit can be very powerful as a methodology.
It is amazing just how much time I and my colleagues have spent over the past years trying to pin down the problems that we want to attack with the Simics product. When you have a product to sell and you depend on selling it, articulating the problem does become very important. The value of a solution to a customer comes from solving problems, nothing else.
There is one more trick to problem formulation that needs to be considered and that I think can really help anyone formulate their problem statement. When a business grows, you have to add a bigger sales force. To make new sales people productive as soon as possible, the marketing and product people have to be able to articulate just which types of accounts (companies) and which types of projects and people inside the companies to look for. Equally (or even more) important is making it very easy to understand when to walk away from a discussion, since there is no match between the customer problems and your solution, and therefore no chance of closing a deal. Thinking about a solution or product in this light does make a difference.
The question I think any researcher should ask themselves before presenting their work is: how can I explain it in such a way that someone in the audience can explain to a third person what it is all about? Which problems are being considered – and which problems are not being considered? Can someone in the audience pick up on what I say and carry on to a third party – who might be that perfect contact I need in order to further my career as a researcher?
That is the true definition of knowing your problem, I think.
To paraphrase Bill Clinton, it’s the problem, stupid.
One comment to clarify the “shift focus” part of the post. There are plenty of projects that aims to “make parallel programming easier”. Too often, these just assume that typical HPC is the problem space. While in practice, there might be much more relevant work to be done in making it easier to program for certain specialized domains. Shared-memory computation is one problem domain – but threaded control code is quite different, as examplified by Erlang. Indeed, Erlang is a good example of problem-driven design, as they started not with “let’s make a parallel language” but with “how can we make telecom programming easier and faster”. That is the kind of thinking that needs to inform multicore work: decide on the problem domain and solve that well, rather than trying to be general and cover all bases. General-purpose programming is actually just another niche when you look at the landscape from a different angle.