Visual summary of operating lessons from Abhinav Asthana.

Lessons from Abhinav Asthana

Abhinav Asthana is the co-founder and CEO of Postman. He began the product as a side project to simplify API testing and debugging, then developed it into a collaborative platform for building and using APIs. — Postman — About the Company.

Part 1: The Founding of Postman

  1. Repeated Workflow Pain Can Reveal a Product: Asthana built Postman after repeatedly struggling to test, debug, and share APIs at Yahoo and his first startup. — Postman — How We Built the Product and Company.
  2. Scratch Your Own Itch, Then Test Whether It Is Shared: Postman began as a tool Asthana needed himself; Chrome Web Store adoption showed that many other developers had the same problem. — Changelog Interviews #360.
  3. Choose the Fastest Useful Distribution Path: A Chrome extension let Asthana ship quickly through a runtime developers already had, and the Web Store supplied organic discovery. — First Round Review — Postman’s Journey.
  4. Build With People Whose Working Style You Know: Asthana recruited Ankit Sobti and Abhijit Kane after working with them previously, reducing uncertainty about trust and collaboration. — First Round Review — Postman’s Journey.
  5. A Side Project Earns Attention Through Pull: Asthana treated Postman as a side project until usage, feature requests, and Google’s interest demonstrated unusually strong demand. — First Round Review — Postman’s Journey.
  6. Delay Fundraising Until the Product Has Evidence: The founders tried to sustain Postman through consulting, sponsorship, donations, and paid upgrades before outside capital arrived through inbound interest. — Startup Project #128 — Abhinav Asthana.
  7. Early Revenue Creates Strategic Independence: A low-priced automation upgrade made Postman ramen-profitable and gave the founders room to learn before committing to a larger business model. — First Round Review — Postman’s Journey.
  8. Solve the Pain, Not the Trend: Postman grew from a concrete API-development problem rather than a thesis about what category would become fashionable. — Postman — How We Built the Product and Company.
  9. Let External Pull Change the Level of Commitment: Strong adoption, detailed feedback, and Chrome’s decision to feature Postman persuaded the founders to treat it as more than a side project. — Changelog Interviews #360.

Part 2: The API-First Philosophy

  1. Treat APIs as First-Class Product Objects: Postman evolved beyond a request client by representing API interfaces, instances, implementations, documentation, tests, and monitoring as connected parts of one workflow. — Changelog Interviews #360.
  2. Design the Interface Before the Implementation Hardens: Asthana’s API-platform vision centers the explicit API definition and connects it to mocks, tests, documentation, monitoring, and implementation work. — Changelog Interviews #360.
  3. APIs Coordinate Work Between People and Systems: Asthana saw that APIs are built to be consumed by someone else, making sharing and collaboration core requirements rather than add-ons. — First Round Review — Postman’s Journey.
  4. Create a Shareable Unit of Work: Postman Collections turned useful request sequences into portable artifacts that teammates could reuse for debugging, documentation, and testing. — Changelog Interviews #360.
  5. Connect Testing to the API Workflow: Collections and the Newman runner allowed API requests to become repeatable automated checks that could participate in continuous delivery. — Changelog Interviews #360.
  6. Collaboration Can Become the Product’s Growth Loop: Sharing a collection gave the recipient immediate value while naturally introducing another user to Postman. — Changelog Interviews #360.

Part 3: Building for Developers

  1. Developer Experience Is a Flow Problem: Asthana defines good developer software by whether it preserves deep work, removes small points of friction, and presents the right context at the right time. — First Round Review — Postman’s Journey.
  2. Reveal Complexity Progressively: Postman was designed so a newcomer could become useful quickly while advanced capabilities appeared as the user’s needs grew. — First Round Review — Postman’s Journey.
  3. Combine User Feedback With a View Beyond the Horizon: Asthana balances immediate customer requests with hypotheses about how API work and the market are likely to evolve. — First Round Review — Postman’s Journey.
  4. Remove Friction That Breaks Concentration: Small interruptions, unnecessary prompts, and badly timed information can push developers out of flow even when each feature seems individually reasonable. — First Round Review — Postman’s Journey.
  5. Understand the User’s Actual Work: Postman’s early product decisions came from doing API work directly and later from watching customers use the tool inside real workflows. — Changelog Interviews #360.
  6. Let Community Extend Support: The founders answered questions themselves, then scaled support and marketing from the relationships already forming in community channels. — Postman — How We Built the Product and Company.
  7. Design for Important Non-Developer Participants: Product managers, technical writers, solution engineers, and other non-developers became enthusiastic Postman users, reinforcing the need for accessible interfaces. — First Round Review — Postman’s Journey.

Part 4: Scaling the Company

  1. Communication Systems Must Change With Company Scale: Postman moved from founders working in one room to a global organization, repeatedly changing how teams communicate and coordinate. — Stack Overflow — Postman’s Journey.
  2. Global Teams Need Explicit Coordination: As engineering spread across locations and functions, Postman had to replace informal founder communication with clearer goals, written context, and organizational mechanisms. — Stack Overflow — Postman’s Journey.
  3. Use Monetization Experiments to Discover the Buyer: Bulk purchases of an individual upgrade revealed team demand; a six-month beta and price tests then validated recurring collaboration software. — First Round Review — Postman’s Journey.
  4. Separate Individual Utility From Organizational Value: Postman kept the single-player developer experience broadly free while charging teams and enterprises for collaboration, management, and governance. — First Round Review — Postman’s Journey.
  5. Tie Teams to a Clear Shared Goal: Asthana found that scaling coordination improved when functions could connect their work to one repeatedly communicated company objective. — Stack Overflow — Postman’s Journey.

