BEFORE
EXPERIENCE OPERATIONS · SELF-INITIATED · WORKING PROTOTYPE
The team did not need another dashboard.It needed a place to remember the work.
Experiments lived in spreadsheets, links, and people’s memory across hundreds of programs. I mapped the records and relationships the team was already tracking, then built a working product for finding what was live, who owned it, and what we had learned.
01 · ORIENT TO THE PORTFOLIO

PROTOTYPE SCOPE
THE PROBLEM WAS NOT REPORTING
The team had data.What it lacked was operational memory.
One program at one school might have several live variants, a control, a few tests, and recent launches. Across the full portfolio, simple questions became surprisingly hard: What is live? Who owns it? Which version is current? What did we learn last time?
The process depended on people remembering naming conventions, spreadsheets, links, and conversations. We did not need another dashboard widget. We needed a shared place the work could live.
The product needed to remember the portfolio so the team did not have to.
IN THE PROTOTYPE
Search once and see owner, state, program, tests, and learning together.
MODEL THE PORTFOLIO BEFORE STYLING THE SCREENS
The information architecture becamethe product strategy.
I mapped the relationships the team was already managing informally, then built the navigation and records around them. The same structure had to answer a portfolio question and explain the history of one specific experience.
Line of business
The operating context and shared template family.
School + program
The institution and offering being represented.
Experience
The persistent product record across versions and channels.
Variant + test
The live implementation, control, hypothesis, state, and learning.

FIND THE THING SOMEONE ACTUALLY REMEMBERS
Search, filters, and quick pathsturned fragments into a browsable portfolio.
People rarely remember an internal ID. They remember the school, program type, owner, a recent launch, or what the page looked like. Search and filters needed to work from those imperfect clues without breaking the underlying taxonomy.


ONE EXPERIENCE BECOMES A SHARED SOURCE OF TRUTH
The record connects the work,the hypothesis, the state, and the evidence.
A record brings the live experience, ownership, channels, devices, hypothesis, goals, performance, project brief, and test-versus-control view into one place. It is where someone can understand the work and decide what to do next.

School, program, channel, device, publication date, lifecycle state, and ownership.
Hypothesis, goals, linked brief, and the reason the variant exists.
Sessions, leads, conversion signal, statistical significance, and update recency.
Test and control shown together so a decision does not depend on memory or another tab.
BUILD THE PRODUCT, NOT JUST THE CONCEPT
A working prototype made the operating modeltestable before a roadmap existed.
AI helped me build and revise the prototype faster. I still made the product decisions: what the records meant, how they connected, which workflows mattered, and what the interface needed to make clear.
The working prototype exposed problems the static screens missed: unclear states, broken links between records, awkward transitions, and layouts that failed with real content. Coding it changed the design.
AI increased the speed of making. It did not replace the judgment required to decide what should exist.Product definition
Converted an operational pain into a coherent product model.
Workflow design
Designed the portfolio, records, filters, comparisons, states, and actions.
AI-assisted build
Implemented a functioning prototype to test density and behavior.
Source-faithful previews
Real imagery and realistic content exposed wireframe issues.
THE OUTCOME
An internal tracking problem becamea product strategy for experimentation operations.
The value is not another place to look at metrics. It is a shared system for knowing what exists, how it relates, what is live, why it was created, what changed, and where the team should go next.