Launch Is the Beginning¶

In a project mindset, "launch" is the end. The team ships, the budget closes, the press release goes out, and the work is over. In a product mindset, launch is the start. It is the moment the team finally gets to learn what the software actually does in the hands of real users, in real conditions, against real constraints. Most of what the team will ever learn about the product happens after launch.

This is one of the deepest cultural shifts a software organization has to make. Treating launch as the finish line produces predictable failure modes: under-investment in operations, abrupt handoff to a team that did not build the system, lack of capacity to respond to what users actually do, and a roadmap that has no place for what production reveals.

What Production Reveals¶

The team builds against a model of the user, the workload, and the operational environment. The model is always partial. Production is what fills in the gaps.

Some of what the team predictably learns only after launch:

Real user workflows. Users do not follow the happy path the team designed. They click in unexpected orders, use features for purposes they were not built for, and combine workflows in ways that produce surprises.
Edge cases. Inputs the team did not anticipate. Data shapes the test fixtures did not include. Sequences of events that the design implicitly assumed would not happen.
Performance patterns. How the system behaves under real load is reliably different from how it behaves in synthetic tests. Bottlenecks, caching effectiveness, and the cost of operations all come into focus.
Support needs. What questions users ask, what they do not understand, where the documentation fails, and where the product itself needs to be clearer.
Operational bottlenecks. Which alerts fire often, which on-call procedures actually work, which dependencies are flakier than expected, and which assumptions about deployment do not survive contact with reality.
What the customer actually values. The features used heavily versus those touched once and abandoned. The pricing model that works versus the one that was theoretically clever.

None of this can be discovered before launch. The work the team does after launch is what turns a shipped artifact into a working product.

The Handoff Trap¶

The most reliable failure mode in operations is the handoff: a team builds the software, ships it, and hands it to a different team to run. The build team has the context; the ops team has the responsibility. The two are misaligned by structure.

Symptoms of the handoff trap:

The operating team inherits operational debt they did not create. Logging gaps, missing observability, brittle deploys, fragile dependencies: all decided by people who do not bear the cost.
The building team has no skin in operational outcomes. Incidents become problems for "ops to handle," not signals for the building team to learn from. The build team's metric is shipped features; the ops team's metric is uptime. The incentives diverge.
Knowledge does not flow back. What support, on-call, and operations learn about the system does not change what the next version is built like. Each generation of the product makes the same mistakes.
Improvement requires negotiation. Fixing a problem that crosses both teams requires getting both to prioritize it, which usually requires escalation. Most of the time, the fix never happens.

The modern alternative is "you build it, you run it": the team that ships the software also operates it.¹ When the same people carry both responsibilities, the feedback loop closes; the cost of operational shortcuts is felt by the people who could have prevented them.

What This Looks Like in Practice¶

A few habits keep launch from being the end of the team's attention:

Plan for operational work as part of the project. A project that does not budget time for post-launch instrumentation, documentation, handoff, and iteration is not actually shipping the product; it is shipping the artifact.
Treat the first weeks of production as a discovery phase. Real workflows, real data, real users. The team should expect to be actively learning, not maintaining a finished thing.
Define what "stable" means before declaring victory. A feature is not done at deploy. It is done when error rates are normal, support volume is in line with expectations, and the team has learned what it expected to learn.
Close the feedback loop on support and incidents. What support hears, what on-call sees, and what incidents reveal should feed back into the team's understanding of the product, the system, and the next iteration.
Resist the project framing. "We're done" is a project sentence. "We just shipped" is a product sentence. The team's vocabulary shapes the team's behavior.

Product thinking

Launch is when the product begins learning from the world. Everything before launch is hypothesis; everything after is evidence. A team that does not budget for the evidence has not yet shipped a product.

The "you build it, you run it" framing comes from Werner Vogels's 2006 ACM Queue interview about Amazon's operational practices, where he attributed it to the practical lesson that handing off operational responsibility separated the people making engineering decisions from the people paying for those decisions. The pattern is now widely adopted across the industry. ↩