Related Posts
Conversation Starter
Anonymous User
Need 11 likes pls
Additional Posts in Product Management
Coach
How hands-on are you in scrum meetings?
New to Fishbowl?
Download the Fishbowl app to
unlock all discussions on Fishbowl.
unlock all discussions on Fishbowl.
Heavy question - here’s some quick points.
API PM is a little different bc you have to work backwards from what the end customer needs and then make it easy for the developer to extract that value from your service (to solve for said end customer need).
Requires more system level understanding of your tech landscape. You must be far more conversant in how data flows (or doesn’t) between your systems. These are the ingredients your API is going to utilize to expose the discrete functionality you offer.
The roadmap and features of your API product(s) will be heavily dependent on the system and process level APIs being in place. (e.g. if you manage an ‘Order Location’ API Product, the success would be dependent on smaller API calls to the customer DB, inventory systems, and ultimately the shipping service.)
There are just more puzzle pieces - but it’s fruitful if you have patience.
Are you referring to API Middleware products like MuleSoft or Dell Boomi? If yes, each product is unique in its offerings and so you should know their architecture, product roadmap and gaps prior to interacting with client
I've only been a PM for a year and a half, but almost exclusively on APIs. I think having a strong technical aptitude is more important than for managing something with a GUI. Customers that care about your API are always gong to be technical types, so you have to be able to hang with them in conversations. The metrics and how you have to collect them are also very different.
CB1 - For API requirements, I have to take into account the needs of the UI as well as the needs of the customers that access the API directly, so the UI PM also has a lot of influence over what we build in the API. It can be difficult at times getting engineering resources to build API features that don't benefit the UI, even if it's important to API users. If actually be interested to hear from other API PMs how they handle that tension in their companies.
PM - I do track MAU, both overall and of specific endpoints. Another important metric for me is the number of customers accessing the API from each integration. I'm also responsible for getting integrations built (either internally or by partners) and knowing which ones are the most used and by which customers is important for prioritizing that work.
Ditto the above comment. Your customers are developers, so it's important to understand what is important to developers. Understanding what the characteristics of a good APi look like, API documentation, etc. The design of an API is just as important as design of a front end application, so it's important to know enough to have an opinion on it.
Coach
I'd also argue that you need to be well versed in how to scale data models that support changes to API elements. Focusing your team on emergent architecture, over preplanned. It's critical they don't box themselves in on how the architecture will support the API.