I’m sure you’ve run into this, I know I have. Many times. You get a requirements document or other request and it’s all about the solution rather than the problem. What you want, what you NEED, as a competent technologist, to deliver the best solution is a statement about the problem to be solved. You see it as your job to deliver creative and cost effective solutions.
I found a few good tools that can be used to help work from a candidate solution back to the problem. I’ve used these both for personal analysis as well as part of structured meetings to help the solution recommenders work backwards to the problems.
The first is the famous Five Whys. You’ve probably used this many times and it is one of those obvious codifications of basic human behavior that people are observed to use in the wild when seeking to understand a problem. Start with the proposed product features and repeatedly ask WHY.
Product Feature: Wireless Network (WiFi) Interface
WHY does the product need WiFI? So the customer doesn’t have to wire in the system.
WHY doesn’t the customer want to wire in the system? So they can move it around.
WHY is it a problem to move the system around if it’s wired? Because they might have to pull wire to the new location and that expensive/troublesome and a constraint on consumption.
That seems like a satisfactory answer, but don’t stop!
WHY does the systems need a network interface? To deliver updates.
WHY do updates need to be delivered over a network? So we can update remotely and monitor the health of the system remotely.
AHA! Two base requirements discovered: Remote Updates and Remote Health Monitoring.
The second technique comes from The Innovator’s Guide to Growth. Here the concept is that customers have “jobs to do” and that a successful product will help them do those jobs. However when trying to discover those “jobs,” we often have to work from solutions the customer is using–perhaps even ones that have been cobbled together. Frequently the people we’re meeting with may not think in terms of “jobs to be done” or problem statements or the terms we need for our art. They think in their own terms, but can usually speak confidently about the tools they use. Whether this is the case or we are starting from a candidate solution proposal, the solution can be decomposed to discover the “job to be done.”
Solution: System with WiFi
What are the solutions capabilities? Networking anywhere within the location.
What barriers does WiFi overcome? Having to pull wire to new locations for the system.
What objectives can it address? Portability of systems.
In what circumstances will WiFi be most effective? Where the RF propagates well, wired grids are not prevalent, and systems need to move around.
For what jobs is the solution applicable? Moving the system to new locations that lack wired networks but are within RF range.
The results here are not as concrete, but the nuances are valuable. We’ve discovered not only the job the customer wants done, but also some constraints on even the proposed solution. If we dug on this “job” a bit more, we’d probably discover additional contraints on doing the job that can lead to requirements–such as weight, mounting, power, etc.
Next time you get a stack of “how” passed to you, try finding the author and work through some of these techniques with them to get to the “what” and “why.”
Posted by scottrfrancis 
