CloudBees Unify.
February to May 2025.
One launch, sixteen weeks. We repositioned CloudBees from the Jenkins company to the control plane for software delivery, because a competitor was about to define that category for us.
I refused to measure this launch by what shipped.
Impressions can look great and a launch can still be failing underneath them. So I set the measures before we started, and picked one to steer by. The rest were instrumentation.
Top of funnel was healthy and we won about 60% of deals that reached qualified, so stage 3 was the only broken link in the chain. Impressions can look excellent while nothing gets there.
Assets shipping is not evidence a message landed. Gong call scoring was.
PMM's standing metric. Cycles ran six to nine months, so removing a stage was worth more than adding a touch.
A customer who will vouch is the only proof the positioning is real.
Tests whether the story reached a higher buying center.
The launch was anchored on field readiness, not on an event.
Most launches this size get hung on a conference date. Ours couldn't. CloudBees had been the only real option in its category for a decade, so our reps had never had to sell competitively. That, not awareness, was the real problem. The anchor became internal instead: a mini sales kickoff to get the field the new story in person, before any of it went public.
- Early Feb 2025The signal
We heard a competitor was about to ship against capability we already had. That set an end-of-May target and started the clock.
- Feb 2025CloudBees Unify, named
We named it CloudBees Unify and staked the control plane category claim, so the language was ours to define rather than answer. Two analyst submissions, to Gartner and Forrester, anchored the new narrative.
- Feb to MayValidate, then arm the field
Wynter message testing against the real buyer, analyst briefings, a mini sales kickoff, and the SDLC 101 course that taught reps the lifecycle they were selling into.
- May 2025Unify launches
On the date we set in February.
- July 2025Great impressions, pipeline was stalling
TOFU metrics were lighting up, but deals were stalling at Sales Stage 2. We had a qualification problem, not an awareness problem. That is when I went back to win/loss.
- August 2025Re-anchored on control plane
Rebuilt the core differentiation around control plane, the category language we'd already seeded in February. Same window we set the PMF bar.
- November 2025Independent validation
We commissioned the DevOps Migration Index, an independent study on enterprise rip-and-replace failure, to back the control plane argument with data we didn't write ourselves.
Read the DevOps Migration Index - January 2026Proof, not announcement
The bar moved from launch to product-market fit: 10 referenceable customers. We closed at 13.
- Owned the launch narrative
- Developed the positioning
- Built the messaging framework
- Led the Gartner MQ submission
- Led the Forrester Wave submission
- Prepped the exec briefings
- SDLC 101 course
- Sales plays and competitive GPTs
- Champion program with the top reps
- Gong pitch-relevance scoring
- Customer reference conversion
- Deal size and win-rate analysis
The market's answer to tool sprawl was consolidation. I bet against it.
- 1Rip out the toolchain you have
- 2Standardize on a single vendor
- 3Govern whatever survived the migration
- 1Keep the tools each team already chose
- 2Put a governance layer above the whole stack
- 3Enforce policy in the runtime, not by convention
We named it the control plane in February 2025, before the term was in common use. And it was a risk argument rather than a preference. Bind your governance model to one vendor and you've bet your own audit exposure on that vendor's release cadence.
A coordination layer whose only fully supported stack is its own is not a coordination layer. It is a migration with governance attached as the incentive.
I kept two things named separately. The control plane is where policy and evidence get defined, and release orchestration is the execution layer where they actually run. Collapse those into one word and the whole reposition reads as new packaging on the product we already sold.
Every tool is green. But can you ship?
The build passed. The scan came back clean. The board signed off. But is it safe to ship?
CloudBees Unify is the one layer above the tools you already run. It reads every signal, resolves every conflict, and gives you a single honest answer.
Same tools. Same teams. No migration.
cloudbees.com/unifyBoth of these carry our CPO's byline and I informed the narrative behind them. They're a pair on purpose. The first is the launch manifesto written for the architect, our champion. The second is the executive rebuild, five months later.
“We are not a platform. We are CloudBees Unify, an operating layer for the modern enterprise.”
“What's missing isn't another platform. It's a DevSecOps control and context plane.”
PMM owned the source. Every channel downstream inherited it.
I didn't hand marketing a positioning doc and hope. Positioning and messaging sat with PMM, and the press release, the blogs, the webinar series, the campaigns, and the sales plays were all built off it rather than each writing their own version.
Then the internal half, which is the part that decides whether a message survives past launch week.
The teaching piece was a course I built called SDLC 101. Our reps knew our products and not the lifecycle those products lived inside. Customers don't buy point solutions, they buy solutions to their problems, and you can't sell to a problem you can't locate.
had us filed
The organizing rule was embrace, don't replace. Name the one stage we genuinely owned, and everywhere else connect to what the customer already ran instead of pitching a rip and replace. A rep who can place a stated pain onto a stage knows in the same instant whether we have an earned claim, an embrace claim, or no claim at all.
Force Management Command of the MessageThe discovery-to-proof structure reps actually sold withThe impression data was excellent. None of it converted to qualified pipeline. A quarter of good-looking numbers is exactly how a launch dies quietly. Win/loss told me why: we had champions, not a line to the VPs who sign, an access problem as much as a perception one. The control-plane reframe existed to close exactly that buying-center gap. I rebuilt the executive materials around business outcomes, armed reps with sales plays and training, and used Gong scoring to prove the message was actually landing.
We marketed a unified platform while we were still launching individual products.
Nine months in, that was the honest read. Externally the story was one platform. Internally we were still sequencing releases feature by feature, prioritized by engineering capacity, and that gap comes due the first time a customer asks the platform to behave like one. It changed how I organize launches, around customer outcomes rather than around whatever happens to be shipping.
That same nine-month mark is where we were still working out where AI fit into the platform story, what we settled on calling the context plane, parallel to the control plane language from launch. Getting that timing right mattered: it's what carried into how the messaging evolved for our SKO in February 2026.
The smaller one I keep relearning is to validate with customers before the internal moment, not after. And a launch is a program, not a moment. May 2025 started it, and proving it out took the rest of the year. Nearly all of the learning happened in the first 90 days.
We ran this with an awareness-grade launch and pipeline-grade metrics, and nobody said that out loud on day one. If I'd declared the objective as pipeline at T-minus-16-weeks instead of letting the metrics imply it later, funnel instrumentation would have been critical path from the start instead of something I backfilled a quarter in. The flat quarter was a planning failure before it was a messaging one.
The other: we commissioned the DevOps Migration Index in November, five months after launch. Run that same study pre-launch instead, and we'd have had independent ROI signal to validate the control-plane messaging before we bet the reposition on it, not after.
I proved the same Jenkins-to-platform reframe on our release orchestration line, a $45M business, where it drove +26% ARR. Separate launch, two years earlier, and I keep it separate. It's why we knew the motion was repeatable.
At a January product offsite I reframed three separately queued capabilities into one buyer outcome and pushed the launch trigger from GA to demoable. I moved on before that phase reached GA, so there's no downstream number attached to it. I'd rather say that than imply one.
Everything referenced above, in full.
Reconstructions written from public CloudBees material plus proof points I can personally verify. No confidential detail, no roadmap, no invented numbers. Where a claim needs evidence CloudBees never published, it says so.
The plan as it should have been briefed on day one, with a RACI across nine functions. Its whole point is the correction: funnel instrumentation belonged on the critical path, not backfilled after a quarter of great impressions and no pipeline.
Worked from competitive alternatives up rather than from the product down, including the alternative most positioning exercises forget: the buyer keeps governing manually and buys nothing.
The pillar structure under the launch narrative, with claims marked UNPROVEN where CloudBees has not published the evidence, plus the one messaging risk the company actually ran into.
Discovery-to-proof structure for selling against a consolidation platform or against the status quo. Where the honest answer was not quantified, it says so.
Every stage tagged against where CloudBees had an earned claim, an embrace claim, or no claim at all. Includes the deploy-versus-release mix-up every new rep walked in with, and the cake analogy they actually repeated back.
February 2025. Why we submitted on the product line that would become Unify instead of on our strongest legacy tooling, and what that cost us on paper to buy a truthful record before the May launch.
Three separately queued capabilities, reframed into one buyer outcome, with the launch trigger moved from GA to demoable to recover 90 days against competitors already embedded in deal cycles. I left before this phase reached GA, so there's no downstream number attached, only the bet and the reframe.
Live properties. The two posts carry our CPO's byline and I informed the narrative behind them.
This is built to be talked through.
Happy to walk the whole thing live, including the calls I'd make differently and the ones I still think were right.