Skip to content
Published on

How to Ship Output Consistently — A System for Producing Results

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

Before We Begin

For a long time I lived in the state of "working hard but producing nothing." My notebooks were full, my idea list was long, I had read plenty of books, and yet I had sent almost nothing out into the world. One day a colleague said something offhand that stuck with me for years.

"You prepare a lot. But I've never actually seen you finish anything."

It stung, but it was true. I was not a person who produced results; I was a person who prepared to produce results. This essay is the system I built and refined over the following years to ship output consistently. I keep the motivational talk to a minimum and focus on tangible methods, real cases, and checklists.

First, one clarification. The "output" I am talking about is not something grand. A single blog post, a working prototype, a presentation deck, a merged PR, a shipped feature, a proposal sent. If it has entered the world in a form someone can see and evaluate, it is output. The key is whether it exists outside your head, not inside it.

1. Perfectionism vs Shipping: The Real Problem Lies Elsewhere

Perfectionism is often mistaken for "having high standards." In my experience the real cause is somewhere else: fear of evaluation. If you don't release it, you are not judged; if you are not judged, you do not fail. Perfectionism is actually a sophisticated strategy for deferring failure indefinitely.

Once you admit this, the direction of the solution changes. It becomes not "lower your standards" but "increase the frequency of being evaluated." If you ship small and often, you slice evaluation into small pieces, and the fear any single evaluation carries shrinks.

Here is the difference between the two mindsets.

ItemPerfectionist modeShipping mode
GoalFlawless outputEvaluable output
Feedback timingOnce, at the very endOften, early, repeatedly
Meaning of failureA denial of self-worthA single piece of information
Sense of timeInfinite (someday)Finite (this week)
Typical resultA pile of unfinished workImperfect but existing

Do not confuse perfectionism with thoroughness. Thoroughness can be exercised even after you ship. Perfectionism tries to finish everything before shipping and ends up shipping nothing.

A Small Experiment: Deliberately Ship the 70-Point Version

For one month I set a rule: "If it is a 70 out of 100, I ship it no matter what." Whether it was a blog post or code, the moment I felt it was a 70 I stopped touching it and published. The result had two parts. First, the world did not collapse. Second, the feedback I got at 70 was far more accurate than crawling toward 90 alone. The 90 I imagined by myself was usually pointed in the wrong direction.

2. Breaking Work Small: Shrink It to a Finishable Size

The most common reason output never appears is that the unit is too big. "Build an app" is not a finishable unit. "Draw the UI for the login screen" is a finishable unit.

There is exactly one criterion for splitting: can you finish it in a single sitting? I usually break work down until each piece can be completed within one or two hours. Anything bigger gets split again.

In her book "Bird by Bird," Anne Lamott recounts what her father told her younger brother, who was overwhelmed before a report on birds was due: "Bird by bird, buddy. Just take it bird by bird." You cannot swallow an elephant whole. You have to cut it into bites.

Here is an example of splitting a large goal into finishable units.

Big goal:   "Build a personal blog"
            |
            v  (first split — by day)
            +-- Create Next.js project + first deploy
            +-- Post list page
            +-- Post detail page
            +-- Dark mode
            |
            v  (second split — by two hours)
   "Post list page"
            +-- Render list with dummy data
            +-- Read markdown files
            +-- Sort by date
            +-- Tag filter

Once you have split it, finish the smallest single piece first. The order does not matter. What matters is the fact that "there is one piece I finished today."

Signs That Splitting Is Stuck

If you try to split but feel "I can't split this any further," it is usually one of two things. First, you do not yet know what you are building. In that case, change it into an exploration task like "spend 30 minutes sketching the screens on paper by hand." Second, several things are mixed inside one piece. If there are two or more verbs (for example, "design and implement"), that means it can be split.

3. Deadlines and Timeboxing: Fit the Work to the Time

Parkinson's Law states: "Work expands so as to fill the time available for its completion." If the deadline is a week, it takes a week; if it is a month, it takes a month. So if you deliberately shrink the time, the work shrinks too.

Timeboxing is the technique of changing "do this until it is finished" into "spend only 90 minutes on this." When the time is up, you stop regardless of completeness, and you treat the state at that moment as output.

I use this approach for writing.

Timebox example — one blog post

09:00-09:25  Outline and skeleton (Pomodoro 1)
   Break 5 min
09:30-09:55  First half of the draft (Pomodoro 2)
   Break 5 min
10:00-10:25  Second half of the draft (Pomodoro 3)
   Break 5 min
10:30-10:55  Polish + publish button (Pomodoro 4)

Rule: publish at 10:55 no matter what. If unfinished, ship the current state.

