Reducing collaboration friction in Postman
How I simplified workspace sharing to make collaboration the default, contributing to a 24% year-over-year increase in collaborative users.
Snapshot
Most work in Postman starts in a personal workspace. It is the single player mode of the product, and people stayed there longer than they should. The moment they tried to involve someone else, things became complicated.
Sharing from a personal workspace meant making a structural decision before a simple one. You had to move your collection elsewhere or convert the entire workspace. For many users, collaboration also required creating a team for the first time, surfaced right when they just wanted to share. None of this felt natural, and it slowed people down.
I led the redesign of this experience with partners in Product, Design, and Engineering. The goal was simple. Make it easier to go from single player to multiplayer, by untangling sharing from workspace structure and team setup.
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
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.
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 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. Every morning started with a fresh pull of overnight data, and watching the charts climb became a small ritual. Our dashboards were still being stitched together, and we had occasional misfires in event tracking, but even with imperfect data the trend was unmistakable. Collaboration was increasing fast.
Immediate impact
Collection share conversion jumped from about 10 percent to 28 percent within two months.
This helped drive a 24 percent year-over-year increase in collaborative users on paid plans.
After updating the share modal in personal workspaces, conversion rose from 8 percent to over 21 percent in the first week, later stabilizing around 25 percent.
Team invites hit all-time highs across email, guest, and link flows.
Thousands of users moved from individual to multi-user teams for the first time.
Internal workspaces with at least two active collaborators reached new records, especially in professional domains.
Feedback and tradeoffs
We also heard from users right away. One person was surprised that sharing a collection implicitly expanded visibility for the entire workspace. They thought they were sharing with a single person, not the whole team, because their plan did not support private collaboration. They missed the upgrade nudge that communicated the difference. The feedback was valid. It was one of the tradeoffs of the model, and undoing the action required going back to the workspace. In practice, though, most users never adjust visibility after sharing, and the broader behavior still moved in the right direction.
Further improvements
If I had more time, I would finish the job by collapsing types and visibility entirely, letting users set “who can see this and what can they do” from one single place.
This was one of the most system-heavy projects I have worked on. It was challenging, but also rewarding. Seeing collaborative behavior shift almost immediately is one of the reasons I love this work.
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.