The most useful sentence in any discovery

"This is a bit nuts, I know, but..."

A print button that logged you out

A few years ago we were sitting with a warehouse team during the early days of a project. The picker we'd ended up next to was running through her morning. She got to the part where she prints dispatch labels for the day's orders.

She clicked print. The legacy system she was working in offered her a PDF download. She saved it, opened it, hit print again from the PDF viewer — and the system logged her out. She went back to the login page, logged in, found her way back to the order list, scrolled to where she'd been, picked the next order, clicked print. PDF. Open. Print. Logged out. Back to login.

She did this — exactly this — about two hundred times a day.

Nobody had ever told us about it. Her line manager didn't know. The MD certainly didn't know. It hadn't appeared on any requirements list, in any workshop, in any of the four meetings we'd already sat through with the senior team. It was just the way the job got done.\

We poked around the system's settings for twenty minutes and found a checkbox somewhere about "force re-authentication after document export". Untick. Hit save. Done. We didn't build anything. We didn't bill them. We just fixed it.

That picker's day got materially better, that day. And every day after.

The bit that doesn't show up in workshops

We covered the macro version of this in the Tuesday-morning post — that the most useful knowledge in any operation is held by people who don't tend to speak up in big meetings. This post is about the actual craft of getting that knowledge out of them.

A few honest observations from twenty years of doing this:

Workshops surface the polite version of the problem. Eight people in a room, the most senior person there sets the tone, the rest answer the questions that get asked. Nobody volunteers the "this is a bit nuts" stuff because it makes them look like they've been doing something daft for years.

Requirements gathering surfaces the imagined-fix version of the problem. Ask a person what they need and they'll describe a slightly nicer version of the thing they currently have. They won't describe the real shape of the pain, because they've stopped seeing it.

Org charts hide the actual experts. The picker who knows about the print-then-relogin loop reports to a supervisor, who reports to an operations manager, who reports to the MD. None of those three layers above her have ever pressed her print button. None of them know.

What does work is sitting next to her, watching her press the print button, and asking "what just happened there?"

How to actually get someone to talk to you

This is where most discovery — even well-intentioned discovery — falls down. The mechanics matter.

Their space, not yours. You go to where they work. Not their meeting room. Their desk, their bench, their station. They're a guest in a meeting room and they behave like a guest. They're at home at their desk and they tell you the truth.

No laptop, no notebook open at the start. A laptop is an interview prop and they can tell. A notebook is the same with extra friction. Open hands, mug of tea, sit down. The notebook can come out later — once they're talking about the work, not performing for you.

Don't ask what they need. Ask what they did this morning. Ask them to walk you through the next thing they're going to do. Ask what was different about Friday afternoon. The good answers all live in the verbs, not the nouns.

Time, not pressure. People don't unload twenty years of small frustrations to a stranger in twenty minutes. The first session is mostly polite. The second is more honest. The third is where the real stuff lands. Most discovery efforts cut this short because it's commercially uncomfortable to spend that much time without producing a deliverable. The work of producing the deliverable later is enormously easier when you've spent the time first, though.

Visible patience. They will pause mid-sentence and check whether you've understood. They will half-apologise for what they're about to say. They will worry that they're going on a tangent. The right response to all of these is to nod, sit forward, and wait. People can tell when you're actually interested.

The sentence to listen for

Almost without exception, somewhere in the second or third visit, the moment lands. They'll be halfway through a description of something — usually something they've been doing for years — and they'll pause, and they'll say:

"This is a bit nuts, I know, but..."

That sentence is the entire reason you're there.

The thing they're about to describe will almost always fall into one of four buckets:

• A workaround they invented to compensate for software that doesn't quite do the job
• A repeated piece of work nobody upstairs knows is happening
• A piece of institutional knowledge that lives only in their head
• A small, maddening friction — like the print button that logged you out — that costs them an hour a day and has been costing them an hour a day for years

Until they said it out loud, they hadn't registered it as a problem. It was just the job.

What you do with it

Sometimes the answer is: build something. Most of the time, eventually, that's where the work lands — that's how we end up shipping the bespoke piece of software the whole engagement is for.

But sometimes the answer is: fix the print-button thing this afternoon.

That choice — not trying to bill for it, not writing it up as a requirement for the next phase, not turning it into a deliverable — is the bit that earns trust. Because for the picker who's been quietly losing an hour a day for years, the people who fixed it that afternoon are now the people she trusts. Next time we come back, she tells us things she's never told anyone. Next time her boss asks her how the project's going, she vouches for us. None of that was on the engagement letter.

The honest version: the small fixes you do for free in the first week of a project usually return more value to the engagement than any single deliverable. They're the bit that makes the rest of the work possible.

Trust isn't earned in the steering committee. It's earned at somebody's desk, twenty minutes after you noticed something was broken.

A version you can run yourself

If you're a business owner reading this, you don't need to hire us to do this work. You can do a real version of it yourself.

Once a quarter, give yourself an afternoon. Pick one person in your business who never says much in meetings — usually one of the longest-serving people in operations, or in the back office. Go and sit with them at their desk. No laptop. Don't tell them you're "doing discovery". Just ask them to walk you through what they're working on.

The first hour will be polite. The second hour, if you're patient, will not be.

You'll come back to your desk with three or four things you didn't know about your own business — and at least one "this is a bit nuts, I know, but..." moment that's almost certainly fixable, and has probably been quietly costing you money for years.

If after a few of those afternoons it turns out the fixes are bigger than something you can do in-house — or you'd rather have us run a structured version of it as part of a discovery sprint — say hello. We'd be happy to pick up where you left off.