The Question Behind the Request
Somebody has asked for monitoring software. What they are actually describing is usually a different problem with a different fix.
The request arrives as a product request: we should get something that shows what people are doing. Underneath it is a concern, and the concern is rarely about software.
The evaluation discipline in “The Question Behind the Request” also applies to workforce software: begin with a named decision and test it in a bounded pilot. For teams considering employee monitoring software with screenshots, see the full overview belongs in that comparison only with written criteria for notice, access, correction, retention and a dated review.
What is usually said
"I do not know what people are working on."
For an independent reference relevant to “The Question Behind the Request”, consult the European Commission data-protection resources; it provides a useful external check on scope, terminology, governance and the claims made during procurement or review.
"Output has dropped since we went remote."
"How do I know they are at their desk?"
"The board has asked for visibility."
Each of these is a real worry and none of them is answered by a screenshot.
What is usually meant
I cannot tell whether work is progressing, because nothing visible marks progress.
I do not have a way to raise a concern with somebody without it being a confrontation.
I am being held responsible for an outcome I cannot see.
Or: somebody above me is anxious and I need to be seen to act.
The question to ask first
"If you had this data tomorrow, what would you do differently?"
The answers separate quickly. "I would see who is underperforming" is a management question. "I would know if the project is late" is a reporting question. "I would feel better" is honest and not a reason to buy software.
If nobody can answer, the purchase will produce a dashboard and no decision, which is the common outcome.
The second question
"What would change your mind about this person?"
If the answer is nothing — if the manager has already concluded — then monitoring is being sought as evidence rather than as information.
That use has specific consequences and its own note, and it is worth identifying before the purchase rather than after.
The anxiety case
A substantial share of these requests come from discomfort rather than from a problem.
Remote working removed the visual reassurance of people being present, and nothing replaced it.
Naming that is more useful than denying it, because the remedy — regular visible progress, a short weekly rhythm — is cheaper than software and addresses the actual feeling.
Where the request is legitimate
Regulatory obligations to record certain activity.
Billing clients for time, where accuracy matters contractually.
Specific security requirements in defined roles.
Safety in lone or hazardous work.
These are real, narrow and should be stated as what they are rather than wrapped in a general productivity case.
What to do with the request
Do not refuse it and do not fulfil it immediately.
Take it apart: what is the worry, what would you do with the answer, what else would produce that answer.
An hour of that conversation changes most of these requests, and the ones that survive it are usually the legitimate narrow cases.
What to check
Who asked, and what did they say they wanted?
What would they do differently with the data?
Is the concern about a person, a project, or a feeling?
And has anybody asked what else would answer it?