Frontend/Backend Product, a hard one to call
By Andreia Proença
Back in time, the first products appeared as an extension of the human body. They were mainly used to guarantee human survival — stones adapted to kill animals, animal leather to warm human bodies, etc. As the social hierarchy of needs went up, the product complexity evolved into the most sophisticated (digital) products to help society to strive and thrive by answering complex problems and needs.
Product manager (PM) jobs arose to maximize the happiness of the different product users (direct or indirect). This happiness is not linked with the end goal or result of the product itself but relates to an inner satisfaction felt by the user when an action/intention is accomplished (there is indeed dopamine release). A product aims to speed that accomplishment without friction; in turn, it aims to speed up happiness. That is the PM goal, either for a physical or a digital product.
Let’s follow a water bottle example throughout the article to make a parallel with the digital product specificity: a bottle of water is ergonomic, it has a stopper to handle the water and keep the product intact: it fits the users’ need for water drinking and transportation perfectly.
Deeping into digital products, there are two perspectives of any functionality: the back end and the front end. The back end is backstage, where the foundations are set first to be shown later. The front end is the stage, where the features serve the final user.
Using the water bottle example, the back end will be the raw glass, and the front end would be the bottle itself.
Despite the common purpose, there are some relevant differences that you, as a PM, will face working and evolving each of the product types: product users, product development agents (product designers, managers, and engineering ), PM work methodologies, and product optimization. Let’s dive deep into each one of those!
Let’s start with the Product user
On the front end (FE) side, your users are the actual users of the product. You have a privileged and direct view of the product usage: you can test and feel if it provokes the intended happiness.
Working with back-end (BE) products, you will have the same final users, but your direct users will be the ones serving those final users — FE products. So as in a water bottle, the raw glass (BE) has two types of users: direct — the bottle makers — and indirect — the final drinkers.
Regarding the analysis and the approach to users’ needs, there is also a significant difference: a BE product is designed in a way to be scalable and so, in most cases, to be used by several FE interfaces.
Here lies the complexity: if you have multiple interfaces, you‘ll have different end users with different related needs; this should influence the way you build a BE product — a sweet point between being as transversal and agnostic as possible (satisfying all FE MVP needs) but support FE evolution on its specificities whenever possible (when it’s not clear but you see some potential of feature scalability or adaptability).
Back to the water bottle example, if you are a BE PM, you must think your product, the glass, would be used for juice bottles, wine or milk, and so it must have the common requirements of those: the capacity to preserve liquids, to be malleable to different formats. However, you should include the capacity to adapt to each bottle’s specificities whenever possible: changing opacity, capacity to handle different labeling, storing liquids in a hot or cold environment, etc.
(Though this is the most common scenario, it is not mandatory that BE has a FE to fulfill final user needs. An example: the final user requests the need through service tickets, and the support team uses the product only by its endpoints (as a proof of concept). The complexity of users would be naturally small in those cases once you are cutting the middle users — FE).
Let’s now focus on the development agents, namely the Product design work
PD and PM form a valuable team, and this joint effort is critical in several phases of the design thinking process, either on FE or BE. Though we have distinctive differences between them, the Product Manager defines product viability (go/ no go), cares about product adoption (stakeholders /users’ expectations), and closely follows all the development process (w/engineering team), Product design(PD) works aesthetics and closes the solution (FE products) but most important and transversal to both product types, PD focus on product usability:
- Empowers user research, the “why” questions and its results seen through different perspectives enable an empathic product development journey targeted to user needs.
- Critical capacity to match the needs with the functionality (to be) developed.
The way a PM works with the Engineering team is quite different depending on the product type. Engineering team members are the ones responsible for deciding the feasibility and solution. BE, and FE teams must have the same starting point: business need, context, and expected outcome translated into use cases.
Though, it is important to put things visually: BE may use diagram flows — at the maximum maturity level, are translated into API’s flow; FE may use wireframes — in the maximum maturity level, would be high fidelity designs.
The tendency to dive deep into the technical scope can happen in both team types: stories created without value in themselves but as technical tasks to build a greater deliverable (who never?) can mess up each one’s responsibilities and roles.
It is important to try to counteract this tendency, not only by focusing the agents on their value: PM on the viability, the engineering team on the feasibility; but as it is a key factor for team motivation: everyone that adds value to the product, in a wide range of skills, should apply their knowledge and creativity as part of the end result.
Picking the water bottle example again, if it is made by assembly, using molds or glue, it’s up to the masters of production as long as the requirements are met.
Focus now on PM work methodologies, it is tightly related to the product visibility characteristics.
While building a product, on FE you can see how the product looks for the user and check and test what is missing and if it matches what was projected.
On the BE, you have a product you can’t see immediately! Endpoints and events are what your BE product can offer to your direct users, and so it’s testing those that you’ll know if it behaves as expected.
Coming to the bottle example, if there is a requirement for bottle glass (BE) to support xºC of temperature, it would be something you could confirm visually by testing the material.
This extra final validation (powered by the team’s QA) in stories’ acceptance criteria or end-to-end feature tests is important to remove risks of miscommunication, misinterpretations, or any missing details, and it will help you to see and cement the functionality developed.
While assessing and following product adoption, FE can receive direct user feedback while BE can have a challenge: BE is further the root need and may not receive 1st hand final user feedback.
To tackle this challenge is very important to:
- guarantee a solid and recurrent collaboration between FE and BE PMs and set expectations on each side (ways of working);
- measuring the health and usage of the product: error rate, problems, adoption, performance/load.
Regarding product optimization, the longest life period of a product, the agility of a roadmapcan also be distinct.
For the same functionality, BE developments are often more lengthy than front-end ones. Why is that? It often involves different micro-services and APIs, the core/logic development, and all the other BE product dependencies (that are minor in FE).
So normally, BE implies a more rigid roadmap and so, embracing new ideas or developments not planned is tougher. This can have a direct impact on how you manage stakeholders, either on their frustrations by not having the need answered right away or to explain the reason why that can’t happen.
Making an analogy with the bottle example: changing the material for all the bottles is quite different and demands an extra alignment with all the bottle makers than just changing the shape or adding another logo in the water bottle doesn’t require. To tackle this expected characteristic, it is important to question the need and not assume a given solution, think of a wide range and out-of-the-box alternative solutions, and have an MVP mindset.
Each product type has its smooth points and challenges, and each product manager can assess which makes the best fit with his/her characteristics and motivations. Once the back end is more dependent on other co-BE products and it can lack direct user context, it is the heart of all the logic and allowed behaviors; on the other side, the front end is more intuitive and with immediate user contact; but lacks the freedom to set and build new functionalities from scratch.
One cannot live without the other, but both certainly induce happiness!
Originally published at https://www.farfetchtechblog.com on June 27th, 2023.
