How to set a release rhythm and ship in weekly cycles.

Speed of learning is the advantage of a small tech startup. Shipping small changes every week is how you turn that into practice. It also makes problems smaller: a release with three changes is far easier to fix than one with thirty.

Why it matters

Long release cycles hide risk. Work piles up, integration gets harder, feedback arrives late and the team loses the sense of progress. A weekly rhythm keeps everyone honest about what is actually done and gives users regular reasons to come back.

The weekly cycle

1. Plan at the start of the week. Take the top outcome from the roadmap, agree the smallest set of changes that moves it, and write each one as a clear task with a definition of done. Keep the list short enough to finish.
2. Build in small pieces. Break tasks so each can be finished in a day or two. Merge code into the main branch often, behind a feature switch if it is not ready for users.
3. Review and test as you go. Every change is reviewed by another person and covered by basic automated tests on the essential path. Test on a staging environment that mirrors production.
4. Release before the end of the week. Use a release checklist: tests pass, change notes written, database changes reversible, someone available to watch for errors after release. Avoid late-Friday releases.
5. Demo and review. End the week with a short demo of what shipped to the whole team, plus a look at the numbers and user feedback. Ask what to stop, start and continue.
6. Tell users. Publish short release notes or an in-product message explaining what changed and why. It shows momentum and invites feedback.

Supporting practices

• Automated deployment. Releases should be one command or one click. Manual deployments slow you down and cause mistakes.
• Error tracking and monitoring. Know about problems before users report them.
• A simple board. To do, doing, review, done. Limit how much is in “doing” at once.
• Shared rituals for remote teams. A short written daily update, one planning call and one demo a week is often enough.

The sample Product Execution Sprint shows how this rhythm can be run in practice, and the Product Execution Canvas keeps each cycle tied to an outcome.

Worked example

FleetNote was releasing once a month, with each release taking two days to stabilise. The team moved to weekly cycles: Monday planning tied to one roadmap outcome, daily merges behind feature switches, a release every Thursday morning and a Friday demo. They added automated deployment and error alerts in the first fortnight. Within two months they were shipping four times as often, release fixes dropped to a few hours, and pilot customers commented that the product “keeps getting better”.

Common mistakes

• Overloading the week and carrying half-finished work forward.
• Tasks too large to finish in a day or two.
• Skipping reviews and tests to hit the release, then losing days to bugs.
• Releasing without anyone watching for errors afterwards.
• Shipping without measuring, so you never know whether a change helped.
• Letting urgent bugs hijack the week. Keep a small, agreed allowance for fixes so planned work is not constantly displaced.

When weekly is hard

Some products, such as native mobile apps awaiting store review or hardware-linked systems, cannot reach every user weekly. Keep the weekly rhythm internally anyway: build, test and release to a small group of testers or internal users each week, and batch public releases every two to four weeks. The discipline of finishing small pieces matters more than the exact release date.

What to measure

• Releases per week.
• Share of planned tasks completed each week.
• Time from starting a task to it being live.
• Share of releases needing a fix or rollback.
• Time to recover when something breaks.