SDLC 101: The Course That Taught Reps the Lifecycle
Reps knew our products. They didn't know the lifecycle those products lived inside. Customers don't buy point solutions, they buy solutions to a problem, and a rep can't locate a problem inside a lifecycle they can't picture. Before Unify, the rep's mental model stopped at Jenkins: CloudBees was “the CI tool,” full stop. That's an accurate description of one stage out of seven, and it's exactly the box the market had us filed under for a decade.
Unify's launch was the occasion to widen that picture, so the course maps the full lifecycle, not just the stage CloudBees came from. The strategy behind the map was embrace, don't replace: focus the product claim on the one stage CloudBees actually excelled at, and everywhere else, embrace the tools already in place rather than pitch a rip and replace.
A rep who can place a customer's stated pain onto one of these seven stages knows, in the same instant, whether CloudBees has a right to be in that conversation at all, and if so, whether it's a heritage claim, an embrace claim, or no claim at all.
Never our territory. Embraced by connecting to it (a planning tool, a repo), never pitched as something to replace.
The one stage CloudBees actually excelled at and owned outright.
The stages Unify let us compete for, by embracing the tools a customer already runs and coordinating them as one governed system, rather than asking anyone to migrate off them.
A business need becomes a scoped, sequenced body of work.
Product managers, business analysts, engineering leads
CloudBees never sold a planning tool. Unify connects to it so a release traces back to the work item it shipped.
A plan becomes a change set: writing, reviewing, merging source.
Software engineers, tech leads, code reviewers
Connect to the repo a customer already runs. A rep says that plainly rather than implying we want to own it.
Reviewed code is compiled and packaged into a reproducible artifact.
Build and CI engineers, DevOps engineers, release engineers
Real credibility, not something to disclaim. But it is one stage out of seven, and treating it as the whole pitch is what kept reps boxed in.
The built artifact is checked against functional, performance, and security requirements.
QA engineers, SDETs, security engineers, test automation
No native test engine, and embrace don't replace means we don't try. A test run in any of these becomes a tracked step in the same governed release.
The governed decision that a candidate build is approved to ship.
Release managers, change advisory board, compliance and audit
The stage the control plane reframe is built on. The immutable release manifest wraps around whatever tooling is already there.
An approved release physically moves into an environment.
SRE and platform engineers, DevOps engineers, release engineers
Unify doesn't replace the deploy engine a team runs, it tracks that deploy as a step in the governed release.
Policy, evidence retention, and the audit trail across the other six.
Security and compliance, platform leadership, auditors, CISO
The most forward-leaning claim, and the one the retro flagged hardest. Runtime policy for AI agents is architecture, not yet a measured outcome.
Deploy is an action. Release is a decision.
Reps used the two as synonyms. They aren't, and the difference is the whole reason CloudBees treats them as separate stages. Deploy is the mechanical fact of an artifact moving into an environment, up to and including production. Release is the governed call that whatever just moved is actually available to customers.
The two routinely happen apart. Code can be deployed to production behind a feature flag, sitting there dark, fully shipped and not released to a single user. A release can happen with no new deploy at all, flipping a flag on code that has been in production for a week.
A rep who collapses them will describe a customer's dark-launch practice as broken ("you deployed it but it's not live?") when it's a deliberate, mature pattern they built on purpose. Naming the distinction correctly is often the fastest way a rep earns credibility with a platform engineering audience in the first five minutes.
Baking a cake
The seven-stage map, accurate as it is, isn't what a rep repeats back to a customer at 4pm on a Friday. A cake is.
- PlanDeciding what cake to bake and pulling the recipe. That decision belongs to whoever is planning the event, not to whoever eventually bakes it.
- CodeMeasuring the ingredients and mixing the batter. CloudBees doesn't sell flour, and it doesn't sell mixing bowls either.
- BuildPutting the batter in the oven. The stage CloudBees has always owned: the oven everyone already trusts to turn batter into a cake, the same way every time.
- TestThe toothpick test. Checking that what came out of the oven is actually done before anyone commits to serving it.
- ReleaseThe decision that the cake is frosted, inspected, and cleared to leave the kitchen. A decision, not an action.
- DeployCarrying the cake out and setting it on the table. The action, not the decision. A cake can sit under a cover, deployed but not released, same as a feature flag.
- GovernThe recipe card that travels with the cake, so when someone asks what is actually in it later, an allergy question, an auditor, there's a written answer instead of a reconstruction.
CloudBees was never trying to be the cookbook or sell the flour, and it wasn't asking anyone to buy a new oven. Theirs already works. What Unify added was everything after the oven: knowing the cake is done, deciding it's ready, getting it to the table, and keeping the card that says what's in it.
Embrace, don't replace.