What Four Turnarounds Taught Me About Shipping Ugly

I have run the same experiment four times without meaning to. Four different companies, four different logos, four different products. Every time, I told myself I was being careful by holding something back until it looked finished. Every time, the delay cost more than the mess I was trying to avoid would have. I only noticed the pattern because it kept wearing a different costume each time, and eventually the costumes stopped working.

The instinct that looks like diligence

The instinct to polish before you ship feels like professionalism, but it is usually fear wearing a lab coat. It presents as “we are not ready yet” when the honest sentence is “I am not ready to be seen being wrong yet.” The two sentences produce the same pause, but only one of them is actually protecting the business.

Eighteen years in the Australian Army taught me the version of this instinct that is genuinely correct. Maintain the gear. Inspect the kit. A hidden crack in the wrong piece of equipment gets someone hurt. That training runs deep, and it is right in a context where the cost of a visible failure is measured in safety. I carried the same reflex into companies where the actual cost of a visible failure was much smaller: an ugly screen, an awkward pricing number, a sales deck that needed a rep to wince once before it got better. I treated those the same way I would have treated a maintenance check on a vehicle, and that is where the instinct stopped being diligence and started being a tax.

The tell that it is fear rather than rigor is what the delay is actually protecting. Real diligence protects the customer or the business from a cost that is hard to reverse. Fear-dressed-as-diligence protects the person holding the draft from the discomfort of a stranger seeing it before it is good. Those are different jobs, and only one of them belongs on a CEO’s desk.

I did not see the pattern clearly until I had repeated it enough times to recognize the shape. One instance of holding something back looks like a judgment call. Four instances, across four different companies, with four different teams and four different products, stop looking like judgment and start looking like a trait. That is the uncomfortable part of writing about founder lessons honestly: the mistakes that are actually worth naming are rarely the ones that happened once.

What four CEO seats taught me about the same mistake

Across four acquire-triage-stabilize-handoff CEO roles, I made the identical mistake under four different names: I treated the moment before a customer saw something as the finish line, instead of treating the moment a customer reacted to it as the actual starting line. I walked into FIVE CRM, then Teamgate Sales CRM, then Appsembler, each time inheriting a system someone else had built and a team that was waiting to see what kind of operator had just arrived. I joined Sendspark in December 2025 the same way, after both of the company’s founders had already departed, stepping into a product and a team I had not built.

A career built on walking into new companies every twelve to eighteen months turns out to be an unusually good way to discover you have a recurring flaw, because the context resets every time and the mistake does not. At each seat, the shape of the error was the same even though the surface details changed. A product change held back internally until the interface stopped looking rough, instead of in front of a small group of real users who would have told me what actually mattered within a day. A pricing number refined in a spreadsheet by every stakeholder who wanted a say, instead of tested against a real buyer’s actual hesitation, which taught me more in one call than a month of modeling. A go-to-market message polished until it read well in a deck, instead of handed to reps early enough to watch where a prospect’s attention actually dropped.

In every one of those cases, I called the internal version “getting it right” and the customer-facing version “the risk.” It was backwards. The internal version was the guess. The customer-facing version was the only place the guess got tested. I was spending the most expensive resource I had, time inside a turnaround window that was already shorter than I wanted, protecting a draft from the one input that could have actually improved it.

I wrote about the specific mechanics of joining a company you did not build in an earlier essay, and the polishing habit is the quieter cousin of that mistake. The installed-CEO playbook problem is about importing a plan built for a board that already approved the deal. The polishing problem is smaller and sneakier: it does not look like a strategic error at all. It looks like competence. Nobody in the room ever says “let’s protect ourselves from customer feedback.” They say “let’s make sure this is right before it goes out,” and the sentence is persuasive enough that it took me four companies to hear what it actually meant.

Why shipping volume is the mechanism, not the proof

Shipping volume is not evidence that something works, it is the actual mechanism that makes it work, because deployment generates specific failure modes and learning that no amount of internal planning can produce in advance. I did not have a clean name for this until I read a short thread by Jen Zhu Scott on the humanoid robot shipment race, which made an argument about hardware that applies just as directly to software, pricing, and go-to-market motion.

Her point: in complex manufacturing, quantity does not always mean quality, but shipping in volume means invaluable knowledge acquisition, supply chain optimization, and economy of scale. One commenter on that thread sharpened it further, arguing that the operators who are actually ahead are the ones willing to ship ugly v1s in the field instead of polishing demos in a conference room. The thread surfaces an old dialectical idea: quantitative change, enough of it, compounds into qualitative change. You cannot think your way to the qualitative shift. You have to ship your way there.

Translate that out of hardware and it says something uncomfortable about the spreadsheet model, the internal design review, and the stakeholder-approved pricing deck. None of those produce the specific failure. They produce a plausible list of failures, which is a different and much weaker thing. A planning meeting can generate forty hypothetical objections to a new pricing page. A hundred real visitors generate the three objections that actually matter, in the exact words real buyers use, which is the only version you can act on. The field does not give you a prediction. It gives you data, and data is the only input that reliably changes a decision that a room full of smart people has already talked themselves into.

This is the same lesson the AI 2027 forecast applies to deploying AI agents inside a company: stop treating the rollout as a question you answer in a room, and start treating it as a question the field answers for you once something real is in front of it. The forecast’s argument is about management discipline once an agent is live. The manufacturing thread’s argument is about why the agent, or the product, or the pricing page, has to go live at all before the discipline has anything real to work on. Neither argument is about moving fast for its own sake. Both are about where the actual information lives, and it is never inside the review meeting.

The cost of the ready instinct

Every quarter spent perfecting something privately is a quarter in which the only feedback loop that could have told you what was actually wrong never ran, and that gap does not stay flat, it compounds. This is the part that is easy to underestimate from inside the delay, because nothing visibly bad is happening while you wait. The cost shows up later, as distance, not as an event.

