The Operator's Week: A Rhythm for Running Several Small Products at Once
Ask an operator with several small internet products what they did last week and you'll usually hear a list with no shape: a bug here, a customer email there, a half-started feature, three dashboards glanced at out of anxiety rather than schedule. Every product got touched; nothing got moved. The portfolio didn't fail that week — but multiply that week by a year and it will have quietly failed without a single dramatic moment to mark it.
The failure mode: round-robin attention
The natural way to run several products is to rotate: give each one attention when it asks for it, loudest first. It feels responsible — nothing is neglected — and it is precisely how everything stagnates at once. Round-robin attention has two structural problems. First, it allocates your best hours by squeakiness rather than importance, and squeaky is almost never the same as important. Second, it makes progress on any single product asymptotic: every product gets enough attention to stay alive and none gets enough to change state. A portfolio run this way converges on maintenance-only, and a portfolio that is all maintenance is a museum with hosting costs.
The fix is not working more. It's refusing to let the week be shapeless — deciding in advance what kind of attention each day carries, so that important work gets concentration and routine work gets a schedule instead of a mood.
The four blocks of the week
One mover, chosen on Monday
Each week, exactly one product is the mover: it gets the deep-work hours, and the win condition is written down in one sentence before the week starts. Ship the redesigned signup. Get the new pricing live. Close the integration. Everything else in the portfolio is explicitly in maintenance mode that week — and that's a sentence worth saying out loud, because guilt about the products you're not advancing is what pulls operators back into round-robin. The mover rotates over the month by deliberate choice, not by whichever fire burned most recently. A product can be the mover two weeks running if the work deserves it; a product can also wait a month, and survive waiting, because maintenance mode is a real mode and not a euphemism for abandoned.
Maintenance on a timer, not a feeling
Checking dashboards is either a scheduled task or a nervous tic — there is no third thing. The maintenance block is a fixed, bounded window: uptime and error checks, queues and backups verified, the small recurring chores done, each product visited on its checklist. Bounded is the operative word. Maintenance expands to fill any container it's given, because it always feels productive and never requires courage. Give it a container. When maintenance uncovers something big, it doesn't get fixed in the maintenance window — it gets written down as a candidate for next week's mover slot, which is exactly the discipline that keeps one broken thing from silently consuming the week.
Support in batches, with honest exceptions
Interrupt-driven support is the most expensive habit an operator carries, because its cost is invisible: each individual reply is five minutes, and the context-switch it forces destroys the half hour around it. The batch rule: support gets answered in one or two fixed windows a day, and customers learn the rhythm faster than you'd expect — a reliable answer at a predictable time reads as more professional than an instant answer at a random one. The honest exception is the genuine outage or the payment failure, which interrupts everything, mover included. The skill is keeping the exception narrow: an operator who treats every question as an outage has decided, without noticing, that strangers schedule his week.
The Friday review that closes the loop
The week ends with a short written review: did the mover hit its sentence, what did maintenance surface, what does each product's health look like against its own baseline, and — the question that actually steers the portfolio — what is the strongest candidate for next week's mover. Written matters. A review that lives in your head is a feeling; a review on paper is a record you can disagree with later. Over months, the stack of reviews becomes the portfolio's memory: which products keep earning the mover slot, which keep generating maintenance load without generating anything else, and which have quietly become candidates for the harder conversation about killing things.
Why one mover beats two
The objection arrives immediately: surely two movers a week means double the progress. It doesn't, and every operator who has tried it knows the specific way it fails — both projects advance to eighty percent, and eighty percent shipped is zero percent shipped. Deep work doesn't divide cleanly; the residue of one project contaminates the concentration of the other. One mover per week is not a limitation to outgrow. It is the mechanism doing its job: forcing the ranking decision — which product, this week, deserves the scarce thing — that round-robin exists to avoid making.
Making the rhythm hold
- Put the blocks on the calendar as appointments, including maintenance. An unscheduled rhythm is a wish.
- Write the mover's win sentence where you'll see it daily. Vague movers produce busy weeks and empty reviews.
- Keep a parking file for mid-week ideas and non-urgent breakage. The rhythm dies by a thousand reasonable-sounding interruptions, and the parking file is where they wait to be judged on Friday instead of acted on at the moment of maximum enthusiasm.
- Let automation own the schedulable work — reports, checks, publishing, follow-ups — so the maintenance block is review, not labor.
- Protect one block for nothing at all. A week packed to the edge has no capacity for the genuinely unexpected, and portfolios generate the genuinely unexpected on their own schedule.
None of this is sophisticated, which is rather the point. Operators don't lose portfolios to insufficient cleverness; they lose them to shapeless weeks, each one locally defensible and collectively fatal. A rhythm — one mover, timed maintenance, batched support, a written review — is the cheapest piece of infrastructure a portfolio can own. It costs a calendar and some stubbornness, and it is the difference between running several products and being run by them.
Common questions
What if two products both genuinely need to move in the same week?
Then you've found the ranking decision the framework exists to force. Pick the one where a shipped week changes more, and give the other the first claim on the following week. If both are truly urgent every single week, the portfolio is telling you it's one product too wide for its operator — which is better learned from a calendar than from burnout.
Doesn't batching support hurt customers?
Predictability beats speed for almost all support. A reliable answer within a known window reads as professional; an instant answer at random hours mostly trains customers to expect interrupts you can't sustain. Keep a narrow real-emergency exception — outages and payment failures — and let everything else meet the rhythm.
How is this different from just doing sprints?
Sprints plan one product's work in cycles; the operator's week allocates one person's attention across several products. The mover slot borrows the sprint's focus, but the framework's real work is done by the other three blocks — scheduled maintenance, batched support, and the written review — which exist precisely because a portfolio, unlike a single product, fails through diffusion rather than through missed deadlines.
Every property in the Don Gastón portfolio is independently live — built, deployed, and operated by one person.
See what's live in the portfolio