Prep

Do the homework, arrive with a hypothesis about their pain, say it back to them before touching the demo. Their corrections tell you which beats to lean on.

Every beat has one designed aha. Don't show a feature and move on. Pause, look at the camera, check whether it landed. If it didn't, stop and find out why.

After a landing line, say nothing. Three full seconds. The temptation to fill silence with more features is where most demos die.

End every beat with a real question that forces them to contrast what they just saw with their current reality. Not 'make sense?' — something specific.

If they're disengaged or measured, name it directly: 'You seemed pretty measured about that. Is this something you already have, or is it something different you were hoping to see?' Better to know now than finish into silence.

At the close, tell them what they're thinking before they say it: 'Here's what I've seen happen at this point. Your team needs to discuss internally.' You drive the close, they don't.

The whole demo is structured around their problems, not Flow's feature list. Every beat opens with their pain and closes with the outcome in their language.

After the recap, explicitly ask if it's okay to spend 20 minutes on these specific problems. They say yes. Now they've bought into the structure.

• →Traditional requirements management was invented for external contracts. Applied internally, it creates adversarial dynamics. SpaceX dropped the word 'requirements' for internal design teams entirely.
• →NASA case study: requirements were used as a weapon. Engineers were told 'don't think about the wider system, just do what the spec says.' That created the functional silo.
• →The fix: systems engineers stop being administrative gatekeepers and become organizational connective tissue — enabling direct cross-team communication instead of routing everything through a bottleneck.
• →Start with informed guesses, label them as assumptions, update as data comes in. Breaks the circular dependency where everyone waits for a 'locked' requirement before doing any design work.
• →Quote from the chapter: "Every team must not always optimize locally to achieve mission-level success."

• →The difference is mostly psychological: requirements feel immovable, design criteria feel negotiable. Renaming them changes how engineers engage with them.
• →"The paradox of modern systems engineering: To start designing, you need a requirement. To write a requirement, you need the design." The answer is to start with an assumption and iterate.
• →Assign one owner per criterion. That person is accountable for hitting it, renegotiating it when conditions change, and communicating updates to affected teams. Five minutes with the owner beats 25 hours of document review.
• →Even external requirements from customers or regulators can be approached collaboratively: open dialogue about trade-offs rather than locking everything down early. Example: lighter payload sooner vs. heavier payload on schedule.
• →Pari Singh: "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.'"

• →Agile and regulatory compliance aren't in conflict. You add rigor to speed once you're moving; adding speed to rigid process almost never works.
• →Certification, Engineering, and Systems Engineering run on different cadences and should stay separate teams. Certification needs to be thinking years out while engineering iterates week to week.
• →Early prototypes carry 2-3 requirements; a certified vehicle carries 10,000+. You don't define all 10,000 up front — complexity accumulates through iterations as you learn what actually needs to be controlled.
• →Use when Rivian pushes back about automotive safety standards: the certification trail is an output of the iterative process, not a reason to skip iterations.
• →Pari Singh: "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."

• →The traditional V-model (one pass, requirements to validation) is replaced by nested V-cycles. Each cycle is a bounded experiment targeting specific unknowns with a demonstrable output at the end.
• →Hardware development mirrors software CI/CD: frequent integration, rapid testing, results fed back into design within hours. Verification isn't a phase-gate, it's an operational rhythm.
• →Anti-patterns: over-scoping iterations (building too much at once) and under-targeting risks (not being specific about what you're trying to learn). Speed without truth-seeking is chaos.
• →Skyler Shuford, COO Hermeus: "Build 'reps' with your team on the full lifecycle to build it into the culture."

• →When a subsystem constraint conflicts with a system-level goal, the gap surfaces immediately and triggers a decision, not a months-later surprise. Example: battery model projecting 74 minutes against a 90-minute flight requirement.
• →Responsible Engineers own specific components and propose design criteria based on real test constraints, not top-down dictates. Their assumptions are tagged and linked to verification methods so changes auto-propagate upward.
• →Successful teams move from hub-and-spoke (one systems engineer owns all requirements) to a graph model where every domain engineer keeps their own criteria current.
• →A weekly alignment rhythm keeps intent and reality in sync: what assumptions changed, which constraints updated, what's now out of envelope. Without that cadence, top-down and bottom-up drift silently.
• →Adam Thurn, Chief Engineer at Anduril: "Everyone needs to think like a systems engineer. If your widget is amazing, but the system doesn't deliver, no one cares."

• →Verification becomes a design input from day one. Every criterion has a verification plan when it's written, not when the hardware is done.
• →Every requirement carries a confidence level — assumed, proposed, verified, or frozen — so stakeholders know exactly how solid each number is at any point in time.
• →When a test fails, the requirement is auto-flagged, the responsible engineer is notified immediately, and a retest is scheduled after root cause is addressed. No manual tracking, no status meetings to find out what failed.
• →Pari Singh: "Things like temperature, thrust, dimensions, firmware logic — these aren't static. They're assumptions. They change daily, especially early."
• →Key demo phrases: 'build to find problems,' 'bounded engineering experiment,' 'scope, build, test, verify, feedback.'

• →Integration starts at V0, not after all subsystems are 'done.' Interfaces are testable contracts between teams from the beginning.
• →Every interface has a single responsible engineer. When underlying components change, that owner is automatically notified. Unclear ownership is the most common source of late-breaking integration failures.
• →Interface status: tentative (assumptions documented), confirmed (basic behavior tested), frozen (end-to-end verified). Nothing freezes without test coverage.
• →Adam Thurn, Chief Engineer at Anduril: "Everyone's work needs to interface with others. We need to think about how data flows, how control flows, how software and hardware interact."
• →Visible live in the demo: change an Onshape parameter, watch every dependent interface and requirement update immediately.