Breaking the Gridlock: How a Vision Prototype Aligned a Product Team
This is the story of creating a vision to unify enterprise tools into a single platform that enhances the current B2B managed service and provides new B2C self-service functionality.
Looking ahead

Problem Spotting

Showing the way
Cross-functional Alignment
Background
Siloed tools and mindset
The enterprise tools of the demand-side platform were designed to serve specific roles within the organization and throughout the campaign life cycle.
One tool is designated for users in the pre-sales stage.
Another group of users alternates between two additional tools after the insertion order is signed to set up and launch a campaign.
Analysts utilize a third set of tools to monitor live campaigns.
Post-campaign reporting consists of several third-party applications.
A desire to serve a more flexible user base
If you wanted to see the full campaign lifecycle, you had to log in to several different systems. There was no cohesion. No shared data. No simple way to move work from one stage to the next.
We'd known this for years. There were discussions of turning the disparate internal tools into a client-facing platform to open the door to self-service business while still offering managed service opportunities.
Problem spotting
Too limiting
Aligning tools with organizational roles and the processes those roles performed restricted the capabilities of each tool.
Growing discrepancies
Focusing narrowly on each tool resulted in divergent interaction patterns, styling, and even fragmented coding of components.
The need for unity
These tools were loosely connected, and with a growing push from the business for self-service capabilities, they needed to be presented as a single platform.
Instictual design
The hypothesis
I believed that people weren't aligned because they couldn't visualize what "unified platform" actually meant. Every stakeholder was imagining something different in their head.
I needed to give them something concrete to react to, not a final design, but a bold concept that made the vision tangible.
My approach:
Create a functional prototype that showed what the platform could become
Make it visually different enough that people couldn't mistake it for an iteration
Leave enough undefined that people would fill in the blanks with their own ideas
Use it to spark imagination and break through the decision paralysis
Showing the way
Unify tools into one platform:
Usage becomes more flexible while outputs stay consistent.
Enables customization to align with organizational structures.
Data presented in context:
Data is distributed across the platform.
Allows for immediate adjustments without tool-switching.
Streamlined workflow:
Seamless transition between different stages of work increases efficiency.
Example: Converting pre-sales plans into campaigns with a single click.
Communicating the vision
The history of isolated product initiatives made it challenging for the product and engineering teams to visualize the benefits of a unified platform. I created a prototype of a concept that aimed to:
Visually represent the concept boldly.
Highlight a few key differences.
Leave many aspects undefined in hopes of sparking imagination across the organization
Exact workflows (wanted teams to solve this for their domains)
Specific features (wanted product teams to propose ideas)
Technical implementation (wanted engineering to determine feasibility)
Existing tool
Platform concept
Normalize
Brand the platform, not the individual tools.
Establish a foundational and flexible navigational element.
Give intrinsic names to the tools and sections.
Eliminate unnecessary iconography and language.
Modernize
Adhere to established patterns regarding things like URL structure, page names, and breadcrumbs.
Implement a responsive layout for consistency and flexibility.
Recode anything that can be improved with newer methods.
Stylize
Build with a modern component library.
Push that library to create a personality for the platform.
Dark mode first, but give it some atmosphere.
Redistribute functionality and information
Each tool still might have a specific function, but this shouldn't prevent it from providing the user everything they need to inform an action and either take that action or quickly get them where they can.
Put the right dose of information and functionality in the right spots.
Allow appropriate movement from one area to another.
Results
The Presentation
I scheduled a meeting with cross-functional leadership: product managers, engineering leads, UX team, and key stakeholders from sales and operations.
I showed them the prototype without preamble. Just: "Here's what this could look like."
The reaction was immediate:
Product: "Wait, users could convert a plan to a campaign with one click? That would change everything."
Engineering: "The URL structure would need work, but this is actually doable."
Operations lead: "If I could see this data without switching tools, I'd save hours every week."
For the first time, people were talking about possibilities instead of constraints.
What it unlocked
1. Engineering proposed a backend API strategy
They'd been stuck debating architecture. Seeing the prototype helped them visualize the data flow and agree on an approach.
2. Product created three XL initiatives
Unify navigation and authentication
Build shared data layer
Create a new planning module (tool)
3. Leadership approved budget for platform work
They'd been hesitant to invest without a clear direction. The prototype gave them confidence we knew where we were headed.
The prototype became the north star. Teams would reference it in planning: "This moves us closer to the platform vision" or "This doesn't align with where we're going."
Shipped
In 2024 we shipped:
Shared design system implementation (see separate case study)
Unified navigation (all tools accessible from one place)
2025 outlook:
Single sign-on (no more logging into separate tools)
Plan-to-campaign conversion (one-click workflow)
Contextual data display (seeing relevant info without tool-switching)
Looking back
What I learned
The prototype worked because it was bold but not prescriptive. If I'd designed every screen in detail, people would have critiqued the specifics instead of buying into the vision. The sweet spot was showing enough to make it feel real, but leaving enough undefined that people could contribute their expertise.
I also learned that organizational change requires a catalyst. We'd been talking about platform unification for years, but talk doesn't break gridlock. Something visual and tangible does.
The prototype's visual design was intentionally dramatic (dark mode, atmospheric styling). That wasn't just aesthetic, it was strategic. It signaled "this is different" and helped people think differently about what we were building. Sometimes you need to make something look new for people to believe it can be new.
When the Foundation is Broken: Rebuilding Targeting from the Ground Up
Investigating the shortcomings of systems that were straining the business and uncovering the extent of necessary changes.
75% Faster: Building a Design System That Actually Gets Used
Retooling the design system from the ground up by customizing an open-source React component library





