Turned an avg of 2 months for cloning and rebuilding work into 5 minutes of configuration, and made a 2x deprioritized ask fundable.
ServiceNow · 2023 - 2025 · platform strategist across 8 business units
“Strive to be of value, not of success” — Albert Einstein
The problem nobody owned
I had seen this pattern before. Designing tools for developers and admins, I watched separate teams ship separate tools with separate vocabularies, and customers felt like they needed a PhD to understand our internal product boundaries just to complete their work.
That feeling was familiar when I moved to the platform team behind workspaces for the people who fulfill requests.
In my first 30 days on the platform team, I interviewed leaders across the org, and one word kept coming up: interoperability. Many teams wanted it, but no two teams meant the same thing. To one, it meant sharing customized components across Workspaces. To another, it meant sharing customized workflows across Workspaces. Interoperability was brought up as a top priority in 2 separate planning cycles, and resulted in being deprioritized, twice. Engineering had never seen it as more than a slide in a deck.
Then, in a discussion forum I hosted, a business unit partner put it bluntly: "I'm sick and tired of trying to explain what we want for interoperability. Why don't you guys just make it work?"
What I saw
The demand for interoperability was clearly expressed by many teams, but nobody could properly scope it. Engineering couldn't estimate it, so leadership couldn't fund it. Meanwhile, our customers were paying the price for that gap.
Workspaces were essentially siloed applications. If a customer admin wanted another application's workflow inside the workspace their team already used, they had to clone the page, take ownership of that page, and implement it manually by hand (likely in a pro-code environment). That could take on average 2 months, and every clone became something they now had to maintain. So, for every time that customer wanted to upgrade their ServiceNow instance, they would often lose enhancements to that workflow.
After my business unit partner's blunt remark, I set myself a goal for how I show up to work: be a transparent sheet of glass. Anyone talking to me should see and understand the platform clearly, and anyone on the platform should see and understand the business units clearly. That meant up-leveling our designers to be platform thinkers (more specifically: ServiceNow platform thinkers) when bringing their solutions to the table.
Who I pulled in
First thing I did was gather all the decks scattered across email, Teams, and SharePoint. Then I brought 8 business-unit teams into a two-day workshop to pull apart the definition for what each one actually needed.
The result was a matrix of distinct asks:
- Components - reuse a piece of another team's workflow, like a service agent seeing an incident trend for the account in front of them
- Pages, as-is - bring another application's page in as a navigation item, data and all
- Pages, on your own data - repurpose another team's page template for your own records
- Modules, as-is - surface another application's module as an informational block, like a full view of a customer account
- Modules, on your own data - run a shared module inside your own records, like one team's change process on another team's case
Framing this information made it easier to point and say "is this what you mean?"
Each type had its own job to be done and its own cost. For the first time, engineering had specific asks they can scope, leadership had specific bets to fund, and each business unit could find its use case in a shared framework instead of using a term that could mean so many different things.
Engineering has confirmed that component-level interoperability is already supported. However, some BU leaders struggled to understand how to implement it because they found the enablement tool, UI Builder, and platform architecture difficult to navigate. The bigger problem is there was no published documentation for how workspaces were supposed to be built.
With a senior director's sponsorship, I partnered with engineering and enablement on a guide to every layer of the stack and what the builder did and didn't support for Workspaces. Teams no longer had to guess while the bigger work was still in flight.
I spent hours speaking with engineering and getting clarity around the nuances so that other teams didn't have to.
The page and module types were different. A page depended on its workspace app shell type (tabs, breadcrumbs, or custom), so it didn't move cleanly between workspaces. That was one of the biggest engineering hurdles to overcome.
To make the funding case, I made the pain visible instead of describing it. A flow diagram showed the whole process.
A walkthrough showed the most common path from the user's seat: opening a workflow from another application.
I kept that first flow simple on purpose so no one could call it exaggerated, then layered in harder cases.
The walkthrough showed the pain between two applications
This is further exaggerated based on real use cases that span across multiple applications
Customer advisory sessions confirmed the rest. The fragmentation wasn't just frustrating users; to our discovery it was also affecting purchasing decisions.
What changed
- Turned one vague word into a five-part taxonomy that engineering could scope
- Launched the builder support guide, which became the canonical reference for business unit teams
- Secured funding on the third pitch, after two deprioritized cycles
- Shipped in September 2025, the first major core-platform release without an executive mandate behind it
- Turned up to two months of cloning, ownership, and implementation work into about five minutes of configuration during early access
At least a dozen early-access customers switched it on, and the advisory council captured their satisfaction with the release. Deeper adoption metrics belong to the business-unit team that owned the rollout, so I don't report them here.
Internal teams had mostly built in silos. For the first time, their work showed up together inside the product.
What it exposed
While interoperability solved the distribution of workflows across the platform, it didn't solve for a coherence experience. Workflows designed separately by different business units could now appear side-by-side, and there was no shared quality standards between them. Conflicting interaction patterns that had stayed hidden inside separate products were suddenly obvious.
We didn't fully resolve that problem in the current work stream. About 3 months after release, the organization shifted focus to a successor AI-native platform, where interoperability was built-in as part of the foundation. The implementation was later superseded by the new tech stack; and the taxonomy and guide still informs that work. The lesson became a requirement: interoperability had to be paired with shared page architecture and quality governance from day one.
What I'd tell a leader facing this
- Bridge the knowledge gap: If an ask keeps getting deprioritized, check whether the people deciding actually understand the problem and the solution. In this case, they understood neither.
- Sustain momentum through continuous artifacts: Don't let the problem go stale between cycles. Publishing along the way kept it alive, so by the third pitch a team was ready to pick it up. If I did it again, I'd ship the guide first and bring engineering into the workshop instead of translating everything for them afterwards.
- Hide the org chart: Technical interoperability across system boundaries does not automatically yield a cohesive user experience. Plan the quality layer alongside the distribution layer, or your users will feel your internal organizational silos.
- Establish end-to-end ownership: Someone has to own the whole problem, not just fragments of it. My manager gave me room to do that, and it cleared the path for the people who built it.