It’s Not Done Until It’s Deployed to Production

One sunny afternoon, a developer—let’s call her Alex—was typing the final lines of code for a feature her team had been working on for weeks. The tests passed. The code was reviewed. The merge button was clicked. The ticket moved to the coveted Done column on the sprint board.

Victory, right? Time for Alex to bask in the glow of a job well done.

Two months later, that feature still hadn’t reached production. It was stuck in staging, buried under a pile of other “done” features waiting for deployment. Customers never saw it. The problems it was supposed to solve remained unsolved. And yet, the team patted themselves on the back for completing the sprint goals.

Sound familiar?

This story repeats itself in teams everywhere. Features are celebrated as “done” before they ever deliver value. But here’s the hard truth: your software isn’t done until it’s in production and making a difference for users.

#The Myth of Done

“Done” is a tricky word. Developers love saying it. Project managers love hearing it. Stakeholders assume it means their problems are solved. But more often than not, “done” is a lie.

In many teams, “done” means one or more of the following:

• The code is written, peer-reviewed, and merged.
• The feature passes all automated tests.
• QA has signed off on it.
• It’s sitting in a staging environment.

These are important steps, sure, but they don’t represent actual value. Until your feature is live in production, it’s like baking a cake and never serving it.

#Why “Done” Means Deployed

1. Customers Don’t Benefit From Staging

Code sitting in a staging environment isn’t solving problems. Your users don’t know it exists. The value it was supposed to bring to the business? Still locked away, waiting to be realized.

Imagine building a bridge. You lay the foundation, secure the beams, and pave the road. But instead of opening it for traffic, you put up cones and walk away. The bridge is technically complete, but it’s not serving anyone.

If your definition of “done” doesn’t include deployment, it’s not done.

2. Production Is the Real Test

Here’s the thing about staging: it’s predictable. Controlled. Safe. Production is reality: unsimulated traffic, real data, real stakes—actual user behavior, unpredictable spikes, and Murphy’s Law put your code to the test.

Features that work perfectly in staging might crumble under the pressure of real-world use. Until your feature survives in production, it’s not battle-tested—and it’s certainly not “done.”

Roll out safely with feature flags, canaries, or progressive delivery. On mobile, phased store releases count as deployed if users can reach it and you can observe it.

3. Value Only Exists When Users Feel It

This is the big one. Software exists to solve problems, improve experiences, and make life easier for users. A feature that’s coded but not deployed is like a car stuck in the showroom. It might look great, but it’s not taking anyone anywhere. It’s the difference between owning a Lamborghini and never getting to drive it off the lot.

#Rethinking “Done”

If “done” doesn’t mean “code complete,” what does it mean? It’s time to redefine it.

1. Deployment to Production

This is non-negotiable. If a feature isn’t live, it’s not done. Deployment is the moment when all your hard work starts to matter.

2. Monitoring and Observability

Deployment isn’t the finish line; it’s the starting gate. Once your feature is live, you need to know how it’s performing. Is it fast? Are users engaging with it? Track latency, error rate, adoption, and task success so the feature isn’t just deployed—it’s thriving.

3. Validating Business Value

Every feature should have a purpose. Whether it’s boosting revenue, improving efficiency, or delighting users, you need to validate that your feature is achieving its goals. If it’s not, the work isn’t over.

Define the value moment before you code: e.g., +3% signup conversion, −20% time-to-complete, p95 latency < 400ms.

#From Code Complete to Value Delivered

Changing how your team defines “done” isn’t easy, but it’s essential. Here’s a start:

1. Expand Your Definition of Done

Create a team-wide agreement that “done” includes:

• Successful deployment to production.
• Monitoring and alerting in place.
• Validation that the feature is meeting its goals.

2. Embrace Continuous Delivery

Continuous Integration and Continuous Deployment (CI/CD) pipelines make it easier to deploy small changes quickly and safely. If deploying feels heavy or risky, CI/CD turns it into small, repeatable steps—an assembly line for software that avoids risky batch releases.

Tools to consider: GitHub Actions, Jenkins, GitLab CI/CD, and my favorite, Buildkite.

3. Make Deployment a Team Effort

Gone are the days when deployment was just Ops’ problem. In modern teams, everyone—developers, QA, product managers, and platform/SRE—shares responsibility for getting features to production.

4. Celebrate Impact, Not Just Code

Shift your team’s celebrations. Instead of high-fiving when code is merged, celebrate when it’s live and making a difference for users. This reinforces the idea that real success is about delivering value.

#Common Pitfalls (And How to Avoid Them)

Pitfall 1: The “It Works on My Machine” Mentality

This classic excuse ignores the complexities of real-world deployment. Encourage developers to think about production from day one.

Pitfall 2: Long Staging Backlogs

If features pile up in staging, it’s a sign your deployment process needs work. Start small: aim to deploy at least one small change to production every business day.

Pitfall 3: Measuring Output, Not Outcomes

Teams that focus on closing tickets rather than delivering customer value often lose sight of the bigger picture. Track metrics like user adoption and business impact—not just lines of code or story points completed.

#Benefits of a True Definition of Done

When “done” means deployed and delivering value, amazing things happen:

• Faster Feedback: Smaller, incremental deployments mean quicker learning.
• Happier Customers: Users get value faster, and their trust grows.
• Less Technical Debt: Issues caught early are easier (and cheaper) to fix.
• Stronger Team Alignment: Everyone focuses on delivering value.

#Final Thoughts: Is Your Work Really Done?

Next time someone on your team declares a feature "done," ask these two questions:

1. Is it live in production?
2. Is it creating real value for the business?

If the answer to either is “no,” the feature isn’t done—it’s just resting. And resting features don’t make happy users, boost revenue, or solve business problems.

This week: ship one small change daily, add one outcome metric per feature, and review impact two weeks post-launch.

Let’s stop pretending features are done when they’re not. Let’s get them off the couch, out of staging, and into the hands of users where they belong.

Because done isn’t done until it’s delivering real value.