I think of it as software and hardware. The assembly line produces a spectrum of hardware with two very tall camel humps whose mean is "male" and "female." The hardware is all the physical stuff, not just sex organs but also brain wiring, etc. The important thing is it varies because the assembly line is really complex (and because nobody designed it, but that's a different issue...). The gender "humps" aren't distinct models, but they are hardware configurations that have a high probability.
Next the release management team loads the software. Again, the software is a spectrum with a distribution very much like the hardware. Typically the configuration matches a hardware configuration that is in the locality of the "male" hump with a software configuration that is in the locality of the "male" hump. But there's variance, and sometimes the mapping is way off or even the opposite of the expectation. To make it more complicated, since the software is manifested in physical material and processes that live in the same natural medium as the hardware, the two constantly interact and modify one another, at least around the edges. (The analogy breaks down here, or perhaps the "software" is better thought of as firmware.)
Finally, the product gets released and programs start running on it. The programs perform IO with the outside world, but the software/firmware is extremely malleable and learns based on inputs. One of the most important input streams relates to perceptions of gender, so for example if the machine displays male hardware and seems to be delivering outputs characteristic of female software, this causes a lot of dissonance. Part of the hardware/firmware/software configuration is the material substrata that gives the machine consciousness and self-perception, and it has an enormous set of routines for dealing with this dissonance, including modifying its own software to adhere more to expectations associated with the hardware. The selection of these routines is also dependent on the external stimulae -- for example the subroutine that accepts inputs from the "father" unit physically battering the machine for liking flute rather than drums. (The father unit obviously was built the same way and has been dealing with its own software lifecycle).
Trans people, to me, are running x-ish software on y-ish hardware and, rather than follow the hitherto socially popular routine of forcing the software to adhere to the hardware, want to do the opposite. As gendered expectations based solely on hardware fade, more machines will probably be perfectly happy with their initial configuration, since the "mismatching" won't carry negative inputs.