I’m a non technical PM who recently started a new job only to find out there were no front end components.
I have worked with API’s before, but I’d work with a front end connecting to an API, so I could view/test/learn what information is being passed, how the data’s used downstream etc. But now my product is microservice service to microservice service. Without being able to read the code, I feel like a burden to my engineers, unable to field basic support questions.
I’m not sure how to excel in my role, without customers to interview or competitors to research how can I find new opportunities or add value to my product?
I do get requirements from other dev teams but they code changes and so I prioritize them in a project manager fashion, but I’m just not sure if that’s what’s expected for this kind of role. Id love to hear your thoughts.
The API is your user interface - you need to ensure you know the business goals / uses cases of your users, how the API is used (roughly), and what functionality they need.
The business goals and use cases are no different than “typical” PM work - meet with users and their stakeholders to ask them. Develop an understanding of their business.
To understand usage patterns, you have a few options. You can develop enough technical knowledge to intuit what API calls need to be made to satisfy the use cases you learn about. You can ask the users to literally walk you through their code structure (at a high level - you shouldn’t need to read this yourself). The info you want is usually what calls they are making, and how many times, to achieve their goals - and how information from one call pipes into the next. Your engineering team may also be able to help you here by building metrics and maybe even records of sessions? Depends on how exactly your system is built and what it logs, but I think that would be possible.
Lastly, approach new feature requests like you would any other product. What additional data do users need to accomplish their jobs? You might not be able to intuitively handle ease of use questions, but people aren’t going to reintegrate just because you made something easier to use anyway.
As a developer myself, I agree with you. But the problem here is that you can’t click around an API like you can in an app. THAT’s part of the problem OP is facing.
To add: documentation, example code, test environments where developers can experiment with the API, etc. could also be considered part of that user interface.
Also you might get inspiration from researching “developer experience”, which is UX applied to developer users.
- ask a developer to teach you how tp use Postman, basically a free tool to call APIs. You can type your inputs and see the result.
- learn the absolute minimum of being able to read code so you can call the APIs yourself. Really it shouldn’t be that complicated, at least for some base cases. All you need are basic templates that you modify yourself depending on your needs (change the parameters basically)
- ask your engineers to build you a basic frontend for the APIs.
Everything else you can still do as a PM. Interview users, ask for improvements, pain points, prioritization, bug reports, etc.
I have a dual profile PM/dev so let me know if I can help. Happy to jump on a call and see what can be done.
@Nathan, Thanks for your insight. That was really helpful.
Thanks for the input.
Thanks Donovan, really appreciate it.
@Donovan, Wait, why would you recommend a front end for a product that is backend (API) driven? Unless users want that functionality, this would be a waste of time. The goal is to ensure their customers can use the API. If the product is an API it means it’s developers who use it.
@Carlos, There are many ways to build a basic interface for an API. Automated tools exist that can do it in two clicks.
But even done manually, It’s just a few fields for inputs, a “Run” button, and a textbox to display the result. It’s a few hours of work for a developer.
On the other hand such a small thing might multiply OP’s impact in the team. If you can’t run basic queries on your main product your value to the dev team goes down dramatically.
Edit: such a tool could even be released to the clients as a troubleshooting/testing tool.
Who are your users? Is it just dev teams?
@AhmadBashir, Yeah that’s right, the only people to make changes or use my services directly are other developers.
And those developers will have their own services that that plug into a client facing front end.