Our goal is to understand our customer's pain points so that we can serve them a solution. That's the goal. The Magic Toybox system is winnowed as a value offering down to a simple pain point and a simple remediation: we drive traffic to businesses. We are a marketing and advertising platform. In a way, this makes our work simple. We know what we offer, and we believe that functionally we can offer it. The questions become:
- What customer venues derive benefit from this?
- Which, of those venues offers the best cost benefit for our approach and pursuit?
- Do these subsets understand their problem?
- Do these subsets understand our solution as an answer to their problem?
This process begins with needgathering. We must know how our customer sees their problem, in order to build a bridge between it and our solution.
- Understand the work as it exists. Use concrete recent incidents, workflows, artifacts, handoffs, and consequences.
- Reflect the problem back accurately. Send him a concise summary or workflow diagram and ask what you misunderstood.
- Validate priorities and boundaries. Determine which problems matter, which are tolerable, and which the institution would actually address.
- Only then test possible interventions. At that point, a concept or prototype is evidence that his input affected the design—not a request that he endorse a guess.
Plan for no more than a 30 minute meeting. You aren't important to them, but they are very important to us. Your opening can be cold or warm.
- Cold - Present unknown or known, and ask about the problem. Cold happens because businesses understand businesses, and they know that customer validation is the first step in someone trying to sell them something. Some can be standoffish, but others can be supportive. You are, after all, trying to help them. Note: Do not assume that no interest in Customer Validation means no problems.
- Warm - They know you already, or you are somehow aligned with them already discussing the problem. Warm happens because people like to talk about their problems.
- Hot - You are seeing the problem happen, and you talk about it with them directly afteward
You'll note that in all cases, you have only so much leverage in defining the temperature of an opening. Get used to cold, but always be on the lookout for warm and hot.
If you have any heat to the opening, you will probably start with Critical Incident Review or Workflow Mapping.
- If they start by telling you about their business and how it runs -> Workflow Mapping -> Artifact Elicitation -> 5 Whys
- If they start by telling you about a specific incident -> Critical Incident Review -> 5 Whys
- If they ask what you're selling, answer directly --> We aren't, yet. We want to sell what will solve problems for you. We have a bit of an idea what that is, and we want to know if we're onto something --> Proceed to Workflow mapping. They'll probalby start complaining.
This will open up the topic of cause and effect. As you proceed, you will begin applying:
- Prioritization (Forced and General) - Understand why things go the way that they do
- Counterfactual - What would happen if things were or went differently?
- Substitute and workaround - What if they tried something else? What else have they tried?
- Shareholders - Who bears out the risk/who suffers
This opens up the 5 Whys to an exploration of their attitude towards the problem, as well as what they've done to remediate it. This is how you get to the problem, its impact severity and customer's problem awareness. These are the (qualitative) data points that we need from an interview
By the end of 30 minutes, try to understand:
- What outcomes he is responsible for
- Which recurring decisions are difficult
- How information currently reaches him
- Where the workflow fails or becomes expensive
- Who else participates or controls adoption
- Whether the problem is frequent, consequential, and funded
A basic method for drilling down into the cause of problems. This tool is useful for both direct discovery, and for assisting customers in self-discovery, making it both a map to #3 and #4.
Don't keep asking "Why" like a five year old. Acknowledge what was said. They should know enough of the problem to give you a thread to pull on. Is it regulatory? Is it that they haven't the time to work on the problem more? Is it a trivial problem to them, and they're just complaining? The latter is an essential possibility to isolate and remove from the pool of feature-associated efforts. The others, and those like them, have potential.
- “What makes that important?”
- “What happens when that is unavailable?”
- “Why is that consequence significant?”
- “What does that prevent you from doing?”
- “Who notices when it goes wrong?”
- “What would become possible if it worked better?”
This method approaches the unpleasantness by making them relive it. This is why it's not always preferred. In some cases, particularly with people of a technical sort, it's more likely to be constructive. However, the interviewer must always keep it a construtive flow of information, and not an invitation to complaining.
Ask about the last actual occurrence, not the general process.
Tell me about the last situation where you discovered a problem later than you would have preferred.
This exposes exceptions, improvisations, unofficial tools, delays, and decision points that a standard process description often hides.
Look for the progress he is trying to achieve rather than the task or software category.
A possible administrative job might be:
Help me understand whether a situation requires intervention, without forcing me to reconstruct the case manually across several offices.
Investigate three dimensions:
- Functional: What must be accomplished?
- Emotional: What does he need to feel confident about?
- Social: How must the decision appear to students, faculty, leadership, auditors, or accreditors?
Jobs-to-Be-Done explicitly includes these functional, emotional, and social dimensions. (Christensen Institute)
Build a mental sequence:
Trigger → information gathering → interpretation → coordination → decision → action → follow-up
At each step ask:
- Who acts?
- What information enters?
- What tool is used?
- What decision is made?
- What can fail?
- Where does ownership transfer?
You are looking for handoffs, duplicate entry, missing context, long waits, and places where someone must interpret unstructured information.
Ask what the work physically looks like:
- “What document do you open first?”
- “What report is most useful?”
- “What spreadsheet or email thread tends to appear?”
- “What would be on your screen during this process?”
- “Could you describe the fields or information you compare?”
In a later session, ask permission to observe a sanitized example. Stanford’s needfinding materials emphasize combining interviews with observation and immersion, because work practices often reveal needs that people do not spontaneously articulate. (Stanford d.school)
Administrators can usually produce a long list of legitimate problems. Force tradeoffs:
You can improve only one of these this year. Which one do you choose?
Then ask:
What makes that one more important than the others?
A simple ranking or card-sort exercise can expose differences between problems that are merely recognizable and those that are genuinely important. Strategyzer uses forced ranking and card sorting to refine customer jobs, pains, and gains. (Strategyzer)
Explore what would happen without intervention:
- “What happens if nothing changes for three years?”
- “What would cause this to become a senior-leadership priority?”
- “What would make it not worth solving?”
- “When does the current approach work perfectly well?”
- “Which cases do not need improvement?”
The negative cases protect you from exaggerating the market.
¶ Substitute and workaround analysis
Ask what has already been “hired” to solve the problem:
- Existing enterprise systems
- Spreadsheets
- Business-intelligence reports
- Shared drives
- Email
- Meetings
- Institutional-research staff
- Advisors’ personal knowledge
- Manual case review
Your real competitor may not be another product. It may be an employee, a committee, an unofficial spreadsheet, or acceptance of the status quo.
Ask him to place people around the workflow:
- Who experiences the problem?
- Who performs the work?
- Who benefits from improvement?
- Who could block change?
- Who bears the risk?
- Who controls the data?
- Who controls the budget?