A release-cadence transformation at Datasite: moving from quarterly, big-bang releases (each one a major, coordinated, risk-laden event) to roughly 20 deployments per day with no customer-visible disruption. This was only possible once the Monolith-to-Microservices Migration Playbook had decomposed the platform into independently deployable services, paired with the CI/CD and testing discipline needed to ship small changes safely and often.
Deployment frequency is a leading indicator of architectural and organizational health: a company still doing quarterly releases likely still has a monolith and a top-down, plan-heavy Roadmap (Feature/Project List) process; one shipping dozens of times a day has decoupled its services and its teams enough to let each Product Trio or squad (Spotify Squad Model) release independently. The target isn't speed for its own sake — it's the ability to validate ideas from Discovery (Product Discovery Process) far faster than a quarterly cycle would allow, using Feature Flagging / Cohort Release.
Apply: treat release cadence as a diagnostic — if teams can't deploy small changes independently and frequently, look upstream at the architecture (still a monolith?) and organization (still siloed?) before trying to fix process alone.
Cagan sets a hard floor: a team must be able to release independently at least every two weeks, or "sadly you don't even have the benefits of basic scrum" — let alone the product model. He treats this as a quick diagnostic for Cosplaying the Product Model: teams still batching releases on a longer cycle are reusing the word "agile" without the substance ("fake agile").
Delivery should ideally be continuous — daily, or many times a day — with two weeks as the outer minimum cadence. This requires telemetry at three levels (infrastructure, application, and user) plus A/B testing and dark launches to ship safely at that speed.
Cagan credits continuous deployment/delivery as the foundation the other Product Model (vs. Roadmap Model) dimensions depend on: frequent, independent, small releases per team, ideally daily or multiple times a day, with every two weeks as the minimum acceptable cadence. Practical test: if a team can't release independently at least every two weeks, fix the build/deploy pipeline before attempting any other product-model change.
Cagan points to the book Accelerate as the empirical case for continuous delivery — years of research correlating deployment frequency and stability practices with organizational performance. He uses it to preempt the objection that continuous delivery is a developer-comfort preference rather than a business-results practice.
Cagan argues continuous delivery — small, frequent, reliable, uncoupled releases with Telemetry / Instrumentation (Three-Level Monitoring), A/B testing, and dark releases — isn't optional infrastructure but the mechanism that makes outcome claims verifiable. Without it, talk of "outcomes over output" is, in his words, just "hand waving": there's no way to actually measure whether a shipped change solved the problem.
Cagan treats small, frequent, reliable, uncoupled releases as prerequisite infrastructure, not a nice-to-have: "if you don't have the ability to do small frequent reliable uncoupled releases, good luck being any good." Without this — plus instrumentation and telemetry, A/B testing, and dark releases — a team has no way to prove whether a shipped change actually produced the outcome it was meant to.
Из тем: Transformation in Practice