Assumptions Video Walkthrough

Project-specific video explaining methodology and assumptions.

Assumptions Video Walkthrough

Priority: Should Have

Add a project-specific video to the onboarding flow where the client watches an explanation of how the engagement works, the assumptions behind the quote, and what to expect. Checkbox confirmation: "I watched the video and understand the approach."

Why This Matters

Deep Work evidence:

The assumptions video was Deep Work's most effective expectation-setting tool. From the Typeform onboarding (Step 3):

"Please watch the following short video. It's important you don't skip watching. In order to come up with our quote and proposal, THE COMPANY has made a series of assumptions. These are important because they create a baseline for estimating the project. If any of these assumptions change, the budget, schedule and project plan put forth to accomplish the goals of the project may need to be re-evaluated."

This was followed by a separate confirmation screen — "I watched the video" — because it matters that much. Two separate acceptance steps for one video.

Why it works:

  • Video is harder to skim than text (people actually absorb the content)
  • Sets personal tone (client sees and hears you, builds trust before Day 1)
  • Creates a reference point for mid-sprint conversations ("as I explained in the video...")
  • Reduces "but I thought..." conversations during the build

Research Tech gap:

The Research Tech onboarding had written terms and assumptions but no video walkthrough. This worked for Bartosz (technical founder, clear expectations, already trusted the process from warm introduction) but wouldn't scale to clients with larger teams, less sprint experience, or weaker warm connections.

What to Build

In the Founder Onboarding Flow

Add a video step between the engagement summary and terms acceptance.

Page: "How This Sprint Works"

  • Embedded video (Loom or YouTube unlisted, 3-5 minutes)
  • Content covers:
    1. Sprint methodology overview (one flow, one week, shipped to your codebase)
    2. Workshop expectations (2.5 hours, scope lock on Day 3)
    3. Async communication model (no calls during build days, updates via agreed channel)
    4. Deliverables (working code, user testing with real users, evidence-based iteration)
    5. What's NOT included (full redesign, multiple flows, backend architecture, ongoing support)
    6. Assumptions that affect the quote (if these change, we re-evaluate together)
  • Checkbox: "I watched the video and understand the approach"
  • Cannot proceed to terms without checking the box

In the Team Member Onboarding Flow

Embed the same video (or a shorter 2-minute version) in Page 1 of the team onboarding flow. Team members get the same context the founder has — just without the pricing and contractual detail.

Recording Process

Each video is recorded fresh for the project:

  1. After the pre-sprint call, record a 3-5 minute Loom
  2. Reference the specific flow being built
  3. Reference project-specific assumptions (e.g., "we're assuming your React codebase")
  4. Reference any constraints discussed on the call
  5. Keep it personal — face to camera, conversational, not polished production
  6. Upload to YouTube (unlisted) and embed in the onboarding flow

Total time: ~15-20 minutes including recording, uploading, and embedding.

Client-Specific Adaptation

  • Scope references change per client (which flow, which product)
  • Technical assumptions change per client (codebase, stack, existing design system)
  • Tone calibration per client — technical founders want directness (retrospective learning: "Sometimes it's hard to tell if the idea is stupid")
  • Length stays at 3-5 minutes regardless of complexity

How It Connects

  • Deep Work reference: deep-work-upfront-admin-reference.md Part 2, Questions 3-4
  • Deferred feature: next-client.md item #1 (marked "Priority")
  • Embedded in: sprint.zebradesign.io onboarding flow
  • Methodology principle: "The structure says no" — the video sets boundaries before the sprint starts

This was marked "Priority" in the deferred features list for good reason. Deep Work never shipped a project without it. The only reason it was cut from Research Tech V1 was time pressure on the first build.