I’ve worked in 18-day all-hands hustles and year-long Sisyphean builds. Most teams argue about speed. The real question is how to stage risk. Shopify’s GSD cycle taught me a simple rule: reversibility determines speed. If a change is easy to undo, you can move fast and learn from users. If it isn’t, you slow down, get precise about requirements, and earn the right to ship.
Shopify’s GSD framework follows a Proposal → Prototype → Build → Release → Observe → Done cycle that typically lasts 3-6 weeks, prioritizing lean teams and high agency. Most importantly, each phase transition comes with a leadership review where any project can be stopped, modified, or approved. These reviews give teams permission to explore while containing risk.
There are two modes, decided by one factor: reversibility. Reversible changes need fast, hypothesis-driven work. Irreversible changes call for slow and methodical, requirements-driven delivery.
- Fast, hypothesis-driven mode: prototype quickly, focus on the riskiest assumption, measure, and expand if the hypothesis proves out. Learn fast with minimal spend.
- Slow, requirements-driven: clear requirements, incremental steps towards the goal, explicit cross-functional alignment, with a higher bar before release. Speed is less important than control.
Most commonly, I’ve seen the slow mode applied in fast mode environments. This feels like extensive planning, long strategic debate over theories, and huge research teams. It’s stagnation. These products are outpaced by a smaller, working solution.
Fast mode in a slow mode environment creates noise. It can feel chaotic, with solutions pointing in all directions. Without conviction, exploration is endless and investment becomes waste.
The mistake is not choosing fast or slow; it’s choosing the wrong one.
Regardless of mode, three principles hold.
- Start with the user pain, not a prescribed solution. Solve a frequent, high-impact, or costly need.
- Define the outcome you want to see, not the output. The change should be meaningful and measurable.
- Never forget the unit economics, operational load, or regulatory constraints; the weight of one is enough to crush a concept.