auhtor_image
Tim Hines

Principal Consultant and Practice Head

I frequently have heard experienced product managers evangelize the distinction between the “What” and the “How” of a solution – particularly in technology product management.  This is an effort to distinguish the “problem space” and the “solution space.” (1) The idea behind this distinction is to improve the chances for success for the project. When this is actually put into practice, it is however harder than it seems to get right.  It’s common for experienced product managers to confuse the How form the What and to get sloppy in their distinction.

Why?  Because it’s so easy to describe the What in terms of the How.  I saw this recently when I was asked to review a Go To Market plan for a company and give my feedback.  The plan was structured well enough, but for the life of me being a newly invited outsider, I could not clearly distinguish What is being solved and How they were going to solve the problem.  They had a section in their plan dedicated to the What they were solving. It provided good contextual bits and pieces and even well formulated buyer and user personas. But they described the What in terms of a series of wireframes – which if you didn’t know a wireframe is usually describing the How.  When I inquired about the issue nobody could articulate clearly the problems, the pain points or more importantly why the users would care.

If you ever find yourself in this situation, and it’s easy to do, it’s time to take a step back and reassess.  Product teams are always busy executing in their daily tasks and sometimes they just need to rekindle the discipline.  Other product teams haven’t actually ever been taught some of the key attributes of the What and the How. For these teams, chances of success is low and they need to slow down for a little education.  Most commonly product teams become too close to the problem (or the solution) and can’t see the forest from the trees. Probably a deeper set of issues here that will require some more drastic redirection. Outside influence can help put this back on track.

Regardless, here’s a little tip as to how to avoid confusing the What from the How and to help your project get back on track:  

  • Infuse the discipline with a being sure to answer the question of Why.  And more specifically Why the user persona cares about the What. I like to ask these three questions which helps keep me centered and focused on the pain.
    1. What is the problem?
    2. What are the reasons for the problem?
    3. Why does it matter that we solve this problem?

Remember if you are answering these with wireframes and not words, you are in the solution space and focused on the How.  Articulation of What very succinctly and distinguished from How will result in greatly improved chances of success for your project.

(1)These terms and ideas are very well articulated by Dan Olsen in the Lean Product Playbook.  It’s an inspiration and a solid resource for every product manager. https://www.linkedin.com/in/danolsen98