Suppose a company is changing its procedures and are zeroing in additional on offering backend apparatuses and items for clients with the greater part of this approaching as APIs. Their experienced PM’s has daintily addressed, and APIs are yet not 100 percent exclusively dealing with that item. What are a few things they should know about and take care of before proceeding ahead?
11 Likes
More infra and less design in APIs. Changes to API along with versioning are unheard of in mobile app PMing. Lot of things we take for granted in mobiles, like scaling, availability, auth and tracing are important to consider for APIs. With a good engineering team, APIs will be fun. Otherwise it will be hell with fights and miscommunications all the time.
10 Likes
This “otherwise” scenario is spot on to my situation… lots of arguments in meetings with engineering’s lately (not from me but I’m participating in the meeting)
I guess the project is getting to a quite a stressful place with low resources, time, and squeezing them.
10 Likes
Some problems aren’t yours to fix. Focus on improving your life and situation, perhaps by looking elsewhere
8 Likes
Understanding the chain and how the end user is expected to sequence. Knowing the difference between the types of requests and when/how they are used. Security/authorization are pretty big ones. The tougher part is forecasting request volume, how you queue or scale resources to handle the requests, negative scenarios and how to inform the end user. A lot of it is verbiage when writing stories or having design discussions but it’s definitely fun in its own way. Get comfortable with Postman or a similar app.
From a PM pov, understanding how to define the response and what is the appropriate level of detail in each response for the API(s). As a product, an API is retrieving sips of data, not necessarily chugging. They can definitely become logic puzzles to extract the most key information in the most efficient manner possible.
8 Likes
In your case, simply put, the API is the product; vs the app.
Try to answer those questions
- who are the users?
- what are their jobs to be done?
- why do they need us? … I guess more fundamental PM questions
You should see right off that expectation is vastly different.
API is more specific product and as it is for developers, you need to understand developer and technical detail very well, much easier if you are/were developer
7 Likes
They can definitely become logic puzzles to extract the most key information in the most efficient manner possible.
That actually sounds like fun to me
7 Likes
It is going to be tough. I have seen people who have done both and the subject matter and how you manage it was not as translatable as one expected it to be.
He went from mobile with a few stops along the way to APIs. Found out he is just more of a front end PM.
6 Likes
Why would someone prefer API over user facing? And vice versa?
5 Likes
APIs force you to think about the value chain of your product a few levels further down than user facing - it’s bit of a game of “transitive value-transfer” and there are often a magnitude of order more of potential use cases with APIs than user-facing solutions.
For example, a friend worked at a healthcare company where she owned both a user facing flow of “help user x easily purchase supplies for y procedures” and a backend API strategy (she does not necessarily recommend doing both, but that’s a different discussion).
As part of that they had to build sets of APIs to interface with external supplier companies. if she was thinking about user value for the front end, she would connect what problem was she solving for the user, and how well did her solution solve that problem.
Thinking about the API, she had to work with her engineering team and end users (developers + their buyer personas e.g. partnership managers) to understand what are all the potential “components” of this workflow and how could they extend those components to different use cases. What were the use cases that had the highest value and priority to customers, and how could they generalize endpoints to allow users to meet their needs, either with the same endpoint, or slightly different skinned endpoints by persona? they then had to think about the performance and what were the underlying systems or services that were connected to our external APIs, and how they orchestrated/invested in those systems to ensure scalability.
Personally, I love API products. There is a bit of a higher technical bar, more technical stakeholders and customers that you’ll work with, and more analytic/technical tooling to monitor the health of your product. However, “front-end” or “full-stack” PMs sometimes get more glory in orgs where there are “back-end” or API PMs.
4 Likes
I was recently writing draft on API product management. But here are key things that may help you to get started on the concept & shift thinking toward API :
If you want to dive deeper into API products & build API product teams, check out this book published by apigee.
Key Insights from The API Product Mindset Book:
API Product Mindset :
APIs are the mechanism that software use to talk or connect with other software.
Internal & external developers are the main customers of API products.
It has the potential to unlock new opportunities or verticals to drive business growth.
Stripe is a great example of how the API first approach has helped to build great payment integrations & software solutions.
B2B & B2C customers use Stripe to support payment in their application.
No need to:
- Build Own payment integration
- Deal with the complexity of building, maintaining & supporting different payments
Value Proposition : - Reduces Go To Market time of internal/external teams significantly.
- Increases productivity of internal & external developers.
- Allows product teams to experiment at lightning speed.
- Positive developer experience
- Enables companies to create an ecosystem.
Tip for Stakeholder Alignment :
Connecting the API consumption & usage insights to Customer Satisfaction, Customer Growth & Revenue is the main key to get buy-in from Stakeholders & organization functions like finance, sales, marketing, legal.
Main Steps involved in building APIs as Products:
- Building a minimum viable product: design, develop, secure
- Curating a world-class developer experience: publish, evangelize, scale, monitor
- Championing the business value: establish KPIs, iterate, monetize
Principles of API Design as a Product :
Non-Technical :
Intuitive to developers, Extensible, Well documented, Derive insights from API usage, Understand how customers are using these APIs
Technical :
Service-level agreements, Caching, Performance, Scalability, Access Control, Security, Rate Limiting
3 Likes
In my personal opinion, API PM should be more focused on how to enable developers to achieve their business goals than worry about the API design, scaling, documentation, SLAs, Auth, etc. These are best suited for developers, DevOps, and technical writers to own. In addition, API PM should work with security stakeholders to ensure the API goes through a rigorous process to ensure only people with the right ACL can view the data.
Developer business goals can be internal such as outsourcing devops (AWS, google cloud) or external such as safely accepting payments from customers of the developer (e.g. stripe).
2 Likes
It seems pretty different to be honest. With an API, your customers are developers, and with an app, your customers are consumers. I would imagine that the way you market and sell them would be very different. Like the difference between B2B and B2C.
1 Like
I wouldn’t say it’s overly different. Our endpoints are the majority of our products. Lots of integration work and interdependencies on multiple teams which requires lots of coordination and at times handholding.
It’s good to work backwards and still gain an understanding of ‘why’ the end experience is how it is to facilitate the correct data in the correct manner.
Do not get me started on mismatching picklists and translating data though. I am a firm believer we should simply proxy data.
Design isn’t key here, important to know how the data will be used to make sure you expose the right information, but deciding in design will primarily be out of your hands.
Testing will be very important as you don’t want to break anything already existing.
Any changes will need to be well communicated so the number of support issues are at a minimum when you toll out the changes.
Database architecture will be key here. Lean on you tech lead to learn but it should fall on your tech to outline that.
Always try to think a few steps ahead of the request. How can this request grow? What will they need after this? How can this be built for expandability?
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.