No, it's a narrow mentality of what a product is. If you are writing code, that code interacts with humans in some way. It might not be a consumer or even B2B product, it might be strictly an embedded library that interacts with nothing except other code, but even that should be designed to meet the needs of the other programmers who have to interact with it.

A lot of programmers want to be handed concrete requirements so they can focus solely on implementation, but in practice this leads to gaps. A programmer who thinks beyond their immediate scope to the end-to-end context and human players involved where their code is executed will deliver far more value and avoid so many common disasters that happen when non-technical people are solely responsible for requirements.