 Hello, everyone. Thank you for coming to this presentation where I'm going to try to answer the following question. Do backends need product managers? Let me introduce myself quickly. My name is Justyna Walkowska. I live in Poznan, Poland. I work as a director of product management at Cyber Source, which is a visa company. I have more than 15 years of experience working in IT and more than five in a pure product role. I have a PhD in computer science, natural language processing, to be exact. And before getting into product management, I've worked in academia, R&D, and also in the regular engineering department. So far in my career, I have managed products, product managers, engineers, and linguists. And as we know that PMs often have to juggle many hats, I find this array of experiences quite useful in my daily work. In the slide, I have enumerated some of my most famous employees here. But it's important for me to say that I'm going to be speaking about the entirety of my experience working with backend teams and not necessarily about the details of what I'm doing with my current employer. Okay. So this is today's subject. Do backends need product managers? Notice that I'm saying backends and not backend teams. And this is intentional. You probably know from many sources, including cram.org, that what needs a product manager is the product itself. It is, of course, beneficial for a team to have access to the product person. We often talk about the triad, which is the PM, the tech lead and the designer, if the designer is there because of course with backend products, it's not always necessary. So these are the people who lead the engineering team and the PM is in that group. But it's important to say that the PM really manages a product and may work from zero to n teams while doing that. I will say backend team quite a few times in this presentation, but philosophically, I think it's important to call out that it's the backend and not the backend team that I'm discussing here. Okay. So do they do backend teams need product managers? Of course, I think they do. Of course, I wouldn't be doing this presentation if I thought otherwise. A backend or an infrastructure team is either indivisible. And this is when things are going well, or everyone is mad at them when things go all right. And suddenly the team is just ignoring all future requests because they have to be putting down fires. The reality of these teams is usually quite harsh. They often have many competing sources of requests and are often putting off bigger initiatives indefinitely because there's always something coming up. So I want to spend a moment discussing the sources of requests that end up in backend teams, backend products backlogs. So the first source of these requests are the logs. I want to share a story. So I have been in a situation where someone, an engineer created a useful automation which filed a Gira ticket every time there was a stack trace in the logs. It did count the occurrences of these stack traces. So if this was the exact same thing, this would not lead to the creation of a Gira ticket. But the outcome of that was that when I joined that team, they had 3000 open tickets created by that tool and they were convinced that there will come a day where they close them all. Then we have customers or customer support teams, community support teams, especially in situations where the customer and the client is not the same entity. This is a high priority source because they raise issues that affect the actual end user. However, especially at scale, they need to be checked. In other words, the reports coming from this group and the requirements need to be verified. Customer support team members often channel the needs of a specific group like one client or a segment of users, for instance, power users. And this group and the requests coming from this group may not be representative of the general population. And sometimes, actually, they are in direct conflict with the interest of a larger group of users. The balance here and this approach has to be adjusted, of course, depending on whether you are dealing with an off-the-shelf, large-scale product or a bespoke solution with just a few users. Then we have front-end teams. And I will mention the subject of mission teams a little later in this presentation. But focusing on the front-end-back-end scenario, front-end teams develop new features and often need back-end or infrastructure support to complete them. This sort of cooperation is not uncommon, but it leads to a situation which is often not normal for back-end teams, and this means actual deadlines. Care should be taken to discuss these requirements in advance, also because sometimes a minor front-end change can lead to an explosion in the back-end. And an example of that might be the inflexible no-SQL databases where, for instance, where the front-end wants to be able to search by a new feature, it may turn out that the entire database schema has to be changed. Then another source of requirements and ideas for a back-end team comes from inside. It's important for the PM to have a good relationship with engineers and to trust them. I'm not talking about blind trust. Over-engineering is an actual issue, but ambitious and well-read engineers often can detect upcoming issues before they happen, or they can suggest new technologies that will significantly cut costs or improve the performance of the system. These people need a space or a platform to speak up. At the same time, most PMs, of course, have faced the challenge of never-ending refactoring, so it's an important skill to be able to recognize which fixes proposed by the team are necessary, and we will come back to this in a way while discussing objectives and metrics for back-end teams, which will come a little later in this presentation. Then we have production crushes. Of course, something like that happens, the back-end team, probably all teams in the company have to just drop everything and contribute. Then we have compliance, like GDPR, GDPR or ADA. ADA is, of course, more front-end-related, or any official regulations in your domain. They can sometimes appear unexpectedly when a standard changes, and this actually was the case with GDPR for many companies and the interpretations of it. Then last but not least, another source of requests and requirements for back-end teams and back-end products are the company objectives, which should radiate down to every team in the company. I'm going to show a separate slide showing some business objectives that can affect back-end teams. I want to show you a diagram now. This is something I built in Excel using data obtained from JIRA. The red line here shows the consumption of story points in the initiative product, actually, that the team was supposed to be focusing on. The yellow line shows the total consumption of story points, so the space between the red and yellow lines represents the distractions. The work that the team had to do or ended up doing that was not related to the main product work they were focusing on. The blue line is the number of points to complete the goal. It's also growing together with the understanding of the problem by the team. To analyze this for a moment, a conclusion you can draw is that if the team had only worked on their roadmap items, they would have completed by a week, I think these are weeks at the bottom, 30. When with the current story point consumption rate, the prognosis is week 50 if nothing gets added. I want to share this twist to this. I want to say this is what happened after a product manager joined that team because the statistics before that were far worse. I want to spend a moment discussing the client. Who's the client for a backend or for a backend team? Some sources will argue that the client, the ultimate stakeholder, is always the real paying client or the end user. Again, these may be two different entities anyway. I understand this approach. It's similar to that parable about the NASA employee who sweeps floors for a living, but asked about what they do, explains that they contribute to sending people to the moon. This is a valid perspective, but it's not always a practical one. I believe it's important, crucial even, to know and remember the ultimate goal to which you are contributing, but in everyday life, you need to focus on the people and stakeholders closer to you. In a way, to refer back to the slide about sources of requirements, these are the clients and stakeholders of the backend team. As I said, the actual client, we have the end users and teams which represent them. Internally, we have sales, marketing and solutions, customer support. We have other components of the system and the teams and products that are related to them. Of course, a special place is held in this category by the front-end teams, the front-end components. Finally, we have the executive team and the CEO. When they decide on something, they change direction at a given point. It's not always possible to challenge that idea. A good product manager needs to know when to say no and needs to know the difference between a valuable improvement and an instant gratification simple fix, which is something that backend engineers, when left unattended, will often do. I insist that there's nothing wrong with relying on and building trust with the more immediate stakeholders and reaching out to the more distant ones less often strategically to course correct. You may have realized already that I like sharing anecdotes and I want to tell you this one. Once I received a Gira ticket, took the user story concept a bit too seriously, at least in my opinion. The title read, as a service, I need to do something to be able to do something else. I respect the dedication of the person who created it, but it's a bit much to me, but it does make sense to remember that all the microservices in the ecosystem can be your clients, both in the technology sense. Of course, there's the client server architecture, but also in the business sense. Okay, what I want to show you now, so this is a list of traditional business objectives. I took it from a book called product roadmaps we launch. You have the full title at the bottom of the slide. This is a set of business objectives that are usually valid for any company and any product. We have the sustainable value category with support core value and create barriers to competition. We have the growth section and grow market share, fulfill more demand, develop new markets, improve recalling revenue, and there's the profit section where the objectives are support higher prices, improve lifetime value, lower costs, and leverage existing assets. So I filtered this list, as you can see here, and I've highlighted the traditional business objectives that usually affect the backend, the backend teams and the backend product. So we have support core value. This is kind of obvious, of course, for the product to work. Usually the backend is necessary and all the improvements we do and will be reflected in the backend. In the growth section, we have fulfilled more demand. Where this translates to the backend, this is about scaling and performance. So when we want to scale, when we expect that next month, for instance, with an ad campaign, we are going to have 10 times more users. This is a place for the backend team and backend product to shine, to find ways to be a performer. In the profit section, we have lower costs. So this is in a way similar. Can we serve this higher traffic without paying so much more for servers, for instance? What can we do? What engineering magic can we apply so that we can do the same thing for more or we can do more for the same price? And the leverage existing assets, this is similar. Can we serve a bigger group of clients with the same pool of resources? Can we build a new feature reusing parts of what we already own? So I've shown the business objectives, business metrics that can usually be impacted most by backend teams. Now I'm going to look at this from a different perspective. Which metrics should we track while prioritizing to make sure we have the biggest positive impact on the objectives that we are focusing on. Again, I'm talking in general, of course, every product and every company is different. And these lists that I'm presenting shouldn't be treated as exhaustive. Okay, so one important metric to keep in mind when prioritizing backend work is impact on infrastructure costs, like data transfer costs. And actually, I'm going to include one longer case study from this category in my presentation. Then we have future engineering costs. So legacy code causes delays and creation of new features can take much longer if the code is messy. And it depends a lot of the culture of an organization whether this is recognized and the teams are allowed to dedicate some time to improving the quality of the code without producing new features. Or in some companies, this is actually a very difficult conversation, which still should happen. Then we have performance. I'm not talking about performance for performance's sake. Sometimes, you know, something can happen. Something can take twice as much time and still not be a problem in some scenarios, but it's important to remember that performance affects two very important things. One of them is just user satisfaction. They don't want to be waiting ages for the page to load, especially if the ads load faster. And SEO. So how fast your web page especially is affects when this will be ranked by Google. So this is something you cannot forget. Then we have security and compliance, which ties to things like brand reputation or even fines for some violation of rules. Resilience, the cost of your system breaking down after stress or attack. Obviously, you should protect your system from this. Then we might have SLAs, software level agreements. If your company is committed contractually to, for instance, providing the five nines availability level, meaning that 99.999 percent of the time your system is available. So if you see that you are approaching a moment where this no longer holds true, this is something you absolutely have to invest in. And then company-wide roadmaps and metrics, including the metrics of front-end teams. So this is something, as I said, that kind of radiates into the backend teams, backlogs and priorities. Okay, now I want to discuss for a moment how to track. So traditionally, most PMs understand how to track the behavior of users interacting with that front-end. You have Google Analytics, you have its alternatives, and it's reasonably easy to track the user journey, to try the finance and the conversion, whatever you want. When you are dealing with a backend product, how can you know how your system is being used when you pretty much cannot see it? There are, of course, many tools, and I'm not going to discuss custom solutions here. I want to mention tools that are available out there and I have used them. So the two tools I want to mention are Grafana and Kibana. This is not a sponsored talk. There are also alternatives to these tools, but in my experience these tools proved invaluable, so I want to mention them. And there will be a horror story at the end. This is the case study that I have been teasing for a moment now. Okay, so Grafana is the leading open-source software for time series analytics. If you don't know what time series data is, time series data is a collection of observations obtained through repeated measurements over time. This definition comes from the Influx DB page, and Influx is one of the time series databases. So you can measure requests sent to your service per minute, percentage of requests served by different instances of software or different software versions. And Grafana can work with different databases like Influx, which I mentioned already, Primities and CloudWatch. It's also possible to be alerting Grafana. So for instance, when the system performance is lower than your SLA or the error rate is too high, you can be alerted even to the developer's mobile phones. So just to look at this example here for a moment, for instance, this is a Grafana dashboard. And this part here, and I'm aware that it's quite small on your screen. This shows the usage of the memory and the CPU power over time. And then the other tool is Kibana. And you may actually have heard another term, the Elk stack. So Elk ELK stands for Elastic Search Log Stash Kibana. And this is a set of tools that are often used together to manage logs. So Log Stash throws the system logs, like success, failure, stack traces, this kind of things. Elastic search makes searching easy. And Kibana lets you visualize and analyze it. So you can build diagrams based on the classic log contents like success versus failure. But you can also create visualizations for custom data that you decide to include in the logs. And again, to look at this dashboard here, maybe this is an interesting part. I took this from the company's website. So I don't have deep understanding of this view. But what we can suspect here is that we have countries here. And for what percentage of users come from which location, and then what kind of requests or responses are they exchanging with our system? Okay. So the horror story. I have a fun and illustrated anecdote, which shows the importance of tracking and analyzing what's going on in the underbelly of your system. So the issue at hand, a company I worked for had to store a significant amount of images data in a CDN to make it quickly accessible to people around the world. A CDN stands for content delivery network. And this is a group of proxy servers that are distributed around the world. So that when users request content, like images, it is served from a place closer to them so that they don't wait for such a long time. The cost for the company was the amount of data served from the network. So not stored there, but served to users. And naturally, we were interested in using a file format with a significant amount of compression to decrease the size of the files sent to the users. We were aware of a file format called WebP introduced by Google that produces much smaller files even if the compression is lossless. The challenge, though, was that not every browser was able to display these images yet. And also most of the time users cannot really open them on the desktop with the default tool they used to preview images. Originally, it was also not very easy to detect even web browser supported this format or not. So one of our engineers, and I told you about how important it is to have this healthy relationship with engineers, one of our engineers was following the news, some tech blogs and whatnot. And let us know that the adoption rate of this file format with the browser increased. It also became easier to detect which browser supports it by exchanging the HTTP header information. So the team then built the following diagram, let me show it to you, which showed the following information. So the orange and green area is the percentage of traffic where we are already sending the WebP format to the client based on some MVP solution that we put in place. The blue part is clients who cannot read this format, so they have to be served the old one. But the red thing is the gap that we had to fill. So the red thing is the users that could read this format, but we are not recognizing them correctly and we are not sending it to them. And we were able to calculate based on this diagram, also of course some additional research, that if we bridge this gap, we can save $20,000 per month for the company just for the transfer of images. And for a start-upy company, this was of course worth it. So this is what we ended up doing. So why am I calling this a horror story? So I'm glad you asked. This is something that of course in retrospect it's funny, it was horrifying what it was happening. So we implemented the solution, we sent it to production and then we gathered around the screens in the office with champagne glasses in our hands to watch the effects. And here is what happened. This is the bandwidth usage, so amount of data transferred. This is, we released the solution, I think you cannot see my pointer, so towards the right side of the diagram. And we saw this. So we saw that right after our deployment, the amount of data served to users went high incredibly. We were mortified of course. But then we decided to look at another diagram that our engineers have also put in place. And this is bandwidth usage per service. So the blue thing is our product and the product that my team was working on. The orange thing is a new product that was just starting. It's insignificant here. The red thing is what's important. So this was another product from our company's portfolio that was smaller but also important. And this is what happened. So it turned out that they released something on the same day and they made a mistake. So they somehow ended up sending full-size images rather than thumbnails to the users. And then the browser was shrinking this image on the client side. This was a roller coaster ride. And an important thing, in addition to just, I'm showing you how important looking at the metrics is and tracking them. But kind of a side effect of us working on this was that we actually noticed this. We noticed this peak because it turned out that that other team was not looking at these metrics and they wouldn't have realized that this problem occurred until probably the next time we were built for data transfers. So I want to show something kind of just for definition purposes. I'm talking about backend as a product and backend PMs. You might have heard about technical product managers. So is this who I am describing? Well, it depends. The term TPM can have different meanings in different companies. Most often a TPM is a regular PM who happens to have an engineering background. So can talk to engineers at a slightly different level than someone who came into product from another field. It may help with getting trust of engineers, but it can also hinder someone's career a bit because some recruiters will think that a TPM does not ever interact with end users. But watch out. The TPM can mean a different thing entirely. Some companies have introduced this BPM, TPM separation. BPM is business product manager, TPM is technical product manager. And this is more along the lines of a PMPO division. So the BPM is the product manager and then the TPM is a product owner, like really working hands on with the team. So anyway, when I say that backend do need product managers, I mean product managers in general, whatever you call them, people who represent the business perspective and help prioritize, but of course can also effectively communicate with the teams. So I am talking about backends, backend products, backend teams, backend metrics. One might suspect that if there is a backend, there must also be a frontend. So how do they fit together? You might be hearing about empowered cross functional and mission teams which are able to do things end to end without creating unnecessary inter-team dependencies. So what about them? If we talk about mission teams, do backend teams still make sense? So well, first of all, I want to stress one more time. I hope it was clear in my presentation, but I want to just say it explicitly that the backend can be and often is a product in its own right with its own metrics, objectives and stakeholders and clients. So a mission team does not need to mean frontend and backend. The mission team is a team that's responsible for their product end to end. They can build and develop the product without the need to wait on anyone else. So this means no waiting for ops, databases, data structures, networking and so on. This may also mean frontends and UX, but doesn't have to. So a mission team is responsible for development of a product. However, that product is defined. A mission team should not get blocked when they want to use products and components developed by others. Best case scenario, they should also feel comfortable introducing small changes in the adjacent components that they are using. This, of course, is an idealistic approach. In reality, it's often faster to ask a member of another team to do this one time, small task in the code base, rather than send our clumsy code for review. Sometimes the owners of the code will simply not allow you to touch it. All depends on the circumstances to which, of course, we always need to adjust to the circumstances in the spirit of being agile. To summarize what I'm trying to express in relation to mission teams, the concept of a mission team is not in contradiction to the existence of backend teams and backend products. A mission team works on a product and a technology product may but doesn't need to include a frontend. A backend team can be a mission team is what I'm trying to say. Okay, so I'm approaching the end of this presentation and this is my last slide, summary and takeaways. So the first thing I hope you can take away from my presentation is that most often than not, the backend is a product or even a component in the backend can be a product. The second takeaway, as a product, the backend needs a product manager. Without a PM, many teams will drown in refactoring and conflicting requirements that will not allow them to deliver on the big initiatives that really impact the company objectives. Three, backend, frontend, mobile, embedded, always keep the client in mind, both the end user and the paying client and also remember about the internal teams and components that are using your outcomes. Four, be aware what is happening in your system. Think about the metrics, however they are expressed and you can be working with anything, KPIs, SLOs, OKRs, just be aware of them, track them and remember how you want to know, how you want to influence them. I suggested two useful tools for the backend metrics, Grafana and Kibana, which can give you important insights about the backend. Finally, backend teams can work as empowered mission teams, taking full end-to-end ownership of their product. Thank you very much for bearing with me. Here's some of my data. Feel free to reach out to me, for instance, only in. I occasionally blog and speak, less occasionally I work and take care of my family. I have just moved to a new space at Medium. This is my third blog in general. You are welcome to follow, but also give it time because it's a new thing. Thank you very much.