01 / ScaleRelevant work was hard to find.
Thousands of records across organizations made it difficult to isolate the work a team actually needed.
ServiceNow / Platform strategy
One platform.
Many ways to work.
From governed business-unit independence to AI-powered onboarding. A platform strategy that reduced onboarding from months to days in the prototype/pilot.
EWD + OTTO / Time to first useFrom months
From months
to days.
Observed baseline280days
Measured prototype/pilot<2weeks
280-day baseline from New Relic observability. Under two weeks measured in the combined EWD + OTTO prototype/pilot. Production is planned for early 2027; the workflow is not live yet.
SPM was shared. Enterprises were not.
As Strategic Portfolio Management expanded from IT into HR, Finance, Operations, and GTM, admins were managing thousands of records and configurations in one shared environment. Different organizations needed different rules, but the platform did not give them a simple model for that independence.
New Relic observability showed an average of 280 days from setup to first use in Project Workspace. For a subscription platform, this was more than admin friction: customers were spending much of their first year implementing before teams could use what they had bought.
Problem statement
How might we give business units meaningful independence while preserving one governed enterprise platform?
01 / Scale
02 / SeparationDifferent teams inherited the same experience.
Business units needed their own visibility, layouts, processes, and data requirements without creating separate environments.
03 / GovernanceLocal fixes created enterprise costs.
One-off customization risked fragmented configuration, maintenance overhead, and inconsistent reporting.
My role was to turn these overlapping requests into an experience strategy: define where business units needed control, what had to remain shared, and how admins could understand that boundary.
A tactical request exposed
a platform problem.
At a roundtable with hundreds of admins, the request sounded simple: “Can we please scope access?” But HR did not want to work like IT. Teams needed different processes, data, and access without affecting everyone else.
The reframe
What does “separate” mean—and where do business units need independence?
The platform lacked a simple mental model for organizational independence. Better filtering alone would not solve that.
Four perspectives. One platform question.
I triangulated customer needs, recurring deployment friction, technical constraints, and enterprise planning patterns to understand what needed to be independent—and what had to remain shared.
Research synthesis / Illustrated workshop
What does “separate” really mean?
01 / Customers & admins
Too many records.
Relevant work gets lost across organizations.
Business units need different ways to work.
02 / Customer Success
The friction repeats.
Onboarding and configuration slow deployment.
Look for patterns across customers.
03 / Platform & engineering
Build on what exists.
Preserve access controls and upgradeability.
Avoid one-off configuration systems.
04 / Landscape analysis
Flexibility is common.
Compare local control with central governance.
The opportunity is governed variation.
SynthesisDefine what can vary locally.
Protect what must remain shared.
Protect what must remain shared.
Landscape findings
How the market organizes independence.
| Model reviewed | Pattern identified | Question for EWD |
|---|---|---|
| Shared environment + filtering | One environment; narrow the visible records. | Does a filtered view create a durable business-unit boundary? |
| Salesforce | Org + app model. | How can local configuration coexist with centralized governance? |
| Aha! | Workspace model. | Where should team-level configuration live? |
| Jira Align | Role + team model. | How do roles and team context shape access and experience? |
| Planview | Enterprise model. | How does local variation roll up into enterprise planning? |
Comparison lens: permissions, local configuration, workflows, data variation, and enterprise governance.
Landscape insight
The market offered flexibility. The harder problem was governed flexibility.
Across Salesforce, Aha!, Jira Align, and Planview, I compared local control with central governance. The opportunity was meaningful local variation while preserving one enterprise model.
Separation wasn’t one problem. It was four.
The four pillars defined the scope of independence. Each became a concrete set of admin decisions and downstream consequences—not four separate customization systems.
Security
Who can see what?
- Record visibility
- Business-unit separation
- Roles + access rules
- Confidential work
- Cross-org leadership visibility
Experience
What should they see?
- Views + forms
- Shown / hidden fields
- Layout + field order
- Workspace presentation
- Context-specific experience
Process
How should work happen?
- Playbooks
- Approvals + stage gates
- Workflow steps
- Automation
- Lifecycle differences
Data
What does the work require?
- Custom fields
- Attributes
- Custom tables / structures
- Dynamic categories
- BU-specific data needs
Shared foundationScalability · Governance · Reporting · Upgradeability
Controlled independence.
HR should work like HR.
Finance should work like Finance.
The platform should still work as one.
Local autonomy needed to coexist with shared data, reporting, governance, and upgradeability. I used that tension as a decision rule: reject concepts that increased local flexibility by weakening the shared platform, and reject concepts that preserved governance by forcing every business unit to work the same way.
01 / Global baselineStart with shared rules02 / Business-unit partitionOverride the differences03 / Resolved experienceShow the right workspace04 / Governed systemRetain a common foundation
Decide where the complexity belongs.
I evaluated three approaches against local independence, platform integrity, and admin cognitive load.
01 / Filtering & cullingNarrow the view.
Fast, familiar ways to narrow records.
The tradeoff
No durable organizational boundary. Admins still manage context manually.
02 / Scoped spacesSeparate the spaces.
Greater local autonomy for each business unit.
The tradeoff
Configuration, governance, and reporting can fragment over time.
03 / Partitioned model · SelectedGovern the differences.
Durable boundaries within one shared platform.
The tradeoff
More platform and setup complexity, in exchange for less ongoing context management.
I chose the partitioned direction because it moved repeated context management out of the admin’s daily work and into a governed model. The cost was higher platform and setup complexity; the benefit was a durable boundary that could support all four dimensions of independence.
Where to start / Project Workspace
Prove the model in a connected part of the platform.
Project Workspace touched resources, financials, risk, workflows, approvals, and reporting. Starting here made the dependencies tangible and gave the model a meaningful test of whether it could extend across SPM.
01 / A clear starting pointOne front door.
One front door.
Every product behind it.
Configuration Hub brings discovery and product setup into one place. The next step is specific to the product, without losing the shared platform context.
02 / Establish the boundaryA business unit.
A business unit.
A place of its own.
Create a partition, choose its owner, and inherit a baseline. The overview keeps the business context visible as configuration becomes more detailed.
Ownership, membership, and the parent configuration stay explicit.
Configure once. Understand the consequences.
The prototype follows Maya, an enterprise admin, and Sasha, a project manager. Maya starts from a global baseline, configures a partition across the four pillars, and previews the experience before handing it over.
Sasha sees the result: relevant projects, appropriate navigation, and the fields and process her work requires. She does not need to understand the configuration that produced it.
03 / Shape the experienceShared by default.
Shared by default.
Different by choice.
Access and presentation are separate decisions. Set the permissions, then shape the navigation and dashboard that people actually use.
Security / The boundary underneathVisible isn’t the same
Visible isn’t the same
as permitted.
Roles, inherited permissions, and local overrides explain who can reach the work.
04 / Configure the way work movesThe right process.
The right process.
The right information.
Make the boundaries a shared decision.
01
Security governs reach
A hidden module and a permission boundary are different decisions. The model makes both explicit.
02
Experience governs presentation
Views, navigation, fields, and layouts resolve from the configuration relevant to the business unit.
03
Process governs progress
Playbooks, stage gates, and approval steps can vary while remaining part of the shared platform.
04
Data governs meaning
Local attributes support different work without abandoning the enterprise foundation.
My contribution was connecting customer needs to a model that could be discussed across disciplines. Customer Success brought recurring deployment friction; Platform and Engineering brought existing capabilities, maintainability, and upgrade constraints. The four pillars made those inputs part of the same set of decisions.
For each request, the question became explicit: what can a business unit change, what must remain shared, and what will the person doing the work experience? The prototype connected admin configuration to the downstream workspace so that the consequences could be reviewed together.
Experience it / Interactive prototype
Now follow the whole journey.
Start with the baseline, configure a business-unit partition, then preview the member experience. The prototype connects the decisions shown above.
Open interactive prototypeThe model became
the onboarding engine.
EWD defines what a business unit can configure. The next phase connects that model to OTTO: the admin supplies the documentation, and OTTO turns those requirements into onboarding that can be reviewed and launched.
Part two / EWD + OTTOPrototype/pilot · Production planned early 2027
Admin knowledgeDocument the division.
OTTO orchestrationPrepare the work.
Approved executionLaunch onboarding.
Explore the process
Process illustration · Not live product UIFrom documents to deployment.
Admin supplies context
Build the division’s source of truth.
The admin supplies discovery findings, onboarding documentation, the four configuration pillars, and workflows for each division.
DiscoveryDivision requirements
OnboardingDivision requirements
SecurityDivision requirements
ExperienceDivision requirements
ProcessDivision requirements
DataDivision requirements
Division workflowsDivision requirements
OTTO thinking
Turn documentation into requirements.
OTTO connects the supplied material to security, experience, process, and data. The proposed flow makes unclear or conflicting requirements visible before configuration proceeds.
SecurityWho can access which records?
ExperienceWhich views, forms, and fields?
ProcessWhich approvals and lifecycle?
DataWhich attributes and structures?
Resolve with the adminConfirm missing ownership, conflicting policies, and division-specific exceptions.
OTTO prepares
Create the onboarding plan.
OTTO uses the requirements to prepare division-specific configuration and an onboarding workflow. The plan connects the shared baseline to each division’s local needs.
Shared enterprise baselineGovernance + common configuration
HRLocal requirementsOnboarding workflow
FinanceLocal requirementsOnboarding workflow
ITLocal requirementsOnboarding workflow
Admin decides
Make the proposed action legible.
The admin reviews the plan, checks local exceptions, and confirms what will change. This carries forward OTTO’s thinking-versus-acting model: show the reasoning, then ask for approval.
Illustrative approval summary
Division onboarding plan
- Source documents mapped to requirements
- Shared baseline and local changes visible
- Ownership and unresolved questions reviewed
- Admin approval before launch
OTTO acting
Launch the approved onboarding.
OTTO creates and launches the approved onboarding workflow for the division. The admin can follow execution and address exceptions instead of rebuilding the entire setup manually.
Approved plan becomes onboarding
ConfigurationDivision workflowOnboarding tasks
Execution stays connected to the approved requirements.
A proposed visualization of the pre-launch workflow. Example divisions and review states explain the process; they are not screenshots or a live integration.
Measured prototype/pilot resultMonths to days.
The combined EWD + OTTO prototype/pilot reduced onboarding from 280 days to under two weeks. Production has not launched; the planned release is early 2027.
The connection to my earlier OTTO work is the interaction principle: distinguish thinking from acting. The admin can understand the proposed plan before OTTO executes it. EWD supplies the governed structure; OTTO applies it to discovery and onboarding.
Faster onboarding.
The same governed foundation.
280 days
Observed setup-to-first-use baseline in Project Workspace.
<2 weeks
Measured result in the combined EWD + OTTO prototype/pilot.
Early 2027
Planned production launch. The combined workflow is not live yet.
The first part established the configuration model: meaningful business-unit independence across security, experience, process, and data. The second part connected that model to OTTO, turning division documentation into an actionable onboarding plan.
The prototype/pilot demonstrated the time reduction. The next success bar is production: sustain that speed while preserving access boundaries, reporting consistency, upgradeability, and clear admin control.
Listen for the problem underneath the request.
The initial request sounded like a filtering problem. Research made it a question about organizational independence. That shift changed the scope of the design and the kind of system we needed to build.
The highest-leverage decision was defining where independence should stop.
Next story