Every regional team we work with faces the same arithmetic: a fixed launch date, a distributed crew across two or three time zones, and a backlog roughly twice the size of the calendar. The teams that ship anyway are not the ones with more people. They are the ones with a stricter method.
Over the last few years our squads have settled on a playbook that works under real deadline pressure. It has three parts: discovery that ends on time because it is time-boxed, a backlog ordered so brutally that the top is always shippable, and weeks that end in a demo rather than a status meeting.
Time-box discovery to ten days
Discovery fails when it has no end date. Give smart people an open-ended research phase and they will keep researching, because there is always one more stakeholder to interview and one more edge case to map. So we put discovery in a box: ten working days, a named decision-maker on the client side, and a single written output — a scope small enough to build in the time remaining.
Inside those ten days we run stakeholder interviews in the first half and prototyping in the second. The prototype is clickable but ugly on purpose; its job is to force decisions about scope, not to win design awards. On day ten the client signs a fixed scope, and whatever did not fit goes on a phase-two list that nobody is allowed to feel guilty about.
- Days 1–5: interviews, systems access and technical spikes on the riskiest unknowns.
- Days 6–9: a clickable prototype tested with five real users.
- Day 10: signed fixed scope plus an explicit phase-two list.
- One rule throughout: no new requirements without removing something of equal size.
Prioritise ruthlessly, demo weekly
Once building starts, the backlog gets one ordering principle: if the project stopped today, the top of the list must already be worth launching. That means the boring load-bearing work — logins, data imports, the checkout path — comes before polish, admin screens and nice-to-have reports. Ruthless sounds harsh, but clients love it once they see a working product in week two instead of slideware.
Each week ends with a demo of running software, not a progress report. Demos do two jobs at once: they surface misunderstandings while they are still cheap to fix, and they keep distributed teams aligned without daily meetings across time zones. A fifteen-minute recording, shared the same afternoon, beats an hour of synchronous stand-ups.
"A tight schedule is a design constraint, not an excuse. It tells you exactly what matters."
The result is unglamorous and reliable: smaller launches that arrive on the date promised, with a phase-two list the client is genuinely excited about instead of a phase-one apology. Tight schedules do not reward heroics. They reward teams that decide fast, build the important half first, and show their work every single week.
Related articles
Have a project in mind?
Tell us your deadline first — we will plan backwards from it.