This hasn't seen an airing in a while, because it became accepted wisdom years ago. You're encouraging a bad design that the world has learned better than to employ.
This way, the DLL will be somewhere (usually a "Bin" subdirectory) within the application's own subtree rooted at "\Program Files\company\product\".
This plainly shows just how poorly thought-out Windows is, to paraphrase:
we didn't design a directory tree like UNIX, and we don't have a proper runtime linker like UNIX, so we are going to swipe using the bin/ directory like on UNIX because we don't know where else to put stuff, and while we're at it, we will rename bin/ to Bin/ because we don't know any better, and also while we're at it, we'll dump all the dynamically linked libraries which the application needs into that mis-named Bin/ directory.
Because Windows doesn't have a proper operating system structure, nor does it have a clean structure (case in point C:\Program Files (x86)\, even if your Windows is 64-bit), nor does it have a runtime linker with the functionality equivalent to ld.so.1 (the only way to get anything close to -Wl,-R/opt/local/lib/64 out of LINK.EXE is to use an XML manifest(!!!), and $ORIGIN keyword's functionality of ld(1) is science fiction for LINK.EXE).
How amateurishly bad can one get? Wintendo is a gift that just keeps on giving...
* http://jdebp.eu./FGA/dont-put-your-dll-in-the-system32-direc...