Journal · Operations
What makes a better business question
A report is only as good as the question behind it. Most questions put to a business system are too vague to act on, and that is fixable before any software changes.
This piece is outlined and not yet written. The sections below are stubs. Published structure, dek and metadata are close to final; the prose is not. Target length is 1200 to 1500 words, per the month-one content plan.
Ask a business system a vague question and it will answer. That is the problem. The answer arrives formatted, totalled and apparently authoritative, and nobody can do anything with it, because the question it answered was not one that had a decision attached.
The companion to this piece, The questions you stopped asking, is about how a business loses access to a question it used to be able to ask. This one is about the questions that were never worth asking in the form they were put, and what a better form looks like.
A question with no decision behind it is a report request
Stub. The first test. If no plausible answer would change what anybody does on Monday, the question is reporting, not inquiry. Worked contrast: "how were sales last month" against "which of last month's orders made less than they cost to fulfil".
The four tests
Stub. Each to be written out with a before and after pair drawn from ordinary operating work, not from any client's figures.
| Test | The question fails if |
|---|---|
| Decision | No answer would change an action |
| Unit | It does not name what is being counted, per what |
| Boundary | It does not say over which period, or for which part of the business |
| Falsifiability | No answer could turn out to be wrong |
What the data has to carry before the question can land
Stub. A better question usually fails on the data rather than on the asking, and the failure is specific and findable: a missing key between two records, a date that records when something was entered rather than when it happened, a cost captured at the wrong grain. This section names the three or four usual ones and how to check for each.
Asking more of your data
Stub. The upgrade ladder. From counting, to comparing, to attributing, to predicting, with the honest note that most operating businesses have not finished the first rung and that the later rungs are not worth buying before the earlier ones work.
What this does not prove
Stub, and it ships in every piece. A better question does not make a thin dataset answer it. The tests above sort questions; they do not create records that were never kept. And a question that passes all four can still be the wrong priority for the quarter.