The Questions a Reviewer Asks About Your Work Sample

What reviewers look for in a BA work sample, in the order they look for it: seven questions across twenty minutes, and what stops the read at each one.

Numbers in this note carry source tags ([POLICY], [THREADS n=10], [MINE]). What the tags mean.

Someone sends me a work sample and I give it twenty minutes. I have been on the other side of those twenty minutes too, which is the more useful half. Everything below is worked on the returns case published on this site: returns and complaints at a mid-size online retailer, built only from the published returns policy, its help centre articles, ten public complaint threads I picked myself, and a walkthrough of the published journey as far as it goes without placing a real order. No client, no engagement, no interviews, nobody inside that company asked anything. I use it because I can show you every objection it collected without redacting a word.

A review of a work sample is a sequence of questions asked in a fixed order, where each answer decides whether the reader asks the next one. That order is the thing nobody tells you about, and it is why a strong document can be closed after ninety seconds.

In short

• The read runs as a sequence with stoppers in it. A sample only reaches question four if one to three came back clean.
• The first two minutes go on provenance and on the decision you are asking for, which is why the summary page belongs at the front and the model does not.
• The review log answers the one question a finished draft cannot, and it is the artifact almost nobody sends.
• The filled table and the blank one are below. Run your own sample through the blank one before somebody else runs it through theirs.

What do reviewers look for in a BA work sample?

Not completeness. Completeness is easy to fake and boring to check.

What I am hunting for is seams. A document written by somebody who did the work has visible joins: a place where two sources disagreed, a number that got labelled rather than rounded, a branch added late because someone pushed back. One assembled from a template has none of that. Every heading present, every sentence smooth, nothing that had to be earned.

So the questions run in an order built to find seams fast and stop early when there are none. Below is how my own twenty minutes go. The clock is mine rather than a standard; the order is the part I would defend.

The reading order, filled in on the returns case

Two things there matter more than the rows.

Four of the seven stoppers are about honesty rather than skill, and three of those end the read before minute six: a detail you were not free to publish, a figure that turned out to be an invention, and a sample with nothing open in it. From outside a company, answering every question is not possible, so a sample with no open questions says you either missed the gaps or filled them with plausible guesses.

And the order is the reverse of the one you wrote in. You built the model first and the summary last. Lay the file out in production order and the first thing I open is a diagram with no argument attached to it.

Minute four: what does the review log say that a finished draft cannot?

A review log is a short table recording what somebody objected to, what changed as a result, and what did not change and why. Three to six rows, half an hour to keep, and it is the artifact I open before the requirements.

The reason is narrow. A polished draft tells me you can produce a polished draft. It cannot tell me what you do when somebody who knows more than you says the thing is wrong, and that is the behaviour being hired. A log answers it, and it is close to impossible to fake, because invented objections are soft. They are the ones you already knew how to answer.

Here is what came back on the returns case. Two readers, asked for objections rather than the compliment after a self-review against the scorecard: a developer on the delivery side who reads process models before registers, and a business analyst who reviews requirements documents for a living. Neither works for the retailer. Two sessions, 2 and 6 April 2026, five rows in all, and three of them show what a log does that a draft cannot.

Row one. "Your as-is is the happy path, so your to-be looks better than it is." The developer, ten minutes into a session that started with the model and never reached the register. My first as-is ran call, evidence, decision, refund, and stopped. What changed: the parked branch went on to the model, with no owner, no clock and its frequency marked unknown. That one sentence produced more than my own second pass had. REQ-015, escalation ownership, did not exist before it, and neither did BR-12, the rule naming who owns a missed window.

Row two. "A customer whose parcel never arrived has nothing to photograph." The business analyst, four days later. My proposed process routed everything through a form built around photographic evidence, which quietly made one group worse off, and it was the group least able to argue about it. What changed: non-delivery and lost parcels are out of scope now, with a reason and an owner. What did not: the placement. It went in the scope table rather than into a fourth acceptance criterion, because an exception you exclude on purpose is a scope decision and belongs where a reviewer will look for it.

Row three, the one that earns the table its fifth column. "Four in ten is a count, not a rate." I had ten complaint threads I picked myself, four of which ended with nobody owning the case, and two pages after my own source table called those threads unrepresentative, I had written a sentence about all cases. What changed: every use of the figure now names the denominator, the selection method and the date. What did not: the number. The stronger objection was to cut it and say only that the branch exists. A labelled count can be rechecked by a stranger in twenty minutes, and a shrug tells the reader less. The disagreement stands in the log, where a future reader can find out that somebody competent thought I was wrong.

The log closes with a line that takes ten seconds to write: v1.2, 9 April 2026, two peers, two sessions, five objections raised, four accepted, one held with reason. Set that against the seven questions above. It settles provenance, it dates the document, and it says the argument happened before the version in my hands. Three of the seven, at the bottom of a table.

The common failure is the log where every row was accepted. That shows compliance, and compliance is not what is being assessed. You can be wrong in the fifth column and still finish ahead of the person who has no fifth column.

The blank version, for your own sample

Copy this and run it against a document you have already written. Twenty minutes, alone, before anybody does you the favour.

The fourth column does the work. Fill in your stoppers before the answers, because the ones you cannot bring yourself to type are the ones a stranger reaches first.

Where to start

Take the sample you already have and do three things to it, in this order.

Move the summary page to the front and rewrite its first line so that it asks for a decision, names who makes it and carries a date. Add the log, even if the only reviewer so far is you two days later, marked honestly as a self-review. Then run it through the scorecard: twenty-five checks across six artifacts, free, no email address asked for, and check 20 is the one about holding your ground.

The worked case and the blank templates behind it are in the Proof Pack. If you are still deciding what to build, the six artifacts a reviewer looks for comes first.

Then send it to one person who will tell you it is wrong, and write down what they said before you answer them. Whatever lands in their first two minutes is what your reader was going to hit anyway. This time you get to fix it first.

All field notes · The portfolio guide · More in The Case File