Reducing collaboration friction in Postman
How I simplified the workspace and sharing model to remove the friction that was actively blocking collaboration, contributing to 25% paid collaborator growth and ~$2M ARR in a single quarter.
Snapshot
Sharing a workspace in Postman was harder than it needed to be. The flow asked users to choose between workspace “types” and permission concepts they did not fully understand, which led to hesitation, drop-off, and collaboration that never started.
I reworked the share and invite experience around a simpler mental model, with clearer defaults and fewer decisions up front. The goal was to make collaboration feel like the obvious next step, not a configuration exercise.
The result was a big lift in successful sharing. Share flow conversion increased from 8% to 28%, contributing to measurable growth in collaborative usage.
The Core Problem
Collaboration broke down at scale
Sharing is one of the most important collaboration flows in Postman. When people share, team usage grows, collaboration deepens, and the product becomes more valuable. The problem was that our very sharing flow carried too much friction.
This friction was especially visible in growing organizations with hundreds of developers. These teams had already standardized on Postman, but collaboration was not happening as expected. Work stayed isolated, even when the intent to collaborate was clearly there.
Customer calls made the pattern impossible to ignore. Collaboration was not failing because teams did not want to work together. It was failing because most work never left personal spaces in the first place.
“Most of them are still working in their personal workspaces.”
An Engineering Manager about their team using Postman.
The data confirmed what we were hearing
Across large teams, the majority of active work lived in personal workspaces. This held true even in organizations with widespread adoption and hundreds of licensed developers. The system made staying in single player mode the easiest option.
Below is an example from a customer with ~300 Postman users. Despite the scale, most activity still happens in personal workspaces, visible only to the developer who created it.
Single player was simply easier
If you started in a personal workspace, sharing required making a structural decision before you could make a simple one. Move your collection into a different workspace. Convert your entire workspace. Hope you picked the right path.
In large organizations, many developers still started outside a team context, even after adoption had scaled. For them, collaboration also meant creating or joining a team mid flow. To avoid this complexity, many users exported instead. Exporting worked, but it created duplicate collections that drifted out of sync and kept teams from working in the same place.
Constraints shaped the problem space
We could not change Postman’s backend workspace model. Plan limits, approval flows, and legacy behaviors all had to remain intact. Improving the experience meant simplifying the model on the surface while respecting everything underneath.
The Solution
Merging workspace types
We merged personal, private, and team workspaces into one unified type: Internal. An Internal workspace can be visible only to you and invited people or to everyone on your team. The type never changes. Visibility does. This shift removed three legacy decisions and replaced them with one clear question: who should see this work?
Remove friction when sharing
Sharing from an Internal workspace that is visible only to you now expands visibility in a predictable way. On lower plans, that means exposing it to the team. On higher plans, it means private collaboration. Many modern tools take this approach because it aligns with how collaboration-driven business models work. You opt out of visibility, not into it.
Share and manage roles from a single place
We also unified inviting people and managing roles into a single access modal. These actions used to live in separate parts of the product, which added friction and made role upgrades harder to discover. Bringing them together aligned with users’ mental models and matched patterns they already understood from other tools. It also gave use the opportunity to relocate some other functionality, that no longer belonged here.
What I am most proud of is the level of systems thinking this required. Understanding how every part of the model behaved across plans, approvals, and legacy patterns was its own challenge. Modernizing the experience without touching the underlying system meant I had to know that system inside out. And because we were introducing organizations as a new top-level entity, we designed everything to support that future model as well.
How we worked: Simplifying collaboration at scale
We started by mapping how people move through the work lifecycle: from working alone, to private collaboration, to fully shared team work. We aligned this with the software development lifecycle to understand where friction showed up and what actually mattered.
Benchmarking confirmed a clear pattern across modern tools: creation and access belong together. Visibility is the mental model people rely on when deciding whether to collaborate.
Continuous alignment and fast iteration
Diagrams, wireframes, and prototypes in Figma helped us test ideas quickly. Weekly syncs, async Looms, and tight loops with Engineering kept us aligned. Because we had to support every plan tier, approval flow, and legacy edge case, we continuously validated scenarios and documented gaps as we found them.
We also made intentional scope calls. As we tested flows, we uncovered long-standing issues outside the project. Fixing everything would have ballooned the effort, so we focused on the friction that directly blocked collaboration and captured the rest as debt.
Key Decisions
Decision 1
Unify the experience without changing the underlying model
We chose to keep the existing workspace model intact. Personal, private, and team workspaces still exist in the backend, and all APIs remained unchanged.
Instead of changing the model, we changed the experience. Users start with an Internal workspace and set visibility through actions. Inviting someone automatically updates the underlying type.
This avoided breaking changes while removing the need for users to manage workspace types up front.
Decision 2
Make collaboration the default path
We shifted collaboration from an explicit decision to a built-in behavior. New users now start with a team by default, and existing users get one automatically when they take a collaborative action.
This removed the need to decide when to create or join a team. Users simply act, and the product ensures the right structure exists underneath, resulting in smoother, more streamlined workflows.
| Before | After |
|---|---|
| Create team first | Team exists by default, or is automatically created |
| Friction when trying to collaborate | Collaborate seamlessly, no additional steps |
| Lots of decision making, potential drop-off points | System fills the gaps, no decision making |
Impact and Reflection
We tracked adoption closely after launch. Even with imperfect tracking early on, the trend was clear: collaboration increased rapidly.
Immediate impact
Collection share conversion increased from ~10% to 28% within two months.
In personal workspaces, conversion rose from 8% to 21%+ in the first week, then stabilized around 25%.
Collaborative users on paid plans grew 24% YoY.
Thousands of users collaborated with others for the first time.
Feedback and tradeoffs
We heard from users right away. One common point of confusion was that sharing a collection implicitly expanded visibility to the entire workspace. Some users expected to share with a single person and missed the upgrade nudge explaining the difference.
The feedback was valid. It was a known tradeoff in the model, and reversing the action required additional steps. In practice, though, most users did not adjust visibility after sharing, and overall collaborative behavior still moved strongly in the right direction.
Further improvements
With more time, I would finish the job by collapsing workspace types and visibility into a single model, letting users decide “who can see this” and “what can they do” from one place.
This was one of the most system-heavy projects I have worked on. Seeing collaborative behavior shift almost immediately reinforced the value of simplifying models instead of adding more options.
Final Takeaway
People often assume meaningful impact comes from shipping something new. More often, the leverage is already there. It just needs to be tightened, simplified, and stitched together so it works as one coherent product.
This project reinforced that lesson. Simplification is still one of the most powerful tools in product design. One day I might even finish that Steve Jobs book on my shelf and get the official endorsement.
More often, the leverage is already there. It just needs to be tightened, simplified, and stitched together so it works as one coherent product.
This project reinforced that lesson. Simplification is still one of the most powerful tools in product design. One day I might even finish that Steve Jobs book on my shelf and get the official endorsement.
If you want to discuss this work, feel free to reach out.
