Use this map when people say “the tool does not work” or “the team will not use it.” It helps you decide what to check and how to respond. Do not use it to rate employees or force every problem into one category.
Start with what went wrong
Record:
- Task and expected result: What should happen?
- Actual result: What happened instead?
- People and records affected: Who or what is affected? How often does it happen? What is still unclear?
- Evidence: Keep a link or note from a record, system setting, or task walkthrough.
- Immediate impact and owner: Who will limit harm to the service or process now?
If the problem threatens a key service, accurate records, or a required safeguard, limit the harm first. Do not make the team wait for a full analysis before getting help.
Match the question to the gap
These are possible explanations, not labels for people. Start with the signal, test the question, and change the response if the evidence points elsewhere.
| Possible gap | Observable signal | Question to investigate | Response to try | Check that it helped |
|---|---|---|---|---|
| Feature: the required result seems unavailable | An experienced user cannot reach the result with the current setup. | Can they demonstrate it with the right settings, access, and connections? Is the requirement still valid? | Confirm the limit. Consider a configuration change, redesigned process, bounded temporary method, or a different tool. | Demonstrate the required result and safeguards. If impossible, name who decides what to change. |
| Workflow: the result is possible through different steps | Familiar steps produce the wrong result or users cannot find the new path. | Which old action must stop? Where does the new path begin and end? | Build an old-to-new task card and practice with a daily user. | The user follows the card, completes the task, and sees the right result without missing directions supplied by an instructor. |
| Hidden behavior: a background action has changed | A notice, default, timing rule, or automatic action is missing or has a different effect. | What used to happen without a deliberate step, and what depended on it? | Trace the trigger and affected people or records; assign and document the new behavior. | Show the action occurs when needed and that someone can detect a failure. |
| Leadership experience: the leader's starting point differs from the user's | A leader calls the steps obvious while daily users encounter missing instructions or unclear reasons. | Has the leader watched someone do the task without coaching? Which assumption differs? | Observe, explain the change, and revise instructions, practice, support, or expectations. | The user can perform the task and find help; the specific leader assumption has been tested. |
Feature: the required result seems unavailable
- Observable signal
- An experienced user cannot reach the result with the current setup.
- Question to investigate
- Can they demonstrate it with the right settings, access, and connections? Is the requirement still valid?
- Response to try
- Confirm the limit. Consider a configuration change, redesigned process, bounded temporary method, or a different tool.
- Check that it helped
- Demonstrate the required result and safeguards. If impossible, name who decides what to change.
Workflow: the result is possible through different steps
- Observable signal
- Familiar steps produce the wrong result or users cannot find the new path.
- Question to investigate
- Which old action must stop? Where does the new path begin and end?
- Response to try
- Build an old-to-new task card and practice with a daily user.
- Check that it helped
- The user follows the card, completes the task, and sees the right result without missing directions supplied by an instructor.
Hidden behavior: a background action has changed
- Observable signal
- A notice, default, timing rule, or automatic action is missing or has a different effect.
- Question to investigate
- What used to happen without a deliberate step, and what depended on it?
- Response to try
- Trace the trigger and affected people or records; assign and document the new behavior.
- Check that it helped
- Show the action occurs when needed and that someone can detect a failure.
Leadership experience: the leader's starting point differs from the user's
- Observable signal
- A leader calls the steps obvious while daily users encounter missing instructions or unclear reasons.
- Question to investigate
- Has the leader watched someone do the task without coaching? Which assumption differs?
- Response to try
- Observe, explain the change, and revise instructions, practice, support, or expectations.
- Check that it helped
- The user can perform the task and find help; the specific leader assumption has been tested.
More than one gap may apply. A missing feature may turn out to be an access problem. A hidden default may cause a workflow problem. A leader's assumption may explain why nobody spotted either one. Choose Mixed or Unresolved when needed.
Choose a fix and a test
| Field | What to enter |
|---|---|
| Likely gap type | Feature / Workflow / Hidden behavior / Leadership experience / Mixed / Unresolved |
| Possible explanation and support | What might explain the problem? What have you seen that supports it? |
| What might prove it wrong? | What else should you test? |
| Next check / person / deadline | What will you check next, who will do it, and by when? |
| Planned fix / person / deadline | What will you change once the findings support that choice? |
| Test of the fix | What task, result, or safeguard must work? Who will check it? |
| Review date and result | What did you find? Will you close the issue, change the plan, or ask for more help? |
Likely gap type
- What to enter
- Feature / Workflow / Hidden behavior / Leadership experience / Mixed / Unresolved
Possible explanation and support
- What to enter
- What might explain the problem? What have you seen that supports it?
What might prove it wrong?
- What to enter
- What else should you test?
Next check / person / deadline
- What to enter
- What will you check next, who will do it, and by when?
Planned fix / person / deadline
- What to enter
- What will you change once the findings support that choice?
Test of the fix
- What to enter
- What task, result, or safeguard must work? Who will check it?
Review date and result
- What to enter
- What did you find? Will you close the issue, change the plan, or ask for more help?
Check that the task now works before closing the issue. Installing a change or finishing training is not enough. If the first explanation is wrong, keep the notes and test a new one.
Example from my experience
At Northpoint, we had orders for a property turn created outside the intended turn process. The system could create the orders, but the familiar steps left them outside the place needed for turn tracking. I had also assumed the new steps would be clear to users.
This points to Workflow + Leadership experience as gaps to investigate. It does not prove a feature was missing. A useful response is a clear task guide, practice with daily users, and a check that the order appears under the right turn.
This example comes from my operating experience. It is not a current product guide or a claim that every turn problem has the same cause.
Next action
Use the task guide for changed steps. Put the plan to limit harm, investigate, and test the fix into the support plan. Revisit launch readiness if the findings change what can launch.
Supporting source
- Year One, Episode 5: Property Meld to AppFolio — The Hardest Maintenance Migration — I discuss the four gaps and the turn-order problem from our migration. The matrix responses and tests are proposed guidance.