Start with the problem. Then decide what Optimizely should do.
The best solution usually isn’t “use more Optimizely.” It’s figuring out which parts of the problem Optimizely should own, what the customer’s existing systems already do well, and where the handoffs need to work.
- 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
The approach
Five decisions, in this order.
I use the same sequence whether the customer is buying their first testing tool or deciding where agents belong. Skipping ahead is how teams end up owning software nobody uses.
- OUTCOMEWhat behavior needs to change. Revenue, lead quality, content speed, test quality, member retention, marketing capacity. I want the business number first.
- SIGNALWhat we know well enough to act on. Which data is clean enough to trust today, and which one still needs work before anyone personalizes on it.
- DECISIONWhat experience, content, offer or feature actually changes. The CRM keeps the account record and the warehouse keeps the history; too much platform, too early, is where designs go wrong.
- OPTIMIZELY’S ROLEWhich product, or products, should own that change: Experimentation, Personalization, ODP, CMS, CMP, Commerce or Opal. Usually fewer than the contract covers.
- PROOF + OWNERSHIPHow we’ll know it worked, and who owns it once the deal is signed. If I can’t answer that, the design isn’t finished.
Solution patterns
Four slots. Same five-part decision model in each.
A, B, C and D are the architectures I reach for most: web-plus-feature experimentation, personalization and data, regulated content, and commerce. Where I have a delivered or pursued program that fits one cleanly, I use it. Where I don’t yet, I say so and give the pattern instead.
The architecture matters because ownership matters.
- 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 start from what ODP can create.
- 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 slot 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.
AI is easier when you decide what each AI is allowed to own.
- 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.
How I’d connect the capabilities.
- Outcome
- A commerce behavior worth changing, such as browse, quote, configure or checkout, tied to a number commerce already owns.
- Signal
- Customer and account context already sitting in commerce, CRM or the CDP, filtered down to what’s clean enough to act on today.
- Decision
- Which part of the commerce experience changes for which customer or account, and which part stays the same for everyone else.
- Optimizely’s role
- Commerce for the transaction, ODP or CRM for account context, Web or Feature Experimentation for the test itself.
- Proof + ownership
- A commerce metric the commerce team already tracks (conversion, order value, repeat purchase), owned by whoever runs that funnel once the test ends.
I don’t have a delivered or pursued program that cleanly fits this slot yet, so this is the pattern, not a client result. The logic: commerce behavior leads to customer context, which leads to a decision, which leads to an experiment.
Other designs
Not every good design fits a clean architecture.
These two didn’t map onto the four patterns above, and I’d rather show the design than force it into a slot it doesn’t belong in.
A new testing platform wasn’t the strategy.
- 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.
- Status
- A pursuit. This is the approach I proposed, not work I delivered.
- The 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
Don’t bolt AI onto the stack. Give it a job inside the stack.
- 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.
- The 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.
This was a proposal. Nothing has been built yet. It spans CMS, commerce, customer data and agents at once, so it reads as a roadmap rather than any single lettered slot above.
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.