← All field notes
LinkedIn ↗Erin Naylor · Field Note
Field NoteJune 26, 2026 · 6 min read

Designing the System Around the Study

The hard part usually isn't finding the need. It's getting the org ready to act on it.

Enterprise CCaaSProduct strategyStakeholder work

The request came in sounding simple enough. A large enterprise customer wanted to understand how mobile and tablet could better support field service operations, and on paper that reads like a usability study with a device constraint attached. It took about two weeks of conversations before I understood that mobile was not really the subject. What they were asking, without quite saying it, was whether the product could support a different way of running their business, one where store leaders and area managers and quality teams could watch what was happening, make a call, and act on it from a phone in the middle of a shift.

If I had run the study as originally framed, I would have produced a list. Feature requests, navigation complaints, a handful of customer-specific asks, all of it defensible and none of it particularly useful six months later. So I rewrote the question the work was answering: what has to be true for mobile to become a surface people trust operationally, and where should we deliberately hold back, defer, or invest?

Strong signal, no owner

The customer signal was not the problem. Stakeholders were clear that mobile mattered to how they worked, particularly around quality management, reporting, and supervisor activity, and they were clear that the issue was less about missing functionality than about finding the right information and turning it into a decision. Internally the picture was messier. Product had real concerns about roadmap priority and engineering bandwidth, and reasonable doubts about whether mobile had enough business justification behind it to earn a slot.

That combination is a familiar trap in enterprise research. You can produce something completely valid and watch it go nowhere, because nobody owns it, nothing is prioritized against it, and the business case was never made. The customer's expectations went past discovery too. They wanted to see how findings would turn into workflow changes, concepts, review checkpoints, actual change.

Rigor as expectation management

A lot of the discipline in this project had nothing to do with method. It was about not overpromising in customer-facing rooms, positioning the engagement as discovery and insight routing rather than a commitment to roadmap changes or delivery dates. I have come to think that is as much a part of rigor as an unbiased question. Keeping evidence separate from interpretation, telling a customer-specific need apart from a platform opportunity, being explicit about what is actionable now versus directional later, and leaving uncertainty visible instead of smoothing it over with a confident story.

So the plan changed shape. Instead of one mobile study I ran it as a few parallel tracks: implementation and value realization issues specific to this customer, mobile workflow improvements, supervisor workflow validation, reporting and decision support, and the business context that would make a prioritization conversation possible. That structure meant the work stayed useful even where a given product area was nowhere near ready to invest.

The finding is not the unit of value

The shift that mattered most was realizing a finding is only worth as much as its destination. An implementation issue belongs with the account and services teams. A usability problem belongs with product and design. A future workflow opportunity belongs with leadership, and it needs a different kind of evidence to land. So I gave every insight an owner, a decision it was meant to inform, and a confidence level, which sounds bureaucratic and turned out to be the thing that kept the readout from ending with the question I have heard too many times in too many rooms: who owns this now?

It also kept the customer relationship honest. They stayed a genuine partner in shaping the work without reading their own participation as a promise of investment, because the framing was consistent every time: we are learning where the current experience supports or limits value, and routing what we find to the teams who can evaluate it.

Research does not create impact by revealing the truth. It creates impact when it helps an organization decide what to do with the truth.

The most useful artifact from that project was not the discussion guide or the readout. It was the decision structure built around the study, the thing that sorted what could improve the customer's experience today from what belonged to existing product paths, what needed a future investment conversation, and what was really a signal about strategy. That is the version of the job I want to keep doing.


Filed by Erin Naylor — June 26, 2026