Product Manager on a backend application

As microservices architecture is becoming a popular way to develop systems, the structure of these systems has evolved into a collection of small services, each with its own properties and characteristics. This approach allows teams to develop, deploy, and scale different components of an application (almost) independently and with greater ease.

Regarding the Product side, this kind of architecture reinforces the emergence of a significant number of backend applications and gives new challenges for Product teams to handle.

Understanding Data Flow and APIs

As a PM on a backend application, the first thing for me was to understand the data flow of the application I was working on. I had access to mermaid diagrams that explain the processes, to Kafka topics and the OpenAPI documentation to learn about the input and output format of the APIs, including expected types. I turned these elements into more visual schemas -for people who are not familiar with this syntax- that present the essential concepts in a visual and easy-to-digest way.
This step is important to be able to talk with other products that call or receive data from the app and to clearly understand who are the application’s users that are not the end users of the website, but rather other applications that consume the API.

The strategy must focus on problems (not the solution)

Once the data flow is mastered, the Product Manager will always need a deep functional understanding of the business to establish the product strategy so the product fits into the market, the main customer needs are met and the business goals are achieved.

To be more explicit, I’d like to take a concrete example of a user buying a product online. Different elements need to be taken into account to ensure that online payment is effective and that the user receives the paid products, with the chosen delivery method, within the mentioned deadlines.

The basic feature of a payment service is to allow users to pay online and to facilitate it by offering the most appropriate payment methods (credit card, gift card, BNPL -Buy Now Pay Later- for bigger baskets, etc.). To do so, the service must be connected to several others in order to manage shipping costs depending on the delivery method chosen, handle the response from the customer’s bank to ensure that the sale is validated, in the case of a basket with marketplace products ensure that the marketplace seller is paid for the sale made, deal with refunds when necessary, etc.

To enable online payment for a user, many services communicate with each other. Some contact end-users to offer them the best suited payment methods regarding the context (device, country, basket amount, etc.). Others handle communication with PSPs -Payment Service Providers- where responses must be managed and errors made explicit not to block payment, or even the turnover retribution to marketplace sellers. In order to carry the business the best way, online payment issues need to be tackled as efficiently as possible, and interactions between different services need to be seamless.
In the end, the frontend has to deal with the UI and UX to make online payment easier for final users.

This example shows the different problems that must be considered before to launch the online payment functionality.

Be talkative about the app, so people will understand it

As a Product Manager on a backend application, one of the key responsibilities is to ensure that all stakeholders have a clear understanding of the application’s purpose. An effective approach is to document the application on a corporate wiki, as it provides a centralized location for people to access and read the documentation. If technical documentation is mandatory for developers working on the service (and those who will work on it), I believe that the creation of comprehensive documents for non-technical people is also essential.

A service or an application can be described by using various formats (diagrams, videos, explanatory texts …). Since non-technical individuals may struggle to understand the features of a backend product it is necessary to present the information in a way that is easily accessible. Unlike frontend interfaces, updates and enhancements made to backend applications are not visually apparent.

Additionally, highlighting key performance indicators (KPIs) related to the application can be valuable. These may include metrics such as application availability, API response time, the number of users accessing the back-office, or the frequency of database requests. These KPIs are important when they are combined with business metrics that help to improve the product. For example, if the response time of the API is reduced when the payment is processed, what would be the impact on conversion rate? They also provide stakeholders a deeper understanding of the application’s performance and its impact on users and on the business.

How technical a PM has to be, working on a backend app?

Should a Product Manager know how to write code? This is a recurring question about how technical a PM is supposed to be.
In my opinion, a PM doesn’t need to be proficient in writing code. For a backend application, the product’s users are developers themselves so without being a developer theirself, a PM should have user empathy and have a basic knowledge of technical concepts such as HTTP and SQL. Having a technical culture helps the PM to talk to developers and understand their needs.

A PM with a technical background must be careful not to bias their point of view and lead to conflicts when the technical solution provided is not the one they would have chosen. There is a balance to find but eventually the PM needs to focus on developing a product vision, involving the team in the various stages of discovery and delivery, and facilitating collaboration between stakeholders.

There is a wide range of tools that can help the PM in their role; two of them that I like working with are Postman and MetaBase:

• Postman is a tool for testing APIs: it allows to send requests, validate expected data types, and ensure error handling is well-managed
• MetaBase is a tool for querying databases -with or without- using SQL queries: it provides a user-friendly interface for exploring and analyzing data

A back-office is an interesting tool for those with less technical knowledge. It offers an interface to access and query data without the need for direct SQL queries. Depending on individual needs, different levels of access can be granted, allowing authorized users to easily retrieve specific information without requiring extensive programming skills or direct access to the database.

Challenges

In a microservices architecture context, Product Managers have to ensure that the vision of each individual product really matches the overall vision of the application and to be aware that the time to market for each product can vary significantly based on dependencies with other internal applications and/or external services.

Being a PM on a backend application is probably not the first thing we think of when we talk about this job and it’s important to expect a frustrating side because new features are not always demonstrated in a visual way. There are no mockups or designs to show, no classic web analytics to track page views and conversion funnels, and no visual enhancements either.
Improvements are more about adding endpoints, connecting with other applications and services, or optimizing technical aspects. Also, answering the specific needs of other teams using the API will always be part of the game. It has to be taken into account into the roadmap that defines key features and enhancements in order to be more relevant to the market, or to become more agnostic regarding the currently implemented solutions.