Ways to use this in the workplace.
Everything else on this site is about one person and their conditions. This series is about putting that to work at work, one usable idea at a time, and it will grow as the research does.
Five ideas transfer cleanly from the research to the workplace. Each comes with the kind of error it catches, because a method you cannot picture catching anything is decoration.
1. When someone is not doing the thing, look at the conditions before you look at the person
The core move on this site is that we observe someone under conditions we created, then mistake the response for a property of the person. That happens in businesses constantly and it usually sounds like a personality assessment.
A scenario, and a common one. Someone is told for months that outreach is their top priority, and building keeps happening instead. The diagnosis on file is about character. Chooses the comfortable work. Lacks discipline. Rules get written to fix them, and the rules do not hold.
Now look at the conditions. Outreach means reaching people who answer phones between nine and five. The hours this person actually has free fall after seven. The rule asked for daytime work at night, which is not a discipline problem, it is a scheduling impossibility, and every failed attempt gets read as weakness when it is the same structural fact showing up again.
The useful version of this question in a business is not why won't they do it. It is when exactly could they have done it, and with what. If the honest answer is never, no amount of coaching fixes it, and everyone involved has been quietly concluding something false about a person for months.
2. Ask what the number is a number of
Observation This is the habit that has paid for itself fastest, and it costs nothing. Across two research passes for this site, headline figures kept turning out to be something other than an effect. A count of how often researchers mentioned a factor, read as proof that factor mattered most. A list of which accommodations were most commonly used, read as which ones worked. A median cost calculated only among the quarter of people who could name a cost. A spread of averages standing in for a spread of people.
The workplace version is the load-bearing number nobody has traced. Most plans have one, a market size, an adoption rate, a cost per unit, that every projection quietly multiplies through. Trace it and a surprising share of the time it turns out to be a placeholder someone once wrote down to make a spreadsheet run, and the plan looks exactly as rigorous with the invented number in it as it would with a real one.
Try it on any business number you rely on. Revenue per customer, engagement, pipeline, utilisation. Ask what was counted, by whom, among which people, and what got excluded. The number survives that question or it does not, and you find out in about ninety seconds.
3. Grade what you actually know, in writing, next to each claim
Every claim on this site carries a label saying how much weight it can hold. Evidence, Suggestion, Hypothesis, Observation, Question. It is the most useful thing I have built here and it transfers to a plan without modification.
Take any strategy document and mark every sentence as measured, reported by someone else, or assumed. Most plans have never been through that pass and it is uncomfortable the first time, because the assumed sentences are usually the load-bearing ones. That is the point. A plan where the assumptions are labelled is not weaker than one where they are hidden. It is the same plan, honestly described, and you can now see which parts to go and check.
4. Write down what you expect before you look
After anything happens, you will have a story about why, it will feel true, and you will have no way of knowing how much of it was assembled to fit the outcome. This is as true of a product launch as it is of a person.
So write the prediction first. Before the campaign, before the feature, before the hire. What specifically do you expect, how much, by when. Then it can turn out wrong, which is the whole value. A prediction you cannot fail is not a prediction, it is a mood.
The version of this with real evidence behind it is the premortem, and it is the one genuinely good item I have found in the productivity content that circulates online. Before starting, imagine the project has failed completely and ask why. It works because it is the rare business exercise that assumes you will be wrong.
5. Change one thing
Hypothesis Not a research finding, just arithmetic. Change the pricing, the copy and the audience in the same week, watch the number move, and you have learned nothing about which of the three did it.
An example of how this fails quietly. A team sees social posts getting reach and almost no clicks, so they test a better destination page. Nothing changes, and the audience gets blamed. The actual reason is that the platform never made links in that position tappable at all, so there was no click to win regardless of where it pointed. A clean test, run on the wrong variable, producing a confident and false conclusion about people.
Before testing anything, the cheap question is whether the thing you are changing is even connected to the outcome you are watching. Often it is not, and the test is dead before it runs.
The one that matters most, and it is the same one
All five reduce to a single question. Is the thing you are measuring the thing you care about?
Clicks are not interest. Utilisation is not contribution. Hours logged are not work done, and the day someone spends on the hardest problem may well bill less than the day they spend on something straightforward. Intent to leave is not leaving, and the gap between them is where a lot of confident retention claims live. Every one of those substitutions is made because the easier thing is what the system already records.
That is the same error this whole site is about, wearing a suit. A person is judged on how they performed in a room somebody else chose, at a time somebody else set, and the result gets written down as a fact about them. A business does the identical thing to itself with whichever number its software happened to collect.
Where this stops. None of the five items above is a research finding about people. They are reasoning about measurement, and observations from this project’s own verification work, illustrated with scenarios. The scenarios describe common failures, not studies, and nothing here is a finding about businesses in general.
What I have not tested. Whether any of this works as advice. Nobody has run a trial on whether teams that label their assumptions make better decisions, and I have not looked for one. If you try it and it does nothing, that is worth telling me.