Experimentation Brain Experiment Portfolio Governance Framework

Document Type: Framework
Status: Canon
Authority: HeadOffice
Applies To: Experimentation Brain, Data Brain, Research Brain, Affiliate Brain, Ads Brain, Conversion Brain, Finance Brain, HeadOffice, All AI Employees
Parent: Experimentation Brain Canon
Version: v1.0
Last Reviewed: 2026-05-08


Purpose

The Experiment Portfolio Governance Framework defines how MWMS manages experimentation as a balanced portfolio of iterative, substantial, and disruptive tests rather than a random sequence of isolated experiments.

This framework ensures MWMS does not become trapped in low-impact optimization loops, shallow testing velocity, or short-term margin polishing.

The framework governs how MWMS balances:

  • quick wins
  • meaningful user journey improvements
  • bold strategic experiments
  • innovation testing
  • learning depth
  • operational feasibility
  • business impact

Core Principle

A mature experimentation program balances optimization, learning, and strategic growth.


Definition

Experiment portfolio governance is the structured management of experiment types, effort levels, impact categories, business objectives, and learning value across the MWMS experimentation ecosystem.


Structural Role

This framework connects:

Experimentation Brain
→ owns portfolio governance

Data Brain
→ validates measurement and evidence quality

Research Brain
→ supplies problem themes and opportunity signals

Affiliate Brain
→ supplies commercial opportunity tests

Ads Brain
→ supplies acquisition and creative tests

Conversion Brain
→ supplies funnel and behaviour tests

Finance Brain
→ evaluates resource allocation and ROI exposure

HeadOffice
→ governs strategic alignment and survivability

AI Employees
→ recommend balanced experimentation actions


Portfolio Reality

Not all experiments serve the same purpose.

Some experiments optimize existing systems.

Some experiments test meaningful user journey changes.

Some experiments explore new growth directions.


Rule

Experimentation should not be reduced to small tactical tweaks only.


Iterative Test Layer

Iterative tests make smaller improvements to existing experiences.


Examples

  • copy changes
  • CTA wording
  • layout refinements
  • minor trust element adjustments
  • small friction reductions

Benefits

  • fast to build
  • low risk
  • useful for refinement
  • supports test velocity

Risks

  • limited learning depth
  • strategic stagnation
  • low stakeholder excitement
  • over-optimization of margins

Rule

Iterative tests are valuable but should not dominate the entire program.


Substantial Test Layer

Substantial tests meaningfully influence the user journey.


Examples

  • changing page structure
  • introducing new decision support
  • rebuilding a product page section
  • changing subscription presentation
  • redesigning offer comparison logic

Benefits

  • stronger learning potential
  • clearer user behaviour signals
  • more meaningful business impact
  • stronger stakeholder relevance

Risks

  • higher expectations
  • more planning required
  • greater design and development effort

Rule

Substantial tests should form the core of a mature testing roadmap.


Disruptive Test Layer

Disruptive tests significantly change the user journey or strategic direction.


Examples

  • testing a new funnel model
  • introducing a new pricing structure
  • changing primary navigation behaviour
  • testing a new offer presentation model
  • validating a new acquisition-to-conversion pathway

Benefits

  • high learning value
  • strategic breakthrough potential
  • business model insight
  • roadmap influence

Risks

  • higher uncertainty
  • stakeholder resistance
  • greater operational impact
  • stronger governance required

Rule

Disruptive tests should be protected as strategic learning assets.


Impact And Effort Separation Layer

Impact and development effort are not the same thing.

A low-effort change can create high impact if it affects a critical user touchpoint.

A high-effort change can create low impact if it changes something users do not care about.


Rule

Experiment priority should not be judged by build effort alone.


Critical Touchpoint Layer

Small changes at high-leverage touchpoints may produce major impact.


Examples

  • checkout CTA
  • pricing selection
  • subscription choice
  • lead form submission
  • navigation decision point
  • product selection area

Rule

Touchpoint importance influences impact potential.


Portfolio Balance Layer

MWMS should maintain a healthy mix of experiment types.

Suggested default balance:

  • 60% iterative
  • 30% substantial
  • 10% disruptive

This ratio may change depending on:

  • business maturity
  • traffic level
  • resource availability
  • strategic urgency
  • risk exposure

Rule

The portfolio should balance safety, learning, and breakthrough potential.


Velocity Layer

Test velocity matters, but not at the expense of learning quality.


Examples

Weak velocity:

  • many small tests with low strategic value

Strong velocity:

  • consistent tests across iterative, substantial, and disruptive categories

Rule

Experiment velocity should be quality-adjusted.


Learning Value Layer

Experiments should be assessed by what they teach, not only whether they win.


Examples

  • customer motivation insights
  • friction discovery
  • trust barrier identification
  • offer positioning clarity
  • pricing sensitivity learning

Rule

Losing tests can still create valuable strategic intelligence.


Business Impact Layer

Experiment portfolios should support business growth, not only interface polish.


