The mobile ask that wasn't about mobile.

A national automotive service network had raised concerns about mobile and tablet usability. The internal read was reasonable: managers work away from a desk, the tablet is small, they want more of the platform on it. There was expansion on the table, so the answer carried commercial weight as well as operational weight.

That framing had a shape I've learned to distrust. Which features are missing is a question that always returns an answer — a feature list — whether or not a feature list is the problem.

The onsite wasn't a standalone study. It was stage one of a five-stage program I'd structured so that findings could not skip ahead of their evidence:

1. 01

   Research and discovery

   How operational leaders work today, and where mobile and tablet help or hinder.

   →
2. 02

   Implementation optimization

   What existing capability, configuration, workflow, or enablement can already address.

   →
3. 03

   Proof-of-concept enablement

   Show how close current capability gets, with solution consulting and the account team.

   →
4. 04

   Product opportunity identification

   Route only what implementation genuinely cannot address.

   →
5. 05

   Future-state validation

   Clarify what must be true before expanding with confidence.

The guiding principle is the sequence itself: value realization first. Nothing gets treated as net-new product investment until existing capability, configuration, workflow, and enablement have been ruled out. That ordering is what keeps a research program from becoming a feature-request intake.

Two days, four locations, one market. Contextual review of call review, coaching, reporting, mobile, tablet, and cross-system workflows — observed in the room where they happen, with the phone ringing and someone walking up to the counter mid-sentence.

Every observation was captured against a fixed frame, so the notes could be compared across sites instead of pooled into vibes:

Participant role · location or session · workflow observed · tool or surface used · user goal · device, orientation, and zoom · point of breakdown · workaround and its consequence

And every item was labeled with what kind of evidence it was, because these are not interchangeable and treating them as interchangeable is how a research program quietly turns into a roadmap:

• Observed directly — behavior or system response witnessed during the visit
• Participant statement — a reported experience or opinion, not independently observed
• Requested enhancement — a change explicitly asked for
• Proposed solution — a suggested interface, feature, or technical response
• Open question — an idea or capability question with no evidence of need behind it yet

Most of what arrives in a field session is in the bottom three categories. Most research reports present all five as if they were the first.

Day one produced four site visits and a pile of partially consolidated notes. Day two was already booked.

I consolidated overnight and shipped a directional debrief before the next morning's first visit. It named five working clusters, attached an explicit safe interpretation to each, and converted day two from more-of-the-same into a targeted test.

It also carried a page listing what it deliberately did not provide:

That page is the whole point. The speed only means something because the boundary is stated. A fast readout without one is an early wrong answer with a head start.

Day two stopped asking managers to describe their work and started asking them to perform it:

• Show us the last thing you did on your phone in here.
• Where in the store are you standing when you do that?
• What do you handle on the tablet, and what sends you back to a desktop?
• Show us something that's harder on mobile than it should be.

Watching someone switch to a desktop mid-task tells you more in four seconds than twenty minutes of them explaining why they sometimes do.

Reviewing a call is almost never discussed on its own. It comes up as the first step in something else — a callback, a coaching conversation, an appointment verification, a save.

And the evidence kept leaving the system in order to survive that gap. Case numbers copied onto paper. Screenshots emailed onward. Exports rebuilt by hand at every level of the hierarchy. A note that lives in a pocket until it isn't legible anymore.

Those artifacts were not user error. They were the workaround for a system that supports reviewing better than it supports acting on what you reviewed. Evidence has to survive the distance between noticing something and doing something about it, and when the platform doesn't carry it across that distance, people carry it themselves.

The same fragility appeared at every level of the organization, with different evidence at the front of it:

Different inputs, different altitude, same underlying job: get the right person to the right place with enough context to have the right conversation.

Which produced the decision implication that mattered most commercially — do not assume one dashboard, one level of detail, or one interaction model should serve every operational role. That is a very different roadmap than the one a feature list would have produced.

The second question produces a workflow. The first produces a backlog you'll regret.

The progression the evidence kept tracing:

1. 01

   Monitor

   What is happening?

   →
2. 02

   Orient

   Where is the opportunity concentrated?

   →
3. 03

   Diagnose

   What might explain the pattern?

   →
4. 04

   Communicate

   Who needs to understand or investigate it?

   →
5. 05

   Act

   What intervention, coaching, recovery, or escalation should follow?

   →
6. 06

   Verify

   Did the action change the outcome?

When I put that in front of division leadership, they recognized the first five as how operations already works. Verify they didn't — it's my extension, based on the field evidence, and it's the one every organization skips.

I labeled the recognition as exactly what it was on the slide: participant recognition, not a framework validated across the enterprise. That sentence cost me nothing and buys the model a much longer life.

The interim synthesis splits evidence into three columns and refuses to blur them.

Confidence was scored separately by organizational level, so no one could read a strong store-level finding as an enterprise conclusion.

Three proof-of-concept candidates are written up with working scenarios, capability areas to assess, and value hypotheses. All three carry the same stamp:

The most useful thing research can do partway through an engagement is make the next decision sharper without pretending to be the decision.

Every finding splits down two tracks before anyone argues about roadmap.

Track one — current value realization. Can existing capability, configuration, implementation, integration, policy, process, or enablement address this? Six assessment areas came out of the onsite, each with an assess first question set and an explicit value hypothesis, ordered for near-term evaluation.

Track two — product opportunity. Is this a structural problem that survives after every implementation option is exhausted? Five candidate problem spaces, each with a strategic question, an argument for why it may exceed current capability, and a written list of what still needs validating before it advances.

Neither track is a conclusion. An item can start in track one and reveal a product boundary through use — the two aren't mutually exclusive, and the routing table says so explicitly.

Treating every issue as a product gap delays value the customer already paid for. Treating every issue as a configuration problem buries real product opportunity. The routing is the work.

The engagement isn't finished. A second market is scheduled, leadership interviews are still running, and the current-capability assessment hasn't concluded. Nothing here is a validated enterprise-wide finding, and I've worked hard not to let a compelling pattern get promoted to a fact on the strength of being compelling.

What's true so far: the customer's opening question was answerable in a week and would have produced the wrong roadmap. The better question took two days in stores and cost a night of sleep.