Disclosure: This article was generated with AI and reviewed against the source transcript.
A founder reserves Friday afternoon for customer research. On the first Friday, a support issue consumes the slot. On the second, a release runs late. The calendar still contains a research session, but the work has stopped happening.
In this hypothetical example, the missing piece is a decision about what happens when the normal plan becomes unavailable. Moving the calendar block again leaves that decision unresolved.
Justin Sung’s video “How to Build Systems to Actually Achieve Your Goals” offers a useful lens for this problem. He describes examining the conditions around a goal, reducing the effort needed to repeat the work, and gradually addressing the underlying problems that make temporary workarounds necessary.
My application of that idea is to give a recurring work routine an explicit recovery rule. Decide what deserves to happen on a disrupted day, how to preserve the work already done, and when the normal routine resumes.
Define a finished unit of work
“Do customer research” leaves many decisions until the moment the session begins. The founder still has to choose a question, find the relevant conversations, and decide what counts as useful progress. If the available time is shrinking, those decisions can consume the session.
A smaller unit might be: review one recent onboarding conversation, identify one unresolved difficulty, and save the observation with a link to the source. This is an illustrative workflow, not a proven research method. Its benefit as a design is that the finish line is visible.
The unit should still contribute to the real objective. Collecting a pile of disconnected quotations would be easy to count while doing little to improve a product decision. The founder needs a reason for reviewing that conversation and a place where the observation can inform subsequent work.
Before choosing a schedule, write down the output the routine is supposed to produce. Include where it goes and what happens next. A routine with a clear output is easier to resume because the next action does not have to be reinvented.
Design the interrupted version in advance
Sung discusses a person whose after-work study plan repeatedly collided with fatigue, travel, and family commitments. He works through possible changes while checking the new obstacles each change would create. The example illustrates the value of examining the surrounding conditions rather than treating the initial schedule as fixed.
For the hypothetical founder, that might mean keeping a short list of conversations ready before Friday. The normal session could examine several conversations and synthesize a finding. If an urgent support issue intervenes, the reduced session could capture one observation and leave a precise next step.
The reduced session needs a boundary. It is a recovery option for disruption, not an excuse to redefine a substantial project as a tiny daily checkbox. Decide which situations activate it and when to review repeated use.
For example, if the reduced version is used repeatedly because the same release meeting consumes Friday, the schedule itself needs reconsideration. The routine has produced information about a recurring conflict. Continuing to celebrate the small checkbox would conceal that information.
Preserve state when you stop
An interrupted task becomes more expensive to restart when its state is held only in memory. A brief handoff to your future self can record the source under review, the observation already captured, the uncertainty that remains, and the next concrete action.
That note should be short enough to write at the actual stopping point. An elaborate reporting requirement would introduce another task that is easy to abandon when time is tight.
For the research example, the saved state might say that one onboarding conversation raised a question about setup terminology and that the next step is to compare it with another conversation. It should preserve the link and distinguish what the customer said from the founder’s interpretation.
This is my proposed application of the video’s principles. The transcript does not report a test of this founder workflow. Whether it helps would need to be assessed in actual use.
Use recurring disruption as evidence
Sung also argues for revisiting temporary workarounds as the system develops. A workaround can help a person continue while leaving the condition that created the problem unresolved.
In a work routine, that suggests a practical review: identify why the recovery version was needed. Was there a genuinely unusual interruption? Was the planned output too large? Did the task depend on a person or document that was repeatedly unavailable?
The response should match the observed problem. A missing source document calls for a preparation step. A recurring calendar conflict calls for a scheduling decision. An unclear research question calls for better scoping. Adding another reminder does not resolve all three.
A routine also consumes capacity. If the work cannot fit alongside existing commitments, reducing scope or renegotiating those commitments may be necessary. No arrangement of reminders can establish that every desired activity fits into the same week.
Choose one recurring task that has slipped recently. Define its smallest useful output, prepare the inputs, and write a recovery rule for the interruption that actually occurred. After the next attempt, record whether the output was useful and what prevented completion. Use that observation to change one part of the routine before adding more machinery.
Source: Justin Sung, “How to Build Systems to Actually Achieve Your Goals”. This article develops an original work-routine example from the video’s general ideas. The founder scenario is hypothetical, and no improvement in productivity is claimed as a measured result.