Interest leaves an unanswered question
A promising trial, an unfinished switch
Imagine a team considering a reporting tool to replace part of its spreadsheet workflow. The person responsible for the weekly report likes the demonstration, opens a trial, and reaches the data-import screen. No import is completed. The following week, the team sends its usual spreadsheet.
That sequence could lead a product manager toward simplifying the import, explaining the benefits more clearly, or offering migration support. Each response assumes something different about why the customer stopped. The same recorded behavior could also reflect a technical failure, missing permission, or a decision that the spreadsheet is good enough for now.
What would switching actually mean?
Before investigating the unfinished import, it helps to define the change the customer was considering.
For this team, a meaningful switch might mean preparing a reliable weekly report in the new tool and having colleagues use it in their review meeting. Importing data would be one step toward that outcome. It would tell us little, by itself, about whether the new workflow was useful.
A Jobs to Be Done view of switching
The progress the customer wants
Jobs to Be Done looks at the progress people seek within particular circumstances. The Christensen Institute describes products and services as things people “hire” to help make that progress. Jobs to Be Done theory.
In the reporting example, a possible job is preparing a trustworthy account of the week’s performance in time for a review meeting. The person responsible may want fewer reconciliation tasks, more confidence in the figures, and less time spent explaining discrepancies.
Those are hypotheses about this customer. A polished dashboard and an enthusiastic reaction don’t establish which of them matters, or whether the existing process causes enough difficulty to justify changing it.
The circumstances are essential. A newly expanded team struggling to reconcile several reports faces a different decision from a small team whose spreadsheet takes little effort to maintain.
Push, pull, anxiety, and habit
The switching approach developed by the Re-Wired Group examines four forces: the push of the current situation, the pull of a new solution, anxiety about changing, and habits associated with the existing arrangement. Re-Wired’s explanation.
Applied to our example, these could include:
- Push: Repeated discrepancies make the weekly report difficult to trust.
- Pull: The new tool promises a consistent view with less reconciliation.
- Anxiety: The person responsible worries about presenting incorrect figures after migration.
- Habit: Colleagues already know where to enter updates and find answers.
This gives the PM useful possibilities to investigate. It doesn’t establish which force explains the unfinished import.
There may also be a straightforward constraint: the customer cannot upload company data without approval. Even if they feel confident about the product, they cannot proceed until that approval is granted.
One stalled step, several explanations
The spreadsheet still does a job
The spreadsheet deserves a fair comparison.
Suppose it contains exceptions that the team understands, supports last-minute changes, and produces a report everyone knows how to read. Its disadvantages may be real, but moving away from it also means transferring knowledge, checking figures, and coordinating people.
From the product team’s perspective, importing a file might look like a short setup task. From the customer’s perspective, it could begin a change to a process they are accountable for keeping reliable.
Intercom makes a related point in its application of JTBD to onboarding: getting value from a complex product can require work beyond configuration, and the people involved may have different reasons to adopt it. Intercom on onboarding and stakeholder needs.
The person exploring the tool may welcome the change while the colleagues supplying the data see additional work.
What could explain the abandoned import?
The table below compares possible interpretations of our hypothetical case. These are alternatives to investigate, and several could apply together.
On smaller screens, scroll horizontally to compare all three columns.
| Possible explanation | Evidence to look for | Response to consider |
|---|---|---|
| The import cannot handle the customer’s data. | A reproducible failure with the relevant file structure or required fields. | Fix the failure or assess whether the requirement fits the product’s scope. |
| The customer fears disrupting a reliable report. | Concern about specific discrepancies, combined with uncertainty about checking or reversing the migration. | Explore a preview, reconciliation step, or reversible trial. |
| Permission or cooperation is missing. | An approval request, a named decision maker, or a dependency on colleagues who haven’t agreed to participate. | Address the approval or coordination requirement. |
| The expected improvement is too small or poorly timed. | The current report meets the need, while migration demands time or money the team won’t commit now. | Reconsider the value proposition, target circumstances, or timing. |
Even a revealing clue can remain ambiguous. A customer returning to the import screen several times could be struggling, waiting for someone else, or simply working around interruptions. The event tells us where to look more closely.
Find evidence that separates the explanations
Reconstruct the most recent attempt
A conversation about a specific attempt gives the investigation more substance than a general question about whether the customer likes the product.
Teresa Torres recommends gathering concrete stories about past behavior, then testing the insights they produce through action. Her distinction is useful here: someone describing an intention and someone attempting a task provide different kinds of evidence. The Ladder of Evidence.
For our reporting example, the relevant story begins before the import screen. What happened during a recent reporting cycle that prompted the search? What alternatives did the customer consider? What did they prepare for the trial, and who else became involved?
The sequence after the stalled attempt matters too. Returning to the spreadsheet could mean abandoning the new tool, postponing the migration until after a deadline, or continuing an evaluation while keeping the report running.
Where available, the file used, an error message, a support request, or an approval conversation can help make that account more concrete.
Challenge the first explanation
Suppose the customer explains that they lacked time to finish. That still leaves several possibilities open.
They might have expected hours of manual cleanup. They might have been waiting for a colleague to provide an approved export. Or they might have decided the benefit was too small to justify spending another afternoon on it.
These explanations suggest different next steps, so it helps to check which one fits what happened. If the customer was waiting for an approved export, reducing manual cleanup would still leave them unable to proceed. If they had the file and permission but decided the benefit wasn’t worth the effort, the question becomes whether the new workflow offers enough improvement to justify switching.
Customer accounts and product events each have limits. An account may omit details; event tracking may miss activity outside the product. Neither should be stretched to fill the other’s gaps.
One customer’s experience can reveal a problem worth addressing. Establishing it as a broader adoption priority requires understanding whether it recurs among the customers and circumstances the product aims to serve.
Choose what to change, or learn next
Choose a response the evidence supports
Suppose the investigation points to concern about the accuracy of migrated figures. A limited trial using a copy of a previous report could help explore that concern before committing to a broader migration. The customer could compare the results with a report they already understand and identify discrepancies or additional checking work. That would provide evidence for deciding whether to improve the migration process, address a missing capability, or investigate further.
Understanding the job also leaves solution choices to be tested. Re-Wired explicitly separates uncovering the customer’s circumstances from the subsequent work of designing and testing an offering. Re-Wired on moving from customer understanding to solutions.
Check progress in real work
After a change, follow the team through its next reporting cycle.
Could the person responsible reconcile the figures? Did colleagues receive what they needed? How much checking or duplicate entry remained? Did the new workflow remain useful during the following reporting cycle?
A partial switch may be enough: the new tool might handle consolidation while the spreadsheet remains useful for other tasks.
If the team completes the import but still prepares the meeting in its spreadsheet, the adoption question remains open. The next investigation should follow that work: what does the spreadsheet still enable that the new arrangement hasn’t earned the responsibility to replace?