Collaboration @ Postman
Collapsing the Postman → Slack → Postman loop for 40M+ developers
The Problem
Postman had the world's largest collection of API data. Teams were building, testing, and maintaining APIs together. But the collaboration? It was happening entirely outside the product.
Every API change notification was a manual process: find the diff, write a message, paste into Slack, hope the right person sees it.
If a teammate changed an endpoint you depended on, you'd find out when your tests broke — not before.
There was nowhere inside Postman to discuss why a request worked the way it did, or flag concerns about a schema change.
API review cycles happened over email, with no audit trail. Who approved this? When? Nobody knew.
"We use Postman for building and Slack for talking about what we built. They're two separate tools for one job."
Research
I embedded with 6 engineering teams for 2 weeks before writing a single spec. Watching real collaboration is very different from hearing people describe it.
The real problem wasn't that Postman lacked collaboration features — it was that every collaboration touchpoint required leaving the product. Each exit was a context switch that cost teams 10+ minutes of focus time.
Design Process
Developer tools demand extreme restraint. Every feature we added needed to justify its existence — devs have the highest tolerance for turning things off, and the lowest tolerance for noise.
The Solution
We shipped three interconnected systems designed to make collaboration happen inside Postman — not around it.
Thread discussions directly on any request, response body, or test script. @mention teammates. Resolve threads when done. Comments are version-aware — they travel with the collection through every change, not just the snapshot you commented on.
- ✓Attach to request, response body, headers, or test script
- ✓Version-aware: comments persist through schema changes
- ✓@mention with smart autocomplete from workspace members
- ✓Resolve/reopen threads — clean audit trail
Modelled on GitHub's notification model — the one developers already trusted and understood. Surfaces only changes that affect your work: a dependency you use changed, a thread you're in got a reply, a review you requested is ready. Slack and email digests available as opt-in, not default.
- ✓Dependency-aware: notified when your endpoints change
- ✓Thread mentions surface above everything else
- ✓Conservative defaults — expand only what you want
- ✓Slack integration: send digests to your team channel
Request reviews, assign reviewers, block publishes until approved. Full audit trail — who approved what, when, and with what comments. Designed to slot into existing PR workflows: API changes now carry the same accountability as the code that calls them.
- ✓Request review from any workspace member
- ✓Block publish/merge until minimum approvals met
- ✓Full approval history in collection changelog
- ✓Integrates with existing PR workflows via API
Outcome
We shipped to 5% of users in week 1, ramped to 100% over 6 weeks. Every metric moved — but the one we're most proud of is the hardest one.
"We cancelled our Notion doc for API reviews. Everything lives in Postman now. That's the first time I've ever said that about a collaboration tool."
Three enterprise customers cited collaboration features as the primary reason for upgrading to Team plans in the 90 days post-launch. The 0% in-app collaboration metric — our north star — moved to 34% of shared collections having at least one comment. The hardest metric to move.
Learnings
Start with fewer notifications than you think you need. It's much easier to add signals than to recover trust once users have learned to ignore you. Every irrelevant ping destroys a little bit of the channel's credibility.
AI-suggested reviewers felt like surveillance. A simple recency list felt natural. Developers value explicit, predictable systems over magical ones they can't explain.
The best collaboration feature we shipped was not adding anything — it was removing the 11 handoffs that took people out of Postman. Friction removal > feature addition.
Our v1 notification defaults were too aggressive. We spent 4 of 11 iterations just dialling back. Default to minimal and let users opt into more — never the reverse.