From time to time I see folks tweet how they are frustrated with Postman not doing exactly what they want in a particular area of the API lifecycle, letting us know they are moving on to greener pastures. The most common framing for these emotional tweet bursts usually centers around Postman catering to the enterprise and is forgetting our roots when it comes to being their specific reason hey adopted Postman. From my vantage point there are a number of ACTUAL reasons behind why Postman users invoke in these Tweet storms, with “selling to the enterprise” being actually pretty low on the list regarding why they find themselves in the position they are in—let me see if I can break down how I see this recurring theme.
Selling to the Enterprise
In response to Postman selling to the enterprise—yes we are. We are selling to the enterprise because we are, well….a business, and a venture backed business. The majority of our “developers”, “customer”, and “users” operate within the enterprise, so we are listening to what they need and providing a platform for them to be more successful. Sure, we are motivated by revenue, but this doesn’t mean we aren’t motivated by feedback from our users as well. Selling to the enterprise is a reality for any startup who is building software, and it really shouldn’t be a surprise to anyone, or really be much of a talking point when it comes to critique of any API service provider. I would ask a few things of anyone taking this position.
- Who do you sell to? - Do you plan on not selling to the enterprise as part of the business you are building, and tif you do, are you going to weight responses from developers who are not affiliated with an enterprise organization, over those who are?
- Always have a Plan B, C, and D - You should plan that EVERY platform you depend on will eventually head in a different direction, shut down, or generally stop meeting your needs, and have alternate suppliers available, this is business 101.
- Enterprise Complexity - Saying a platform has grown too complex for you means it may have, but it also might mean that maybe you aren’t aware of how a platform works, as well as maybe be out of alignment with the larger community a platform services.
There is a little bit of truth to the statement about Postman selling to the enterprise. But there is whole lot omitted when someone tweets about this on Twitter. I would invite anyone using the “Postman is selling to the enterprise” to come argue why we shouldn’t to our board and investors. It really isn’t a defensible position in any form. I get it. I am a developer, and I am not always in agreement with enterprise way of doing things, but I am also not in denial about how the startup world works. I have had lots of frustrations with Postman capabilities over the years, alongside other platforms I use like Github, JIRA, and others I depend, but I never complain broadly about “selling to the enterprise”, cause I know doing so demonstrates I haven’t done my homework, and my positioning is more emotional than reality.
API Feedback Loop
The next dimension of this conversation I see play out over and over is that 98% of the people I see taking these positions have not taken time to utilize any of the feedback loops that are in place to help steer the Postman rocket forward. I would say that there are five distinct layers of feedback loops in place, and while people who participate within these layers do not always get exactly what they want, I find they are much less likely to emotionally claim on Twitter that Postman is leaving them behind because they are part of the conversation, and they understand more about what is actually going on when it comes to the Postman platform, but also their own API lifecycle.
- Postman Github Issues - If you are staking out your position on the Postman road map with getting acquainted with the existing questions made via Github issues, voting them up, and submitting your own feedback, then I can guarantee you will feel left behind. I am regularly impressed to see how Postman product managers do their research via our Github issues before they take to building new features.
- Postman Community - There are a wealth of conversations occurring via the Postman community forum, and you can learn from other folks who are putting Postman platform features to use in interesting ways, and are totally willing to share their tactics with you. Always engage within our community before heading over to submit a GitHub issue, cause you never know what you will learn.
- Postman Customers - We have an entire team dedicated to conducting conversations with our customers, gathering their feedback, and then making it available for product managers to use when it comes to steering the road map. Sure, many of these customers are enterprise customers, but many of them are business and team users as well. Are you a customer? Are you providing feedback?
- User Experience - Our user experience team is eager for Postman users to participate in surveys and other feedback session to help make the overall user experience of Postman meet the needs of a wider audience. I know there are general as well as specific persona based discussions going on, and I know that your feedback as part of this process would be very welcomed.
- Ambassador - One place to learn a lot about the Postman platform, as well as the wider API lifecycle is as part of Postman developer relations and the community as an ambassador. I’ve spent a lot of time at this frontline between what Postman does and what people want it to do, and you learn A LOT about what Postman does that you didn’t know about, and you learn a lot of new ways in which Postman is applied that you never would have imagined—I highly recommend spending time at the frontlines.
To the uninitiated Postman looks like this massively funded closed startup moving forward at lightning speed. I know. I spent years on the outside. Once I joined the team I learned so much about how the product actually works, how it is used in the trenches of API operations, as well as how the product teams are gathering feedback from users and incorporating that into a coherent product that is moving forward at a very fast pace, while still serving millions of users simultaneously. This is something that is true for any API provider or service provider—if you aren’t actively part of any of the existing feedback loop your outbursts on Twitter are only just that, and you indeed are likely getting left behind, but you run the risk of not just being left behind by Postman, but also the wider API community.
API Platforms and Lifecycles
Another dimension I see folks struggling is that they do not have a clear view and understanding of the API lifecycle. Often times when someone is upset about a specific Postman capability they aren’t seeing how it fits into the overall platform or lifecycle vision. It is common for Postman users to be operating within a silo and using the product for a single, or maybe a couple of stops along a lifecycle. Then when those capabilities evolve on their own, or in concert with other capabilities, people feel like Postman is leaving them behind. When in reality there are other lifecycle evolutions within the wider API sector happening that may not be understood, as well as additional platform benefits emerging that you can’t see or won’t be able to take advantage of because of your API world view. Here are some the common ways I see folks stumbling.
- Specifications - Most folks I see complain about being left behind don’t see the difference between documentation and the specification behind the documentation, let alone how it impacts the rest of the lifecycle. They don’t get the difference between Swagger and OpenAPI, and many other little nuances that you just see as Postman complexity, but ultimately are being sorted out in the wider API community.
- Lifecycle - Folks just aren’t seeing the entire API lifecycle, and they focus on the most tangible aspects of the lifecycle like API documentation or code. Missing out on the lifecycle benefits, which they just dismiss as complexity.
- Platform - For those who are just embarking on their wider API lifecycle journey they don’t fully see the benefits of an API platform, which is a newer concept to make sense of. They don’t understand that Postman relies on OpenAPI to bridge the existing software development lifecycle via Git, and it is up to you to decide how much of the platform you are ready for, allowing you to use workspace, but not documentation, or testing, but not mocking. When you begin to see the platform you begin to have more control over when you are stuck at one stop along the API lifecycle you simply see Postman as a documentation or testing tool.
- Isolation - Ultimately isolation is the biggest illness I see amongst existing Postman users. They use Postman all by themselves and do not collaborate, sync, coordinate, orchestrate, and choreograph API options across large teams and organizations. When operating in isolation you always run the risk of behind left behind, and it won’t be just Postman that does this to you.
I have spent the last decade paying attention to the big picture of APIs. I still struggle to see the big picture. I also regularly lose touch with what is actually happening on the ground floor of API operations. There is no right way or wrong way here, but it is very common to blame complexity on your API service provider(s) when you don’t have a clear definition of what the API lifecycle is and isn’t, and how the API service providers and tooling you’ve adopted fit into that. API services and tooling are individual building blocks that can and should be plugged in across various stops along the API lifecycle. An API platform is where you do this in a scalable, reliable, interoperable, and orchestrateable way—it is common for folks to see the entirety of Postman as a single stop along the API lifecycle, rendering many of the other lifecycle capabilities simply as complexity, or for someone else. Relaying on the UI and published documentations, which are the more tangible outputs as what is possible rather than embracing the API way doing things.
Embracing the API Way
Beyond not playing an active role within the API feedback loop, and understanding the role that API specifications play across the API lifecycle, and when it comes to building on an API platform, most Postman users who get stuck at one stop of the API lifecycle like docs or testing, haven’t fully embraced the API way of life, and are just using them in tactical ways, void of any API strategy or belief system. There are a handful of fundamental aspects of APIs you need to grasp become you find little more zen when it comes not just building APIs, but also consuming APIs—here are a few things I notice in these moments:
- Postman API - These folks aren’t using the Postman API. Realizing that the API specifications, workspaces, environments, monitors, and other API platform building blocks all have APIs that can be used to automate, orchestrate, and execute beyond what the Postman UI enables natively.
- Command Line - You can run Postman Newman at the command line, further shifting the conversation for how you put the Postman platform to work, weaving Postman collections in with other aspects of your API development toolbox.
- CI/CD Pipelines - You can execute the collections you have defined for any instance of your APIs, 3rd party APIs you use, or the infrastructure behind your API Operations at the pipeline layer of your operations using Postman Newman.
- Workspaces - It is interesting to watch folks step away from Postman due to documentation not being configurable enough, which is just one part of a longer list of consideration, never having considered the value of documentation in public workspace that is immediately searchable by 13 million developers—never considering how documentation changes in a workspace, letting the opportunity pass them by.
- Network - Being able to flick the switch on the workspace which contains APIs, documentation, environments, mock servers, tests, and other capabilities either natively or piped in via the APIs of other services and open source tooling for a team, or publicly to a community is one aspect of the Postman platform that can be hard to see when focused on a single stop along the API lifecycle.
- Open Source - The open source tooling that influences the Postman road map is another blind spot for many folks who get stuck at a single stop along the API lifecycle when using Postman. Beginning with Postman open source converters, url parsers, Neman, and other core open source tooling. But then things from the community that do things our road map hasn’t caught up with like generating an Open API definition from a collection, generating custom documentation from OpenAPI or collection, or any of the numerous other ways the open source community is augmenting the Postman platform.
If the Postman web or desktop doesn’t do what you want it to do currently, and you opt to leave before using the API, CLI, or open source solutions that argument the platform, I am pretty sure you haven’t been struck by holy API spirit yet, and aren’t using APIs to their full potential. I regularly get frustrated by the Postman UI. But you know what, I understand that I am one person, who happens to work at Postman and have influence on the road map, but also realize that there are many other ways in which I can leverage the Postman platform to get done what I need done. The most common thing I see with folks who get stuck is they are just using Postman for a single dimension of API, and not including the Postman API in their approach, let alone using Postman to leverage the APIs for the infrastructure they are using behind their API operations.
Postman is Selling to the Enterprise and Working to Meet the Needs of Over 13 Million Developers
I understand that it can be difficult to see the full scope of the API universe. I don’t expect folks to be able to see it. I also don’t expect that I am going to fully understand what it is like to “do APIs” on the ground within your organization or industry. I also am not in denial that Postman struggles with delivering a user interface and user experience that meets the needs of all 13 million users—it just ain’t an easy thing to do. However, I do get to write lengthy responses to the quick, emotional, and broad sweeping claims about Postman not caring about its developers. It is something that is difficult to not take personally, and at this stage of my career I know better than engaging with folks on Twitter about these things—especially as a Postman employee. However, I do find it valuable to think through my responses to these allegations, and work through how I see things, so that next time I do find myself in a conversation with someone, I can dive in with more clarity and coherence.
Ultimately, it isn’t easy to operate a platform. Let alone a platform that is the underlying plumbing for platforms across almost every business sector. We aren’t going to be able to make everyone happy. I am fine with this. However, I am in the business of understanding the overall API lifecycle, and helping folks develop more awareness of the big picture. This is all journey that we are ultimately at different places on, and it is my job to quickly iterate through many different possible journeys regularly on my own, while also joining customers and partners in their own journeys. Throughout this process I learn from what I am seeing, while also sharing previous learnings and experiences with whoever I encounter. So whenever I encounter folks stuck at a specific stop along the way, banging their head on one specific areas of a much longer journey, I feel compelled to share what I know in the most constructive way possible. So, publishing it here on API Evangelist as opposed to engaging on Twitter has become the healthiest way for me to do this, which also has the widest impact possible within this ever expanding API universe we find ourselves in.
