In previous articles, I talked about the relationship between the product manager and engineering, UX, product marketing and project management. The question that remains is: what about the other areas of the company? How is the product manager’s relationship with operations, service, legal, sales, administrative finance, and human resources?

Operations

The operations area is responsible for maintaining the product. For online products, ops is responsible for ensuring that all the infrastructure is available and with good performance.

The operational quality of a product has to do with two operational characteristics of the product:

1. The product must have a good performance: Each customer request to the product must respond in less than X seconds. The definition of this X is the performance definition of this product. It is important to know that X is not an integer; it can and ideally should be a fractional number less than 1 (for example, the product must answer requests within 0.3 seconds). Different product features may have different performance expectations.
2. The product should be available for use as long as possible: This is the SLA (Service Level Agreement), defined as a percentage number, for example, 99.9%. This number can be measured in a day, month or year. Within a month, 99.9% availability means 43.2 minutes of unavailability, while 99.5% means 3 hours and 36 minutes of unavailability. When we look at the availability of a product, we must take into account two factors. (1) Frequency of problems: the time between each outage. Imagine that your product has 99.9% availability, which means a maximum of only 43.2 minutes per month of unavailability. If this unavailability happens on a particular day for 1 minute every 10 minutes, this means the product will be unstable for more than 7 hours that day. There is an operational metric that should be tracked that helps to measure the frequency of problems. This is MTBF, or mean time between failures. (2) Duration of the problem of unavailability or malfunction: here the rationale is simple. If there is a problem with the product, the problem should last as little time as possible. There is also an operational metrics that must be tracked that helps you measure the duration of the problems. This is MTTR, or mean time to resolve, or average time to resolve.

The definition of good operational quality is a definition that has to be made by the product manager in conjunction with engineering, UX and operations. Of course, we always want to offer the highest quality possible to our customers, but the higher the quality, the higher will be the cost to maintain the product.

It is important for the product manager to define, together with engineering, UX and operations, what is the acceptable quality level and acceptable operating cost for the product. This is what we call a non-functional requirement, as it is not a product feature. It is a feature that impacts its use.

In order for operations to operate the product, it is important that the product be “operable”. It seems kind of redundant what I just wrote, but it is not uncommon to see practically ready-to-release products that have to go back to development, because some simple operational points were not taken into account, such as: what to monitor, how to monitor it, what to do if monitoring finds something not functioning as expected.

Ideally, this should be considered before you start developing the product. If you fail to do that and think about these points only after the product is ready, there is a good chance that you will have to redo something in the product to fit these operational standards. In order to discuss what operational issues should be considered before and during product development, it is a good idea to have someone from operations to participate more closely in product development.

Although the operations relationship should be closer to engineering than to the product manager, it is the latter’s role to follow that relationship and to help wherever possible, especially in defining non-functional operating requirements.

Customer support

Ideally, your product does not require phone, chat, or email customer service. This is what we call no-touch or low-touch products. However, as much as you work with UX to make this true, there will always be customers who want to talk to someone at your company for some reason related to your product. Therefore, you should prepare your customer support team to talk to your customers and to solve their problems.

Before launching your product, you should prepare and deliver training to your service team so that they are prepared to answer key questions. Once it is released, you should follow up on all the calls not only to see the quality of the answers given by the customer support team, but also to understand what are the main questions they have when using the product.

Your goal should be to minimize these contacts by trying to resolve these questions directly in the product. This is a task that you will need to do with the UX people working on the product. Every time you launch a new feature or an improvement to an existing feature, you must communicate to the support team in advance to get them ready so they can fully support questions about these new features.

Legal

Your business legal area can be internal, external, or even a hybrid of these two options. Regardless of the model, it is important that it has good knowledge in the digital field, and is constantly updating itself, as many laws and regulations are still being created. New laws and regulations related to software products, digital products, and online products come up quite often, and it is important that your legal department monitors and knows the details of these new laws and regulations.

The legal area has two main functions linked to your product:

• User Agreement: In this agreement, the main product features are documented, including service level, service type, data privacy policy and payment methods. In addition, this contract must contain the rights and duties of both your customer and your company, ie the rules that must be respected for the proper functioning of the product. For example, at Locaweb we decided at a given time to provide our Website Hosting product with unlimited disk space. To be able to do this, we have contractually agreed what can and cannot be done on our Unlimited Disk Space and Hosting Website Hosting product to ensure the product works well for all customers. We’ve created the unlimited policy explaining that “having unlimited space doesn’t mean you can use your hosting in a way that impairs the operation of the server, for unlawful purposes or otherwise violates applicable law”. In addition to writing the contract, the legal handles all claim that your clients make in the legal context, usually through lawsuits against your company; therefore, you should use empathy to understand the concerns your legal area certainly will have about your product and how it is used.
• Vendor Agreement: In this agreement, the focus is on how your company’s relationship with the software vendors that will be part of your product will be managed. For example, at Locaweb we have the Web Hosting product, which can be on Linux or Windows. On Linux, we have to understand the open-source software use agreements to see if the Linux Website Hosting product can be built using such software and if there are any restrictions we should consider. On the Windows platform, we must constantly check Microsoft’s software licensing agreement to make sure that we are offering the Windows Site Hosting product in accordance with Microsoft policies.

