I think you can reduce (abstract?) the number of role further: - Builders. This would be software developers in the I.T. world. - Users. Regardless of what

I think you can reduce (abstract?) the number of role further: - Builders. This would be software developers in the I.T. world. - Users. Regardless of what their specific domain expertise (or lack) is in, those who utilise the system. - Maintainers. Those who fix what's broken. "Repair techs" from the world of complex machinery, "software maintenance" in I.T. Possibly also: sales & marketing, who describe and position the products, management, who oversee general operations, and logistics and/or operations, who fit the pieces together and support them outside general maintenance (an I.T. analogue might be DevOps or systems admins roles). Each of these has their own perspective, goals, relationship, and set of concerns with the system. And whilst there may well be levels of expertise within each role, there's a larger set of uniform and consistent concerns and relationships each addresses as well. In complex physical kit, you'll generally see such roles expressed as engineering, manufacturing, marketing, (customer) operators, logistics, maintenance (on-site repair and adjustments), and sales & marketing, or terms to that effect. The roles typically exist within software and information products as well, though of course not all physical analogues map directly. Within a complex product, you'll have the user interface, a maintenance or technician's interface, component-level design (which may or may not be designed for field maintenance), demo modes and marketing collateral (for sales/marketing), and considerations for the actual construction, packaging, and logistics supply- and delivery-chain support for the devices, etc. Each of these is effectively a level of abstraction onto the end product.