There is a traditional division of labor: consultants write the strategy, designers make the wireframes, engineers build the code, and operations vendors keep it running. We think that division itself is the problem.
In the first six months after launch, more real things happen to a product than in the entire year before it. Users click on places we were sure no one would click. Monitoring pages someone at 3am for the first time. Support starts hearing questions we never imagined. If the design and engineering teams dissolve at v1, all those real events have nowhere to land.
What this looks like in practice
Every launched project has a resident engineer and a product manager who directly own it for at least 12 weeks after launch. Monitoring, growth instrumentation, compliance renewals, point releases — all of it sits with them. This is not a “maintenance contract.” This is part of delivery.
// Default engagement shape
const shape = {
phase_0: 'Consulting', // weeks 1–3
phase_1: 'Design', // weeks 2–8
phase_2: 'Build', // weeks 6–18
phase_3: 'Launch', // week 18
phase_4: 'Operate', // week 18 → ongoing ★
};The starred line is what this post is actually about.
“Delivery” is not a moment. It is a continuous state — software still running, still used, still being changed.
One concrete example
Last year we built the companion app for a sleep-aid headphone in partnership with Whale Precision. After v1 shipped, we noticed a non-trivial portion of users were disconnecting Bluetooth before sleep — they were using the headphones as a white-noise device and wanted their phones away. We put “offline mode” on the roadmap that week and shipped it shortly after.
That feature could not have appeared in any pre-launch planning document. It only exists in the real world. Only the people who stay can see it.