Product Release Lifecycle Management
Redesigned Vivi's release model from a continuous, high-churn deployment cadence to a staged Preview/GA channel system. The result: NPS moved from approximately 40 to nearly 80, and the product team regained the ability to ship with confidence.
The Situation
Vivi’s growth had been fast — perhaps too fast for the release infrastructure to keep up. By the time I joined, the company was shipping software updates directly to production with minimal staged rollout, which meant that every release was a live experiment run on the full customer base. Schools are an unforgiving environment for this kind of model: IT teams don’t have time to debug unexpected regressions, and teachers definitely don’t.
The Problem
The core issue was structural. The release model had no gate between engineering “done” and customer “live.” When something broke — and things broke regularly — customer support absorbed the impact immediately, and the CS team was fielding tickets that were essentially product defects dressed as support requests.
The downstream effects compounded:
- NPS was stagnant around 40. Customers were tolerating Vivi, not advocating for it.
- CS team was reactive by default. They had no mechanism to predict which releases would generate ticket spikes.
- Engineering confidence was eroding. Shipping felt risky, which created hesitation and longer internal review cycles — without actually reducing defect rates.
The Approach
The solution was conceptually straightforward but organizationally challenging: introduce a staged release channel system.
Preview Channel: A voluntary opt-in for technically sophisticated customers (school IT directors, power users) who were willing to receive updates 2–3 weeks ahead of general availability in exchange for providing feedback. This gave us a real-world signal layer between QA and production.
GA Channel: The standard release path. Updates only promoted to GA after Preview cycle results were clean — defined by a specific threshold of CS ticket volume, crash rates, and proactive Preview partner feedback.
Internal Governance: Established a Release Readiness checkpoint with CS and Engineering leads before each GA promotion. Short, structured, decision-focused — not a bureaucratic review.
Customer Communication: Developed a standing release notes format that CS could use directly in partner conversations — with plain-language descriptions of what changed, what improved, and what to watch for.
The Outcome
NPS moved from approximately 40 to nearly 80 over the following release cycles. CS ticket volume from regression-related issues dropped substantially. Engineering shipped with more confidence because defects surfaced in Preview rather than in production.
The Preview channel also became a relationship asset — the school IT directors who opted in became informed advocates, and their feedback loop improved feature definition on subsequent releases.
What I Learned
Organizational buy-in matters as much as the release framework itself. The system only worked because CS, Engineering, and Product aligned on what “ready” meant before the first Preview cycle ran. Without that alignment, a staged channel is just bureaucracy. With it, it becomes a quality multiplier.