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.
The Shipping Problem
Shipping drives revenue and sustains the business. Shipping new products in a timely manner and providing subsequent updates are critical. If we can't ship, we can't deliver value. So why is it so hard?
We Have Tools — They Track the Wrong Things
We invest in project management practices and tools: Gantt charts, task lists, burn-down charts, Jira, Trello, GitHub projects, Notion, Asana, MS Project, and more. Things appear to progress well. Issues get checked off. The burn-down chart tracks the line.
But these tools track meta-data — data about the thing, not the thing itself. There is no guarantee it is complete and accurate. If developers get rewarded for checking issues off every sprint, they will eventually make sure that happens, even though quality, maintainability, and other factors suffer.
We Add Resources — They Don't Always Help
If things are not getting done, another natural approach is to add more people or bring in consultants. Depending on the context, these changes can help, but often they don't solve the underlying problem.
We Add AI — It Can Create New Risks
AI is accelerating development with great success. However, used incorrectly, it can generate 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.
What Actually Goes Wrong
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 and integration problems that catch everyone off guard
Perhaps the most damaging scenario is when we don't find out we are in trouble until near the end of the planned development cycle.
It seems like everything is progressing as planned. Items on the list are being checked off, but out of nowhere come surprises that no one could foresee — the last minute shipping gap. As the saying goes, the last 10% takes 90% of the time.
Why Projects Blow Up at the Last Minute
Complexity Creates Uncertainty
Modern connected products are complex. They contain advanced electronics, complex software, large amounts of data storage, and network connectivity. While we used to understand and touch most of the system, we now only directly create or interact with 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
Another result of complexity is timeline compression. In complex systems, the consequences of early decisions surface in months, not years. When the long-term catches up with us before we ship, delays are inevitable.
The Communication Gap
Development teams often struggle to communicate effectively 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 don't fully understand user needs.
The Real Enemy: The Unknown
All of the above boil down to one thing — the unknown. Our tools do a good job at tracking what we do know. The problem is in what we don't know, or worse, what we think we know that doesn't match reality.
There are two types of unknowns:
- Things we don't know.
- Things we think are true, but are not. 1
The second is more damaging because it prompts people to take action and go down paths that are difficult to undo. It is not too hard to say "oops, I did not know about that problem." But it is really hard 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?
"It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so." - Mark Twain (maybe)
The BIG 1.0 Release Trap
BIG releases are appealing — 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. And what we don't see with those high-end products is the rigorous internal release and testing programs — something lower-volume industrial products often don't have the luxury and resources to do.
The BIG Release mindset assumes all the code and designs will magically come together when the BIG day comes. It never goes this smoothly. One-off prototype processes don't scale. Only release processes scale. Is there a better way?
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:
- Something useful that others can experience and use.
- 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 will brush this off. But if it's obvious, are you shipping on time? The reality is that it is easy to implement something complex and incredibly hard to get to simple. Release First is a simple solution to a hard problem — but simple is not always easy, because behavior change is required.
"It's not finished"
This is the number one objection by engineers. We like to have 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 time investment to set up release automation has dropped dramatically. And the time invested early in release processes is quickly paid back many times over.
The Human Factor
The biggest barrier to Release First is human nature. The BIG 1.0 Release fits our tendencies better — procrastination, excitement, and glory. Release First is boring at first, invisible, and rarely gets rewarded. Very few developers are naturally wired for it. Thus, Release First is not a technical problem but a cultural one.
The Bottom Line
The sole purpose of product development is to produce something that can be used and provides value. 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 that is useful?
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.