Running discovery with people who don't want software

Product discovery advice is mostly written for consumer software, where users have chosen to be there. Operational discovery is different. You are interviewing people whose current process works well enough for them, who have seen previous systems arrive and leave, and who correctly suspect that your project has an efficiency number attached to it.

They are also the only source of the information you need.

Start by being honest about the number

The instinct is to soften the purpose: "we're just exploring how things work today." Nobody believes it. Everyone knows a system is coming, and pretending otherwise means every subsequent answer is filtered through a guess about your real agenda.

I have had far better sessions by opening with the actual brief — including the target. It costs you the pleasant fiction and buys you the rest of the conversation. People who know what you are optimising will tell you where the optimisation is naive, which is the single most valuable thing they can give you.

Watch a shift, do not book a workshop

Workshops produce the idealised process. What you need is the real one, which includes the workaround, the second spreadsheet, and the WhatsApp group that carries the exceptions.

You find these by being present during actual work, at the times when it is difficult — the busy shift, the handover, the incident. Ask the two questions that surface everything:

• "What did you have to do today that you would not describe as your job?"
• "When this goes wrong, who finds out first, and how?"

The second question maps the informal escalation network, which is almost never the one on the org chart, and which your system will either support or fight.

Treat the workaround as a specification

Every workaround is a requirement someone has already validated at their own expense. A shadow spreadsheet is a feature request with a working prototype and a year of usage data.

When you find one, resist the reflex to eliminate it as non-compliance. Ask what it protects against. Usually the answer is a real failure mode the official process does not handle, and if your system does not handle it either, the spreadsheet will outlive your launch.

Design so the first week is easier, not harder

Adoption is decided in the first week, by whether the tool made someone's day better or worse. If the honest answer is "worse now, better later," you will not get to later.

Concretely: pre-fill everything you can derive, make the common path fewer taps than the paper version, and let people finish a task with one hand while holding something in the other. These sound like polish. They are the difference between a system that gets used and a system that gets documented.

The signal that it worked

Not usage numbers — those can be mandated. The signal is when someone asks for a feature. That means they have started treating the tool as theirs, and at that point discovery stops being something you schedule and becomes something that arrives on its own.