I'll describe my experience and try to get some "strategy" out of it.
I've once pair-programmed with a complete non-programmer. He was expert on the subject matter of the software product we developed. On the contrary, I had no experience in the problem domain. And he also was my supervisor at the moment (I know this may sound strange :)
Major benefit of this methodology was that I had to explain implementation of many things from his knowledge domain, thus ensuring the exactness of implementation and his understanding of the process, which meant he understood why it took this time.
Another benefit is easy focus on the task, no distractions (ha-ha, imagine opening Twitter before the nose of your boss).
It was quite intimidating at times, however, since even a tea break became quite a "distraction from work" (not from his point of view; it was just inconvenient to ask for break and so on).
So, this isn't really a pair-programming since he pretty much couldn't review the code as it was typed in. However, it seemed to be a sane strategy (at least for some time). It ultimately worked at all because of relative simplicity of both development methodology (I mean, no complex software design techniques like OOP Patterns were involved) and subject matter. This would't work in case we had to develop a compiler I think. I believe it still could work in case non-programmer observer is participating in the process of development of small clearly defined pieces. Say, it's ok to have him watch programming of a function "compute the parameter X from Y and Z by given algorithm", but may be not so ok to have him watch overall system design process (meaning development of software architecture, i.e. hierarchy of classes, since it's too abstract).
I think it would work even better in case he would have some basic programmer skills, as I would't have to explain "what's an array is".
Hope it helps :)