A idéia do TDD é começar com testes e trabalhar com isso. Assim, para tomar o seu exemplo de "Um catálogo precisa ter uma lista de produtos" poderia ser visto como tendo um teste de "Verificar os produtos no catálogo" e, portanto, este é o primeiro teste. Agora, o que contém um catálogo? O que contém um produto? Essas são as próximas peças e a ideia é juntar alguns pedaços que seriam algo como um ProductService que nascerá depois de fazer o primeiro teste.
A idéia do TDD é começar com um teste e depois escrever o código que faz o teste passar como o primeiro ponto. Os testes unitários fazem parte disso sim, mas você não está olhando para o quadro geral que é formado começando com os testes e, em seguida, escrevendo o código para que não haja pontos cegos neste ponto, pois ainda não existe nenhum código.
Tutorial de Desenvolvimento Orientado a Testes , onde os slides 20-22 são os principais. A ideia é saber o que a funcionalidade deve fazer como resultado, escrever um teste para ela e depois construir uma solução. A parte do design irá variar dependendo do que é necessário, pode ou não ser tão simples de fazer. Um ponto importante é usar o TDD desde o início, em vez de tentar introduzir tardiamente em um projeto. Se você começar com os testes primeiro, isso pode ajudar e é provável que seja digno de nota. Se você tentar adicionar os testes mais tarde, isso se tornará algo que pode ser adiado ou atrasado. Os slides posteriores também podem ser úteis.
Um dos principais benefícios do TDD é que, começando com os testes, você não está preso a um design inicialmente. Assim, a ideia é construir os testes e criar o código que passará esses testes como uma metodologia de desenvolvimento. Um Big Design Up Front pode causar problemas, pois isso dá a idéia de travar as coisas no lugar que faz com que o sistema seja construído para ser menos ágil no final.
Robert Harvey adicionou isso nos comentários que vale a pena declarar na resposta:
Unfortunately I think that this is a common misconception about TDD: you can't grow a software architecture by just writing unit tests and making them pass. Writing unit tests does influence the design, but it doesn't create the design. You have to do that.