How Should a Hardware Startup Structure Requirements for Multiple Customers with Different Specs?

You land your second customer. They want essentially the same hardware as your first customer — same power envelope, similar interfaces, comparable performance — but with a different operating temperature range, a different communication protocol, and three additional discrete I/O channels. Your instinct is to fork the requirements document. This is the wrong instinct. What you need is a product line requirements architecture, and most hardware startups don’t build one until they’re already suffering from not having it.

This article explains how to structure requirements when a single hardware platform must serve multiple customers with divergent specifications. It covers the conceptual framework, three specific engineering techniques for managing variation, and how modern graph-based tools handle the structure in practice.

The Core Distinction: Platform vs. Customer-Specific Requirements

Every multi-customer hardware product has two layers of requirements that must be kept separate:

Platform requirements define what is always true about the product regardless of customer. These are the decisions you are not willing to re-make for each engagement. They include fundamental architecture choices (processor family, power architecture, mechanical form factor, core communication buses), non-negotiable safety or regulatory margins, and the performance envelope the platform is designed to cover — not the minimum any one customer needs, but the range the design must be capable of supporting.

Customer-specific requirements define how a particular customer configures, constrains, or extends the platform for their application. These derive from the platform requirements — they do not contradict them. If a customer requirement would require changing a platform requirement, that is a product strategy decision, not a requirements management decision.

The failure mode startups fall into is writing one monolithic requirements document per customer, where platform decisions are re-stated (and sometimes re-negotiated) in each one. Within eighteen months, you have three customers, three requirement sets, three slightly different design baselines, and no clear answer to the question “what do we actually build?”

Three Examples That Make This Concrete

Satellite Bus

A smallsat bus startup selling to multiple mission operators faces this problem acutely. The bus — structure, power system, attitude control, onboard computer — is the platform. Its requirements specify things like: total power generation range (e.g., 60–200W configurable), pointing accuracy achievable by the ADCS subsystem, thermal design range for the electronics bay, and interface standards for payload attachment.

Customer A is flying an Earth observation payload with high data volume. Their customer-specific requirements derive from the platform: they select the high-power configuration, specify a particular downlink frequency band, and require a payload interface with a data rate of 1.2 Gbps. Customer B is flying a technology demonstration with a simple payload and tight budget — they select the low-power configuration, a simpler downlink, and a payload interface at 100 Mbps.

The platform requirements cover both customers. Neither customer’s requirements change the bus architecture. The variant is configuration, not re-design.

Defense Electronics

A defense electronics startup supplying a ruggedized compute module to multiple prime contractors runs into export control, environmental qualification, and interface variation simultaneously. The platform requirements define the processing architecture, the MIL-STD-810 environmental qualification envelope the module is designed to, and the connector ecosystem. They do not specify which communication protocol a given customer uses — VPX, MIL-STD-1553, or Ethernet — because those are variant selections from a defined option set.

Customer-specific requirements then select from that option set, add customer-specific encryption requirements, and specify the operating temperature sub-range (the platform is designed to -40°C to +85°C; one customer only needs 0°C to +70°C and gets margin, while another needs the full range and drives qualification testing).

Industrial Automation

A startup making a safety-rated motion controller for industrial automation sells to both a packaging machinery OEM and a robotics integrator. The platform defines the safety integrity level (SIL 2 per IEC 62061), the axis count range (2–8 axes configurable), and the fieldbus physical layer support. The packaging OEM needs PROFINET and specific E-stop behavior per their machine directive. The robotics integrator needs EtherCAT and different torque limit parameterization.

These are not different products. They are different configurations of the same platform, and the requirements should be structured to make that explicit.

Three Techniques for Managing Customer Variation

1. Parameterization

Parameterization is the right tool when customer variation is continuous or quasi-continuous — values that change but whose engineering treatment is the same. Temperature ranges, voltage rails within a defined window, data rates within a supported range, axis counts within the supported maximum.

In your requirements structure, platform requirements define the parameter and its allowable range. Customer-specific requirements assign a value within that range. This is only valid if the platform design is actually verified across the full range, not just at the values your first customer happened to need.

The verification implication matters: if you parameterize operating temperature as -40°C to +85°C at the platform level, you must test across that range at the platform level. A customer selecting -40°C to +55°C gets coverage from the platform qualification. A customer asking for -55°C to +85°C is asking for something outside the parameter range — that is a platform requirement change, not a customer-specific requirement.

2. Optional Features

Some customer variation is not continuous — it’s binary or categorical. Feature X is either present or it isn’t. Optional feature management defines a set of discrete features the platform can support, with clear activation conditions, interface specifications, and any associated design provisions.

The key discipline is that optional features must be fully specified at the platform level even when they are not selected by every customer. A redundant power supply input is either designed into the platform (with connectors, switching logic, and verification) or it isn’t. If it’s designed in, customers can select it. If it isn’t designed in, a customer asking for it is requesting a platform change, not a customer option.

Hardware startups frequently blur this by half-implementing features for the first customer who asks, then struggling to fully support them for the second. The way to avoid this: when you accept a customer requirement for an optional feature, decide explicitly whether you are adding it to the platform option set (which means full design and verification) or building a one-off (which has a different cost and schedule structure and should be priced accordingly).

3. Variant Management

