Prep
Interviewer research, Flow team bios, mock scenario framing, and the demo principles I'm running. Per-prospect run sheets live on /rivian and /anduril.
The two mock scenarios
Task 1 — Rivian is a new prospect. You are pitching Flow to them for the first time. The interviewer plays Rivian Head of Systems Engineering evaluating whether to purchase. Treat this as a first sales call. Do not reference Rivian as a customer story — use Joby or Astranis if you need a reference.
Task 2 — Anduril is an existing Flow customer.20 systems engineers are active on the platform. Domain engineers (ME, EE, SW) haven't adopted it and see it as extra admin work. Your job is behavior change, not a purchase decision. Close with a concrete live action, not a next-step conversation.
Background only (do not say in either demo):In reality, Rivian is an actual Flow customer with 1,500 engineers on the platform. Scott MacKenzie, Rivian's Director of Product Development Process and Tools, is publicly quoted: “Flow really opened up our collaboration around product requirements.” This is why the Rivian persona will be knowledgeable and push back realistically. It makes Task 1 harder, not easier.
Attendees
Will not be on the call. He scheduled the meeting via Ashby. We both worked at Flexport. LinkedIn: bobbydunne. Useful for follow-up, not the demo itself.
Will play Rivian Head of Systems Engineering for the mock. Trained on what good looks like for this role. Has seen candidates who tour features vs. candidates who nail problem framing. Testing whether you can run a real sales call, not whether you know Flow's UI.
Flow team bios (deep cuts)
Imperial College MEng. Built a hybrid rocket engine consultancy at 22, the internal tool became Flow. Forbes 30U30 Europe 2019.
Two weeks ago (April 15): Published Chapter 1 of the AI Systems Engineering Handbook. 565 LinkedIn comments. Core thesis:
“AI reduces design cost 10x, creates 10x more artifacts, creates 100x the alignment problem. You need structured requirements data for AI agents to work. That's Agentic Systems Engineering.”
Beat 5 of the demo is the live proof of this thesis. Mention “Agentic Systems Engineering” or “continuous alignment” and the interviewer will know you did the homework.
Imperial College MEng. Mercedes-AMG F1 trackside team (2017-2018 championship seasons). AMG One hypercar. Employee ~1 at Flow. Defined what FDE means here.
LinkedIn: “At Flow we focus on spending as much time as we can, every week, with customers.” The Rivian rollout was FDEs embedded directly with teams, migrating data, adapting workflows, training engineers across disciplines. That's the bar.
Previously RVP of Sales at Hightouch. Command of the Message certified (Force Management value-based selling). Joined Flow March 2026 to build the GTM org.
His announcement post explicitly calls out hiring FDEs alongside AEs. He's evaluating whether you can own customer outcomes end-to-end. FDE is a revenue-generating embedded role in his model, not a support function.
The meta layer (the inception angle)
Pari's core claim: “You need structured requirements data for AI agents to work.” My cowork monorepo is the same idea applied to knowledge work. I built a structured, context-rich research system: Flow's handbook ingested, the sandbox reverse-engineered into a walkthrough, decisions version-controlled, all interview artifacts in one repo. AI agents reasoned over that structure to write the MCP server, the script, and the slides.
I didn't build a custom model. I built the data structure. That's exactly what Flow does for hardware teams. When this comes up in the demo, it's not an analogy. It's proof I think in the same paradigm Pari is staking the company on.
“One thing I want to be upfront about before we debrief: pretty much everything I just showed you, including the script and the MCP behind Beat 5, came out of an AI-assisted prep workflow I built specifically for this interview. Research monorepo, handbook ingested, sandbox reverse-engineered into a walkthrough, script written and rewritten by agents working over structured context. I mention it because if I joined Flow, that's the actual workflow I'd bring to customer prep. Not just ‘I use AI.’ A structured system that produces artifacts. Same thing Flow is building for hardware teams.”
Say it once. Don't over-explain. Move on.
“Yes, in about a day, working the same way I'd work as an FDE. The MCP is one artifact. The more interesting thing is what's behind it: a research workspace where the handbook is ingested, the sandbox is reverse-engineered into a walkthrough, and the script was written and rewritten by agents working over that structured context. Pari's thesis is that you need structured requirements data for AI agents to work. I'd describe what I built as the same idea applied to prep work.”
Demo principles I'm running (Sales Feed)
Source: How to Present a MIND-BLOWING Software Demo That Closes Sales (Sales Feed, 10:49). The 8 ideas the run sheets are built around.
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.
Handbook — what to read before the demo
The recruiter said: “Throw the handbook into AI for a summary — it gives more detail about what to highlight in this interview.” Read 9, 11, and 13 first if time is short. The vocabulary from these chapters is what the interviewer will recognize.
Beat 1 + 2 cultural foundation. Requirements as design criteria the team owns, not a contract a PM hands down. Use this vocabulary when explaining the Report view.
Beat 3 vocabulary source. External-facing requirements (what the system shall do) vs. internal design criteria (the numbers teams trade). The interviewer will recognize this language.
The certifications objection handler. ISO 26262, DO-178C, AS9100. Flow's Iterations feature = signed baselines per gate = compliance evidence. Know this for the CoDR Entry moment in Beat 4.
The nested V-cycle model (V0 → V1 → V2 → V3). Each cycle is a bounded engineering experiment. The conceptual backing for 'run the pipeline every day' in Beat 3.
Requirements flow down, subsystem constraints flow up. Live mental model behind Beat 2 — the Cooling Subsystem lead inherits constraints, and when bottom-up reality conflicts with top-down intent, the gap shows immediately in the verification column.
'CI/CD for hardware' defined. Beat 3 and Beat 4 language comes directly from here. Key phrases: 'build to find problems,' 'bounded engineering experiment,' 'scope → build → test → verify → feedback.'
Change management story. When a design value changes, dependent interfaces and requirements see it immediately. Directly visible when you change an Onshape parameter and Flow re-derives the design value.
Vocabulary to use on purpose: “CI/CD for hardware,” “continuous verification as an operational pulse,” “build to find problems,” “nested V-cycles,” “bounded engineering experiment,” “interfaces in the loop,” “design criteria.”