[Product Roadmap] How a vision to play the long game in the industry helped Postman build a rockstar product
A product roadmap clarifies the why, what, and how behind what a tech startup is building. This week, we take a closer look at API development environment Postman, and how it has evolved into an end-to-end lifecycle workflow through intuition and with ease.
![[Product Roadmap] How a vision to play the long game in the industry helped Postman build a rockstar product](https://images.yourstory.com/cs/2/730b50702d6c11e9aa979329348d4c3e/Postman-1589768144170.png?mode=crop&crop=faces&ar=2:1?width=3840&q=75)
After 2010, when the importance of APIs was just starting to be realised in the tech world, the tools for API development were still in their infancy and managing them was a challenge. Specifically, there seemed to be plenty of communication issues with different teams, making the tracking of API updates a hassle.
Abhinav Asthana, the CEO and Co-founder of , built the platform primarily to solve this issue for himself and found that it worked well enough. He then decided to put it up on Chrome Web Store as an open-source REST client, and the app quickly gained popularity.
This gave him and his co-founders the necessary push to take Postman up full time. Abhinav officially set up Postman in October 2014 with Abhijit Kane and Ankit Sobti, and launched Postman as a product in November 2015. The startup also has an office in Bengaluru.
The San Francisco-headquartered startup is a pioneer that prominently helped the tech industry transition its software approach from code-first to API-first.
Today, Postman is used by more than 10 million developers and 500,000 companies around the world. It is not overselling to say that it is currently the only complete API development environment in the market, and its popularity has soared because of its simple and intuitive UI that allows developers to manage every stage of the API lifecycle.
As an API development platform, the range of problems the product stack at Postman can solve is kept intentionally vague. Any problem that users might face on a fundamental level in their regular API development process, is something that Postman should be able to solve in one way or another.
This objective is imperative to Postman as the use of APIs are on the rise, both within organisations and because of the number of organisations using them.
How did it all start?
Postman started as an open source tool that was meant to simplify a very basic API testing workflow, which is a fraction of the problem set that it solves now. Since it was open source, it naturally caught the attention of the developers and quickly became a developer-favourite in most web forums. The first product itself was being used by more than five lakh developers within two years.
Abhijit tells YourStory, "That itself was remarkable and something I didn't expect. But it was also a strong signal that it was a tool that developers wanted, and could potentially grow into a much larger solutions space. One signal we got from here was that collaboration was key. Even though the product originally did not support collaboration, we found that users would often export their Postman data, e-mail it to their friends, and have them import it."
The team then looked into an offline collaboration model, which was already showing indications of becoming big. Since APIs are inherently very collaborative, it made a lot of sense to them, and fundamentally aligned with the trends in the industry.
Abhijit says Postman cannot be remembered for a mere key feature launch positioned as a big event, since the startup is playing a long-term game in the market. The set of problems in API development is broad enough, and different sizes of features have to be shipped to achieve the result.
After the collaboration feature, in the last four years, the startup has launched monitoring, API design, and API documentation – all reasonably big features. They all conveniently feed into the bigger goal of solving the complete, end-to-end API workflow.
Since the beginning, the product is upgraded once every few weeks, which has always been a part of the plan.
The product roadmap
User interaction has always been a very key part of the product cycle at Postman. Before the company was established, Postman itself was open source. The only way Abhijit would follow the product's roadmap forward was via user feedback. The responses were on the lines of 'this is broken,' or 'this is not working,' or 'this is a good idea to build upon,' and so on.
This kind of culture has stayed with the company, and most of the development is intentionally iterative.
Abhijit says, "Our primary source of user communication is GitHub, where a lot of users and a lot of developers are very open to giving feedback about things that are working, things that are not working, and so on. I think the other advantage we have with that transparency is that on GitHub, people don’t speak to you with a company-customer relationship. They talk to you as equals, as developers."
This kind of belonging added to the usability of the feedback the team got. However, at the scale that Postman now operates at, the startup cannot obviously address individual feature requests. Though the team would have to prioritise, reject certain requests, and make some tough choices, it is something that the user base, by and large, is okay with.
"We realised early on that collaboration was an obvious key part of the API workflow, and that we would need to add that capability to the product. But users were also using a variety of different tools to achieve their requirements," he adds.
The API tooling ecosystem was very fragmented. And that’s ironic because APIs are supposed to promote interplay and collaboration between tools and groups of people.
He says that was the inspiration to take the product into other areas like design, documentation, and monitoring. Looking into the future, the co-founders realised that there was potentially some value for the users in having a single platform where all of that could seamlessly take place.
This led Postman to be built into a single product that could handle all phases of the API lifecycle.
What worked, what didn't
Automation is one thing that helps a startup to scale. Postman has been fairly smart in automating the right things at the right time.
Once the team realised that a permanent decision had been taken, a number of operational processes, whether about managing infrastructure, customer support or even weekly meetings, were automated.
"That has led to a point where all our teams can focus on growth and not focus on doing things that a computer can do. And I think that has been a key factor in having a lean team ship out a big product," Abhijit explains.
Showcasing and providing the right value is the only key driver in long-term sustainable growth, and there is no hack around that. The team had to make sure that the analytics were strong. There was so much emphasis on it that the team had an analytics engine setup even before the first API was built.
From a product perspective, changing user habits is always hard especially for a product that has been around for seven years now. If a new user feature has to be introduced that breaks the flow, it is naturally going to cause a lot of problems to the entire user base.
Abhijit adds, "That is a lesson that we learned the hard way early on, where we realised you can’t just change something that’s going to break a lot of important workflows for our users. But with any product decision, we need to be aware of how that might change in the future."
Edited by Kanishk Singh