The Pomodoro Technique (25 minutes of focus + a 5-minute break) is simple but powerful, because the small unit of 25 minutes lowers the barrier to "starting." We usually fear starting more than the work itself. Thinking you only have to do 25 minutes makes it easier to sit down.

Deadlines Are Stronger the More External They Are

A deadline you set yourself, you can move yourself. The strongest deadline is one that someone else knows about. The moment you tell someone "I'll send it by Friday," that deadline suddenly carries weight. This leads to the public commitment in the next section.

4. The 80/20 Rule: Most of the Value Comes From a Fraction

The Pareto principle (the 80/20 rule) is the heuristic that 80% of results come from 20% of causes. From an output perspective this becomes a very practical tool. If you finish the 20% that creates the core value first, you can ship before spending the remaining 80% of the time.

The hard part is identifying that 20%. I ask myself: "If only this existed and everything else were missing, would it still be useful to someone?" The smallest chunk you can answer "yes" to is the core 20%.

What you buildCore 20% (first)The later 80%
BlogA page where one post can be readComments, search, recommendations
Presentation3 slides with the core messageAnimation, unified design
Side appOne core feature workingSettings, onboarding, dark mode
ProposalOne page of problem and solutionAppendix, detailed schedule

This does not mean using 80/20 as an excuse to be sloppy. The core 20% should in fact be done better. It only means: do not pour perfectionism into the non-core 80%.

5. Public Commitment: Narrow Your Escape Routes

One of the cheapest and most powerful ways to change behavior is to commit publicly. We have a strong instinct to stay consistent, so when our words and actions diverge, we feel discomfort. We use that discomfort as fuel for producing output.

When I start a new project, I deliberately create a "hard-to-reverse commitment." For example:

  • Book the presentation slot first. I lock in the event date before the content is ready.
  • Tell the team, "I'll show you a demo next Tuesday."
  • For a series, when posting part one, nail down "weekly series every Wednesday."
  • At a study group, volunteer: "Next time I'll present what I built."

Public commitment has side effects too. If you publicize too large a commitment, you can get crushed by the pressure and put off starting instead. So I tune the size of the commitment to a level that is "a little scary but not enough to make me want to run away."

The Intensity of the Commitment's Audience

Weak  ----------------------------------------> Strong

Writing it in a private journal
  < Telling a close friend
      < Writing it in a team channel
          < Declaring it in a public tweet/blog
              < Locking an event date (canceling harms others)

Further to the right is stronger, but the pressure is proportionally larger. At first I recommend starting somewhere in the middle.

6. The Power of Finishing: The Last 10% Is the Hard Part

The first 90% of a task takes half the time, and the last 10% takes the other half. This is not a joke; it is almost a law. And whether output ships or not is almost always decided in that last 10%.

The reason the last 10% is hard is that it is "the boring work." Building a new feature is exciting, but fixing bugs, handling edge cases, writing docs, and configuring deployment are tedious. Yet output is only complete once you pass through exactly that tedious part.

The method I use is to prepare a "finishing list" in advance. Around the 80% mark, I write down every small task remaining until publishing/deploying. Then the last 10% turns from a vague fog into a checklist of boxes.

Finishing list — publishing a blog post

[ ] Reread and polish the title
[ ] One full read-through for typos
[ ] Check language labels on code blocks
[ ] Click every link to confirm it is alive
[ ] Write the cover image or summary
[ ] After publishing, view once on mobile

Written this way, the giant lump called "wrapping up" is decomposed into six small actions. Smaller actions are not frightening.

7. Momentum: Continuity Is Stronger Than Willpower

Willpower is an unreliable resource. Some days it overflows, some days it is empty. So instead of willpower I lean on momentum. Momentum is the inertia of "I did it yesterday, so I do it today too."

Visualizing continuity strengthens momentum. The "Don't break the chain" method, known from a Jerry Seinfeld anecdote, is a classic. Each day you do the thing, you mark an X on the calendar. When the Xs stretch into a long line, a desire arises not to break that chain.

June output chain (at least 1 output per day)

Mon Tue Wed Thu Fri Sat Sun
 X   X   X   X   X   .   X
 X   X   X   X   X   X   .
 X   X   X  ...

Rule: it does not have to be "big." One commit, one paragraph also counts as X.

There is an important balance here. If you treat the chain as too sacred, you fall into the "all or nothing" trap where one missed day collapses everything. I use a looser rule: "never miss two days in a row." You can rest one day, but not two. This rule lasts longer than a perfect chain.

A Small Starting Ritual

