Decide what Optimizely should own before adding anything else to the stack.
The platform usually isn’t the gap. The gap is nobody decided which team owns which decision, or which system holds the customer record once two platforms both think they do.
- Business problemWhat has to change, in the business’s own numbers
- Customer journeyWhere people get stuck or leave
- DataWhat we know about them, and how much to trust it
- StackWhat they already own and already do well
- Optimizely’s roleThe jobs it should own, and the ones it shouldn’t
- PrototypeSomething they can see working before they commit
- OutcomeMeasured, and run by their team afterward
Real situations
The situations that keep showing up, and the decision I made in each.
Five specific customers, five specific decisions.
Web and Feature Experimentation across the same customer journey.
- Web ExperimentationMarketer-owned acquisition changes
- Full Stack / Feature ExperimentationProduct-owned features, flags and rollouts
- One visitor identityCarried through the quote flow by the tag manager
- AnalyticsWhere results get checked
- GovernanceWho approves what, before anything launches
- Outcome
- Retire a legacy testing tool and keep testing running through a multi-country site migration, without breaking measurement on a quote flow that crossed domains.
- Signal
- Which changes were marketer-owned acquisition edits and which were product-owned features, plus one visitor identity that had to survive the whole quote flow.
- Decision
- Web Experimentation owns marketer-led acquisition changes on the front of the journey. Feature Experimentation (Full Stack) owns product-led features and rollouts deeper in the quote flow. One visitor ID, carried by the tag manager, ties both back to a single journey-level measurement.
- Optimizely’s role
- Web Experimentation + Feature Experimentation (Full Stack), sharing one visitor identity through the tag manager.
- Proof + ownership
- Governance and approval gates written down before launch; marketing owns the acquisition layer’s tests, product owns the feature layer’s, and each reads results against the same identity.
What I did
- Framed Web for marketer-owned acquisition work and Full Stack for product-owned features
- Wrote the onboarding governance and approval gates
- Kept one visitor ID through the quote flow so tests could be measured across steps
Don’t build an audience until you know what you would do differently.
- Outcome
- Whatever decision the business actually needs to change for a segment: a different offer, message or path, not a different audience for its own sake.
- Signal
- The minimum trustworthy identity and behavior data needed to make that one decision, not every signal the ODP schema can hold.
- Decision
- Which segments have earned a different experience today, and which ones don’t yet have enough signal to justify one.
- Optimizely’s role
- Personalization for the experience change; ODP for the identity and audience data behind it.
- Proof + ownership
- A measured difference against the stated decision, owned by whoever approved that segment, not by the platform team that built it.
I don’t have a delivered or pursued program that cleanly fits this yet, so this is the pattern, not a client result. Don’t begin by asking what audiences ODP can create. Begin with a decision worth changing, then determine the minimum trustworthy signals required to make it.
Use AI to check the workflow, not approve the claim.
- Approved-content reviewRegulated review happens upstream, as it does today
- Human and regulatory gateOnly people approve medical and legal content
- OpalEnforces approval status. It never grants it.
- Digital activationPages and campaigns built from approved content
- MeasurementPer-wave baselines and a monthly AI consumption report
- Outcome
- Modernize a regulated CMS without letting anything unapproved publish, and keep AI cost and analytics continuity accounted for through the move.
- Signal
- Which content had already cleared upstream regulated review, and what AI usage looked like wave over wave.
- Decision
- Approved-content review stays upstream and human. The AI layer checks approval status; it never grants it. Fixed rules stay rules, and scheduled judgment work goes to Opal.
- Optimizely’s role
- CMS (SaaS) for activation, Opal scoped to checking approved content and reporting its own cost.
- Proof + ownership
- Per-wave migration baselines measured against sites not yet moved, plus a monthly AI consumption report; the client’s compliance team keeps approval authority throughout.
What I did
- Separated upstream regulated review from Opal’s job
- Proposed measuring the migration in waves against sites not yet moved
- Proposed a monthly report on AI consumption
- Kept always-on AI out of places it would add cost without adding judgment
A pursuit. These were proposed answers inside a larger team pursuit, not delivered work.
Start with one review agent, inside the CMS they already run.
- 0-3 months: One review agentBrand, accessibility and AI-search checks inside the CMS they already run. No new purchase.
- 3-9 months: Close the data loopCustomer and account data from CRM, CDP and warehouse feeding decisions the team can act on.
- 9-18 months: Governed agent modelAgents become part of how marketing works, with people approving what matters.
- The problem
- Strong platforms for CMS, B2B commerce, testing, customer data, CRM, marketing automation, warehouse and assets, each holding its own slice of the customer.
- My role
- I wrote the roadmap proposal: one review agent inside the CMS they already owned, then a customer and account data loop, then a governed agent model.
- Decision
- Start with one review agent inside the CMS they already run, with no new purchase, before connecting CRM, customer data and the warehouse into one loop.
- Customer value
- A first phase small enough to prove in weeks, on platforms they already pay for.
A pursuit. Nothing has been built yet.
Two experiments a week, measured in accounts opened.
- New platformOptimizely was already bought
- Program structureA rhythm of two experiments a week
- AudiencesSegments worth testing against
- Experiment portfolioBeyond simple A/B, toward server-side
- Business measurementAccounts opened, not clicks
- The problem
- The brokerage had just moved to Optimizely and wanted more volume, speed and value from testing, plus better use of audiences and server-side tests.
- My role
- I shaped the response and the working plan.
- Decision
- Keep the platform they had just bought and change the operating rhythm around it: two experiments a week, audiences tied to the test portfolio, success measured in accounts opened.
- Customer value
- A plan the team could run every week, judged by a number the business already reported.
What I did
- Drafted the discovery and response material
- Set a direction of two experiments a week
- Tied audiences to the experiment portfolio
- Proposed measuring against accounts opened rather than clicks
- Laid out the step beyond simple A/B tests
A pursuit. This is the approach I proposed, not work I delivered.
The stack
Optimizely rarely works alone.
In nearly every Optimizely program I worked on, the testing tool sat next to a separate analytics system. CRM, customer data, content and workflow tools showed up as programs matured. My job is deciding which connection actually creates value.
Experience
Where the customer sees the change: pages, content, offers and features.
The decision: Which surface should change first, and who owns it.
Customer data
What we know about the person or account, and how much we trust it.
The decision: Which signal is reliable enough to act on today. The CRM keeps the account record and the warehouse keeps the history; the CDP carries what the page needs.
Evidence
The independent record of what actually happened.
The decision: What we’ll check the testing tool’s answer against.
Activation
Where a decision turns into a message, a task or a sale.
The decision: Which handoff needs to happen without a person copying data.
Agentic
Work that can be done by agents, with people approving what matters.
The decision: Which repeatable step earns automation, and where the human gate sits.
Every design on this page ends with who runs it and how they’ll know it worked.
That’s usually the part that decides whether the customer renews, not the architecture diagram.
A good design still fails if the team can’t operate it.
Optimizely and related product names are trademarks of their owner. This section reflects my own professional experience with the platform. It is not affiliated with or endorsed by Optimizely, and client examples are described by industry, not by name.