Flow provides new-age engineering companies with a requirements tool that is built specifically for their needs and allows them to focus on engineering ground breaking products.

The Agile Systems Engineering Handbook (Volume 2) — [Read now→](/handbook/volume-2/)

Open Graph sharing image

Flow Engineering

Twitter Image

## The Role of Judgment

When it comes to engineering complex systems, how do you decide what to build first? How do you balance ambition with the practical need to ship something? The secret lies in scoping. A practice that requires sharp judgment, a deep understanding of time as a resource, and the courage to confront failure head-on.

Scoping is a test of judgment. It’s about stripping down to the essentials. To the core problem. And pushing back on anything unnecessary.

> 
> "The role of a leader is to say what you're not going to do, as well as what you are going to do."
> <footer><img src="//images.ctfassets.net/c2mtbunjxyfe/6kRleW0cPqxjF783TwtFQL/3d33ff702eb3f93a1057dad9df957e91/ian-abl.jpg" /><author>Ian Jimenez</author><position>VP Engineering, ABL</position></footer>
> 

Done right, scoping drives speed, learning, and progress. Done wrong, it leads to bloated timelines and missed opportunities.

One idea the leaders at SpaceX use a bunch is “future problem.” If it’s a “future problem,” we don’t talk about it today. Today is about making real, tangible progress on the 3-4 things that will give us new information. If we do that, we’re in the race, and tomorrow will come.

This chapter explores how leading companies like Astranis, Planet, and SpaceX reduced scope to the bare minimum, used scrappy prototypes to learn faster, and proved that shipping frequently—rather than perfectly—is the key to long-term success.

### Astranis’ and Planet’s Minimal Viable Satellites

Today, Astranis builds complex geostationary satellites, a notoriously challenging domain. But they didn’t start there.

Their first cubesat, built for Y Combinator’s Demo Day, came together in just three weeks. The “cleanroom”? PVC pipes and shower curtains.

Later, to test their software-defined radio technology, Astranis launched LEO satellites. These early missions helped them iterate on full mission profiles, get more reps for the team from each launch, and steadily progress to a more challenging higher orbit.

Planet’s first satellites were famously scrappy. They used off-the-shelf antennas, purchased from consumer electronics stores, and attached them to their satellites. If this had been a NASA project, months—if not years—would have been spent designing custom antennas with extensive validation and verification processes.

By starting simple, Planet proved their concept worked. They reduced scope to the essentials and learned what they needed to iterate on for future versions.

> 
> "Downscoping is the most important thing a leader can do."
> <footer><img src="//images.ctfassets.net/c2mtbunjxyfe/1z3EdJiXi9zxVQbpLgn9Ls/f8eb6cf4e9524711d89a54f2c9afcedd/pari-flow.jpg" /><author>Pari Singh</author><position>CEO, Flow Engineering</position></footer>
> 

This reduction in early scope to the bare minimum is the same for SpaceX and their Grasshopper. It wasn’t built to reach orbit—it was built to test and refine vertical takeoff and landing capabilities. By focusing on this narrow problem, SpaceX gained invaluable experience in reusability, paving the way for the Falcon 9 and Starship programs.

The core idea here is to go through the full cycle as fast as possible, getting from problem space to solution space as fast as possible. MVP of the whole mission profile. We’ll see later why this in particular is so important.

### Counter Examples

In contrast, programs like NASA’s Space Launch System (SLS) illustrate the dangers of excessive scoping. With over $40 billion spent and no reusable capabilities, SLS highlights the risks of prioritizing perfection over progress.