Part 5: The Age of AI and Agents

  1. Agentic Software Changes the Development Workflow: Postman’s AI work treats agents as participants that can explore APIs, review designs, test changes, and execute multi-step engineering work with context and controls. — Postman — Introducing the AI Engineer.
  2. Agents Need Governed API Context: Useful agents require more than model quality: they need current API definitions, ownership, dependencies, authorization, and execution boundaries. — Postman — Introducing the AI Engineer.
  3. Use AI to Shorten the Path From Idea to Prototype: Postman uses AI to let product, design, and engineering collaborators produce interactive prototypes earlier, reducing translation through documents and mockups. — Stack Overflow — Postman’s Journey.
  4. Context Is the Bottleneck in Agentic Engineering: Asthana argues that agents must understand the existing system—its APIs, services, dependencies, and conventions—before they can make reliable changes. — Postman — Introducing the AI Engineer.
  5. APIs Turn Model Output Into Action: Asthana describes APIs as the mechanism through which language-model agents access live information and execute real workflows. — Stack Overflow — Postman’s Journey.
  6. Use AI to Search Large Feedback Histories: Postman uses agents to synthesize thousands of customer comments, surface recurring problems, and recover prior workarounds. — Stack Overflow — Postman’s Journey.
  7. Make APIs Legible to Agents: Agents need discoverable interfaces and usable context; inaccessible or poorly described APIs are difficult to select and operate correctly. — Stack Overflow — Postman’s Journey.
  8. Expect More Machine-to-Machine Interaction: Asthana expects agents to compose and invoke APIs on behalf of users, increasing the importance of interfaces designed for software consumers. — Stack Overflow — Postman’s Journey.
  9. Keep Agent-Generated Changes Inside Review and Test Loops: Postman’s AI Engineer runs in a sandbox, checks API changes, and routes write operations through explicit approval and existing code review. — Postman — Introducing the AI Engineer.

Part 6: Leadership and Engineering Culture

  1. Measure Product Value, Not Engineering Activity: Asthana emphasizes whether the product is reliable, useful, and helping people accomplish work rather than whether a team adopted fashionable technology. — Stack Overflow — Postman’s Journey.
  2. Keep Architecture Simple Until Demand Requires More: Postman deliberately avoided premature infrastructure complexity, adding and refactoring capabilities when customer scale or reliability made the need concrete. — Stack Overflow — Postman’s Journey.
  3. Keep Product, Design, and Engineering Aligned: Asthana credits cross-functional units with maintaining a shared understanding of the customer, business model, purpose, and product vision. — Stack Overflow — Postman’s Journey.
  4. A CEO Must Build the Team That Builds the Product: As Postman grew, Asthana shifted more attention toward hiring and organizational capability rather than trying to shoulder company building alone. — First Round Review — Postman’s Journey.

Part 7: The Product-Led Growth Engine

  1. Developer Love Can Drive Bottom-Up Adoption: Millions of Postman users continue to arrive organically because individuals adopt a useful tool and carry it into team workflows. — First Round Review — Postman’s Journey.
  2. Free Individual Utility Can Feed Paid Collaboration: Postman made the single-player experience free and monetized the point where teams standardized and needed multiplayer capabilities. — First Round Review — Postman’s Journey.
  3. Optimize for Fast Initial Competence: Progressive disclosure was meant to make users productive in their first minutes without removing the power needed later. — First Round Review — Postman’s Journey.
  4. Community Compounds Product Knowledge: Meetups and online channels allowed users to answer one another’s questions, teach workflows, and strengthen the ecosystem without Postman mediating every exchange. — First Round Review — Postman’s Journey.
  5. Sharing Should Advance the Recipient’s Work: Collections spread because sharing one saved the recipient from rediscovering requests and parameters, making the viral loop useful rather than promotional. — Changelog Interviews #360.
  6. Charge Where Organizational Pain Begins: Postman preserved generous individual use while reserving collaboration, management, and enterprise controls for paid tiers. — First Round Review — Postman’s Journey.

Part 8: Navigating the Enterprise Market

  1. Enterprise Adoption Adds Governance Constraints: The product had to balance developer freedom with the controls, reliability, and governance required by large organizations. — First Round Review — Postman’s Journey.
  2. Use Existing Adoption to Start Enterprise Relationships: Asthana began by meeting active users, handling support, and following opportunities created by real usage before building a larger sales organization. — Startup Project #128 — Abhinav Asthana.
  3. Governance Must Scale With API Use: As Postman expanded across multi-team organizations, customers needed ownership, authorization, reliability, and policy controls alongside developer usability. — First Round Review — Postman’s Journey.
  4. Serve Both the User and the Organizational Buyer: Asthana distinguishes the free developer experience from the value managers and enterprise buyers need to justify standardization and payment. — Startup Project #128 — Abhinav Asthana.
  5. Large Organizations Need a Shared API System of Record: Multi-team companies accumulate APIs across products, business units, and acquisitions, creating demand for catalogs, ownership, dependencies, and common workflows. — First Round Review — Postman’s Journey.
  6. Expand From Tool to Platform Around the User Workflow: Postman’s long-term strategy connects design, testing, documentation, monitoring, governance, and collaboration around the APIs an organization builds and consumes. — First Round Review — Postman’s Journey