Outcomes are seductive because they feel like the point.
Finish the thing. Make it perfect. Get traction. Prove it worked. These goals are clean in theory. In practice they are noisy, delayed, and only partially under your control. And when you optimize for what you cannot control, you get a familiar result: you stall.
I have noticed a pattern in myself. When I chase outcomes, I polish too early. I wait for the moment where the work becomes “worth it”. I treat unfinished things like failures instead of like the normal state of building anything meaningful.
So I have been shifting toward a different operating principle: ship experiments instead.
The failure mode of outcome chasing
The problem with outcomes is not that they are bad. It is that they are lagging signals.
Perfection is a moving target. “Done” is mostly a story you tell yourself. Traction depends on timing, distribution, and luck. Even when you do everything right, the result can still be underwhelming. That uncertainty makes your brain look for safety.
Safety looks like planning. Planning looks like progress. And then you realize you spent a week “thinking about it” and nothing exists.
Outcome chasing also makes work brittle. If the only acceptable end state is a big win, then everything before the win feels pointless. That mindset kills iteration, because iteration requires tolerance for imperfect intermediate states.
What I mean by shipping
I do not mean “publish everything”. Public is only one possible destination.
Shipping is the moment an idea becomes real enough to be evaluated and iterated on. A finished slice. Something runnable, reviewable, or usable. Something that exists outside your head, so you can work with evidence instead of imagination.
This definition scales across different domains:
- A blog post is shipped when it is published.
- A song is shipped when a demo exists that you can listen to and revise.
- Language learning is shipped when the session is done and the system keeps moving.
- Engineering work is shipped when a slice runs end to end, even if it is not elegant yet.
The point is not to win. The point is to create an artifact you can iterate on.
How I design experiments
The engineering part of this mindset is making experiments small and finishable.
A few rules I keep coming back to:
- Define the slice. What is the smallest version that still counts as “the thing”?
- Define “shipped.” What concrete artifact exists at the end?
- Keep it cheap to continue. Reduce the maintenance tax so you do not avoid it.
- Make iteration the default. Shipping should create a clear next step, not a dramatic finale.
This is how you stop negotiating with yourself. The experiment has boundaries. You either shipped the slice or you did not.
What this looks like in practice
A blog is the easiest place to see the difference between shipping and outcome chasing.
If I optimize for outcomes, I start thinking about reach, SEO, engagement, whether the topic is “worth posting,” whether it will resonate. All of that is external and uncertain. If I optimize for shipping, the task is simple: write one piece and publish it. Once it exists, I can revise, link it, repost it, improve the pipeline, and build a body of work.
Language learning is the purest example of outcomes being unhelpful. Fluency is a vague outcome. You never fully arrive, and you can always feel behind. A system is clearer. For me that means daily reviews and a weekly block of real exposure and production. I do not “win” Finnish. I ship sessions. The artifact is boring: finished reviews, a chat done, an episode understood a little better than last time. That boring consistency is what makes progress inevitable.
Music used to trigger the worst version of my outcome brain: “write something great or do not bother.” The shift happened when I started treating songs as experiments. A song is shipped when there is a demo. Not released. Not mastered. Just real enough to listen back to, notice what works, and refine. Once I started writing regularly, the outcome changed without me forcing it. I now have enough material that recording and releasing an EP this year feels plausible. That outcome appeared as a side effect of shipping, not as a prerequisite for starting.
What this changes
Shipping experiments lowers the ego stakes.
If a thing is an experiment, it can be imperfect. If it is imperfect, you can still ship it. If you ship it, you can iterate. If you iterate, you get better.
Outcome chasing flips that chain. It asks you to be good before you have evidence. That is a great way to stay stuck.
I still care about outcomes. I just do not let them drive the process.
A small rule that helps
If an idea cannot be shipped as a small slice, it is not real yet.
Shipping is controllable. Outcomes are noisy.
So I try to ship first and let the outcome catch up later.
