Index / Selected Work / Intrinsic — EC Org Self-Serve
[ Case Study · 02 / 06 ]

Self-serve tooling
for the robotics
deployment stack.

A 0→1 product engagement at Intrinsic (Alphabet's robotics company, formerly Google X). Replacing a manual, CLI-driven org provisioning workflow with a self-serve UI that lets Solution Builders independently set up and manage end-customer organizations in Flowstate.

Flowstate Managed Organizations dashboard — empty state and populated state [ FIG.01 · MVP DASHBOARD ] CONFIDENTIAL · INTRINSIC 2025
Role Product Manager · 0→1 PRD, UX, Research, Launch
Year 2025
Team Deepa · PM Eng × 4 UXD UXR Leadership × 2
Outcome MVP shipped to dev environment · Validated with 6 partners (Trinity, Trumpf, internal CSEs)
01 · The Problem

Org creation lived in the CLI.

Flowstate is Intrinsic's robotics deployment platform. Solution Builders (SBs) — the system integrators who deploy robot solutions for industrial end customers — needed a way to spin up new End Customer (EC) organizations for every deployment.

The existing process required SBs to be granted an orgCreator role, then run inctl commands by hand. In practice, almost no SB used the CLI. Instead, they emailed an Account Executive every time they needed a new org. The AE became the bottleneck.

Why this mattered

  • Every new deployment was blocked behind a manual, ticketed handoff to an internal team.
  • SBs had no direct visibility or control over the orgs they were meant to manage.
  • The model didn't scale. As Intrinsic grew its partner base, AE time became a scarce resource standing between revenue and customers.
  • Future capabilities — IPC management, automated billing, subscription tracking — all assumed SBs could provision orgs themselves.
01
100%
of EC orgs were created through manual AE intervention via CLI
Pre-MVP baseline
02
~30m
average backend provisioning delay between submission and access
Acceptable for MVP
03
3
core workflows missing entirely from the SB-facing UI
Org creation · Users · Lifecycle

02 · Scoping the MVP

From PRD draft to three pillars.

I led the PRD end-to-end — stakeholder interviews, scope definition, dependency mapping, and rollout planning. The biggest unlock was framing the work around the SB's actual lifecycle with a customer, not the backend topology.

Through reviews with engineering, design, marketing, and legal, the MVP collapsed to three pillars — sized so we could ship a working dev-environment deployment by the end of the engagement.

PILLAR 01

EC Organization Creation

SB admins enter org name, location, and admin contact through Flowstate UI. Org ID auto-generated. Email-based onboarding kicks off automatically. No more inctl, no more AE ticket.

Must Haveb/430293288
PILLAR 02

EC User & Access Management

SBs invite EC users by email and assign a role — Admin or Developer for the MVP. View, modify, and remove users with corresponding backend updates and email triggers.

Must Haveb/430293246
PILLAR 03

EC Organization Management

Centralized "Managed Organizations" dashboard. Org switcher, list view with key info, deletion flow with explicit confirmation. Foundation for future IPC + billing features.

Must Haveb/430293566

What I deliberately cut

  • IPC management from the new org dashboard — sequenced as a follow-on so we didn't block on a parallel infra effort.
  • Billing automation — explicitly deferred; the MVP defaults every new EC org to the free tier so we never have to charge during onboarding.
  • EC user journey post-invite — out of scope. The MVP only covers what the SB does.

The main reason an SB creates an EC org is when they're actively thinking about deploying a solution. Everything else is noise. — PRD assumption · validated in research

Managed Organizations dashboard — populated state [ FIG · Managed Organizations dashboard ]
The three pillars made tangible — provisioning, users, lifecycle in one surface Flowstate · MVP build

03 · The Solution

The new workflow.

The redesigned flow folds three previously-disconnected steps — provisioning, inviting users, and lifecycle management — into one continuous SB experience inside Flowstate.

Before · CLI + AE handoff

Manual, ticket-driven, days to days+

  1. SB emails Account Executive requesting a new EC org
  2. AE files a backend request with Intrinsic ops
  3. Ops grants orgCreator role to a designated user
  4. SB runs inctl commands to provision
  5. SB emails AE again to add EC users
  6. Repeat for every change to the org or user list
After · Self-serve UI

Direct, in-product, ~30 minutes end-to-end

  1. SB opens Flowstate → Managed Organizations
  2. "Create Managed Organization" → name, location, billing contact
  3. On-screen confirmation; backend provisions in ~20–30 mins
  4. Email arrives; SB navigates to the new org
  5. Invites EC users by email, assigns Admin or Developer
  6. Manages, switches, or deletes orgs from the centralized dashboard

Live demo — Flowstate dev environment

End-to-end walkthrough of the MVP shipped at the close of the engagement: creating an EC org, inviting users, switching contexts, and managing lifecycle from the dashboard.

Flowstate · Dev Environment DEMO
[ Fig.02 · MVP demo on Flowstate ] Final presentation · Sep 2025

04 · The Journey

A focused sprint, end to end.

I owned the work from problem framing to dev-environment deployment, partnering with engineering, design, and UXR. Here's how the milestones landed against the plan.

Week 01–02 PRD draft completion Owner · Deepa Done
Week 03 Sketches & lo-fi UX flows Owner · Deepa Done
Week 04 Initial Figma prototype Owner · Tiffany (UXD) + Deepa Done
Week 04–10 Backend infra + frontend dev Owner · German & Marcos (Eng) Done
Week 06 Marketing approval — invite emails Owner · Jim (Mktg) Done
Week 07–08 User interviews · Trinity, Trumpf, 3 CSEs Owner · Rebecca (UXR), Jason, Deepa Done
Week 09 Synthesis & MVP refinement Owner · Rebecca + Deepa Done
Week 12 🔔 MVP deployed to dev environment Owner · Eng + Deepa Shipped

05 · User Research

Six conversations, three insights.

I co-ran a rapid usability study with our UXR partner, testing the Figma prototype against three real tasks: create an EC org, add users + assign roles, and manage / delete an existing org.

Who we recruited

A deliberate mix to cross-cut role and product familiarity — three external partners from Trinity & Trumpf (General Manager, Service Tech, Domain Architect across NA and EU) and three internal Customer Solutions Engineers who broker the manual workflow today. Five of six had hands-on Flowstate fluency; one didn't. Coverage across NA (5) and EU (1) — important for surfacing the GDPR signal we found.

Insight 01 — Core workflows lacked "power user" efficiency

Users immediately flagged the single-user invite as a major bottleneck. Onboarding a customer felt disjointed; bulk operations were table stakes for this audience.

When you create a new organization… that is going to be a cumbersome step to add one [person at a time]. You may want some bulk editing mechanism, right? — P4 · Internal CSE

Insight 02 — A strategic disconnect about End Customers

Solution Builders questioned the purpose of EC-specific user roles when they'd been told ECs would not actually use the platform. The role-permission UI was undermined by a missing strategic narrative about who the EC is and what they need.

My instinct is to just select the 'Developer' checkbox. But what's the actual difference between selecting only 'Developer' versus selecting both 'Developer' and 'Viewer'? It's not clear what is included. — P6 · Internal CSE

Insight 03 — A new business opportunity surfaced

Unprompted, partners asked for commercial controls — subscription expiry, renewal, reactivation — directly inside the Managed Organizations dashboard. The feature was being asked to evolve from tooling into a business mission control.

I would want to be able to manage their subscription from within here. I would want to be able to see when's their expiration date… and reactivate their subscription for next year. — P1 · External Partner

Cross-cutting: persona segmentation by company context

The research showed a partner's company context — geography, size, business model — was a stronger predictor of needs than their formal role. A feature critical to a European partner (GDPR-driven data deletion) was a non-issue for a US partner. We surfaced a missing business leader persona focused on commercial management.


06 · Usability Notes

The friction we found.

Beyond the strategic insights, the study surfaced concrete UI improvements we fed directly into the build. The five highest-impact ones:

FRICTION 01

Org creation is hidden in a dropdown

5 of 6 users had to be prompted to read the org-switcher tooltip before discovering the create action. Users expected a prominent button or "+" affordance.

Fix · Reposition CTAP0
FRICTION 02

Creation form is too thin

Single name + location wasn't enough for partners managing customers with multiple sites. Need sub-locations or internal tags.

Fix · Form fieldsP1
FRICTION 03

Single-user invite is the wrong primitive

Users expected to add a team in one motion — paste a list of emails, pick roles, send. The one-at-a-time pattern read as broken, not minimal.

Fix · Bulk inviteP0
FRICTION 04

Roles felt non-hierarchical

Partners expected selecting "Admin" to imply lower-level permissions automatically. Independent checkboxes for each role created confusion.

Fix · Role hierarchyP1
FRICTION 05

Account ≠ Organization settings

Co-locating personal account and org controls was high-stakes confusion. Multiple users feared deleting their own account when they meant to delete a managed org.

Fix · Separate menusP0
FRICTION 06

Delete needs a recovery story

Legal counsel confirmed Intrinsic's incentive is customer return, not aggressive deletion. The "Delete" confirmation needed to surface the 30-day archive window explicitly.

Fix · Confirm copyP0

Deleting all the data from my customer is not allowed in Europe because the data belongs to the customer. — P3 · External partner · EU


07 · The Result

From idea to shipped product.

The MVP shipped to Intrinsic's development environment on schedule, validated against six real users, and laid the groundwork for the team's commercial roadmap.

01
3 1
workflows consolidated — provisioning, user management, and lifecycle, all in one self-serve surface
Outcome
02
0 AE
tickets required to spin up a new EC org in the post-MVP path. Provisioning becomes infrastructure, not a service
Outcome
03
6
partners and internal experts validated the design before launch — Trinity, Trumpf, 3 CSEs, plus leadership review
Validation
CONF
Note on imagery. The screenshots and prototype frames in this case study are stylized representations. Actual UI, internal terminology, and roadmap details remain proprietary to Intrinsic / Alphabet. Anything sensitive has been generalized; everything shown here is consistent with the public framing of the work.

08 · What's Next

Three bets for the next phase.

The closing recommendation to leadership distilled the research into three sequenced bets — the path from "self-serve infrastructure" to "commercial mission control."

Bet 01 · Monetization

Enrich the dashboard with commercial data

Subscription status, renewal dates, reactivation flows. The signal partners gave us — they already think of this surface as the place to manage customer commercial relationships. Lean in.

Bet 02 · EC Insights

Define the End Customer journey

A dedicated UXR study to resolve the strategic disconnect. Until we know what ECs do in Flowstate, we can't build meaningful roles for them. Clarity here unblocks the entire user-management surface.

Bet 03 · Scalability

Ship the power-user features

Bulk invites, separated Account vs. Org settings, hierarchical roles, granular org segmentation. The minimum to make "self-serve" feel actually self-serve at scale.

What I'd carry forward

  • Frame for the lifecycle, not the topology. The PRD landed because it was structured around what an SB does over time, not how the backend was wired.
  • Recruit for context, not titles. Geography and business model gave us more usable signal than role labels did.
  • Treat "self-serve" as a contract, not a feature. Every place a user has to go to a human breaks the contract — bulk invites, recovery windows, role inheritance are all expressions of the same promise.

Keep reading.

[ More case studies ]
[ Let's talk ]

Building in robotics?
Let's talk.

deepabh@stanford.edu [ Stanford GSB · MBA '26 · Co-founder, Proxy Robotics ]