The best way to reattach momentum is to start in a way that is laughably small. "Today I write just one sentence." "I only open the editor." Strangely, once you write one sentence you usually write ten. Once you cross the friction of starting, inertia drags the work along.

8. Measurable Output: Count Results, Not Activity

"I worked hard" cannot be measured. "I published 4 posts" can be measured. To live output-centered, you must move the object of measurement from activity (input) to result (output).

The table below shows how activity metrics and output metrics differ in the same domain.

DomainActivity metric (weak)Output metric (strong)
WritingHours spent on researchNumber of posts published
DevelopmentHours spent codingNumber of PRs merged
LearningPages readSummaries/examples created
ExerciseTimes you went to the gymIncreased weight/distance
SalesEmails sentMeetings booked

Activity metrics are not meaningless. But activity metrics make it easy to fall into self-comfort. "I studied three whole hours today" feels good, but you may have left nothing in the world. Output metrics are cold but honest.

I count output weekly. Every Friday evening I write a list of "what I sent into the world this week." If it is empty, that was a week with activity but no output. This simple retrospective changes the direction of the next week.

9. Closing With a Presentation or Demo: A Device That Forces an Ending

The most effective device for forcing an "ending" on output is a presentation or demo. The fact that you have to show it in front of someone is powerful pressure that makes you finish the last 10%.

A demo has another effect. The moment you try to explain what you built to someone else, it becomes vivid what is important and what is filler. If you cannot answer "why did I build this feature again?", that feature was not the core.

Here is a simple framework for wrapping up a demo well.

3-minute demo structure

1. Problem (30 sec)
   "There was this inconvenience."
2. Solution (30 sec)
   "So I built this."
3. Demonstration (90 sec)
   Show it actually working.
4. Next (30 sec)
   "Next I will do this." (= the next public commitment)

The final "Next" step is the clever part. If you publicize the next commitment as you end the demo, the end of this demo becomes the start of the next output. The cycle turns on its own.

10. A Sustainable Pace: Burnout Is the Enemy of Output

Everything so far might sound like "more, faster." But the key word in shipping output consistently is "consistently." Going all-out for a week and then resting for a month produces far less cumulative output than going a little each day, for a long time.

In "Deep Work," Cal Newport argues that deep concentration has a limit of a few hours per day. In practice, creative work requiring high concentration is hard to sustain beyond three or four hours a day. Sitting at the desk longer than that only accumulates lower-quality time.

My rules for a sustainable pace are these:

  • Set an upper limit on daily output hours. Do not work without bound.
  • Divide the day into "output blocks" and "recovery blocks."
  • Keep one day a week with no output obligation.
  • Treat sleep as part of output. The output of a sleep-deprived next day is low quality.

Burnout briefly increases output and reduces it for a long time. Everyone has experienced paying for a one-month sprint with three months of lethargy. Run at a marathon pace; you just have to not stop.

One year of cumulative output at two paces (conceptual)

Sprint type:  ████░░░░░░████░░░░░░░░░░██░░░░  (jagged, small total)
Sustained:    ██▓██▓██▓██▓██▓██▓██▓██▓██▓██  (steady, large total)

11. An Internal Dialogue: Answering the Voice That Procrastinates

What blocks output is often not a grand obstacle but a small voice in your head. That voice offers plausible excuses. I prepare in advance the dialogue I have with that voice. Here are responses I use often.

Voice: "I should study more before I start." Response: "I can study while building. Let me make the first piece, and study only the part where I get stuck."

Voice: "This is too embarrassing to release." Response: "I decided I ship at 70. The embarrassment fades in a week; the regret of not shipping lasts a year."

Voice: "Others made something far better." Response: "I'm comparing my draft to someone's finished work. Their draft-era surely looked clumsy too."

Voice: "I'm not in good shape right now." Response: "Then let me do just 25 minutes. If it's still no after 25 minutes, I can stop."

What these dialogues have in common is that they do not deny the procrastinating voice. Denial turns it into a fight, and fighting is exhausting. Instead, acknowledge the voice while only redirecting toward "let me start very small anyway." The procrastinating mind is not an enemy; it is merely a signal sent by fear.

12. The Quality of Output: Fast and Good Are Not Enemies

When you hear "ship small, often, fast," it is easy to mistake it for "give up on quality." It is not. Consistent output actually raises quality. The reason is simple: quality comes from repetition.

Compare someone who writes one post a year with someone who writes one post a week. A year later, the latter's writing is almost always better, because it has gone through 50 releases and 50 rounds of feedback. The person trying to write a masterpiece in one shot has thrown away 50 chances to practice.

Here is a summary of the view that treats quality as a result of output, not its enemy.

