Product Development: V. Shipping

Planning decides what deserves attention. Shipping turns that decision into software that reaches customers and keeps working afterward. I want as little machinery between the two as possible.

Projects need a clear owner, branches should become running environments quickly, releases should be continuous and the people building the product should stay close to what happens in production.

Shipping and operating are the same responsibility.

1. Projects

Meaningful work belongs to a project with a clear DRI. The project holds enough context for the team to understand the objective, the current state and the important decisions.

Linear is an excellent tool for hosting product/eng context for every project/feature. It works well with Github for PRs and releases. Every project should have a linear board and slack channel.

Do not reproduce the same information in every tool. Linear is the project index, Github describes the implementation and Slack is for the conversation that needs to happen now. The tools can change. Who owns what, and where the current source of truth lives, should always be obvious.

2. Branches

All new features should start with feature/ prefixed branch. All bug fixes should start with fix/ prefixed branch. This allows anyone across the org to help QA or follow along with the progress.

Work starts on a branch and should become testable as early as possible. With managed infrastructure, a branch gets a live preview and its own isolated data, so product, design, engineering and coding agents all work against something much closer to production than a mock or someone’s laptop.

The PR is the unit of review. Sometimes the author is an engineer. Increasingly it is a designer or PM using codegen, with engineering reviewing the parts that need deeper technical judgment (see The branch is the PRD). Who wrote the first line of code matters less than whether the change meets the bar for production.

Keep branches small enough to be understood, tested and merged quickly. Long-lived branches pile up divergence, hidden assumptions and integration risk.

3. Release

Every team should be shipping features every day. Given every dev tool and infrastructure now works with Git branches, we should be able to go from a PR to a release in a few hours/days.

Planning happens in cycles. Releases do not. A feature should reach customers when it is ready, whether that takes two hours, two days or several weeks of incremental work. Main should always be releasable, and automated checks should catch what machines are good at catching before a human spends attention on it.

Large features do not need one large release. Feature flags, incremental rollouts and narrow vertical slices separate deploying code from exposing behavior to every customer. This matters even more for AI features, where model behavior and production traffic teach you things a staging environment never will.

Announce

Shipping is not done until the customer knows about it. Ship weekly, announce weekly: the changelog is written for the customer, not the team, in words they would use (see principles).

GTM should always be abreast of what is coming down the pipe. They follow the project from the start, and the messaging artifact from discovery, i.e., the landing page, video or memo (see cycles), is what a larger announcement is built from. A small improvement just goes in the weekly changelog.

4. Quality

It is the responsibility of both the product lead and the engineering lead to ensure the quality of the product/feature is being released. Automated and AI-driven tests are helpful, but the leads should obsess over the details and ensure the feature is high quality. With current tooling, the feature can be tested on the feature branch before merging to the main (i.e., deploying to production).

I do not hand work to a separate QA function and call it done. Quality is not a phase. For deterministic software, it means validating the important states and failure modes. For AI features, it also means evaluating model behavior, tool use, latency, cost and the quality of the final outcome.

A feature is not finished b/c the code merged. It is finished when it behaves well for customers.

5. Bug fixes / On-call / Security

We should always be fixing bugs. Every week, one engineer from the team should be on bug duty. If things go down outside office hours, the same engineer should be on pager duty. Before every weekly planning meeting, the product lead should review the bug list and ensure enough scope is available for the allocated engineer. If spare eng capacity exists, the product lead and engineer can try and de-risk some longer-term ideas or pay off technical debt.

Bugs are product work and they compete with features. I do not set aside an arbitrary percentage of every cycle for them. The attention follows customer impact, and if production is unhealthy, feature work loses.

Below are some severity levels for production issues that a product can face:

  1. SEV-1 (Critical): Major outage or critical functionality broken; customers cannot use the product or a crucial part of it. Requires immediate, all-hands response.
  2. SEV-2 (High): Significant degradation; a major feature is partially down, or performance is seriously impacted for many users.
  3. SEV-3 (Medium): Minor feature malfunction; noticeable but not blocking customers from primary tasks.
  4. SEV-4 (Low): Cosmetic or trivial issue, minimal impact.

The on-call engineer should be able to make a call on the severity of the issue and then communicate the same to the product and engineering leads. There should be a Slack channel to manage the communication related to the issue.

Severity is there to communicate impact, not to create ceremony, and it can change as we learn more. The first job is containment and communication, not arguing about the number. An incident has one owner and one place where the response is coordinated. Pull in the people needed to restore service and do not turn it into an all-company group chat.

Afterwards, spend effort on the failure in proportion to what it taught you. A serious or repeated incident deserves a written review and changes to the system. A trivial one does not need a ceremonial postmortem.

Security issues follow the same path. A vulnerability gets a severity, an owner and a fix the same way an outage does, and it does not wait for the next planning meeting. Managed infrastructure gives a small team strong security and compliance without owning every layer of the stack. What we build on top of it is still ours to get right.

6. Close the loop

Production is another source of product information. Support tickets, traces, logs, product analytics, eval failures and direct customer feedback should all flow back into prioritization. A release is not the end of the loop. It creates the evidence for the next decision:

project → branch → review → release → observe → learn → improve

AI can speed up several parts of that loop, but it does not change the responsibility underneath it. Build it, ship it, watch it, fix it and learn from it.

The earlier parts cover principles, meetings, planning and cycles. Who does all of this is in A startup is a sports team and (Fullstack) AI Engineers.