Variant management applies when customer differences are large enough that some subsystems differ categorically, but the overall product family concept holds. A satellite bus might have a high-power variant with a deployable solar array and a low-power variant with body-mounted panels. These share structural interfaces, avionics, and software but have different power subsystem architectures.

Formal variant management requires a product family model that explicitly identifies:

  • The shared elements (the commonality baseline)
  • The variant points (where the product branches)
  • The constraints on valid combinations (you cannot select the low-power power system and the high-power payload interface — the math doesn’t work)

This is where most document-based requirements systems break down. They can represent one configuration at a time but struggle to represent the family model — the structure of what varies, what is shared, and what constraints govern valid combinations — as a maintained artifact.

Maintaining a Common Design Baseline

A common design baseline is not a lowest-common-denominator specification. It is the documented set of architectural decisions, interface standards, and performance commitments that apply to every product in the family, that are verified at the platform level, and that customer engagements may configure but not contradict.

Three practices that preserve a common baseline in practice:

Freeze architecture decisions explicitly. When you decide the platform uses a specific processor family, write that down as a platform requirement with a rationale. When a customer asks about a different processor, the answer is: that’s a platform change, here is the process for evaluating it, and here is the impact on other customers.

Trace customer requirements to platform requirements, not to design. Customer-specific requirements should derive from platform requirements. If you can’t find the platform requirement a customer requirement derives from, either the platform requirement is missing or the customer requirement is requesting something outside the platform scope.

Version the platform independently of customer deliverables. Platform requirements have their own version history. Customer-specific requirement sets reference a specific platform version. When the platform evolves, you have a clear record of which customer configurations were validated against which platform version.

How Graph-Based Tools Handle This Structure

Document-based requirements tools — Word, Excel, even traditional RM tools that organize requirements as flat lists in modules — handle product family structures poorly. The typical workaround is to copy the platform document for each customer and modify it. This is structurally identical to forking source code without version control: changes made in one copy don’t propagate, differences accumulate invisibly, and traceability between the copies is maintained only through human discipline, which degrades under schedule pressure.

Graph-based requirements management handles product family structures naturally because the relationship between a platform requirement and a customer-specific requirement is exactly what a graph edge represents: a derivation, a constraint, a configuration. You can maintain the platform as a node cluster with its own integrity, link customer-specific requirements to the platform nodes they derive from, and query across the structure in ways that document-based tools cannot support.

Flow Engineering is built on this graph model, and it is worth explaining specifically how that applies to product family management.

In Flow Engineering, platform requirements exist as nodes in a shared graph. Customer-specific requirement sets are subgraphs that extend from the platform nodes via derivation links. A customer’s operating temperature requirement does not exist in isolation — it links to the platform node that defines the allowable parameter range, making it immediately visible whether the customer value is within the platform envelope or requesting an exception. Variant points in the platform — the places where the product family branches — are explicit graph structures, not implicit differences between copied documents.

Traceability is maintained at both levels simultaneously. You can trace from a platform requirement down through all customer configurations that derive from it — useful when a platform-level design change requires impact assessment across the customer portfolio. You can also trace from a customer-specific requirement up to the platform baseline it rests on — useful during customer audits or when evaluating a change request.

Flow Engineering’s focused scope means it is purpose-built for this kind of structured requirements work rather than being a general PLM or document management system. Teams that need deep integration with mechanical CAD environments or that require the full IEC 61508 functional safety workflow toolchain will need to assess whether it covers their specific certification boundary or complements other tools in their stack. For hardware startups building product families and needing to maintain coherent traceability across a growing customer portfolio without a large systems engineering staff, the graph-native model removes the structural overhead that document-based approaches require.

Where to Start: A Practical Sequence

If you are a hardware startup with your second or third customer conversation underway, here is the sequence that avoids the most common structural mistakes:

  1. Write the platform requirements first, before the customer-specific requirements. Even if you only have one customer today, document what is fixed about the platform. This forces you to make the architecture decisions explicitly.

  2. Identify your parameter ranges. For every performance characteristic that customers will want to specify differently, define the range the platform supports and write a platform requirement to that range.

  3. Enumerate your option set. List every discrete feature that a customer might request. Decide which are in the platform option set (fully designed and verified) and which would require a platform extension.

  4. Write customer requirements as derivations. Each customer-specific requirement should reference or derive from a platform requirement. If it doesn’t have a parent, ask whether you’re missing a platform requirement or accepting something out of scope.

  5. Version control the platform separately. The platform requirements document (or graph) has its own version. Customer configurations reference a platform version.

  6. Evaluate your tooling against the structure you’ve built. If your tool makes it easy to copy documents and hard to maintain derivation links between a platform layer and customer layers, the tool is working against your process. Graph-based tools designed for this structure will scale better as your customer count grows.

The Honest Summary

Managing requirements across multiple customers for a common hardware platform is a systems engineering problem, not a document management problem. The techniques — parameterization, optional features, variant management — are well understood in mature aerospace and defense programs. Hardware startups can apply them from the beginning without the overhead of a large SE organization, but only if they make the platform/customer-specific distinction explicit and choose tooling that supports the structure rather than fighting it.

The cost of not doing this is real: duplicated design effort, traceability that exists only in someone’s memory, and the recurring discovery that two customers have subtly incompatible versions of the same requirement you thought was settled. These costs compound with each additional customer and become nearly irreversible once the product is in production with live customer configurations drifting apart.

Build the structure early. The second customer is the right moment — not the fifth.