A product engineering system is the framework that connects the three phases every hardware product passes through: engineering, manufacturing and operations. RND Square calls these Shape, Scale and Sustain. Shape covers concept to validated build. Scale covers the transition into volume production. Sustain covers the product once it is in the field. Together they form one continuous lifecycle rather than three disconnected handovers. 

Most hardware companies have three systems that do not talk 

Look at how a typical connected-hardware company actually operates. 

Engineering keeps schematics, layouts, firmware and BOMs across a shared drive, a Git repo and someone's laptop. Manufacturing works from files emailed to the EMS, tracks test results in Excel at the contract manufacturer, and keeps rework notes in a notebook on the line. Operations runs a support inbox, a ticketing tool and a device dashboard that has no idea which board revision it is talking to. 

Each of the three functions well enough on its own. The failures happen at the seams. 

A revision changes and manufacturing keeps building the old one. A unit fails in the field and nobody can tell whether it was reworked at production. A BOM alternate gets substituted and engineering finds out three months later during a debug session. Every one of these is a handover problem, not a competence problem. 

The product engineering system exists to remove the seams.

Shape, the engineering suite 

Shape covers everything from the initial idea to a validated, releasable design. 

This phase owns requirements, architecture, schematic and layout revisions, mechanical files, firmware development, the bill of materials, risk documentation and design validation. Its output is not a prototype. Its output is a released, reviewed, versioned file set that another organisation can build from without asking questions. 

The measure of a healthy Shape phase is simple. If your design engineer left tomorrow, could a competent EMS build the product correctly from what is in the system? If the answer requires a phone call, the Shape phase is not complete. 

Practically, Shape needs hardware version control that works for engineers who do not use Git, a risk register that links to design artifacts, a BOM with validated alternates, and a formal release state that separates draft work from approved work. 

Scale, the manufacturing suite 

Scale begins the moment the design leaves engineering and becomes a repeatable build. 

This phase owns variants, production lots, file allocation to manufacturing, test firmware, test plans, station-level test execution, serial number provisioning, rework records and yield data. Its input is a released file set. Its output is a traceable unit with a complete build history. 

The most common Scale failure is not a bad board. It is a build with no record. A thousand units ship, ninety-nine percent pass, ten are reworked, and none of that is written down anywhere a future engineer can find it. 

Scale also owns the return path to engineering. When a component goes out of stock mid-build, the production team needs a documented route to request an engineering change, and engineering needs a documented route to answer it with a new released BOM. Verbal decisions at this boundary are how untested alternates end up in shipped product

. 

Sustain, the operations suite 

Sustain covers the product from the moment it leaves the factory. 

This phase owns device monitoring, firmware over-the-air updates, provisioning, warranty status, RMA processing, support tickets and field failure analysis. Its input is a traceable unit. Its output is a maintained fleet and, critically, a feedback signal back into engineering. 

Sustain is where most PLM tools stop being useful, because traditional PLM was designed for a world where the product stopped changing at shipment. Connected hardware does not work that way. A device in the field has a firmware version, a configuration, a connectivity state and a failure history, and all of those need to be linked back to the board revision and the production test record. 

That link is the entire value of the framework. When a unit comes back with a fault, you should be able to see its BOM revision, its test results, whether it was reworked, which firmware it shipped with, which firmware it is running now, and whether any of its siblings from the same lot have failed the same way. 

Why the three phases have to share one data model 

The reason to treat this as one system rather than three tools is that the questions worth answering cross all three. 

• Did the risk we logged in engineering actually get tested in production? 
• Was this field failure caused by a design issue, a manufacturing issue, or a component substitution? 
• Which lots contain the untested BOM alternate we approved under time pressure? 
• Did the firmware that shipped on this board match the firmware allocated to that production lot? 
• How many units in the field share the revision that just failed certification? 

None of those can be answered by a tool that only sees one phase. They can only be answered when the design artifact, the production record and the field device are the same object viewed at different points in time. 

How S3Suite implements the framework 

S3Suite is built as three connected suites that share one project map. 

• Engineering Suite: project map, hardware version control, risk management, BOM health scoring, firmware releases, reference vault, bug reports. 
• Manufacturing Suite: variants, production loads, file allocation gates, Station Kiosk test execution, checklists, auto serial numbers, rework and yield records, engineering change requests from the line. 
• Operations Suite: device monitoring, OTA updates, provisioning profiles, warranty handling, RMA processing and technical support, all resolved against the unit's own build history. 

Ask Square AI sits across the three, so a question like "what changed between the lot that is failing and the lot that is not" is answerable from one place rather than three exports. 

This framework is not specific to one industry 

Shape, Scale and Sustain applies to any company that designs and ships electronics hardware. EV charging, telematics, appliances, industrial controls, medical devices, energy metering. The phases are the same because the physics and the economics are the same. Design is cheap to change and expensive to get wrong. Manufacturing is repeatable and unforgiving. Field product cannot be patched by walking to a desk. 

What differs between industries is regulatory weight and volume, not structure. 

FAQ 

What is a product engineering system? 

It is the framework and tooling that carries a hardware product from concept through volume manufacturing and into field operation as one continuous, traceable process rather than three separate handovers between teams. 

What does S3 stand for in S3Suite? 

Shape, Scale and Sustain, mapping to the engineering, manufacturing and operations phases of the hardware lifecycle. Each phase is a suite within the platform, sharing a common project map. 

How is this different from traditional PLM? 

Traditional PLM largely ends at manufacturing release. It manages parts, BOMs and change orders but has no model for a connected device in the field. A product engineering system extends the same record through firmware, OTA, warranty and RMA. 

When should a hardware company adopt a framework like this? 

Before the first volume build, ideally at the point a second variant or a second production lot appears. That is when informal tracking starts failing and when retrofitting traceability becomes expensive. 

Does this replace ERP or MES? 

No. ERP handles commercial and inventory transactions, MES handles shop floor execution at scale. A product engineering system owns the product record itself: revisions, variants, test history and field state, and it feeds both. 

CTA: See how the three suites connect on one product record. [Explore S3Suite] 

Internal links: /s3suite, /insights/releasing-engineering-files-to-manufacturing, /insights/production-rework-tracking-and-traceability, /insights/hardware-version-control-for-electronics-teams