![elon-quote-scoping](//images.ctfassets.net/c2mtbunjxyfe/BpSB66v5VVWrYYthekFFY/3c12f65cc5f793a4def8c976dbf1ebbd/Group_668.png)

Scoping effectively is an exercise in judgment. It requires answering questions like:

- What is the true problem space we need to address right now?
- How do we know we’ve reached the “right” moment to stop designing and start shipping?

What problem do we need to de-risk now? Is it building team muscle or creating evidence for investors? When is the “right” time to move to solutions and start shipping?

The answer lies in continuously reducing scope. Push back on anything unnecessary and pare your goals down to the absolute essentials. Avoid making your MVP too big—focus on de-risking the most critical challenges first.

## Learning Is the Real Goal

Scoping isn’t just about delivering a product—it’s about learning. Start with small, manageable goals and expand from there.

For example, SpaceX didn’t start Starship by aiming for orbit. They began with up-and-down tests to refine basic systems. The learnings from these tests weren’t just technical—they included lessons on how to deliver a product.

Scoping is about judgment, time, and overcoming the fear of failure. It’s about knowing what to build now versus later, embracing imperfection, and learning with every iteration.

Teams that master scoping will outpace their competitors, delivering faster, learning more, and building better products. The question isn’t, “Can we get it perfect?” It’s, “What can we ship today?”

## The Fear of Failure

A major hurdle to adopting an MVP mindset is fear of failure. Engineers often resist “crappy” first versions to avoid looking subpar. But this mindset is counterproductive.

A three-year roadmap might feel safe, but it’s often an excuse to delay shipping. Real learning and progress happen when teams take risks and ship earlier than they’re comfortable.

So what happens when something goes wrong? Easy. Just make another decision. Immediately. What happens if that goes wrong? Make another. If that one goes wrong you’re probably in the wrong business anyway.

Move the mental model from “what’s the perfect solution to the equation” to “shots on goal.” Play darts not chess.

## Time as a Requirement

Force as much scope into that time as you can, not the other way around. The biggest cost in development is time (large team * salaries).

> 
> "Think of time as a requirement, not a resource. Then force as much scope into that time as you can, not the other way around. The biggest cost in development is time (large team * salaries)."
> <footer><img src="//images.ctfassets.net/c2mtbunjxyfe/44cOxbDYm9Ob0Wioq1SrhI/25d5e0632da343416a118931243aa87e/skyler-hermeus.jpg" /><author>Skyler Shuford</author><position>COO, Hermeus</position></footer>
> 

On the cost of failure: If our MVP fails, we lose $100,000. Ok, but how much does it cost if your team ships a month late? $3,000,000?

Ask yourself: With six months, what would you ship? Time constraints force teams to prioritize and focus on what matters most.

Instead of waiting to ship a perfect product next year, aim to ship five imperfect ones this year. Each iteration builds muscle—in your team, your processes, and your ability to deliver under pressure.

When scoping, time must be treated as a critical requirement. Every delay costs more than just money—it slows down learning.

## Building Repetitions: Why Shipping Matters

The biggest mistake teams make is assuming they know how to execute on something they’ve never done before.

> 
> "You need to build "reps" with your team on the full lifecycle to build it into the culture. Everyone from engineering, to manufacturing, to test. They need to start learning together and the best way to do that is to ship something smaller faster."
> <footer><img src="//images.ctfassets.net/c2mtbunjxyfe/44cOxbDYm9Ob0Wioq1SrhI/25d5e0632da343416a118931243aa87e/skyler-hermeus.jpg" /><author>Skyler Shuford</author><position>COO, Hermeus</position></footer>
> 

Shipping continuously builds organizational muscle. It teaches teams how to:

- Deliver products under tight constraints.
- Handle failure gracefully and incorporate feedback.
- Develop a culture of accountability and progress.

This iterative process is just as important for leadership and investors as it is for engineers. It builds trust that your team can deliver value, even under challenging conditions.

The biggest mistake teams make is assuming they know how to execute on something they’ve never done before. Even experienced teams are effectively starting from scratch when tackling a new challenge. This is why:

- __Short Cycles Matter__: The faster you ship, the faster you learn.
- __Hardware vs. Software__: Unlike software, hardware is tested on physics, not people. This makes iterations slower but even more critical.

> 
> "If your team hasn’t done it before, it’s the same as doing it for the first time. Which is why optimizing for cycle speed is so important."
> <footer><img src="//images.ctfassets.net/c2mtbunjxyfe/1z3EdJiXi9zxVQbpLgn9Ls/f8eb6cf4e9524711d89a54f2c9afcedd/pari-flow.jpg" /><author>Pari Singh</author><position>CEO, Flow Engineering</position></footer>
> 

## High-Quality Product, Variable Process

99% of problems occur at the integration level, where subsystems must work together. That’s when you finally put everything together and fly. That’s when you discover how much real testing matters, and how little a rigid process can guarantee. You learn more by building and testing than by following a perfect set of rules. By starting small and testing early, teams can identify and address these issues before they spiral out of control.

This leads to a fundamental tradeoff in scoping:

- __High-Quality Product + Variable Process__
- __High-Quality Process + Variable Product__

You can either aim for a high-quality product by letting your process vary, or aim for a rigid process with the risk of ending up with a subpar product. You simply can’t have both. European companies often default to high process quality and end up sacrificing product agility in the process. Meanwhile, scrappy teams like SpaceX or Anduril allow their processes to vary freely, relying on iteration to reach a high-quality product. It’s a stark divide between next-generation teams and traditional aerospace.

Programs like Starliner prove that following elaborate procedures to the letter doesn’t guarantee success. You can still end up with costly oversights because you become so buried in steps and checklists that you lose sight of the actual engineering. In contrast, agile teams adopt an approach that feels messy in the beginning, but they deliver meaningful hardware quickly. At an early stage, their job isn’t to meet DoD-grade checks; it’s to ship prototypes, test them, fail fast, and refine.

That means you don’t apply the same stringent new product introduction processes to every single subsystem. Sometimes you can cut metal right away and learn by flying. A real prototype—no matter how rough—usually teaches you more than a year of design reviews. But once you have traction and the product starts to solidify, that’s when you layer in more formality, checklists, and rigorous validation. Process is there to help you move faster, not slow you down. Too much formality too soon hurts speed. Too little formality too late can undermine safety and reliability.

> 
> "Get to the heart of what you're trying to learn or demonstrate in this iteration. If you build a machine that churns out iterations, you'll know that if you miss it on this one, you'll get it on the next."
> <footer><img src="//images.ctfassets.net/c2mtbunjxyfe/1z3EdJiXi9zxVQbpLgn9Ls/f8eb6cf4e9524711d89a54f2c9afcedd/pari-flow.jpg" /><author>Pari Singh</author><position>CEO, Flow Engineering</position></footer>
> 

A messy process at the start is normal—and often good. Early-stage teams shouldn’t run DoD-grade checklists. They need to get prototypes out and learn quickly. That’s how you build a real product that works, is safe, and is easy to iterate.

1. __Vary Process with Context__
Don’t apply rigid new product introduction (NPI) protocols to functional safety. Nor do you need spaceflight-level rigor for a simple prototype.

2. __Remove Process Early On__
At the NPI or PDR stage, skip the heavy docs and cut metal. A few extra flights teach more than a thousand design reviews.

3. __Add Rigor When You Have Something Real__
Use process to accelerate progress, not slow it. Early products can be over-constrained by bureaucracy. Later products, once they have traction, may need more formal checks.

In short, you’re choosing between a high-quality product with a process that adapts to the context, or a highly regulated process that risks delivering something suboptimal. If you want to compete with the new wave of agile companies, it’s clear where you need to land.

cover-scoping-in-practicer

hermeus-logo

Hermeus

flow-logo-small

Flow

cover-lp-chapter-5

Practical strategies on scoping complex engineering challenges to move fast. Learn how leading teams strip down to the essentials, embrace fast iterations, and deliver impactful products ahead of the competition. **Read more →**

Chapter 5 — Scoping in Practice: From Minimal Viable Technology to MVP

In a world where engineering challenges are growing exponentially in complexity, the old linear models of "A → B → C" no longer work. Today’s cutting-edge teams—from aerospace to automotive—are embracing concurrent engineering: a way of designing where problems are tackled simultaneously rather than sequentially. The result? Faster timelines, better collaboration, and fewer surprises late in the game.

> 
> "If you build a machine that churns out iterations, you'll know that if you miss it on this one, you'll get it on the next."
> <footer><img src="//images.ctfassets.net/c2mtbunjxyfe/1z3EdJiXi9zxVQbpLgn9Ls/f8eb6cf4e9524711d89a54f2c9afcedd/pari-flow.jpg" /><author>Pari Singh</author><position>CEO, Flow Engineering</position></footer>
> 

But designing concurrently isn’t just about doing more at once—it’s about doing it right. As a leader, you must create the environment for real concurrency. It’s easy to say, “We’re doing concurrent engineering!” But are you sure? Many teams claim they are, yet they remain stuck in a watered-down waterfall. They still toss requirements over the fence, wait too long for feedback, and scramble to integrate at the end. This article explores the prerequisites, cultural shifts, and systemic changes organizations need to move beyond lip service and into real concurrency.

Let’s dive in.

## Prerequisites

1. __Design Criteria, Not Endless Requirements__ (See Chapter 7)
The traditional approach of drafting thousands of detailed requirements, treated as unbreakable contracts, doesn’t align with concurrent design. Instead, teams need design criteria—flexible guidelines that empower engineers to innovate without bureaucratic drag.

__Empowerment Matters__: As a leader, you must give Responsible Engineers (REs) the authority to create and own their design criteria. This ensures those criteria remain grounded in real physics and data, not stale checklists.

__Fewer is Better__: Teams bogged down by thousands of rigid requirements won’t move quickly. Prioritize the critical few that drive 80% of the value. If it doesn’t shape mission-level performance, it’s negotiable.

__2. Culture of Direct Collaboration__
Concurrent engineering thrives on real-time, face-to-face communication. As a leader, you must enable direct access between subsystem owners. This prevents the siloed decision-making that can derail a fast-moving program.

__Instant Collaboration__: Instead of waiting for formal sign-offs, the best teams walk across the room (or hop into an online workspace) to solve problems. Latency kills speed. Leadership should eliminate these bottlenecks wherever they appear.
Authority Sits Where the Work Is: When Responsible Engineers have the power to decide, they move faster and care more about performance than process. This shift is cultural and begins at the leadership level.

__3. Shorten the Feedback Cycle__
As a leader, your goal is to minimize the gap between a design change and its impact on downstream teams. Synchronizing every two weeks—or even more frequently—keeps the momentum going. If it takes weeks to notice someone modified a vital interface, you’re essentially operating in a waterfall mode.

> 
> "The key to balancing speed with rigor isn’t layering on more process—it’s deeply understanding the user base and integrating their feedback before committing to long, inflexible cycles."
> <footer><img src="//images.ctfassets.net/c2mtbunjxyfe/6ru38zQZ5qSzMwcOt5ztkB/1d4d2c35edf9a7426d03ee29cb3a3ce2/christ-true-anomaly.jpg" /><author>Chris Daywalt</author><position>Senior Director, Programs, True Anomaly</position></footer>
> 

__Throughput__

Throughput is the volume of information that moves between people. Low throughput causes confusion, blind spots, and misalignment. Effective leaders increase throughput by ensuring:

- Teams share relevant context at the right time
- Communication is open, transparent, and efficient
- People trust each other enough to exchange ideas freely
- When delay is low and throughput is high, progress accelerates. Teams coordinate smoothly. Minor issues get flagged before they become major problems. Decision-making gets sharper.

Great leaders don’t just manage—they optimize communication across the organization. They create structures where ideas circulate, feedback is immediate, and no one is stuck waiting for clarity.

__Delay__

Delay is the time it takes for information to travel, decisions to be made, or problems to surface. High delay derails progress—people wait, guess, or lose momentum.

Strong leaders minimize delay by building environments where:

- Feedback moves swiftly
- Issues are spotted early and resolved promptly
- Communication loops are short, direct, and clear

> 
> Not everything needs to be locked into a Cameo model when PowerPoint, Excel, or a whiteboard session can align the right people faster.”
> <footer><img src="//images.ctfassets.net/c2mtbunjxyfe/6ru38zQZ5qSzMwcOt5ztkB/1d4d2c35edf9a7426d03ee29cb3a3ce2/christ-true-anomaly.jpg" /><author>Chris Daywalt</author><position>Senior Director, Programs, True Anomaly</position></footer>
> 

Strong leaders running cross-functional teams establish structures that enable a steady stream of ideas, deliver instantaneous feedback, and ensure nobody is left awaiting clarity.

## Problem vs. Solution Space

In concurrent engineering, it’s crucial to distinguish between the problem space (the goal to be achieved) and the solution space (how to achieve it). This separation avoids tunnel vision and gives teams the freedom to develop creative ideas.

__Problem Space__

The problem space defines what needs to be accomplished. It contains the design criteria—broad guidelines that outline desired outcomes without dictating the specific method. This flexibility keeps teams aligned with overarching objectives while allowing them to explore a wide range of approaches. Focusing on a single solution too soon can lock teams into suboptimal paths.

__Solution Space__

The solution space is where teams determine how to fulfill those goals. By keeping it open and iterative, engineers can test and refine their ideas continuously. It’s also vital to empower Responsible Engineers (REs) to write their own design criteria, preserving adaptability and encouraging innovation.

Leaders, meanwhile, manage mission-level requirements to provide overall direction without stifling creative thinking. Concurrent engineering relies on continuous feedback loops, where designs evolve in tandem with ongoing testing. By emphasizing outcomes rather than rigid processes, engineers can focus on meeting core design criteria effectively.

Concurrent engineering teams must integrate regulatory constraints into their design criteria from the start. For instance, engineers at SpaceX refer to their payload guide to ensure compliance while maintaining speed and flexibility. If you wait until the end to validate regulatory requirements, you’ll sink your timeline.

__Design vs. Building: An Intertwined Process__

In a concurrent engineering environment, design and building aren’t separate phases—they form a single, integrated loop. The traditional mindset of “design, then build, then test” is simply too slow.

- __Continuous Testing__: There’s no such thing as “I tested it, and it’s done.” Systems must be tested against evolving criteria at every stage.

- __Daily Baselines__: Concurrent teams baseline their designs daily, creating a living, adaptable framework. This approach minimizes the risk of late surprises and encourages ongoing innovation.

> 
> "Instead of treating software and hardware as separate disciplines, we integrate hardware-in-the-loop and software-in-the-loop testing from the start. That means real performance data drives engineering decisions, not theoretical models."
> <footer><img src="//images.ctfassets.net/c2mtbunjxyfe/6ru38zQZ5qSzMwcOt5ztkB/1d4d2c35edf9a7426d03ee29cb3a3ce2/christ-true-anomaly.jpg" /><author>Chris Daywalt</author><position>Senior Director, Programs, True Anomaly</position></footer>
> 

A test-driven culture further enhances adaptability by emphasizing continuous testing and iterative improvement. For example, Rivian runs over 95,000 tests every night, treating each failure as an opportunity to learn rather than a setback. Embracing failure in this way accelerates progress without fear.

Separating the problem space from the solution space not only improves design quality—it also fosters a culture of agility. Teams remain focused on desired outcomes, yet they have room to innovate and ensure they’re solving the right problems in the most effective ways.

## The Race to Manufacture

In concurrent engineering, the subsystem that finishes first often sets the constraints for the rest. Speed becomes a competitive advantage—if your team is ready before everyone else, you define the parameters others must follow. This dynamic fosters a healthy “race to be first,” where teams eliminate waste, solve problems quickly, and share breakthroughs.

Building “reps” is crucial here. Each round of rapid development familiarizes teams with cross-functional collaboration and accelerates their comfort with change. Over time, these reps compound. A team that has cycled through multiple fast turnarounds will outpace one tackling concurrent engineering for the first time.

> 
> "Speed done right lowers risk rather than increasing it."
> <footer><img src="//images.ctfassets.net/c2mtbunjxyfe/6ru38zQZ5qSzMwcOt5ztkB/1d4d2c35edf9a7426d03ee29cb3a3ce2/christ-true-anomaly.jpg" /><author>Chris Daywalt</author><position>Senior Director, Programs, True Anomaly</position></footer>
> 

Deadlines act as forcing functions in this environment. When teams know they must show progress on a specific date, they’re compelled to deliver incrementally and learn continuously. Treat time as a design requirement, using tight schedules and smaller sprints to maintain momentum. Under these conditions:

- Urgency discourages over-polishing; teams focus on core functionality over optional perfection.
- Blockers can’t stay hidden; problems surface early, when they’re easier to fix.
- Time pressure forces teams to deprioritize non-essential tasks, preventing bloat.

As a leader, you are the architect of these systems and cultures. Set clear deadlines, remove blockers, empower engineers, and celebrate small wins that fuel bigger successes. By doing so, you’ll create an organization that thrives on speed, adaptability, and continuous improvement.

## The Role of Design Reliability

At the heart of concurrent engineering is a focus on design reliability—systems that perform under real-world conditions, not just in lab tests.

- __Avoiding Fragility__: A design that shines in controlled tests but fails under stress isn’t a success. As a leader, insist on reliability as a core principle.
- __“No Such Thing as ‘I Tested It’”__: Testing isn’t a one-time event. Systems are tested daily against changing requirements and real data. This constant validation drives incremental improvements.

## The Role of Leadership in Concurrent Engineering
Your job is to set mission-level requirements while keeping flexibility at the subsystem level. You must also remove any structural obstacles to collaboration. Here’s what that looks like in practice:

1. __Authority to the Responsible Engineers__
Make sure decisions are made by the people who own the subsystems. When REs have real power, they focus on performance over busywork.

2. __Minimal “Requirements,” Maximum Design Criteria__
The team knows what truly matters—thrust, mass, thermal constraints—and everything else is fair game. This fosters creativity and real accountability.

3. __Concurrent from Day One__
Hardware, software, propulsion, avionics—everyone starts together. They shape the mission architecture as it evolves, rather than waiting for a locked-down spec.

4. __Real-Time Collaboration__
Problems can’t hide. If an engineer spots a risk, they walk over to the relevant owner or jump on a video call. Bottlenecks are flagged and fixed early.

5. __Daily Design Baselines__
You can’t wait for monthly reviews. The design is a living document, updated as new data emerges.

6. __Digital Information Sharing__
If it takes two weeks to notice design changes, you’re failing at concurrency. Modern tools are improving, but many teams still build custom solutions to ensure instant updates.

In short, your role is to balance speed with coherence. You don’t reject process; you make process serve the product, not the other way around. That’s how you lead teams to real concurrent engineering—where design, testing, and feedback all happen in parallel, and the entire organization moves faster than the competition.

Concurrent Engineering in Action: A Quick SpaceX Example

- __Start Early__: Propulsion, avionics, thermal, and life support kick off on day one. They don’t wait for a “requirements doc.” They shape the architecture in real time.
- __Own the Bigger Picture__: Responsible Engineers don’t just see the top-level mission goals; they own them. This sense of accountability drives better decisions.
- __Daily Baselines__: The design is a moving target, but it’s captured every day. Everyone knows the latest specs, so integration never halts.
- __“Anti-Process”? Not at all__. They focus on outcomes, not rigid checkpoints. That’s the essence of true concurrency.

When done well, concurrent engineering delivers tangible results: shorter lead times, improved product quality, and teams that learn at every step. As a leader, it’s up to you to create the structures, culture, and trust that make genuine concurrency possible. If you can do that, you’ll find your organization building better products—faster, smarter, and with fewer painful surprises at the eleventh hour.

chapter-6-concurrent-engineering

true-anomaly-logo

True Anomaly

cover-lp-chapter-6

How leaders can create the right environment for concurrent engineering. How to do parallelism in practice to dramatically shorten feedback cycles. **Read more →**

Chapter 6 — Concurrent Engineering: Working in Parallel with Evolving Requirements

We talked about Design Criteria and the cultural implications in Volume 1. You should read the [Requirements: A Modern Approach](https://flowengineering.com/handbook/volume-1/#the-modern-approach-to-hardware-requirements) before starting with this chapter.

The distinction between requirements and design criteria isn’t just technical—it’s psychological.

- **Requirements** carry a sense of rigidity. Hard, unchangeable constraints (e.g., regulatory demands). often viewed as commandments that engineers can’t question.

- **Design Criteria**, by contrast, are seen as flexible guidelines, input rather than a fixed constraint. This subtle shift in terminology empowers engineers to challenge assumptions, propose trade-offs, and iterate more effectively.

### Traditional Systems Engineering: The JPL Trap

Before we jump in, let's baseline what is to come with the legacy systems engineering model and common failure points.

**The Rigid Requirements Approach**
Programs like NASA’s SLS start with **Request for Proposals (RFPs)** and spend years—sometimes decades—finalizing tens of thousands of requirements. The goal is to eliminate all risks upfront. Once requirements are locked, billions of dollars are allocated, and program management becomes a Gantt-chart exercise. Changes are discouraged, creating a brittle system that struggles to adapt to unexpected challenges.

__The Cost of Rigidity__
Legacy systems often experience delays and cost overruns because:

1. Assumptions made early in the process are often wrong.
2. Changes in flight data or external conditions invalidate rigid requirements.
3. Delays compound as programs strive for near-perfect reliability before shipping.

__Modern counter-examples__
Many new, modern space companies, are falling into a similar perfection trap. By aiming for a 95% probability of success and extending timelines to achieve 99.7%, they risk turning a 5-year program into a 10-year ordeal. Each delay justifies adding more requirements, which only increases complexity and cost.

## Design Criteria vs. Requirements

As teams become more cross-functional and iterative, a new way of handling requirements has emerged. The best teams no longer use the IBM DOORS/1000-page document model.

Let’s break down two types of requirements by stakeholder

External Requirements [customer/regulatory/suppliers/partner]
Internal Requirements [sub-teams]

External Requirements are often called Level 0/1 or Mission Requirements. Internal Requirements cover levels 1/2 (system, sub-system, component).

### Design Criteria (Internal Requirements)

These are softer, team-to-team agreements that make the mission work. They’re frequently renegotiated and owned by the engineer responsible for closing them out, often called the Responsible Engineer.

Using the term "Design Criteria" instead of “internal requirements” because it promotes a collaborative mindset. This also promoted a culture where requirements serve the mission profile, not the other way around.

**Ownership**: Assign one owner per design criterion to ensure accountability and clarity. This approach fosters a culture where engineers are empowered to innovate while minimizing the chaos of constant changes.

__Design Criteria Should Be Written Immediately and Continuously Updated__

The paradox of modern systems engineering: To start designing, you need a requirement. To write a requirement, you need the design.

How can you do this with incomplete information? You have to guess. Some call this an assumption or hypothesis.

The only way to break the cycle is to start somewhere and iterate. Your best guess will usually be in the right ballpark, enabling teams to move forward. Ideally, this guess comes from the Responsible Engineer.

It’s not enough to document design criteria. You also need to record the **underlying assumptions** driving those criteria. When assumptions change, design criteria must be updated to avoid cascading errors.

At SpaceX, design changes constantly—flight profiles, trajectories, and loads are in perpetual flux. This creates a ripple effect across subsystems, requiring teams to rerun loads analyses and update designs.

> 
> "Modern teams don’t start with a hard design point—they start with a window. That window is dynamic, and it’s based on assumptions that evolve over time. Over the project lifecycle, the window gets smaller and firmer, as some design criteria turn into things we know with a high degree of certainty."
> <footer><img src="//images.ctfassets.net/c2mtbunjxyfe/1z3EdJiXi9zxVQbpLgn9Ls/f8eb6cf4e9524711d89a54f2c9afcedd/pari-flow.jpg" /><author>Pari Singh</author><position>CEO, Flow Engineering</position></footer>
> 

**Explicit Labels**: Teams should explicitly label design criteria, setting expectations that these will change as the project evolves. Make it clear this design criteria is an “Assumption”. Teams should regularly sync and update each other on changes.

__Design Criteria Should Be Traded Off Over the Iteration__

Requirements should not drive design blindly. Inputs must constantly be revisited and updated as conditions evolve.

Mass margins are a good example. You may find some buffer to give to another team.

Time is a critical factor in requirements. You may hit your 100kg mass requirement but take six months to do it. Or, you could hit 110kg and save six months. Design Criteria make these trade-offs explicit.

By actively reevaluating these parameters, teams can quickly identify synergy or conflicts across multiple subsystems. This ensures no single requirement inadvertently constrains the broader system.

__Design Criteria Drive Ownership to Engineers (Responsible Engineers)__

If requirements are continuously traded off, who’s best suited to handle it? The engineer who owns the part. They are the Responsible Engineers—they own both the part and the requirement.

Every requirement owned by a person provides clear accountability. Talk to the Responsible Engineer before starting analysis; you might find circumstances have changed or buffers are off.

Design Criteria also empower engineers, giving them real ownership of the system. This mindset is crucial.

Having decision-making in the hands of the RE fosters a culture where changes are made swiftly and with technical depth. It also closes the loop between design accountability and real-world performance.

> 
> "You need a person to own a system. You need a person to own a requirement. Don’t worry too much about having every single element documented—have a name, have a rationale, and if something changes, go talk to the person responsible. You’ll learn more in five minutes than you will in 25 hours of document review."
> <footer><img src="//images.ctfassets.net/c2mtbunjxyfe/1z3EdJiXi9zxVQbpLgn9Ls/f8eb6cf4e9524711d89a54f2c9afcedd/pari-flow.jpg" /><author>Pari Singh</author><position>CEO, Flow Engineering</position></footer>
> 

## Requirements (customer/regulatory/suppliers/partner)

The ideal scenario is to treat external parties as collaborators. If you can negotiate as freely with external parties as internal teams, you’ll be faster and more successful.

For example, you could present a customer with a trade-off: “We can deliver 10,000kg to LEO on time, or 8,000kg a year earlier. Is weight or schedule more important?”

Traditional systems engineers might say requirements are fixed and must be locked down early. This isn’t true. Development cycles are long, and things change over time.

> 
> "The core of systems engineering has shifted from ‘avoid change and lock down systems’ to ‘propagate change as quickly as possible across the development program."
> <footer><img src="//images.ctfassets.net/c2mtbunjxyfe/1z3EdJiXi9zxVQbpLgn9Ls/f8eb6cf4e9524711d89a54f2c9afcedd/pari-flow.jpg" /><author>Pari Singh</author><position>CEO, Flow Engineering</position></footer>
> 

The same applies to regulation. If you’re designing a nuclear reactor, it’s in your best interest to ensure it’s safe. Sometimes, regulators may have additional needs that aren’t relevant. In these cases, treat top-level requirements traditionally but coach customers and regulators toward a more flexible approach.

Keep internal requirements as desirements, and expand that mindset as far as possible.

![table-changes-between-traditional-and-iterative](//images.ctfassets.net/c2mtbunjxyfe/7IVDGMJKgM2jZcjCGFsd2c/6c9aec0c58e41fe23c5d445f83615607/Screenshot_2024-11-18_at_17.10.14.png)
*Summary of changes between requirements and design criteria*

## Aligning Requirements and Design Criteria

Here’s how modern engineering organizations can avoid the pitfalls of legacy approaches:

__Set Real Requirements__

Identify the **real requirements**—those that absolutely cannot change. These are often fewer than you think (e.g., 10 at the program level, not 1,000). Examples include strict regulatory constraints and mission-critical parameters.

__Define Design Criteria__

Label all other inputs as **design criteria**, explicitly setting the expectation that they are subject to change. Use design criteria as inputs to models or performance targets, connecting them to simple analyses whenever possible (e.g., thrust linked to Delta-V).

__Streamline the Process__

1. **Program-Level Requirements**: Systems engineers write down the top-level requirements, associating each with a confidence level (e.g., “best guess”).
2. **Design Criteria by REs**: Responsible Engineers (REs) define design criteria based on program-level requirements, iterating in close collaboration with other teams.
3. **Side-Shuffle Between Teams**: Teams validate and adjust their criteria against each other, ensuring alignment across subsystems.
4. **Bi-Weekly Cadence**: Synchronize every two weeks to update and validate assumptions, minimizing feedback loops.

__Just start building without hard requirements__

Cost is driven by time, not by metal. SpaceX probably spends 250M+ a month (made up number), so 8M+ a day. If you wait to have full requirements down to the penny, you’ll have spent 500M and not shipped/learned anything.

Skate to where the puck is going to be.

What are the real requirements for starship? Cost per kg, launch rate, full reusability, Mars.

Re-affirm the top line requirements, and trust your engineers to look after the bottom line. Requirements will come - but probably after we’ve started designing. Expect mistakes, and try to call it learning.

## Example: SpaceX’s Design Review Model

SpaceX achieves agility by integrating requirements and design criteria into a dynamic, stage-gated process:

1. **Back-of-the-Envelope Calculations**: Initial high-level analysis to determine feasibility.
2. **Preliminary Design Review (PDR)**: Within 3-6 months, teams present rough designs and concepts.
3. **Critical Design Review (CDR)**: Detailed CAD models and geometries are finalized. This is the go/no-go moment for manufacturing.
4. **Flight Readiness Review (FRR)**: Final checks before launch, ensuring all systems are go for flight.

This iterative approach allows SpaceX to adapt quickly while maintaining rigorous standards.

## Conclusion

> 
> "Reaffirm the top-line requirements, and trust your engineers to look after the bottom line. Requirements will come—but probably after we’ve started designing. Expect mistakes, and try to call it learning."
> <footer><img src="//images.ctfassets.net/c2mtbunjxyfe/44cOxbDYm9Ob0Wioq1SrhI/25d5e0632da343416a118931243aa87e/skyler-hermeus.jpg" /><author>Skyler Shuford</author><position>COO, Hermeus</position></footer>
> 

The future of engineering lies in embracing change. By distinguishing between hard constraints (requirements) and flexible inputs (design criteria), teams can build faster, innovate more effectively, and adapt to an ever-changing landscape.

SpaceX’s approach—where requirements serve the mission, not the other way around—is a model for modern systems engineering. For legacy organizations stuck in the JPL trap, the lesson is clear: stop pretending nothing will change, and start building systems that thrive on it.

chapter-7-requirements-vs-design-criteria

cover-lp-chapter-7

How can leaders practically roll out a modern approach to flexible requirements and empower teams while hitting mission constraints. __Read more →__

Chapter 7  — Requirements vs. Design Criteria

“Using agile for safety-critical systems will get people killed.” Wrong.

People often say “Agile vs. Regulatory” or “Agile vs. Safety,” implying they are in conflict. This is a misconception. The misunderstanding comes from a flawed assumption: that iteration means “just do stuff and see what happens.” It doesn't.

Consider **SpaceX Dragon** as an example.

When people look at the process and rigour needed when going from Crew Dragon V3 to V4, they assume the same level of detail existed in Dragon V1. It didn’t.

This assumption is understandable. Many people look at the *end state* (e.g., the complex process for going from Crew Dragon v3 to v4) and assume **they need to start there** for Dragon v1.

They assume they need to design everything perfectly from the start. That is incorrect. It all comes down to **scoping and iteration.**

The biggest mistake? Designing backward from regulations. Certification docs from the FAA don’t design aircraft.

Instead, we advocate for **designing iteratively** and bringing in regulatory considerations as you go. But it’s a fine balance. You also shouldn’t wait until the end to validate regulatory requirements or you risk sinking your timeline.

> 
> "It’s typically better for a startup to start at speed and then add rigor once you're starting to make mistakes than it is to start with a whole bunch of rigor and then try to retrofit speed into that. Adding speed to rigor is something I've never seen work, but adding rigor to speed is something that I’ve seen work really well."
> <footer><img src="//images.ctfassets.net/c2mtbunjxyfe/1z3EdJiXi9zxVQbpLgn9Ls/f8eb6cf4e9524711d89a54f2c9afcedd/pari-flow.jpg" /><author>Pari Singh</author><position>CEO, Flow Engineering</position></footer>
> 

Even teams that take an agile approach fall into a set of common traps when designing safety-critical systems. Let’s get started.

## Iterations in the Context of Certification

Iteration means taking calculated risks early in development to achieve a higher safety at production faster and with lower cost.

Each step is planned to work the first time—though the program as a whole might not work perfectly at first.

Most agile companies progress through something like the following iterations:

1. **V0** Something that looks good (e.g., for investors) but doesn’t work at all.
2. **Tech Demo** A functioning system or subsystem to prove you’re *real*. This is not the end goal, but it's real engineering done quickly.
3. **Integrated Iterations** (V1, V1.1, etc.). Continuously test and improve the *core system* (e.g., core engine tests, cooling system, powertrain).
4. **Complete System Prototype** More advanced, closer to a functioning product.
5. **Real Product** Something that truly *works*. This is what you might bring to the FAA, though it’s still not “flyable” or “road legal” yet.
6. **Certified Product** The final product that meets regulatory requirements.

Achieving these iterations requires more than just good engineering. __Three key teams__ must work together along this path.

__Engineering__
Engineers primarily work in CAD. They are the people who do the actual hands-on development.

__Systems Engineers__
Systems engineers live in requirements tools (e.g., Flow), Excel, ICDs, and meetings. They determine what to build, why it’s needed, and how everything integrates.

__Certification__
Certification teams work in FAA/EASA documents, forms, and reports. They prove the system is safe to regulators and keep them satisfied—often years before a final product is complete.

However, these three teams operate on very different cadences and speak very different “languages.”

A natural question is, “How do we bring them together into one integrated unit?”

Short Answer: __Don’t.__

Reason: They are doing three different jobs. You don’t want them to become a single group because each role requires different approaches and focuses. Yet, in order to succeed:

- Engineering & Systems Engineering should operate on the same cadence (requirements → design → iterate).
- Certification runs on a different cadence (what do we need to start doing now to satisfy regulators long-term?).

When teams ignore these differences or try to force a single, unified process, they often derail agile efforts. Common failure points include misaligned timelines, over-documented initial designs, and late regulatory surprises. Leadership is key to managing these diverse cadences. By guiding each group to focus on its unique objectives—and aligning them at key milestones—agile methods can thrive, even in safety-critical projects.

### Prototype → Certified Product: Parallel Paths

Designing safety-critical systems requires more than just good engineering—it demands early and ongoing attention to the certification process. Leadership sets the tone by integrating certification needs into each step of development, rather than tacking them on at the end. This ensures compliance and safety grow in tandem with the product.

![table-going-from-prototype-to-certified-vehicle](//images.ctfassets.net/c2mtbunjxyfe/2qHeBE8Nv1upMbzdJGS30h/a3fa4bebb8bd3b0c6cc77ef84e520d6a/Screenshot_2025-03-06_at_11.24.03_1.png)
*Visualisation of the parallel path and different cadences of engineering and systems and certification*

**Engineering/Systems**
Move quickly with iterative designs, adding more requirements and detail over time.

**Certification**
Works in parallel, preparing the evidence/regulatory framework needed to certify the final product.

> 
> "We make sure that Engineering and Systems Engineering operate on the same cadence, while Certification runs on a different cadence. What do we need to start doing now to satisfy regulators long-term? That’s a different timeline from designing and iterating on a product, and if you mix the two, you get misalignment."
> <footer><img src="//images.ctfassets.net/c2mtbunjxyfe/2GfutJmK86CkY7tWKYzRgA/efff21c543a9b910b4bd7770e339ab79/Group_674.jpg" /><author>John Alser</author><position>Head of Electrical Engineering, Radiant</position></footer>
> 

### Treat Iterations as Configurations/Variants

Early prototypes should have only a handful of requirements (e.g. thrust, flight, power on/off). With each iteration, teams add more fidelity, data, and proof. By the time you reach a certified vehicle, you may have 10,000+ requirements.

That doesn’t mean you should *start* with 10,000.

- Each iteration increases in complexity and fidelity.
- Early prototypes (**2–3 requirements**).
- Successive iterations add more capabilities and more proof.
- Certified vehicle (**10,000+ requirements**).

Designing safety-critical systems requires more than just good engineering—it demands early and ongoing attention to the certification process. Leadership sets the tone by integrating certification needs into each step of development, rather than tacking them on at the end. This ensures compliance and safety grow in tandem with the product.

## Implementing Agile Certification in Practice

1. __Hire Certification People Early__
They are on the critical path, ensuring safety and compliance are integrated from the beginning. Delaying their involvement risks expensive rework and design drift.

Certification Won’t Be Doing the Main Bulk Immediately. Early on, they set up frameworks for documentation, testing, and risk assessment. This groundwork keeps the project aligned and prevents last-minute chaos.

2. __Establishing two parallel tracks helps keep design flexible while meeting regulatory requirements.__

One track handles __Design Requirements__ (Design Criteria), which is softer and evolves rapidly. The other focuses on __Certification__ (Regulatory Requirements), which is more rigid and aligned with specific standards (FAA, EASA, NASA, etc.). By mapping these requirements back to the systems, both design and certification stay connected without blocking each other’s progress.

__Design Requirements Project__
Begin as one project and split later if it grows too large. Expect the details and fidelity of requirements to change with each iteration, reflecting lessons learned and new engineering data.

__Certification Project__
Centralize all certification activities to maintain clarity on standards. Mark each requirement with the relevant regulatory framework and capture the complete set of obligations, ensuring none are overlooked.

> 
> "Carving out the critical characteristics of the system that need to be safe is really key. There are parts of a nuclear reactor that must be designed right to be safe, and then there are quite a few parts that are needed for it to function but don’t necessarily inherently tie into safety. So, we identify those segments and say, 'These are the ones that need utmost rigor, and these are the ones where we can move faster."
> <footer><img src="//images.ctfassets.net/c2mtbunjxyfe/2GfutJmK86CkY7tWKYzRgA/efff21c543a9b910b4bd7770e339ab79/Group_674.jpg" /><author>John Alser</author><position>Head of Electrical Engineering, Radiant</position></footer>
> 

3. __Embrace Parallel Development__
You can’t certify what doesn’t yet exist, so certification and design must advance in parallel—often for years—until the real product is ready. This approach allows each track to focus on its core tasks while still contributing to the overall safety and compliance of the final product.

### Leadership’s Role in Agile Certification

- __Provide Ongoing Support__: Leadership should ensure certification experts have the resources and authority to guide design decisions, even if their workload is light at first.
- __Champion Cross-Functional Communication__: Encourage direct collaboration between Engineering, Systems Engineering, and Certification. Each team must understand how its work impacts the others.
- __Align With Regulatory Timelines__: Leaders should anticipate regulatory checkpoints, funding, and staffing needs so that certification doesn’t become a bottleneck.
- __Emphasize Transparency__: Create a culture where findings—both successes and failures—are shared openly, building trust with internal teams and regulators.

## Recommendations

__Develop a Real Relationship with Regulators__. Bring engineering leads, systems engineers, and certification folks together in conversations. Build trust by maintaining open lines of communication and sharing progress regularly.

__Go Above and Beyond the Reports__. Provide regulators access to core design and engineering data, not just final deliverables. Show your work: share test data, assumptions, and engineering rationale so regulators see the depth of your safety culture.

> 
> "You have to document __rationale__ in your requirements. That’s a key thing a lot of organizations miss. There are so many times where you will create a requirement with some number in there that was really just pulled out of nowhere for convenience… but later, no one knows where it came from. Having that written in the rationale will let people who come back later understand that this isn’t a hard requirement—it was just a place to start."
> <footer><img src="//images.ctfassets.net/c2mtbunjxyfe/2GfutJmK86CkY7tWKYzRgA/efff21c543a9b910b4bd7770e339ab79/Group_674.jpg" /><author>John Alser</author><position>Head of Electrical Engineering, Radiant</position></footer>
> 

__Track Your Assumptions__. Don’t just track requirements; track the design inputs *(NQA1)*. Document where these inputs come from and how they evolve. These assumptions often shape the entire safety case, so clarity is vital.

### Additional Notes and Clarifications

Throughout each iteration, __(1) capabilities gradually increase__, and the role of a Requirements Engineer (RE) spans systems engineering, project management, and hands-on design.

This __(2) iterative method__ is more common in space (like SpaceX) but can still work in traditional aerospace, where it’s sometimes seen as harder to adopt.

Aim for __(3) fixed reliability, increasing capability__. Despite the need for flexibility, “iteration” doesn’t mean “just do stuff and see what happens.” Each step is planned to work on its own, though the overall program might not be flawless at first.

Within each iteration, there’s often a __(4) mini-waterfall—from requirements to design__, build, and test. Turbulence is normal because you’re testing assumptions by doing, not just by analysis. 

Avoid the __(5) analysis trap__: perfecting every calculation can slow real progress. Often, it’s better to build something and learn from tangible data than to rely on endless models.

### In summary

Iterate quickly on engineering and systems. Keep certification in the loop and evolving. By the time you reach your final product, you’ll have all the data and requirements needed to prove compliance—and you won’t be stuck designing everything up-front.

- **Start small** with minimal requirements for early prototypes.
- **Iterate** rapidly to refine design and increase functionality.
- **Run certification work in parallel**, building trust with regulators and mapping the final, large set of requirements.
- **Don’t let regulations drive the initial design**; regulations and certification should inform the design as you progress, not dictate it from day one.

chapter-8-regulatory-and-agile

Radiant

Radiant Nuclear

cover-lp-chapter-8

Practical advice for leaders on merging speed and compliance in safety-critical industries. **Read more →**

Table of contents

Chapter 5 — Scoping in Practice: From Minimal Viable Technology to MVP

Chapter 6 — Concurrent Engineering: Working in Parallel with Evolving Requirements

Chapter 7 — Requirements vs. Design Criteria

Chapter 8 — Regulatory and Agile: Iterative Certification for Real-World Safety

Agile Systems Engineering Briefing

Monthly newsletter and examples on building better iterative engineering cultures from teams like SpaceX, Stoke and Impulse Space.

Product

Company

Legal

Resources