Derived products can be used to achieve different goals. The general idea is that all attributes of the parent are derived to the child as long the child has no value set. As long the native getProduct function is used is a child product a completly normal product. In the handling there is no difference to a normal product, except that the parent_id is not 0. Users are often concerned that child products use too much resources, but due advanced caching methods, it most time even reduces the page load.
This can be used for product patterns. Just create an unpublished product, enter your default values and use the command "create child". Then just work with the children.
Before you start to enter your products, think about your product types. Very often vendors directly sell a bunch of similar products or it is even their speciality to sell only one kind of products. Similar products often need the same customfields. Sometimes you entered already 100s of products of one type and then you notice that you would like to add a hint to each product.
When you organized your products as children, then you can just edit the parent product to change all derived products.
Be aware that in VM2 the customfields are either completly overriden or not. If you want to override the customfields of your parent, click the checkbox on top of the customfield tab. If you want to have more controll over deriving of customfields, you need VM3. There you can decide per customfield.
As fully customisable Variant
The other purpose are different variants of one product. Just create a customfield "Generic child variant", use layout position "ontop", and add it to your parent product.
Now you see a dropdown in your product to select another product. If you select an option, the whole new product is loaded. So you can change the image, price, description, customfields, weight, dimensions, and so on. It is a competly new product.
Remind, the sample data contains also a tutorial in product description