Quick answer: we ship small changes every week by keeping each change small enough to go live on its own, choosing a short list for each product at the start of the week, and checking every change on a desktop and a phone before writing it up for customers. Small changes are easier to test, undo and follow.
- We ship in small pieces because small pieces are easier to check, explain and reverse.
- Customer problems go to the top of each week’s list, ahead of new features.
- Nothing counts as shipped until it has been seen working on a desktop and a phone.
Unavoidable Studio builds and runs several products at once, including Unavoidable CRM, AisleReply, Unavoidably Secure and Unavoidably Social. People sometimes ask how a small team ships anything across that many products. The honest answer is that we do not ship big things. We ship small changes every week, product by product, and let them add up.
Why do we ship small changes rather than big releases?
Because a small change has fewer ways to go wrong, and when it does go wrong, you know where to look. A release that bundles twenty changes can break in twenty places at once, and working out which one caused the problem takes longer than the fix.
This is not our idea. The GOV.UK Service Manual’s core principles of agile describe “regularly releasing and testing small features with your users” and asking for feedback “early and often”. For a studio with several products, small releases also keep one product from swallowing everyone’s time for a month while the others stand still.
What does a week of shipping look like?
A week starts with a short list for each product and ends with a review of what went live. In between, changes go out as soon as each one is ready and checked, rather than waiting for a release day.
- Start of the week: write a short list for each product, in priority order, with each item described in one sentence.
- During the week: work down the lists, one change at a time. Each change goes live on its own once it has been checked.
- End of the week: look at what actually shipped, what slipped and why, and carry anything unfinished to the top of next week’s list.
The lists are deliberately short. If an item cannot be described in one sentence, it is too big and gets split. That one habit does more for our pace than any tool.
How do we choose what goes into the week?
Problems customers have told us about come first, then changes that save customers effort, then new features. That order sounds obvious, but without writing it down it is easy to spend a week on an exciting feature while a confusing screen keeps costing people time.
The signals we use to judge whether a product is working, described in the product market fit signals we watch, feed straight into this. If customers keep asking the same question, the fix is usually a small change to the product rather than a longer help page.
How do we keep quality up when we ship often?
By treating checking as part of the change, not a step after it. Three rules do most of the work:
- Change the live thing in place, with a backup. We edit the current version rather than rebuilding from an old copy, and we keep a backup of what was there so any change can be put back in minutes.
- See it on a desktop and a phone. A change is not done until someone has looked at it working on both. Plenty of layouts that look fine on a laptop fall apart on a phone.
- One change at a time. If two changes go out together and something looks wrong, you cannot tell which one caused it.
Shared foundations help as well. The parts every product needs, from hosting to sign-in patterns, are built once and reused, as set out in shared infrastructure across a studio. Each weekly change then touches only what is unique to that product.
How do we tell customers what changed?
Each product keeps its own record of what changed, in plain words, written for its own customers. Unavoidable CRM, for example, has a public changelog. A good entry says what is different and why it matters to the customer, not how it was built.
Writing the entry is also a useful test. If a change is hard to explain in a sentence, it is often a sign the change itself is muddled. We share the process in the open for the same reason, as explained in why we build in public.
What do we hold back from the weekly rhythm?
Changes that affect what customers pay, what they have agreed to or what they rely on every day get notice rather than a quiet weekly release. That means pricing, legal pages and removing a feature someone uses. Those still ship, but with a heads-up first, so nobody is surprised.
Keeping that line clear is part of how one team can look after several products, which we cover in more depth in running several products with a small team.
FAQs
Does shipping every week mean more things break?
It should not. A small change is easier to check before it goes live and easier to undo if something is wrong, so problems tend to be smaller and shorter. Big releases are where several problems arrive at once.
How small is a small change?
Small enough to describe in one sentence and check in one sitting. A clearer button label, a fixed reminder email or one new field on a form all count. A new module does not: we break that into pieces that can each go live on their own.
Do all the products ship on the same day?
No. Each product has its own list and its own customers, so changes go out when they are ready and checked. What we share across the studio is the routine, not a single release day.
Where can I see what has changed in a product?
Each product keeps its own record. Unavoidable CRM, for example, has a public changelog on its website. For the studio side, the blog is where we write up how we work.
For the full list of products, visit the portfolio, and for more from the studio, browse the blog.
Founder of Unavoidable Studio, a UK venture studio in Leeds building six software companies at once. Answers his own inbox.