Product specification (mandatory). Written by the project manager and/or engineers, for the benefit of engineers (a technical document). When done correctly, this should be a live document to revisit and update. It should also be the foundation from which all product testing is based upon.

May be as detailed or as brief as required, depending on the product. In case of safety-related products, you would also do a risk assessment early on to determine what safety functions there are and these need to be listed in the specification.

Time schedule and budget (optional). Often you write a document with a time frame and deadlines. If there's a development cost budget, this needs to be made clear early on by the manager, as it may affect tool choices etc. Engineers also need to know an estimate of manufacturing cost/unit.

Schematics and Bill of Materials (BoM) (mandatory). Component selections should be based on the specification. Electrical engineers are responsible for most/all of it. If there are dedicated software engineers, they are often responsible for picking MCU + programming tool chain and MCU pinout. As an engineer, you must be able to have a rationale for why every single component was picked.

The schematic must be available in pdf and ideally made in the preferred EDA, so that it is connected to the layout. There must be a part number for all component 1st source and ideally also 2nd source.

References to RoHS compliance and similar might have to be part of the BoM.

There may be a complete product BoM including mechanical parts and then the PCBA is usually listed as single component/subsystem in that one.

PCB layout + manufacturing files (mandatory). Made by the electrical engineer(s) in an EDA. A board outline pdf with component placement should be available to everyone.

For PCB manufacturing, PC files must be generated from the EDA regarding the PCB "stack-up" layers, drill holes/vias, mechanical outlines, silk screen etc etc ("gerber files" is a an industry standard for all of this). For assembly, "pick & place" files in case of SMD are also required.

Design documentation (mandatory/optional). Ought to be mandatory but this comes in diverse forms, if at all. Some documentation regarding how the product was designed, how it works, what supply and inputs/outputs it can handle etc. How detailed it is might depend on the complexity of the product. There are different audiences for such documentation: development/test engineers, test houses/authorities and production staff.

• For development/test engineers (including yourself in the future) it can get deeply technical and as detailed as required. For test houses, they need a product overview about how the product works, what it does and what's the intended environment. Both internal and external product tests would be based on this, as well as the specification. How tests are to be carried out and the results of the tests should be documented, but by whom depends on the organization.

• Authorities expect a technical file, which is essentially all of the mentioned documents here together.

• The production needs to know assembly instructions, programming and calibration instructions etc.

Product conformance documentation (mandatory). This would be test reports from a test house, or your in-house equivalents if allowed/applicable. Depending on where in the world the product is used, you will need a FCC/CE etc declaration of conformity mentioning which parts of product directives and/or standards it conforms to.

User manual (optional). This may be written by engineers or by other staff, but at least the engineers are expected to provide raw technical input to it. If the previously mentioned designed documents are detailed/suitable enough, they may act as that input.

Product specification (mandatory). Written by the project manager and/or engineers, for the benefit of engineers (a technical document). When done correctly, this should be a live document to revisit and update. It should also be the foundation from which all product testing is based upon.

May be as detailed or as brief as required, depending on the product. In case of safety-related products, you would also do a risk assessment early on to determine what safety functions there are and these need to be listed in the specification.

Time schedule and budget (optional). Written by the project manager, if there is one. Otherwise engineers are often expected to write this. Often you write a document with a time frame and deadlines. If there's a development cost budget, this needs to be made clear early on by the manager, as it may affect tool choices etc. Engineers also need to know an estimate of manufacturing cost/unit.

Schematics and Bill of Materials (BoM) (mandatory). Component selections should be based on the specification. Electrical engineers are responsible for most/all of it. If there are dedicated software engineers, they are often responsible for picking MCU + programming tool chain and MCU pinout. As an engineer, you must be able to have a rationale for why every single component was picked.

The schematic must be available in pdf and ideally made in the preferred EDA, so that it is connected to the layout. There must be a part number for all component 1st source and ideally also 2nd source.

References to RoHS compliance and similar might have to be part of the BoM.

There may be a complete product BoM including mechanical parts and then the PCBA is usually listed as single component/subsystem in that one.

PCB layout + manufacturing files (mandatory). Made by the electrical engineer(s) in an EDA. A board outline pdf with component placement should be available to everyone.

For PCB manufacturing, PC files must be generated from the EDA regarding the PCB "stack-up" layers, drill holes/vias, mechanical outlines, silk screen etc etc ("gerber files" is a an industry standard for all of this). For assembly, "pick & place" files in case of SMD are also required.

Design documentation (mandatory/optional). Ought to be mandatory but this comes in diverse forms, if at all. Some documentation regarding how the product was designed, how it works, what supply and inputs/outputs it can handle etc. How detailed it is might depend on the complexity of the product. There are different audiences for such documentation: development/test engineers, test houses/authorities and production staff.

• For development/test engineers (including yourself in the future) it can get deeply technical and as detailed as required. For test houses, they need a product overview about how the product works, what it does and what's the intended environment. Both internal and external product tests would be based on this, as well as the specification. How tests are to be carried out and the results of the tests should be documented, but by whom depends on the organization.

• Authorities expect a technical file, which is essentially all of the mentioned documents here together.

• The production needs to know assembly instructions, programming and calibration instructions etc.

Product conformance documentation (mandatory). This would be test reports from a test house, or your in-house equivalents if allowed/applicable. Depending on where in the world the product is used, you will need a FCC/CE etc declaration of conformity mentioning which parts of product directives and/or standards it conforms to.

User manual (optional). This may be written by engineers or by other staff, but at least the engineers are expected to provide raw technical input to it. If the previously mentioned designed documents are detailed/suitable enough, they may act as that input.