I often hear expressions such as “here we should define what we do, not how we do it”. While sometimes useful, these kinds of statements are often ill-defined.
Let’s take an example from the quality management domain. Some level of process or method description may be said to describe “what” (to do), not “how” (to do it). Typically a process description tells you to do, say, A, B and C where A might be “define the system requirements”. Standing on the level where A, B, and C are described, A could indeed be said to describe a “what” (the “what” being to define the requirements). It doesn’t say anything about “how” to define the requirements.
Now, let’s say that A, B and C are all parts of a higher level process description called “system development” which is one of the business processes of a development organization (along such processes as “system maintenance” and “customer support”). Standing on the business process level, “system development” would be a “what” but A, B, and C would rather be the “how” of system development as they would answer the question: how is a system developed (it is developed by (A) defining the requirements, (B)…).
Conclusion: depending on your perspective, a “what” can be a “how” and vice versa. Looking downward in a hierarchy of process descriptions you see the “hows”. Looking around you at one of these “how” levels you instead see a lot of “whats”. So when you use the (imo false) what – how dichotomy, please at least state whither your head is turned.