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 help teams connect data, workflows, and real conversations so decisions are grounded in reality rather than assumptions.

How I build understanding

Understanding how customers work rarely comes from a single method. I look across signals to see the full picture, including:

• 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 looked like 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.”

That’s a founder sentence.

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.

How I built understanding

To understand what was happening, I looked across multiple signals:

• Usage data to understand where and how work was being completed

• Product workflows to see how tasks were expected to be done

• Conversations with internal teams who worked closely with vendors

• Limited observation opportunities with field users when available

Together, these inputs helped build a clearer picture of how work was actually coordinated on site.

What this revealed

Work was being completed collaboratively, not 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.