McKinsey’s research on enterprise AI adoption found a version of this same pattern playing out right now: companies that deployed imperfect tools early built a 12 to 18 month advantage over competitors who waited for a cleaner rollout, and the gap was not in how polished the final tool looked. It was in how much the organization had already learned about its own failure modes by the time the cautious competitor finally shipped. The early movers were not better at the technology. They had a longer runway of real data, and real data compounds in a way that careful planning does not.

I think the modern leadership-development instinct makes this worse without meaning to. A decade of management advice told leaders to trust the team, step back, and avoid looking over anyone’s shoulder, which is good advice for a team of highly capable doers who mostly need air cover. It is bad advice applied to the specific decision of whether to let an unfinished thing be seen. “Trust the process” quietly became “wait until it is done,” and nobody noticed the substitution because both sentences sound like confidence.

The arithmetic is unforgiving once you write it down. A team that ships something rough in week one and corrects course three times before quarter’s end has run three real experiments. A team that polishes for the same quarter and ships once at the end has run zero. Both teams can point to the same number of hours worked. Only one of them has learned anything a competitor cannot also learn just by watching, because the lesson lived in customer reaction the whole time, not in the finished artifact.

Where the ship-ugly rule actually stops

Shipping ugly is not a license for carelessness, it has a clear boundary set by reversibility, not by how finished something looks: ship early on anything a customer can see and you can still fix, and polish first on anything irreversible or touching money, safety, or trust. The rule is useful precisely because it is narrow. Most of what a team holds back does not belong on the polish-first side at all.

Artifact	Ship ugly first	Polish before anyone sees it
A new pricing page’s copy and layout	Yes, a few real visitors tell you more than a week of internal debate
The billing logic that actually charges a card		Yes, a reversible mistake here is a refund; an irreversible one is a trust problem
A first draft of an onboarding email sequence	Yes, open and reply rates are a faster signal than another round of review
A data migration script touching customer records		Yes, the cost of an error is measured in lost or corrupted data, not a bad first impression
A sales deck’s framing and structure	Yes, a rep’s live reaction in a real call beats another internal pass
A public claim about security or compliance		Yes, this is a promise a customer can hold you to, and it has to be true before it is said

The question worth asking before anything ships is simple: if this is wrong, can I fix it after a customer sees it, or have I already spent something I cannot get back? Most product copy, most onboarding flows, most sales messaging, and most UI decisions pass the first test easily. Billing, data integrity, and anything a customer could reasonably treat as a promise do not, and those deserve exactly the rigor the instinct wants to apply everywhere.

Why this gets worse, not better, inside a turnaround

The pressure to polish before shipping gets sharper, not softer, when you are the CEO who joined a company rather than built it, because your first visible move is being read by a team that is already watching for proof you understand what you walked into. That pressure makes the instinct to wait feel protective. It is actually the most expensive moment to give in to it.

I joined a company after both of its founders had already left, which meant the team had already lived through a transition nobody voted for. Every early decision I made was going to be read as a signal about what kind of leader had shown up, whether I intended that or not. The temptation in that position is to let the first visible changes be as polished as possible, because a rough first move feels like it confirms the team’s worst fear that the new person does not actually know what they are doing. What I underestimated is that the opposite read is just as available, and just as damaging. A team watching a new CEO sit on a decision for weeks does not conclude he is being careful. They conclude he is not sure, and uncertainty reads as far less trustworthy than an imperfect answer delivered with conviction and a plan to improve it in public.

This connects to a problem I have written about before in how founders insert themselves into decisions a system should own: the polishing instinct and the insertion instinct come from the same place. Both treat the leader’s personal review as the safeguard, instead of building a faster, cheaper safeguard that does not require the leader at all. A CEO who personally polishes every customer-facing artifact before it ships has built a bottleneck with the same shape as a founder who approves every decision, just aimed at drafts instead of meetings.

The honest version of competence in that seat is not a flawless first move. It is a visible, fast decision loop: ship something real quickly, say plainly what you expect to be wrong about it, and show the team you will fix it based on what the field tells you rather than what a meeting predicted. That is a harder thing to project than polish, and it is the thing that actually earns trust inside a B2B sales organization during a turnaround window that is shorter than anyone wants it to be.

What actually changed

What changed is a rule, not a personality transplant: anything reversible and customer-observable gets a hard deadline measured in days before it goes in front of a real customer or rep, and the only things exempt from that deadline are named in advance, not decided in the moment I am most tempted to stall. Naming the exemptions ahead of time, the way the no-list has to be built before the yes-list in any AI rollout, removes the judgment call from the exact moment judgment is least trustworthy, which is the moment something of mine is about to be seen by a stranger.

The second thing that changed is smaller but just as load-bearing: I stopped treating “it needs more time” as a neutral status update and started treating it as a claim that has to justify itself out loud. If I cannot say specifically what information another week of internal review will produce that a real customer reaction would not, the week is not buying diligence. It is buying comfort, and comfort is the one thing a turnaround cannot afford to spend time on. My own operating history is full of moments where I mistook the two, and naming the difference out loud, in front of the team, is the only check that has reliably caught me before the quarter closed instead of after.

The instinct that looks like diligence is the same instinct that has cost me the most, in the same shape, at every company I have run. Naming it did not make it disappear. It made it visible early enough to catch before the quarter was gone instead of after. I will keep writing about this pattern as it shows up in new shapes at dearmer.com.au, because an operator history built on walking into companies other people started turns out to be a reliable way of finding the same mistake again under a new name.

What is sitting in your own queue right now, labeled almost ready, that has been there longer than it would have taken a real customer to tell you what was actually wrong with it?