I researched after I wrote — the classic opposite of a research method

08 September 2026

Every research method I ever was or I have ever taught starts the same way: find out what others have done, learn from it, then improve on it. Of course, I did the opposite. I wrote the whole AI guide from my own experience, in one sitting, and only afterwards went to see whether any of it was original.

I did it in that order on purpose — or let’s say, there was a reason. The guide was never meant to be a research project. I had student teams who needed to start working, and I wanted to spend as little time as possible getting them there. So I set down what I had on top of my mind, sent them off with it, and left the reading for later.

Later has arrived now, and I got curious. I gave it about an hour, because I don’t have more time for this at the moment, although it is really interesting. And really, I just wanted to know how clever I really am — a brief summary of the novelty of what’s covered in the guide:

Here is what I found.

Treating AI as a team of specialists you direct — common. The scale from banned use to deliberate, declared use — most universities now have one; in fact I took it off a printout on the wall in the corridor (to keep my guide compliant, or at least aligned, with uni rules). Putting your AI use in the methods section — standard advice. Know your stage before you choose your tools — said elsewhere, more than once. Even the trick I was quietly pleased with, the appendix in which the guide documents its own making, turns out to be a small emerging genre.

I’ll admit I’d expected to be a little more clever than that…

Yet, I hadn’t copied any of it — I’d never seen most of it. I had arrived at the same places from the other direction: from having run the projects, not from having read the papers. A field of people working separately, arriving where I arrived, is not evidence that the thinking was thin. It’s evidence that it is probably not completely wrong — maybe even pretty good.

What the guide adds isn’t a new part. It’s bringing things together.

The management side — the team, the stages — and the academic side — the method, the record — are usually kept apart, one taught to founders and one to students. I put them in one document, pointed at doing the work well rather than staying out of trouble, and I ran it with real teams before I published it. That combination I haven’t found elsewhere. If it exists, please send it to me, and I’ll be happy to read it.

This post is part of Data on Deck - Picture yourself in Enterprise’s captain’s chair with a bridge full of Datas. (Or: How to Use AI in Your Project.)