Sales

The sales team needs to be trained by you and the product marketing person about the product to be launched. After that, it is important to make training updates whenever you release news about your product.

Another important point regarding sales teams is that they can provide a lot of important feedback regarding your product. New features, adjustments to existing features, price and business model adjustments are all topics that the sales team can certainly contribute to. But here it is worth remembering empathy again, that is, remember what the sales team’s goal is: to sell. They see your product from the perspective of “how to sell more”. You need to use your discernment and customer knowledge to judge if the sales input is valid for the product, or if it may eventually hinder your goals.

For example, it is fairly common for a salesperson to come up saying that he has enormous potential to make a big sale, but for the customer to make the deal, he needs some new feature, and if it is not implemented that sale will be lost. It is up to the product manager to have insight into the importance of this new feature for the product and for other product customers.

As seen in the article about Special Requests, when I commented on the difference between the Email Marketing Locaweb and All In Mail products, the product context makes clear this need for product manager insight. Accepting these special requests in the Email Marketing Locaweb product makes no sense. In the All-In Mail product, these requests from the sales team should drive your roadmap.

Finance

Finance is the area that will allow product managers to understand if the product they manage is a good product for the company; that is, if the return on the product is bigger than its costs. Of course, you and product marketing will keep track of your product revenue on a daily basis, but the costs aren’t as simple to track. Finance can help you calculate and track product costs.

You can divide your cost into two broad groups: the cost of maintaining your product and the cost of attracting customers to your product.

The cost of keeping your web product up and running is what we call **operational cost**. In this category we have cost with the infrastructure and people needed to keep the product running. Here in this group, you should also consider your development team, that is, the UX people, the product engineers, and you.

Another operational cost that should also be considered here is the financial cost, ie the taxes you pay. Finance, along with the legal department, is best suited to define the best tax structure for your product.

Marketing and sales investments are the cost of attracting new customers. Whether you spend on AdWords or other forms of online and offline advertisement, you will have a cost and it’s very important that you measure the return it will give you. How much money do you need to invest in marketing to bring in a customer? How much revenue does this customer bring? Is it enough to pay the cost of attracting it, plus the operational costs, and still have a little left to pay for the investment made in developing the product?

This category also includes the cost of sales and marketing teams, and the commissions that are given to the sales team if your company chooses to pay them a sales commission. If you use indirect sales channels, such as selling through partners, partner compensation will also come as part of the cost of attracting new customers. If the marketing team decides to run promotions, such as a first-year discount, it also comes as the cost of attracting new customers.

When you price your product, it is important to consider its cost structure, as the revenue serves to cover these costs and generate some profit. If you do not get enough revenue, your product will not succeed.

Human Resources

At first, it may seem that HR has nothing to do with the product and its management, but it’s all about it. HR is essential to product success, as it will be part of the process of finding and attracting new professionals to work with.

In addition, HR should help with onboarding the new employee, that is, in his or her early days at the company. HR can also assist in training and evaluating people on product development teams. Hence its importance in the success of the product.

Both at ContaAzul as well as at Gympass, the product development teams have dedicated HR people working with the teams, with two main functions: talent acquisition and HR business partner. At Gympass, the dedicated HR team sits together with the product development team.

Administrative

This is another team that seems far from the product and the team that develops the product, but it is not. The administrator maintains the necessary infrastructure for the business to continue to function. Office, meeting rooms, furniture, office supplies, office services (cleaning, snacks, meals, coffee, deliveries, etc.) are all necessary for your business to function and, consequently, for the product development team to be able to do their work.

Summing up

I chose to put all of these areas in one chapter rather than devoting one to each, as I did to talk about engineering, UX, product marketing, and project management because interaction with these areas is not as intense. However, keep in mind that these areas and the product manager’s good relationship with them are essential for the success of your product.

Recalling what I said in the article Main characteristics of a product manager, the most important characteristic every product manager needs to have is empathy, that is, the ability to put yourself in someone else’s shoes to understand her motivations, needs, and problems. This characteristic should be used not only with the customer and users of your digital product but also with people from different areas of the company. The product manager must understand the impact his product has on their work so that they can make working together as fruitful as possible.

As we have seen in this and previous chapters, the product manager interacts with virtually every area of the company, and with many of them, roles and responsibilities may overlap. In the next chapter, we’ll look at a valuable tool to help clearly define the roles of each area in the different tasks related to a product’s life cycle.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success? Check out my new bundle Digital Product Management with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.