Assumptions vs. Reality in Field Work
When products struggle with adoption, the issue is rarely a lack of effort or intent. More often, it’s a mismatch between how teams expect work to happen and how work actually happens across people, tools, and constraints.
I partner with teams to connect data, workflows, and real conversations so product decisions are grounded in reality rather than assumptions.
How I build understanding
Insight into how customers work rarely comes from a single method:
Product workflows and where users get stuck or drop off
Usage data that shows patterns over time
Conversations with customers and internal teams
Observation of real workflows when access allows
Existing processes customers rely on outside the product
Individually, these signals can be misleading. Together, they reveal where products fit and where they do not.
A real example
Product data showed low mobile adoption for a key workflow. From the customer’s perspective, this appeared to be a usage problem that needed to be addressed quickly.
Because the people doing the work were not the direct customers, the team did not have full access to them through traditional research channels.
Why this mattered
Without understanding the difference between the organization buying the product and the people doing the work, the team risked optimizing the wrong behavior.
Clarifying this distinction shifted the problem from improving adoption to supporting how work actually gets done.
Outcomes
Within one month, more than 1,200 tasks were assigned to multiple users. Project managers later reported smoother coordination and easier task management without added complexity.
What this revealed
Work was being completed collaboratively rather than individually. One person often acted as a proxy for the system, collecting information from the rest of the crew and entering it later.
This was not because the product was difficult to use. It was because the product assumed individual task ownership in an environment where work happened across multiple people at the same time.
The issue was not resistance. It was a mismatch between the workflow the product assumed and how work actually happened.