Release First, Ship Faster

Products often ship late. Despite Gantt charts, sprint planning, and adding resources, the last 10% still takes 90% of the time. After seeing this pattern repeatedly across embedded systems and connected products, I'm proposing an approach that changes the dynamic: Release First.

Release First is not a replacement for existing methodologies — it's a lens that supplements them by focusing on one question: Can we release right now? If the answer is no, that gap is your biggest risk.

How we try to ship faster

Shipping drives revenue and sustains the business. If we can't ship, we can't deliver value. So what are we doing about it?

1. Use tools: We invest in project management tools — Gantt charts, task lists, burn-down charts, Jira, Trello, GitHub projects, Notion, Asana, MS Project, and more. Issues get checked off. The burn-down chart tracks the line.
2. Add resources: When things fall behind, we add more people or bring in consultants.
3. Rely on AI: AI promises to get more done faster, so everyone reaches for it.

What often happens

In spite of our best efforts, projects often ship late due to:

• Last-minute bugs
• Integration problems
• Not solving the customer's actual problem
• Manufacturing issues
• Unanticipated feature requests that catch everyone off guard

The most damaging scenario: we don't find out we're in trouble until near the end of the planned development cycle.

Everything appears on track. Items get checked off. Then surprises hit that no one foresaw — the last-minute shipping gap. The last 10% takes 90% of the time.

The BIG 1.0 Release Trap

We love BIG releases — the magical moment when everything comes together. The months of hard work that finally come to fruition. The excitement and fanfare.

... except it rarely works this way unless you are Apple or Tesla. Behind those high-end products are rigorous internal release and testing programs — something lower-volume industrial products rarely have the resources for.

The BIG Release mindset assumes everything will magically come together on launch day. It never does. One-off prototype processes don't scale. Is there a better way?

The problem with tools, resources, and AI

1. Tools track meta-data: Data about the thing, not the thing itself. There is no guarantee it is complete or accurate. If developers get rewarded for checking issues off every sprint, they will make sure that happens — even as quality and maintainability suffer.
2. Resources don't solve the underlying problem: Without processes and workflows that scale, additional resources often compound the problem.
3. AI has similar problems: AI generates code fast. But used incorrectly, it produces a pile of code that is difficult to untangle later. What looks impressive initially may have architectural problems that surface late in the development cycle.

But let's dig deeper. Why are things different today than 10 or 20 years ago?

Complexity Creates Uncertainty

Modern connected products are complex — advanced electronics, layered software, large data stores, and network connectivity. We used to understand and touch most of the system. Now we directly create or interact with only a small part of it.

What does all this complexity produce? Uncertainty. We cannot absolutely predict how things will go, what problems we will encounter, and how long things will take.

Long-term Consequences Arrive Faster

Complexity also compresses timelines. The consequences of early decisions surface in months, not years. When the long-term catches up before we ship, delays are inevitable.

The Communication Gap

Development teams often struggle to communicate with users — both internally and externally. What got done? What is it? How do I use it? Without good communication in both directions, users can't use the product to its potential, and developers miss user needs.

The Real Enemy: The Unknown

All of the above boil down to one thing — the unknown. Our tools track what we know well. The problem lies in what we don't know, or worse, what we think we know that doesn't match reality.

There are two types of unknowns:

1. Things we don't know.
2. Things we think are true, but are not. ¹

The second is more damaging because it drives people down paths that are difficult to undo. It's easy enough to say "oops, I didn't know about that problem." It's far harder to say "sorry, I was completely wrong about that."

How do we manage what we don't know? How do we uncover things we think are true, but are not?

This is the fundamental problem we need to solve.

The Solution: Release First

Release First focuses on three principles:

• Release early — get something real into users' hands as soon as possible.
• Release often — keep the feedback loop short.
• Build the release mechanism first — invest in the ability to release before investing in features.

What is a Release?

A release has two characteristics:

1. Something useful that others can experience and use.
2. Something produced with a high level of confidence.

The Release Circle

A release starts small. Initially, there is not much — perhaps only a specification — and only the development team is interested. But it is something real that can be used and built upon.

Over time, the functionality expands and the circle of users grows: internal teams, sales and marketing, management, beta customers, and finally a general release.

The key point is to release a small slice of permanent functionality early, and then continue to grow during the development cycle. Waiting until the BIG Release is too late. It's OK to start small — as long as it's a release.

Why Release First Works

Release First reduces risk and improves communication because it:

• Exposes unknowns early — problems surface when they're small and cheap to fix, not when they're blocking a launch.
• Drives automation — releasing often pushes teams to automate testing, building, and deployment, which compounds over time.
• Aligns everyone — a release is something everyone can see, touch, and react to. It replaces ambiguous status updates with concrete reality.
• Keeps feedback loops short — the faster users see real product, the faster the team learns what to build next.

Releasing early and often is the way to get to predictability.

Release First also gives everyone involved with the product a common language. It is simple enough that everyone understands it — from engineers to executives to customers.

Addressing Common Objections

"This is too obvious." Most people brush this off. But if it's obvious, are you shipping on time? Building complexity is easy; getting to simple is incredibly hard. Release First is a simple solution to a hard problem — but simple is not easy, because it requires behavior change.

"It's not finished." Engineers' number one objection. We like things "Done" with a capital 'D' before anyone sees them. But we're not saying release the entire product on day one. Can you release the specification? A prototype? An automated build? Start small and expand over time.

"It takes too much time to release." With AI-powered development tools, the cost of setting up release automation has dropped dramatically. And time invested early in release processes pays back many times over.

The Human Factor

The biggest barrier to Release First is human nature. The BIG 1.0 Release fits our tendencies — procrastination, excitement, and glory. Release First is boring at first, invisible, and rarely rewarded. Few developers are naturally wired for it. Release First is not a technical problem but a cultural one.

The Bottom Line

The sole purpose of product development is to produce something useful. Release First cuts through the proxies and meta-data common in project management today and focuses on the real thing — the release. Are we delivering real stuff to real users?

As system complexity increases, so do unknowns and risk. Release First reduces these risks by exposing unknowns early, building confidence through repetition, and keeping feedback loops short.

So let's Release First, and learn where we are wrong in little ways, rather than face a BIG 1.0 humiliation.