Ok, thanks for the clarification, the problem is your understanding of what a snapshot is - it's not what you think it is. Say you have a disk without snapshots, when you create a snapshot all that happens is that new file is created by the hypervisor with JUST the changes to the base disk that have been made since the snapshot, the hypervisor then only sends to the guest operating system the correct data from either the base disk (if that bit of the disk hasn't been changed since the snapshot) or the data from the snapshot file (only if that bit of data has been changed since the snapshot was created). So JUST sending the snaphot file would only include the changed data and be of little or no use on its own - is that ok?
That said what you're actually trying to achieve is very straightforward, just shutdown your VM and select 'Save to OVF' from the File menu, this will then allow you to save the VM in a hypervisor-gnostic format called OVF that you can then transfer to whoever you like. They can then import that OVF file into whatever hypervisor they have (i.e. it doesn't have to be VMWare Workstation). This file will contain the VM saved at the point of shutdown, if needed you could then remove the snapshots as required on your own machine and continue your work.
Here's a (quite poor) diagram I just created;
In this example we have only four data 'blocks'/locations - numbered 1 to 4. As you can see each 'block' contains a bit of data (a single number in this case). We then create snapshot number 1 and change the data in 'blocks' 1 and 3 (to 101 and 75 in this case). At this point if the OS reads 'block' 1 the response from the hypervisor is 101, not 100, and 75 not 50 for 'block' 3, but the response for 'blocks' 2 and 4 remain 200 and 25. If we remove snapshot 1 then everything goes back to the values in yellow. If we create a second snapshot and write the number 102 into 'block 1' then that 'block' and ONLY that block is updated in the second snapshot file, if we read 'block' 3 it refers back to the first snapshot file to get that data and to the base file if we wanted to read 'blocks' 2 and 4. If we save/export the VM at the 'Snap 2' point it will create a single file with the blocks written at that point (i.e. 102, 200, 75, 25).
Now obviously in any situation where the VM snapshots there can be a performance hit for disk IO as there can be multiple reads and writes to disk to achieve this snapshotting mechanism. In fact the more snapshots and the more changes per snapshot the bigger the performance hit can be. That said there comes a point when if a very large amount of the disk has been written to as part of the current snapshot where the performance hit will lessen as almost all IO will be going to the snap file, but that should be avoided really if you can. In fact VM snaps are a bad idea to live with for long as the time taken to remove them (which just really writes changes back to the basefile or an intermediate snap file) gets longer the more change has occurred since the snap. As a rule I don't like snaps existing for longer than 24/48 hours but in a desktop environment that can be stretched a little.
By the way, this mechanism is pretty much how all snapshotting methods work (It can be a bit different in NetApp's WAFL file system and ZFS but it's a good basic understanding at least) in all hypervisors.
Is this clear? If not maybe take a look at the manuals, they're pretty clear.