Why I joined Postman: powering the engine of growth with the API client

How does a simple tool for executing REST commands become the platform for API tooling worldwide? And then how should this platform continue to best serve the needs of all the individual developers and teams now depending on it for their productivity?

In this blog post, I’ll talk about how these questions drew me to join the Postman team in October 2023 as its head of API client. I hope you’ll find my story insightful—whether you’re a Postman user, someone generally interested in scaling platforms, or simply curious about becoming a Postmanaut yourself!

About me

Before I joined Postman, I was VP of product and engineering at Gatsby (and granted an honorary co-founder title; neat!), which was acquired in February 2023 by Netlify. I started at Gatsby in September 2018 as employee #11 working on their open source project. During my time there, I helped build the teams in customer success, product, marketing (that job is hard!), and then ultimately led both product and engineering. With an engineering team of less than 20, we grew a cloud product from basically no revenue to multi-million ARR revenue and thousands of customers—and we built a loved, open source web framework that now powers 0.3% of the web.

But after a great, rewarding, and just a little bit exhausting run, I started looking for my next challenge.

How I got interested in working at Postman

What appealed to me most about joining Postman is that the product is an absolutely ubiquitous developer asset because developers (like myself!) genuinely love using it. Today, more than 30 million developers use Postman. When you mention to any developer, “I work at Postman,” they stop you and say, “I know Postman—I use it all the time!”

These days, I no longer have to have a pithy elevator pitch about what I work on and why it matters: developers know Postman, and developers love Postman.

I still think of myself first and foremost as an engineer who builds useful things (it’s true, I tell you, I still have it). And as an engineer, I am a user of Postman. However, I must be frank: in my leadership positions, I found myself getting hands-on with developer tools less than I would like. So, one of the most rewarding things about applying to Postman was using the product, developing my own ideas about how it could be improved, and presenting these ideas in front of an interview panel.

But even I, as a longtime Postman user, was surprised to discover so many reasons that made me want to join. Since I hadn’t used Postman all that frequently in the past several years, I had a stagnant mental model formed years ago of Postman as “just a REST tool.” This notion was immediately dispelled when I used the product again in-depth. Yes, it is still very much a great REST tool, but the product itself has improved dramatically as it has expanded and grown.

Here are some specific Postman features that I didn’t know about before using the product again—and I not only liked these, but they made me more productive:

• Test features: I built some examples with basically a TDD (test-driven development) approach to development. It was fun to write the test, validate it was breaking, build the feature, and validate that it worked. Rinse and repeat.
• Mock features: I used mock servers to build and iterate on a quick frontend UI without needing to write a line of backend Node.js code.
• Monitors: I used Postman Monitors just to validate that my API was working consistently;  a monitor would send me an email if my API was failing (kind of like an Uptime Robot or Pingdom).
• Postbot: I used Postbot to write tests and documentation with the power of AI. It wasn’t just bolted-on ChatGPT, it was genuinely useful in helping me write meaningful test cases and accurate documentation because the AI already had the context.

These discoveries of product breadth and depth piqued my interest. Postman’s product did so much more than I realized.

The relief of no longer chasing product-market fit

Still, even after playing more with Postman’s product, I didn’t know a lot about Postman as a business. And then? What ultimately sold me was realizing that Postman has found undeniable product-market fit.

For context: product-market fit is the elusive make-or-break for any product. It means that a product has customers that are willing to pay for the problem that the product solves. My previous roles were ultimately spent continually chasing product-market fit, a fickle beast that kept slipping out of my hands more often than I would’ve liked. To steal a metaphor: I’ve spent a good chunk of the past several years seemingly pushing a boulder up a hill and never quite seeing the view from the top. I’d find myself wildly chasing the boulder as it rolled back down. I wanted to finally experience the thrill of pushing that boulder up that hill and figuring out the processes to keep it at the top.

When considering joining Postman, I was very assured by several things that make it clear it has strong product-market fit:

• Consistent year-over-year growth: In my interview rounds, it became obvious that the business has been growing quite dramatically year over year and shows no signs of slowing. Business is booming because teams must build, explore, and innovate with APIs more than ever before.

• An expanding global community of more than 30 million users: Postman continues to see increasing demand from both individual developers to large enterprises. Also, Postman has a more traditional (and genuine!) product-led growth motion that I found really appealing and interesting. Postman isn’t just being leveraged in a particular segment of business type or industry, but it’s very intentionally developer-centric and developer-adopted in large organizations.

