Requirements Management for Hardware Startups Without a Systems Engineer

Here’s the situation: your hardware startup has 20 people. You have a product manager, three or four mechanical engineers, a couple of firmware engineers, someone managing supply chain, and a CEO who still writes some of the architecture docs in Notion. Nobody has “systems engineer” on their title. You’re shipping toward a pilot build. And someone — probably the PM, possibly the CEO — just asked whether you have a requirements document.

The honest answer is probably: sort of. There’s a feature list in Jira, some performance targets in a slide deck, a few spreadsheets from supplier conversations, and a Confluence page that used to be current. That’s not nothing. But it’s also not requirements management. And the gap between those two things will show up as specific, painful problems at specific moments in your development program.

This article is for teams in that position. It is not an argument for hiring a systems engineer or implementing a full SE process. It is an argument for doing a minimal amount of the right things, consistently, so that the failures that kill programs — wrong builds, integration disasters, supplier miscommunication — don’t land on you without warning.

What Requirements Management Actually Is (Stripped of the Formalism)

Requirements management is the practice of making decisions explicit, storing them where the right people can find them, and tracking whether the product you’re building actually satisfies the decisions you made.

That’s it. The formal version — MIL-STD-882, INCOSE handbooks, SysML models — is the industrial-scale implementation of that idea. For a 20-person hardware company, you don’t need the full apparatus. You need the idea.

In practice, this means:

A requirement is a decision written as a testable statement. “The device shall operate between -20°C and 70°C.” Not “the device should handle cold environments.” Not a bullet point that says “ruggedized.” A testable statement with a threshold.

Traceability is the link between a requirement and evidence that you met it. At minimum, it’s knowing which test or inspection validates each requirement. At maximum, it’s a full bidirectional chain from customer need to design parameter to verification result.

Configuration management is knowing which version of the design your requirements apply to. This doesn’t require heavy tooling. It requires discipline about document versions and change records.

You don’t need a systems engineer to do any of this. You need someone willing to own it — and a process lightweight enough that they can maintain it alongside other responsibilities.

The Three Problems That Emerge Fastest

When hardware startups skip requirements discipline, the failures are predictable. Not “might happen” — will happen, in approximately this order.

1. Wrong Builds

The first hardware revision gets built to a spec that has drifted from what the customer actually needs, or from what the firmware team implemented, or from what the mechanical housing can accommodate. Everyone thought they were working from the same definition of the product. They weren’t. The definition lived in different documents, in different people’s heads, and nobody reconciled them before parts were ordered.

Wrong builds are expensive. An NPI run for a 20-person startup might cost $30K–$150K in tooling, parts, and engineering time. Building the wrong thing once because requirements weren’t managed is a survivable mistake. Building the wrong thing twice means you probably don’t have the runway to fix it.

The fix is embarrassingly simple: before any build authorization, run a one-hour review where you check that the build manifest — what you’re actually building — satisfies the requirements as written. Not the requirements as people remember them. As written.

2. Integration Failures

Hardware/firmware integration failures are the second wave. The mechanical team designed a connector to specification A. The firmware team wrote a driver to specification B. Specification A and specification B were both “the spec” at different points in time, and nobody updated the shared document when either changed.

Integration failures are particularly painful because they show up late — often at bring-up, when schedule pressure is highest and debugging capacity is lowest. The root cause is almost always requirement drift: a change was made somewhere in the design that wasn’t propagated to the teams whose work depends on it.

The fix is a change impact habit. When any requirement changes — any one — the person making the change asks: who else does this affect? Then they tell those people. This is not sophisticated. It is just a habit. It saves programs.

3. Supplier Miscommunication

The third failure mode is the slowest and most expensive. Your contract manufacturer, PCB fab, or component supplier builds to a different understanding of your requirements than you have. The difference might be a tolerance, a finish spec, a functional test criterion. You find out when parts arrive — or worse, when field failures start.

Supplier-facing requirements documents are one of the highest-leverage investments a small hardware team can make. A clear, version-controlled document that specifies acceptance criteria unambiguously protects you legally, operationally, and commercially. A supplier who builds to an ambiguous spec and ships you noncompliant parts has, technically, done what was asked of them.

This is the failure mode most likely to feel like someone else’s fault and actually be yours.

When Informality Costs More Than Structure

There’s a real cost to adding process to a small team. Meetings, document maintenance, review cycles — these take time that could be spent building. For very early-stage teams (under 10 people, pre-prototype), the cost of formality often exceeds the cost of informality. Move fast, learn fast, accept rework.

The inflection point shifts at two predictable moments.

First supplier RFQ. The moment you’re sending a technical package to a manufacturer and asking them to quote against it, you need a document that is actually the specification — not a collection of slides and Jira tickets. If you can’t produce that document, you’re either going to get a bad quote or you’re going to have a painful conversation trying to consolidate information that should already be consolidated.

Second hardware revision. By the time you’re on Rev B, you have decisions documented in Rev A’s design history, changes made during Rev A bring-up, and new requirements from customer feedback or testing. Managing three sources of truth in your head or in informal notes is roughly as hard as maintaining a lightweight requirements document — and the lightweight document is far less risky.

