You must have been dealing with the government where the first part of the production run is sequestered for operational testing. No time like after production starts to find out if everything works. That's why every few years we pay for a block upgrade to fix the things that didn't work right on the production models.
Dilbert's statement is career limiting. If only the tech guy/gals would develop the people skills to move into the roles that impact the companies decision making then the companies would be better for it. Here is the types of company managers that I have seen over my career. In my opinion as you go down the list their ability to make good decisions and lead gets worse.
Peter principle: Technical and non-technical people rise to their level of incompetency.
Dilbert principle: Business degreed people are placed as managers due to the MBA or other degree without working in the industry and understanding the business or customers or how to lead people.
Gestapo principle: Degreed people technical and/or business that have no management skills, leadership skills, business skills and due to that, have nothing to do all day but try and catch someone doing something that they preceive as wrong even though they have provided no direction. These people are usually in a goup, with similar lack of skills, that are connected to the top management, with the only tools to manage are fear and intimidation.
I don't want to work where you work, if you have the idea that releasing untested software and hardware is the correct way to go, change of requirements nonwithstanding. You don't skip testing just because you'll need to change the features anyway, is like stopping bathing because you'll get dirty again.
Sorry if that sounded preachy, it remembers me too much of the common practice of "release it now, patch it later"...
Dilbert is here advocating a "waterfall" model where design, test, production occur in strict sequence. For hard products with expensive setup for production (like a car, for instance), this is probably optimal. For software, however, and for hardware products that can be produced "on demand", the PHB and blonde guy have the right idea. Customer requirements always change - because the customer doesn't know exactly what they want until they start using it. So you need to design a flexible framework that can handle constant changes to requirements. I believe this is called "agile" programming.
When writing software to handle government paperwork (our company does import/export), the requirements change weekly with every politicians sneeze. It is job security, like tax programs that need updates every year.