Disciplines the architecture needed to support
Hardware product development work crossed multiple disciplines. The Jira model needed to support discipline-specific work while still giving product managers cross-product and cross-discipline visibility.
| Discipline | Example work |
|---|---|
| Electrical engineering | Board design, schematics, and validation. |
| Mechanical engineering | Enclosures, thermal, mounting, and physical design. |
| Firmware | Embedded software, device logic, and networking. |
| Product management | Roadmap, release scope, and phase tracking. |
| QA/validation | Testing, defects, compliance, and verification. |
Why the old Jira structure was hard to maintain
| Challenge | Impact |
|---|---|
| Product-named projects | Projects became fragile when products were renamed. |
| Manual fields | Inconsistent data entry reduced reporting quality. |
| Cross-discipline work | Electrical, mechanical, firmware, and QA work was difficult to track together. |
| PM reporting | Product managers could not easily see product-level progress. |
| Phase tracking | Development phase information was not consistently stamped. |
| Activity catalog | Existing activity framework needed to become Jira architecture, not loose tags. |
Standard field model
AtlasOptima recommended 12-15 standardized fields to support product, phase, discipline, activity, revision, release, and validation tracking. These fields made reporting more reliable and reduced dependence on product-named projects.
| Field | Purpose |
|---|---|
| Product ID | Stable identifier that survives product renames. |
| Product Name | Human-readable name that can change over time. |
| Discipline | Electrical, mechanical, firmware, QA, or product workstream. |
| Development Phase | Concept, design, prototype, validation, release, and similar stages. |
| Activity Type | Mapped from the internal hardware activity catalog. |
| Hardware Revision | Board or device revision tracking. |
| Firmware Version | Firmware dependency or release tracking. |
| Release Target | Planned milestone or release grouping. |
| Compliance/Validation Type | Certification or test category. |
Automation-stamped metadata
Automation reduced manual PM and designer overhead. Instead of asking users to maintain every reporting field by hand, Jira could stamp product, phase, discipline, release, and reporting metadata from structured selections.
| Trigger | Automation |
|---|---|
| Issue created with product selected | Stamp Product ID, current product name, and reporting fields. |
| Discipline selected | Route to discipline-specific board or team. |
| Phase updated | Update phase metadata and dashboard grouping. |
| Activity type selected | Apply standard labels, components, or reporting dimensions. |
| Product renamed | Keep reporting intact through stable Product ID. |
| Defect created | Classify defect source and support defect dashboards. |
| Release target selected | Add issue to relevant board, filter, or report. |
Reporting model
| Report view | Business question answered |
|---|---|
| Product dashboard | What is the current state of each product? |
| Discipline dashboard | What is electrical, mechanical, firmware, and QA workload? |
| Phase dashboard | Which products are blocked in each development phase? |
| Defect dashboard | Where are defects being identified? |
| Release dashboard | What work remains before release? |
| Cross-product report | Which products have the highest engineering risk? |
Before and after
| Area | Before | After |
|---|---|---|
| Product tracking | Product-named Jira projects vulnerable to rename issues. | Stable Product ID model. |
| Disciplines | Electrical, mechanical, firmware, and QA work difficult to report together. | Discipline-aware Jira model. |
| Activity tracking | Manual or inconsistent activity tagging. | 50+ activity catalog mapped into Jira. |
| Phases | Phase tracking inconsistent. | 6-8 phases mapped into structured fields and workflows. |
| Fields | Manual field entry and inconsistent values. | 12-15 standardized fields. |
| Automation | PMs and designers manually updating metadata. | 15-20 automation rules proposed. |
| Reporting | Hard to create product-level and discipline-level reports. | Dashboards by product, discipline, phase, release, and defect source. |
| Scalability | New products required structural decisions every time. | New products added through stable metadata model. |
What similar hardware teams should validate
Should product identity be modeled as a stable field rather than a Jira project name?
Which disciplines need separate workflows, boards, reports, or ownership rules?
Which product phases must be visible in dashboards and release reporting?
Which activity catalog values should become issue types, fields, labels, or components?
Which metadata can be automation-stamped to reduce manual PM and engineer effort?
Which dashboards must show product status, discipline workload, defects, release readiness, and cross-product risk?
How should product renames be handled so historical reporting remains stable?