The two-week product sprint — what fits and what doesn't

Most engagements that fail were never going to fit in two weeks.

Not because two weeks is too short. Two weeks is plenty of time to ship something real. They fail because the scope was wrong the moment the kickoff call ended — and nobody caught it because nobody wrote down what fits.

This is what fits.

The premise

Fixed scope. Two weeks. One person from kickoff to handoff. One measurable outcome.

That last constraint does the actual work. If you can't name one thing that has to be true by Friday of week two, you don't have a sprint — you have a research project with a calendar artifact glued on top.

What fits

Engagements that fit, end-to-end, inside a two-week window:

A single user flow, end-to-end. Signup → core action → first value. Real backend, real UI, deployable. Not "an MVP" — one slice.
A redesign of one surface. The pricing page. The onboarding flow. The marketing site hero. Replace, ship, instrument.
An API integration + the UI that uses it. Stripe → invoice surface. Twilio → SMS-driven scheduling. The vendor SDK does most of the work; you ship the human-facing edge.
A launch reel + the landing-page hero. 30-second product video, hero copy, three supporting blocks, instrumented. Done.
An architecture audit with deliverables. Stack review against one stated goal (scale, cost, migrate-off-something). Risk register, cost model, handoff brief.

The shared shape: one user, one flow, one outcome. When you can describe the win in a single sentence, the work fits the format.

What doesn't fit

A non-exhaustive list of things I'd turn down — or have watched fail in someone else's hands:

"Build me an MVP." Not a scope. A wish. An MVP is six flows, none of them prioritized. Pick the one slice that produces value first; then we have a sprint.
Anything that needs a research phase first. "I need to validate this idea, then build it." Validation is its own engagement. Don't pretend it fits inside the build.
Multi-flow products from zero. If onboarding, dashboard, settings, billing, and admin all need to exist on launch day, two weeks is not the answer. Twelve weeks might be.
Migrations that touch live data. Migrations need rollback paths, dual-write windows, and a maintenance plan. The work isn't the migration — it's the safety net around it.
Anything blocked on someone else's slow review cycle. If your legal team takes ten business days to approve copy, your two-week sprint just lost five.

If you read that list and think "we can probably get away with it" — you can't. Each of those failure modes was learned the hard way.

The scope memo

Before any sprint kicks off, there's a one-page memo. Both sides sign it. It contains:

The one measurable outcome. Single sentence. "By Friday of week two, a logged-in user can book a slot and receive an SMS confirmation."
What's IN scope. Bulleted. Specific. "Booking UI; calendar API integration; SMS via Twilio; a one-page admin to view bookings."
What's explicitly OUT. This list is more important than the IN list. "No payment flow. No admin user management. No analytics dashboard. No mobile-native UI."
The change-order rule. "Any addition to scope pauses the sprint, gets a written estimate, and resumes only after both parties confirm."
The check-in cadence. "Async daily in Slack. One synchronous call mid-sprint. Working demo at end of week one for an early signal."

The memo is the engagement. The sprint is its execution. Skip the memo and you'll spend half the sprint re-litigating what was supposed to fit.

The "extend the sprint" question

It comes up every time, usually around day eight, after the week-one demo. The client sees what's possible and wants more.

The honest answer: yes, but it's a new sprint. New memo, new scope, new price, new dates. Not a rolling extension. Sprints that "just keep going" are how a two-week engagement quietly becomes a six-month consulting relationship with no exit criteria — bad for them, bad for me.

If the next phase fits the same shape (fixed scope, single measurable outcome), we run another. If it doesn't, that's a real project and needs a different engagement model — retainer, embed, fractional-something. Pick the shape that fits, don't shoehorn.

When to walk away

The clearest signal that a prospect isn't ready for a sprint is when you ask "what's the one thing that has to be true on the last day" and they can't answer in one sentence.

Two sentences, fine. Three, we have work to do before the work. Five, this isn't a sprint — it's a strategy engagement disguised as a build, and pretending otherwise will fail both of us.

Walking away is part of being honest about the format. I'd rather not take an engagement than take one that was never going to ship.