Examples

  • revenue improvement
  • lead quality improvement
  • subscription growth
  • retention lift
  • reduced drop-off
  • improved customer confidence

Rule

Experimentation should remain connected to business outcomes.


Problem Statement Layer

Strong experiments begin with clear problem statements.


Examples

  • users do not understand the offer
  • customers hesitate at checkout
  • traffic clicks but fails to convert
  • subscribers do not trust flexibility claims

Rule

Problem clarity improves experiment quality.


Hypothesis Layer

Every experiment should have a structured hypothesis.


Required Elements

  • problem or opportunity
  • proposed change
  • expected user behaviour shift
  • primary KPI
  • supporting diagnostic metrics
  • risk conditions

Rule

Experiments without hypotheses weaken learning quality.


Portfolio Risk Layer

A portfolio with only safe tests becomes stagnant.

A portfolio with too many disruptive tests becomes unstable.


Rule

Strategic balance protects both growth and survivability.


Stakeholder Layer

Substantial and disruptive tests often require stronger stakeholder communication.


Requirements

  • explain why the test matters
  • explain what risk is controlled
  • explain what learning is expected
  • explain how success will be measured

Rule

Higher-impact experiments require stronger narrative and governance.


AI Governance Layer

AI Employees should:

  • classify experiments as iterative, substantial, or disruptive
  • estimate effort separately from impact
  • identify portfolio imbalance
  • recommend stronger problem statements
  • preserve strategic experimentation diversity
  • flag overreliance on low-impact tweaks

Rule

AI systems must protect portfolio balance.


Reporting Layer

Experimentation reports should communicate:

  • test type
  • expected impact
  • build effort
  • learning value
  • business metric connection
  • survivability risk
  • portfolio balance status

Rule

Experimentation portfolios should remain operationally visible.


Escalation Layer

Portfolio imbalance may require governance review.


Escalation Conditions

  • too many minor tests
  • no disruptive learning
  • excessive risky testing
  • weak problem statements
  • tests not tied to business outcomes
  • low stakeholder trust in experimentation

Rule

Portfolio imbalance should trigger strategic correction.


Measurement Layer

MWMS should monitor:

  • percentage of iterative tests
  • percentage of substantial tests
  • percentage of disruptive tests
  • winner rate by test type
  • learning value by test type
  • business impact by test type
  • effort versus impact relationship

Rule

Portfolio quality must remain measurable.


AI Decision Boundary Layer

AI Employees may:

  • recommend portfolio balance changes
  • classify experiment types
  • suggest higher-impact test opportunities
  • identify low-value experimentation patterns

AI Employees must not:

  • flood the roadmap with random tests
  • prioritize effort alone
  • eliminate disruptive testing capacity
  • optimize only for short-term test velocity

Rule

Experiment portfolio governance constrains experimentation authority.


Cross Brain Integration

Experimentation Brain
→ owns experiment portfolio governance

Data Brain
→ validates evidence and metric reliability

Research Brain
→ supplies problem themes and customer insights

Affiliate Brain
→ supplies offer and commercial test opportunities

Ads Brain
→ supplies acquisition and creative test opportunities

Conversion Brain
→ supplies funnel and UX test opportunities

Finance Brain
→ evaluates ROI, effort, and allocation exposure

HeadOffice
→ governs strategic alignment and survivability

AI Employees
→ operate within portfolio-balance governance boundaries


Failure Modes Prevented

This framework prevents:

  • endless small-test stagnation
  • experimentation theatre
  • weak learning velocity
  • effort-based prioritization errors
  • no breakthrough testing
  • stakeholder disengagement
  • random spaghetti testing

Drift Protection

The system must prevent:

  • confusing test volume with experimentation maturity
  • overvaluing low-effort tweaks
  • ignoring disruptive learning opportunities
  • separating experiments from business outcomes
  • allowing unbalanced roadmaps
  • AI test-generation spam

Architectural Intent

This framework transforms MWMS experimentation from:

→ isolated test execution

into:

→ strategic experimentation portfolio management.

It ensures MWMS develops:

  • balanced testing roadmaps
  • stronger business impact
  • better learning depth
  • protected innovation capacity
  • survivability-aware experiment governance
  • long-term experimentation maturity

Final Rule

A mature experimentation program does not only ask:

“Can we test this?”

It asks:

“What role does this test play in the whole portfolio?”


Change Log

Version: v1.0

Date: 2026-05-08
Author: HeadOffice

Change:
Created Experiment Portfolio Governance Framework defining iterative, substantial, and disruptive experiment balance, impact-effort separation, portfolio visibility, and strategic experimentation maturity governance.


Change Impact Declaration

Pages Created:
Experimentation Brain Experiment Portfolio Governance Framework

Pages Updated:
None

Pages Deprecated:
None

Registries Requiring Update:
MWMS Architecture Registry
Experimentation Brain Page Registry

Canon Version Update Required:
No

Change Log Entry Required:
Yes


END EXPERIMENTATION BRAIN EXPERIMENT PORTFOLIO GOVERNANCE FRAMEWORK v1.0