Postman API: What Product Managers Need To Understand
Software Product Managers drive products to provide business value. Relating solely to the business and functional requirements- and neglecting to understand the technology behind the product- will cripple the Product Manager instead of empowering her. If your software product uses APIs (it’s rare not to), then it is likely that your developers use Postman API. (If you’re not quite sure what an API is — try this explanation, or many other good ones).
There are concrete benefits for Product Managers to use POSTMAN too. First, let’s challenge that- shouldn’t that stuff be the responsibility of developers, and not folks on the business side? Isn’t it too detailed for Product Managers? A waste of precious time?
I argue — No, no, no and no. You do need to use it.
After overcoming initial hesitation, I’ve found it useful to add to my arsenal of tools. The barriers of entry are lower than I expected, and there are multiple benefits — communication with developers, engagement in demos and enhanced understanding of your product.
Note: I have no affiliation or vested interest with the Postman API company or product.
What is Postman API?
It’s a product & service, self described as ‘an API Platform for building and using APIs’.
Basically, it’s a tool to be able to ‘play with’ your APIs. Say you have a software product that’s a website that stores images. The end-user selects an image from her computer and adds a name, then uploads to the website. You most likely have a microservice that enables a few methods: POST (to create), GET (to view the list of images+names), and DELETE (to delete each entry).
Since you are an avid agile ninja, you break down your requirements to deliver value as early as possible. First, you ask for creation and viewing, and offer deletion only at a later stage. Even later, you can offer to edit the name or image.
When your developers create a microservice (or mockup), they can give you access to it via a postman collection. You will need access to a target environment + credentials. Then, you can use the POSTMAN API interface to see what methods are available in the collection. In the first phase of development, you will see ‘POST’ and ‘GET’ methods. You can use this to create entries (images+name), and see that it works. After creating at least one entry (image+name), you can use the ‘GET’ method to list each of the entries that you created. All this, is before there is any front-end development; before there is a screen or buttons that have been developed.
Why use it?
Understand your product
In a product that involves front-end and back-end, delving into postman gave me a more holistic understanding. I could better appreciate the mapping from API to UI. This helps me become a better product manager in terms of breaking down the product into phases, writing clearer requirements, planning the scope of releases, and more. It helps me understand better how to design the front-end, also.
Ensure what you expected is being built
This is a way to detect miscommunications earlier rather than later. For example, you may have wanted to support the creation of images without names. Maybe you even wrote clear requirements for that. However, this was overlooked in development. When you ‘play with’ POSTMAN, you can try to create a image without a name. The postman product makes this kind of thing easy — to add change or remove parameters in the request. And when you do so, you may see that the creation failed. You can ask your developer why, and clear this up earlier rather than later. The developer will tell you that, indeed, she introduced validation for name as a required field, because that was not clear enough from your written requirement.
Understanding edge cases
Using postman helped me better understand when the product was actually built in a way that would support my business requirements, and when we may run into some issues; what use cases would be supported, and edge cases that would not be supported. Understanding this made be better able to communicate this to relevant stakeholders — developers, technical documentation writers, and more.
Write clearer requirements next time, including acceptance criteria
By actually playing with APIs of my product, I could later write more detailed and accurate requirements for more advanced features of the product. This includes better writing detailed acceptance tests, and use cases that I need to be demonstrated in subsequent features.
Contribution to demos
For products/features that are fully Back-end with no front-end, it is very hard to ‘demo’ the completion of the feature. It is standard practice, then, to use POSTMAN to provide a live demo that the required functionality has been developed. Before I began using POSTMAN, I admittedly had a hard time following these demos. Since I began to use POSTMAN myself, I was able to follow much better, and even contribute to the demos. Once, for instance, I noticed that a particular parameter was wrong. There were some tricky use cases, and developer presenting, along with tech lead and others, were a bit stuck. Since I defined the feature and knew it well, and since I knew how to use POSTMAN, I was able to point out what parameter needed to be changed in order to obtain the desired outcome in the demo, and demonstrate that the use case was indeed supported.
Thanks for reading!
About the author
I’m a UX Designer turned Product Manager, with experience in startups, freelance, and agile B2B2C companies. Writing helps me reflect & continuously learn. Connect with me on Twitter.
