Finding an adoption barrier through customer conversations

Start with a specific gap in the customer's intended workflow. Speak with people who own and perform the work. Ask about a recent attempt, then compare their account with available records. Test explanations without steering people towards one.

From observation to verified barrier: three steps

Bring an observation

Prepare a short account of what is known: the task, intended users, period, expected action and recorded activity. Confirm that event and account mapping are credible. An empty chart is a weak starting point if tracking is incomplete or the task has not arisen.

For a hypothetical approvals product, nominated managers might have opened eligible requests while few decisions were recorded. That pattern does not establish whether access, policy, product design or an offline process explains the gap.

Invite people closest to the work. A sponsor can explain the goal; an administrator can explain permissions and setup; a user can describe a real attempt. Note which part each person can speak to; one account may be incomplete.

Who to invite, and what each person can speak to

Ask about a real attempt

Begin neutrally: “Could you walk me through the last time this task came up?” Follow what started it, what the person tried, where they went next and how the work was eventually completed. Ask to see an appropriate example if the customer is comfortable sharing one. Avoid suggesting a cause with a question such as “Was the feature too confusing?”

Useful follow-ups include:

Let the customer correct your interpretation. If someone says the task was completed outside the product, ask whether that was an exception, an approved route or a change in the intended workflow.

Verify the barrier before acting

Record separately what the person said or showed, your possible explanation and what would verify it.

If a user reports that the submit control was unavailable, permission is one possibility. Check with the administrator and relevant access record before naming it as the cause. A single conversation does not establish a general product finding.

Once the cause is clear enough to assign, agree a response with the right owner. An access change needs an authorised customer or technical owner; an unclear instruction may need better guidance; a reproducible fault needs technical investigation; a changed business process may need a revised adoption goal.

Agree when to review the next eligible task. At that point, ask whether the person completed the work and whether the customer accepted the result. If the task has not recurred, keep the finding provisional.

Matching a verified cause to the right owner