Many years ago, I also had this question.
At that time, I was in an IOT company facing B end, and the company did customized business for the enterprise
SurviveEncourage employees and hold all shares. In order to make employees Find customers as soon as possibleRapid growth, but also the use of internal entrepreneurship, encourage employees to find their own business. As soon as two or three people meet and feel that they are in line, they can set up a project team, and then find customers and make plans. As you can see, this is guided by sales customization Outsourcing business. At one time, there are many solutions.
In order to support these solutions, the separation of front end and back end is not enough. Modularization and componentization are inevitable. But because it is
outsourceCustomized, so it is difficult to have a standard API. Most of the APIs are decided by the back-end, which is very confusing. API is not standardized, name and parameters are often changed at any time, mainly depends on the back-end mood. As a result, engineers in the hardware department complained.
Before I got involved in this, the company had just sent 2000 smart blood pressure meters to a customer. They sent data to the server through the API interface. However, one day, a back-end beat the brain and upgraded the API. Two parameters were changed into three parameters. Finally, the blood pressure meter data of the customer could not be transmitted to the server at all.
The back-end is still very unjust, saying that the notification of API update has been synchronized. Didn’t you (hardware) read it?
It is true that no one in the hardware department goes to see API update notices. They have no habit of logging in to OA. In addition, even if you log in to OA, the burned products have already been delivered, and there is no way to be compatible with the new API.
The back-end may not understand that it is normal to update the API in traditional Internet products, but in the hardware field, once the device is shipped, the API is basically unchanged for life (device life cycle). Of course, there is a life cycle for software API, and the API should not be stopped until the end of the life cycle.
API is a mess, I didn’t want to take over. But among all product managers, only I have technical background. Before I was a product manager, I worked as an engineer and developed the Internet of things system based on XMPP and mqtt. Without waiting for me to express my opinion, the boss of the company decided to let me take charge of all the affairs of API and make it into products.
This book is about how to manage API, how to design API, how to iterate API and so on.
But why say from entry to give up? Because API product managers are destined to be a minority. Compared with mass product managers, there are too many factors that are not conducive to themselves. They are equivalent to boiling dumplings in a teapot. Their achievements can’t be quantified. Their works can’t be viewed directly. They can’t brag like other product managers. And if you do well, the performance is back-end, even architect’s. Most API product managers can’t stick to it. If you stick to it, you will find that the field of API products is still very deep. API economy is a new economic form. It integrates open source economy and runs through services. Although there are a small number of them, if you do a good job, it will be very competitive, and the barrier phenomenon is obvious. Because first of all, it is a technical product manager, which surpasses most product managers. Secondly, it needs rich experience. Without a certain amount of time for polishing, it is not good for API products. Therefore, compared with product managers in other fields, it has a certain moat.
In the next article, I’ll talk about the use of API product managers.