From Solo to Shared — Designing Collaboration for a Data Platform

Giving teams the means to work together on data

Mammoth is a no-code platform for managing data — connecting sources, transforming datasets, automating pipelines, and pulling out insights. But it was built for one person at a time. Every workflow belonged to a single account. When teams needed to work together, they passed around login credentials. There were no workspaces, no way to invite someone, no roles, and nothing stopping people from overwriting each other's work.

A platform built for one, used by many

Mammoth had no way to organise anything. No projects, no folders, no permissions — every dataset sat in the same flat space, and users either had access to everything or nothing. Teams needed to work on their own things, keep sensitive data protected, and share when ready. None of that existed.

• No multi-user access — teams resorted to sharing credentials, creating security risks and eliminating any audit trail
• No visibility into how data was being used across an account — coordination happened entirely outside the tool

The gap went beyond access control. Users needed projects, folders, role-based permissions, and a way to manage plan feature coverage — the scaffolding that lets people work independently without getting in each other's way.

Two sources that made the gap concrete

Customer Success flagged the pattern first

The Customer Success Manager kept getting the same question: how do I give someone else access? There was no good answer. It came up so often it couldn't be dismissed as an edge case — this was a basic expectation the product didn't meet. Teams were sharing credentials instead, which created security risks and made it impossible to know how many people were actually using the platform.

User interviews named the structural pain points

Interviews with users matching Mammoth's two core personas went deeper than access. Three problems kept coming up: not being able to grant access at all, no visibility into how data was being used across an account, and no good way to organise datasets without folders or projects. Users wanted distinct roles, better hierarchy, and the ability to work on something privately before sharing it.

I also looked at how other workspace-based tools handle collaboration — shared data, role hierarchies, tiered access. The goal was to lean on patterns people already understood rather than inventing new ones. That research shaped the invitation flows, permission model, and settings architecture.

Holding together competing definitions

Setting direction with competing pressures

The goal was clear, but three pressures were pulling in different directions. Users wanted to work together on data. The business saw collaboration as a way to restructure pricing around plan tiers. And the product was already feature-heavy — adding collaboration couldn't just mean more on top, it needed to simplify what was already there.

Mapping the structural problem

The starting point was flat — one account, one user, everything in a single space. The new model introduced workspaces: a user could belong to several, each with its own plan, billing, and team members, with access scoped by role at both workspace and project level. That meant mapping invitation flows, defining access rules, and designing the full workspace user flow.

Designing roles and permissions

Three workspace roles: Owner (full control including billing), Admin (manages users but not billing), and Analyst (can access content, nothing else). At the project level, a separate layer controlled whether someone could edit or just view — or whether a project was private, visible only to Owner and Admin. The tricky part was keeping this light enough for a two-person team without breaking down for larger orgs.

Validating through usability testing

We ran usability tests with internal and external users before finalising. The workspace model — switching, inviting, managing roles — made sense to people right away. A few rough spots came up around onboarding and project-level role distinctions, and we folded those into the next iterations before handoff.

Navigating scope through constraints

The full vision was bigger than what could ship at once. We broke it into stages — plans and settings infrastructure first, then the core: workspace navigation, invitations, and role assignment. What to defer and what to ship first were decisions we made early, together with Product and Engineering.

Workspaces as the organising principle

Workspaces

Workspaces give teams a shared space for their data workflows, scoped by plan and role. Tying workspaces to plans was a business push. It gave pricing something concrete to attach to and made multi-user access the lever for upselling. Users can belong to more than one, switch between them from the homepage, and set up new ones through a guided flow: pick a plan, add payment, name it, invite people.

Settings & Management

Settings bring together user management, billing, data usage, and API keys — all scoped to the active workspace and gated by role. Data usage views show monthly and yearly breakdowns so users can spot ingestion spikes.

Invitation flows

Three invitation paths — self-serve signup, invited new users, and existing users joining a workspace — each designed to set clear expectations about what they're joining. Every path got proper attention, not just a modal tacked on at the end.

Validated design, structured handoff

I left Mammoth before this shipped to production, so the impact here is about design validation and groundwork — not live metrics.

Usability testing confirmed the workspace model was easy to understand and use. We refined onboarding and role distinctions based on what came up, and folded those changes into the final handoff. A measurement framework was in place — session length, workspace adoption rate, MAU growth — but the project hadn't reached production for those numbers to materialise.

The work touched nearly every part of the product. What came out of it went further than collaboration alone: a role and permission framework other features could build on, a workspace model that tied pricing and billing together, and onboarding flows that work across every entry point.

Designing for competing definitions

The hardest part wasn't any one screen — it was that "collaboration" meant something different to everyone. Users wanted to share data without stepping on each other. The business wanted a pricing model that scaled with team size. Engineering needed to rearchitect how workflows related to accounts without breaking what already worked. The workspace model was the answer that held all three together.

The other big thing was scope. The full vision was there from the start — the discipline was deciding what could wait without weakening what shipped first. Phasing wasn't a compromise, it's what made shipping possible. If I could do one thing differently, I'd have pushed for the measurement framework earlier.