Conventional beliefReality
Go slow for good qualityGo often and quality grows
You must finish in one shotIt improves across many versions
Get feedback at the endGet feedback early and often
Quantity and quality are inverseEarly on, quantity raises quality

There is a famous anecdote from a pottery class. One group was graded on the "quantity" of their work, the other on a single "perfect piece." At the end of the term, the finest pieces all came from the quantity-graded group, because making many naturally grew their skill. The group aiming for perfection accumulated only theory while their hands stayed stiff.

13. A Concrete Case: How I Finished a Weekend Side Project

To reduce abstraction, let me unpack one real case. I wanted to build "a small web tool that organizes bookmarks." I had been turning a similar idea over in my head, only in my head, for six months. This time I did it differently.

First, I made a public commitment. On Friday night, in a group chat with three friends, I wrote, "I'll show you a demo Sunday evening." My escape routes narrowed.

Next, I cut the scope with 80/20. "Paste your bookmarks, and it removes duplicates and sorts them alphabetically." If only that worked, it was useful to someone. Login, saving, syncing all went into the 80% and got discarded.

Then I split Saturday into timeboxes.

Saturday schedule

10:00-12:00  Input box + paste handling (2-hour box)
13:00-15:00  Dedup + sort logic
15:30-17:00  Result display + copy button
Evening      Finishing list + deploy

The last 10% (deploy, connecting the domain, mobile check) did not get stuck, thanks to the finishing list I had prepared in advance. Sunday evening, I posted a working link in the group chat. It was not perfect. The design was crude and there was only one feature. But it existed. For the first time, something that had lived only in my head for six months came outside.

One friend said, "It'd be nice to have a sort option." That was feedback that did not exist in the feature list I had imagined alone. It became the next week's output. The cycle had begun to turn.

14. Common Traps and Responses

The patterns that block output differ from person to person, but some appear repeatedly.

TrapSymptomResponse
Tooling-setup trapPerfecting environment/tools before startingStart with what you have; tune later
Research infinite loopEndlessly gathering material, never buildingPut a timebox on research
Big-bang fantasyBelieving small things are meaninglessProve cumulative small output by measuring
Comparison paralysisComparing your draft to others' finished workRecall their own draft-era days
Repeated startingOnly ever starting new projectsRule: no new thing before finishing

The last one, "repeated starting," is the most common among people who produce no output. The excitement of starting fresh is sweeter than the tedium of finishing. I consciously keep the rule: "I do not start a new project before finishing the one in progress."

15. Designing a Week Around Output

Finally, let me weave all the pieces together at the level of one week. This is the weekly rhythm I actually use.

An output-centered week

Mon: Decide this week's one output + split small + public commitment
Tue: Work on the core 20% in timeboxes
Wed: Finish the core 20% (already in a shippable state)
Thu: Write finishing list + handle the last 10%
Fri: Publish/demo + count weekly output + retrospective
Sat: Recovery or light next exploration
Sun: Rest (no output obligation)

The crux of this rhythm is reaching a "shippable state" already by Wednesday. Then Thursday and Friday become bonus time for raising completeness. Even if something comes up on Thursday or Friday, you ship the Wednesday version and that week becomes a week with output. Always holding a "shippable version" in your hand is the secret to consistent output.

Final Checklist

Here is the checklist I run through when starting a new piece of output.

[Before starting]
[ ] Is this output split to a size finishable in one sitting?
[ ] Can I state the core 20% in one sentence?
[ ] Is there a deadline that is public/external?
[ ] Is there a presentation/demo/publish point that forces an ending?

[While working]
[ ] Am I measuring progress by output, not activity?
[ ] Do I set a timebox and stop when the time is up?
[ ] Am I mentally ready to ship at 70 points?

[Wrapping up]
[ ] Did I write the finishing list in advance?
[ ] Did I decompose the last 10% into small actions?
[ ] After shipping, did I publicize the next output's commitment?

[Sustaining]
[ ] Can I count what I shipped this week?
[ ] Am I keeping the chain of not resting two days in a row?
[ ] Is this a pace that can keep going next week without burnout?

Closing

Producing results is not a matter of talent; it is a matter of systems. Understanding perfectionism as fear, splitting work into finishable sizes, fitting work to the time, narrowing your escape routes, decomposing the last 10% in advance, counting output not activity, forcing an ending with a presentation, and continuing the chain at a pace that does not collapse. It is not flashy, but it works.

The reason my colleague's words hurt at first was that they pointed precisely at something I could change. Becoming a person who ships instead of a person who prepares required not talent but resolve and structure. I encourage you to start by shipping one 70-point thing today. The world will not collapse, and you will become a person who produces output.

References

Discuss on Twitter • View on GitHub