Building the Launch System for a New-Brand Incubator

Two Brands, Nine Months, No Playbook

Before I moved into AI product management, I spent a chapter of my career on the core team of a founder-sponsored new-brand incubator inside a direct-to-consumer unicorn - a small internal group whose job was to take new brand concepts from a blank page to a real, revenue-generating business, fast, using the parent company's distribution and infrastructure as a running start rather than building each brand's go-to-market from zero.

I owned two D2C brands from day one. Not from launch day - from the day the brand concept existed only as a name and a product thesis. Nine months later, the two brands combined were running at a roughly $10 million annualized run rate. That number is the one people ask about first. It is also the least interesting part of the story, because it was not the output of one good idea. It was the output of a launch system that did not exist when I started, and that I had to build while simultaneously using it.

Why "Launch Fast" Breaks Without a System

The incubator's whole premise was speed - launch a new brand in a fraction of the time a standalone startup would take, because you already have manufacturing relationships, a warehouse network, and a customer base to draw early buyers from. What nobody had solved was what happens after the product ships. Every prior brand launch inside the incubator had rebuilt its acquisition funnels, its lifecycle marketing, and its CRM logic from scratch, because each one had been treated as a one-off project rather than an instance of a repeatable pattern.

That meant every launch was reinventing decisions that had already been made, sometimes badly, by the brand before it. Which channels to prioritize at launch versus at scale. How to sequence a new customer's first ninety days so they became a repeat buyer instead of a one-time purchase. What pricing and offer structure actually held up once the launch-week discount expired. None of that was written down anywhere as a system. It lived, if it lived anywhere, in the head of whoever had shipped the last brand.

What I Built: The Launch GTM System

I authored the launch go-to-market system that the incubator adopted as its standard, built around two components.

The first was a set of eight acquisition funnels, each mapped to a different channel and customer-intent level rather than a generic "run ads everywhere" approach - separate funnel logic for a cold-audience discovery buyer on paid social versus a warm-audience buyer arriving through influencer or affiliate content, each with its own landing sequence, offer structure, and expected cost-per-acquisition range so a new brand launch could pick the right combination for its category instead of guessing.

The second was a fifteen-journey lifecycle CRM - a structured set of customer journeys covering onboarding, replenishment, win-back, and loyalty escalation, built so that a new brand did not have to design its retention marketing from a blank canvas. A brand entering the incubator could plug into journeys that had already been tested on a prior brand's customer base, adapted for its category, rather than starting the lifecycle marketing conversation from zero.

Fixing the Money Leaks: Pricing and Offer Experiments

Acquisition and retention infrastructure meant nothing if the unit economics underneath them did not hold up, so I ran a structured series of pricing and offer experiments across both brands - testing subscription cadence, bundle structure, and discount depth against actual churn and lifetime value rather than against launch-week conversion rate, which was the metric everyone had been optimizing for by default.

The result was a roughly 25% reduction in churn and a roughly 40% increase in average order value and lifetime value, driven mostly by moving away from deep, unsustainable launch discounting toward offer structures that priced correctly for what a repeat customer was actually worth. Launch-week conversion rate is a vanity metric if the customer it buys does not come back. Getting the incubator's brands to optimize for the second purchase instead of the first was a harder internal argument than the pricing experiments themselves.

The iOS14 Attribution Crisis

Partway through, Apple's rollout of App Tracking Transparency in iOS 14.5 broke the attribution infrastructure that essentially every direct-to-consumer brand advertising on Meta had been relying on. Pixel-based, last-click attribution that had reliably told us which campaigns were actually driving purchases suddenly reported a fraction of the conversions that were really happening, and every brand running paid social at scale was making budget decisions on data that had quietly become unreliable.

I rebuilt our attribution stack around Meta's Conversions API, moving measurement from a browser-side pixel that Apple's changes had crippled to a server-side event pipeline that reported conversions directly from our own infrastructure. That rebuild recovered roughly 70% of the ad efficiency the platforms had lost to the attribution gap, and it became the reference implementation the rest of the incubator's brands adopted once their own numbers started looking similarly broken.

Codifying the Playbook: 145 Activities, One Standard

Building all of this twice, for two brands, in parallel, made the repeatable pattern underneath the work impossible to ignore. I codified it into a 145-activity range-launch playbook - a sequenced checklist spanning everything from pre-launch category research through the first ninety days of lifecycle marketing, specific enough that a new brand team could execute against it without rediscovering the same lessons the hard way.

That playbook became the incubator's standard for every subsequent brand launch, which is the outcome I am most proud of from that chapter. A good launch is useful once. A good launch system is useful every time after.

Results

Two brands taken from day-one concept to a combined ~$10 million annualized run rate in roughly nine months.
Eight acquisition funnels and a fifteen-journey lifecycle CRM, authored as the incubator's reusable go-to-market infrastructure rather than one-off campaign work.
Churn reduced by roughly 25%; average order value and lifetime value increased by roughly 40%, through pricing and offer experiments run against retention economics rather than launch-week conversion.
Ad efficiency recovered by roughly 70% after rebuilding attribution around Meta's Conversions API in response to iOS14's tracking changes.
A 145-activity launch playbook adopted as the incubator's standard operating system for every brand launched after mine.

What I Would Do Differently

I would have started codifying the playbook alongside the first brand rather than after seeing the pattern repeat on the second one. I treated the first launch as a one-off problem to solve under deadline pressure, which is the same mistake the incubator's prior launches had made before I arrived. I only recognized it as a system once I was forced to rebuild the same decisions a second time.

I would also have pushed for the attribution rebuild earlier, proactively, rather than reactively after the iOS14 changes had already degraded a full quarter of paid media decisions. The signal that something had broken was visible in the data before we acted on it. I was slower than I should have been to trust that the platform-reported numbers, not our targeting, had become the problem.

The Broader Pattern: 0-to-1 Systems Thinking Translates

The specific tools change - acquisition funnels and lifecycle CRM in that chapter, multi-agent orchestration and foundation models in the work I do now. The underlying discipline does not. Every 0-to-1 problem I have worked on since, in an entirely different domain, has rewarded the same instinct: do not solve the instance in front of you, solve the class of problem it belongs to, and write down the system so the next person does not have to relearn what you just learned under deadline pressure.

That is the thread that actually connects a direct-to-consumer brand launch to the enterprise AI platforms I build now. The domain looks nothing alike. The underlying question - what is the repeatable system underneath this one-off request, and who is going to need it after I am no longer the one running it - is identical.