Beyond just thinking of one thing, one paradigm of TDD is to write the least code possible to pass the test. When you write one test at a time, it is much easier to see the path to writing just enough code to get that test to pass. With a whole suite of tests to pass, you don't come at the code in small steps but have to make a large leap to make them all pass in one go.
Now if you don't limit yourself to writing the code to make them all pass "in one go," but rather write just enough code to pass one test at a time, it might still work. You'd have to have more discipline to not just go ahead and write more code than you need, though. Once you start down that path, you leave yourself open to writing more code than the tests describe, which can be untested, at least in the sense that it isn't driven by a test and perhaps in the sense that it isn't needed (or exercised) by any test.
Getting down what the method should do, as comments, stories, a functional specification, etc., is perfectly acceptable. I would wait to translate these into tests one at a time though.
The other thing that you can miss by writing the tests all at once is the thinking process by which passing a test can prompt you to think of other test cases. Without a bank of existing tests, you need to think of the next test case in the context of the last passing test. As I said, having a good idea of what the method is supposed to do is very good, but many times I've found myself finding new possibilities that I hadn't considered a priori, but which only occurred in the process of writing the tests. There is a danger that you might miss these unless you specifically get in the habit of thinking what new tests can I write that I don't already have.