If you’re past either of those moments without a structured requirements practice, the cost of informality is already accumulating. The question is whether it accumulates into a recoverable rework event or an unrecoverable program failure.

A Minimal Viable Requirements Practice

Here’s what “minimal viable” looks like for a hardware startup without a dedicated SE function.

One owner. Someone has the role of maintaining the requirements document. It doesn’t have to be their primary job. It can be the PM, a senior ME, a technical co-founder. But there is one person, and they are accountable.

One document, structured simply. Requirements organized by subsystem or function. Each requirement has: an ID, a statement, a rationale (one sentence), a verification method (test, inspection, analysis, demonstration), and a status. That’s it. No SysML, no model-based tools — a well-structured spreadsheet or a simple tool works.

Review at build gates. Before each build authorization, a structured check: does the build manifest match the requirements? Are any requirements open (unverified)? Have any requirements changed since the last review? This does not need to be a two-hour meeting. It can be a 30-minute checklist conversation.

Change notification. When any requirement changes, the owner identifies affected teams and notifies them. This is a habit, not a system.

Supplier package discipline. Customer-facing and supplier-facing requirements documents are version-controlled and explicitly approved before release. The version number goes on every document. Changes go through the owner.

A PM or senior engineer can maintain this practice in roughly two to four hours per week for most programs at the 20–40 person scale. That’s the overhead. The return is measured in avoided rework.

What Tools Are Actually Appropriate

The tools conversation is where a lot of small teams go wrong. They either use nothing (too lightweight) or they evaluate enterprise requirements management platforms (too heavy, too expensive, too reliant on a dedicated administrator) and decide they can’t afford to implement either.

There’s a middle ground, and it’s grown substantially in the last two years.

For teams at the very lean end — under 15 people, first hardware prototype — a well-maintained spreadsheet with disciplined naming conventions is genuinely adequate. The practice matters more than the tool. A Google Sheet with columns for ID, statement, verification method, and status, maintained by one person, beats a misconfigured enterprise tool maintained by nobody.

For teams at the 20–40 person range approaching production or facing supplier relationships, the spreadsheet starts to break. Version control is painful. Traceability is manual. Change impact tracking is error-prone. This is the range where lightweight tooling pays for itself.

Flow Engineering (flowengineering.com) is worth specific mention here because it’s one of the few platforms designed for this exact gap. It’s AI-native — built from the ground up with AI assistance in the workflow, not AI bolted onto a legacy requirements database. That distinction matters for a small team: AI-assisted requirements authoring means someone who is not a trained systems engineer can write well-formed, testable requirements without deep SE methodology knowledge. The system catches ambiguity, flags missing verification methods, and helps propagate change impact — the exact tasks that fall through the cracks when there’s no dedicated SE function.

Critically, Flow Engineering doesn’t require a dedicated administrator to operate. The setup and maintenance overhead is designed for teams where requirements management is one person’s part-time responsibility, not a full-time role. For a 25-person hardware startup, that’s the only viable model.

The tradeoff: Flow Engineering is not trying to replace IBM DOORS for a 500-person aerospace program. It’s not targeting the customers who need DO-178C audit trails or MIL-SPEC compliance documentation workflows. If you’re in that environment, you’re almost certainly past the “no systems engineer” stage anyway. For hardware startups building toward their first production run, the focused scope is a feature, not a limitation.

Other tools worth knowing: Jama Connect scales well but assumes dedicated administrators and process owners — the cost and configuration overhead is real for a small team. Codebeamer has strong coverage for regulated industries but carries similar overhead. Confluence plus a custom template works for very simple programs and breaks down at traceability. None of these are wrong choices — they’re just calibrated for different team sizes and process maturities.

Practical Starting Points

If you’re reading this as the person who owns the product at a 20-person hardware company, here are the three things worth doing this week.

First: Write down every requirement that currently exists only in someone’s head or in a slide deck. Don’t worry about format yet. Just get them into a single document. You’ll discover requirements that conflict, requirements that are underspecified, and requirements that nobody actually owns. This is useful information to have before your next build.

Second: Define your verification method for each requirement. “How will we know if we met this?” is the question. If you can’t answer it, the requirement isn’t complete.

Third: Identify the two or three people whose work depends on requirements from other teams. Make sure they know you’re doing this, and make sure they know to tell you when their inputs change.

That’s the minimum. It’s not glamorous SE methodology. It’s the specific habit that prevents the specific failures that kill hardware programs at your stage.

Honest Assessment

Requirements management without a systems engineer is entirely possible. It requires lower overhead than most teams expect, delivers more protection than most teams realize, and becomes non-negotiable faster than most teams anticipate.

The question isn’t whether your team needs requirements management. It’s whether you recognize the moment when informality stopped being a feature of moving fast and started being the risk that ends the program. That moment, for most hardware startups, has already arrived by the second hardware revision.

Start lightweight. Make it someone’s real responsibility. Use tools that don’t require a specialist to operate. And build the habit of treating a changed requirement as a notification event, not a private revision.

The rest is implementation detail.