technical use writing the unit tests in TDD -- looking for references

For our case, TDD's best benefit is problem definition: pins down the requirements and lays out what needs to be done in clear terms. these "clear terms" happens to be the code-- which is best suited as test unit(s). in our development team, the problem owners (PO)-- the ones defining a problem and issuing a ticket on it are very often technical developers and can express the requirements in code.

I’m looking for references on “someone else—not (necessarily) to resolve the problem writing the pre-development test units in the TDD(-like) approach.

the textbook definition of TDD suggests the developer to develop the code should also write the test units. And i agree that defining the problem to the point to write some test cases is part solving it-- it's nothing short of problem analysis. however, this wouldn't rule the option of "pre-development tests by another developer" all by itself. In the end –if the PO who wrote the tests feels that s/he has put enough time and might just as well develop it all the way thru, s/he can go for it. our development “dynamics” allows this.

The benefit we would get out of this is the elimination of ambiguity and the go-between due to this. We are a communicative team. However, we are inefficient in communicating the specs. test cases would constitute a common language with clear terms the PO and solution developer (SD) can use to talk the same thing. the PO writes some test cases to define the ultimate outcome and SD sees, at least to some extend, what needs to be done. every development team is different. ours needs this.

This isn’t a search for some test tools or other technologies to use in our process.

i'm looking references , blogs, articles, books(although i doubt books), opinions, previous experiences, etc. on pinning this down—practices/approaches that have been described and/or used somewhere in the literature or actual development environments.

TIA.