• Product conviction and a multi-product future: I learned that the Postman team—both in and outside of its engineering squads—has a demonstrated passion for everything it builds. And this isn’t just centered around the core product/desktop client, but also includes new product initiatives like Postman Flows, Live Insights, Public API Network, and Postbot. Other Postman employees aren’t just excited about them; they are actively using these tools in their day-to-day workflows. Even “the HR guy” (Postman Head of People Ajay Prasad) excitedly talked to me about how the HR team uses Postman features like Flows to streamline its day-to-day tasks.

It was at this point that I really started leaning in. I wanted to work at Postman.

Leading the API client

Luckily for me, there was mutual interest, and I received an offer to join the company. I continued to learn more about the team that I’d be leading: about 15 engineers, product managers, and designers who collectively own the beating heart of Postman’s core product, the API client. The API client team is responsible for helping developers successfully debug, test, and run requests of any protocol (HTTP, gRPC, GraphQL, WebSockets, and more). To help give you an idea visually, the team is responsible for all the areas of the Postman interface outlined in red below—yes, there are a lot of them:

What excited me about working on the API client was how much latitude I would have in serving our users. It can be easy to be change-averse for fear of harming the years of collective usage and understanding that exists in a mature tool. But I was full of ideas and vigor for the future—and that landed well with Postman leadership. For instance, when I asked Postman Co-founder and CEO Abhinav Asthana about what metric he wanted me to target in this role, he asked what metric I, as the outside person coming in, felt should be most important. Once I saw what a supportive, open-minded, and user-obsessed environment Postman operates in, I knew that the API client was something that I wanted to help steer into an exciting direction for the future.

Epilogue: my first 30 days at Postman

Onboarding to the Postman team as a new manager has been a breath of fresh air because it is very clear that Postman works to ensure its leaders are successful. I was repeatedly encouraged: use the product. Develop your own conviction. Don’t spend too much time looking at data; talk to customers. But most importantly, use the product, build with the product, and meet the team and your peers, unencumbered by the challenges and stressors of day-to-day management.

My first 30 days at Postman were such a fun way to start my journey here. I met the team that I would eventually lead—but instead of meeting them as their leader, I met them as a peer and a fellow user of the tool wanting to make it better. I shared ideas, heard their ideas, and didn’t worry about the gravitational weight of a title or a direction. I was working in a meritocracy where ideas and improvement are what matter most.

I spent quite a bit of time in GitHub responding to users and understanding more about the “pulse” that our users are sharing, and I even built a bot to help the team triage and understand insights from this feedback channel. As one member of the team, Postman Staff Engineer Udit Vasu, said: “Our users are telling us what they want and how we can help them.” A big takeaway for me was to continue to keep the team focused on our users and ensure that we’re rapidly following up, as best as we can, with these users.

Last but certainly not least, it has been extraordinary to see what other leaders Postman has hired for other functions. There are leaders coming from recognizable names like AWS and PayPal, and former founders and CEOs of startups. It’s truly an inspiring group and a clear indication of how Postman plans to keep scaling and improving. Stay tuned for more stories from other leaders in this blog post series sharing why they joined Postman.

What’s next for the API client?

Now that I’ve gotten my arms around the team and product, and I’ve developed my own product conviction and sensibilities, the future of Postman’s API client is even brighter and more in focus. We are excited to keep improving Postman for you in 2024. This year, we’re planning to concentrate on a few high-level themes and address some longer-standing feature requests we’ve received from users in GitHub:

• Delight the developer: We’re working to make Postman an even more delightful experience for developers. While simplicity is one angle that all developers can benefit from, we also want to deliver features that help you be effective and more powerful in your day-to-day job: things like HTTP/2 support, support for reusable scripts in the sandbox, and parallel initiatives like Postbot.

• Simplify sending requests and debugging: You probably chose Postman because of the core value proposition of sending a request and using the response to debug, then sharing this with your team in a Postman Collection. We plan to make this core functionality even better and simpler and remove anything impeding you from achieving this essential job.

• Build the multi-protocol future: In the past two years, we launched support for multiple new protocols: GraphQL, gRPC, WebSockets, and MQTT. We built these features to help new users of Postman and teams who may not be using REST (or who are using REST and…something!). We are working to deepen their integration into the full breadth of the Postman API Platform, like using the Collection Runner, as well as continue to focus on improving these protocols. The REST experience in Postman has 10 years(!) of improvements and features, and now we’re making rapid progress in other areas, investing time and customer obsession into building newer features—and making them just as great.

I couldn’t be more excited to keep building the future of the Postman API client in 2024 and beyond. We are relentlessly focused on making the Postman API Platform better for you, and we are excited to make it even more indispensable to developers around the world.

If these problems opportunities are interesting to you and you’d like to join our team, please check out Postman’s open positions.