Dani Weidner Open to Staff roles

Platform / Rebuild and migration

Rebuilding a platform with every customer still on it

Four aging flows needed a full rebuild, and the customers on them couldn’t be asked to wait or start over. I sequenced the work, got the team aligned before any customer saw it, proved the new builder against the old one, and designed a migration that moved 50 accounts with no customer action required.

In one minute

SituationCampaign management, campaign creation, the asset manager, and asset creation all needed rebuilding, on a product customers used every day.
What I didSequenced the rebuild into six phases, ran the session that settled a blocking architecture question, tested the new builder head to head, and designed the migration.
Outcome50 accounts migrated automatically, with no bugs or support tickets reported since launch.

Demo. The new creative builder: looping, no audio. Open full screen ↗

Result0Breaking changes reported since launch across 50 migrated accounts
Result2×Usability rating over the legacy builder, from 7 customer raters
Scope4 into 6Major flows sequenced into a 6-phase roadmap

Decisions

Decision 01 / 04

Ship in six phases instead of one launch

Rebuilding all four flows at once would have bet the whole rebuild on an unproven direction. I built a six-phase roadmap (discovery and foundation, core MVP, asset manager, creation flows, analytics, polish and scale) with a scope line, a success criterion, and a named decision point in each phase.

Stories were mapped by persona, from hands-on marketers to developers and enterprise administrators, so the sequence never served an average user who didn’t exist.

Tradeoff: a longer path to the full vision, in exchange for never committing more than one phase of work before beta users validated it.

STEP SYSTEM DECISION EDGE CASE END MILESTONE 01: CORE MVP MILESTONE 02: EXPANSION HIGH-LEVEL FLOWS INTERNAL DECISION LOGIC HIGH-LEVEL FLOWS INTERNAL DECISION LOGIC OVERVIEW + TEMPLATES CREATE FLOW 1.3 1.4 1.5 1.6 BETA GATE ROLE-BASED ACCESS ARCHIVE 2.2 2.3 2.5 2.6
Fig. The working flow board: both milestones mapped end to end
Decision 02 / 04

Get the team to agree before testing with customers

A core flow was blocked on one question buried in a long chat thread: were two related concepts the same thing, and did editing a shared template change work that already existed? Testing with customers before the team agreed would have turned any result into noise.

I facilitated a cross-functional session that surfaced more than 20 assumptions, separated the 3 the team actually agreed on, and turned the rest into an evidence plan with named owners.

Result: the flow unblocked, and the team reused the decision record on the next contested call.

AGREED DISPUTED EVIDENCE PLAN SURFACE THE ASSUMPTIONS TWENTY-PLUS, MAPPED IN ONE SESSION QUIET DISAGREEMENT, MADE LOUD SORT AGREEMENT VS DISPUTE OPEN QUESTIONS BECOME AN EVIDENCE PLAN GENUINELY AGREED ACTUALLY DISPUTED INCLUDING: DO SHARED TEMPLATE EDITS CHANGE EXISTING WORK? THE EVIDENCE PLAN COMPETITOR RESEARCH PLUS A CUSTOMER STUDY TESTED BEFORE ANY CUSTOMER VALIDATION RAN
Fig. Assumptions surfaced and sorted, open questions turned into an evidence plan
Decision 03 / 04

Prove the new builder against the one it replaced

The new drag-and-drop builder replaced uploading creatives as flat images and hand-editing CSS. “Better” was easy to assert, so I ran head-to-head testing on a prototype with seven customer raters scoring it against their current system.

The new builder scored in the high range and the current system sat near the bottom. Their reasons, like swapping headlines and calls to action without rebuilding a creative, shaped the builder that shipped.

A thousand-percent improvement on the current system.Enterprise customer, media and publishing
NEW BUILDER CURRENT SYSTEM SAME TASKS, TWO SYSTEMS ENTERPRISE CUSTOMERS RATED BOTH DIRECTLY CURRENT SYSTEM FLAT IMAGES, HAND-EDITED CSS NEW BUILDER DRAG AND DROP, EDIT IN PLACE SWAP A HEADLINE WITHOUT TOUCHING CODE THE VERDICT THE GAP WAS DECISIVE NEW BUILDER SCORED IN THE HIGH RANGE CURRENT SYSTEM NEAR THE BOTTOM A THOUSAND-PERCENT IMPROVEMENT ONE MEDIA CUSTOMER, ON THE RECORD
Fig. Same tasks on both systems, and a decisive verdict
Decision 04 / 04

Migrate automatically, and keep behavior exactly the same

Two legacy configuration surfaces had to move into the new platform without disrupting the customers depending on them. I mapped both as paired configuration and runtime flows: where settings live in the new navigation, and what the end user sees when a link fires.

Create, edit, and apply converge at a shared runtime, so automatic migration carried 50 accounts’ configurations over with behavior preserved.

Related: two pieces of this rebuild have their own case studies: bulk link creation and A/B testing.

LEGACY NEW HOME PROTECTED IN TRANSIT LEGACY HOME TWO CONFIG SURFACES, CUSTOMERS DEPENDING ON THEM CONFIG SURFACE 1 CONFIG SURFACE 2 MIGRATED AUTOMATICALLY, BEHAVIOR PRESERVED EXACTLY THE NEW HOME CREATE, EDIT, APPLY CONVERGE AT ONE SHARED RUNTIME CONFIG SURFACE 1 IN THE NEW NAVIGATION CONFIG SURFACE 2 IN THE NEW NAVIGATION CREATE EDIT APPLY SHARED RUNTIME WHAT FIRES WHEN A LINK IS USED FEELS LIKE AN UPGRADE, WORKS LIKE BEFORE
Fig. Two config surfaces moved to the new home, migrated with behavior preserved
Next / Case 02
Creating and editing links at scale