How should the product manager relate to different areas of the company? Engineering, UX, product marketing, project management, operations, sales, legal, finance, customer service, human resources, and general management.

Recalling what I said in the article Main characteristics of a product manager, the most important feature every product manager needs to have is empathy, that is, the ability to put oneself in someone else’s shoes to understand their desires, motivations, needs, and problems. This feature should be used not only with the customer of the product but also with people from different areas of the company.

As said, the product manager must understand the impact his product has on legal work: have legal issues increased due to some new functionality in the product? And what about the sales, support, operations, finance, marketing staff, did the new product complicate their lives so much? And for the product team, the engineers and UX analysts who are part of the product core team, how do your product decisions impact their functions?

This is what we will see in this new series of articles!

Product engineering and product management

I will start by talking about the relationship between product engineering and product management.

Definition

Product engineering is responsible for developing the product and keeping it operating. With the business vision brought by the product manager, plus the solution design made by UX people – based on an understanding of the customer’s need or problem – product engineering “builds” the product.

To build it, they must not only do the programming but also define the technical architecture. That is, what infrastructure it will run on, which programming language is most appropriate, which database is most appropriate, how to ensure the non-functional requirements of this product (response speed, availability, scalability, etc.). It is also important to validate with the product manager whether the cost of this infrastructure fits his business model.

The fact that the product manager is responsible for defining the product to be made may give the impression that product engineering reports to product management. However, this view is incorrect, and if areas behave in this way, the chance of product failure increases because those who perceive themselves subordinate have less commitment to the outcome.

Product engineering, product management, and UX are one team, there is no subordination relationship between any of these groups. They should function as partners, each with their own expertise and responsibility, collaborating to produce the best product possible.

Innovation

In the previous diagram, product engineering brings the available technology. As I explained in the article Innovation: what is it?, to innovate is not simply to know the latest technology. You need to know not only this, but all available technologies, and how to use them. This is the role of product engineering. The opportunity and potential for producing an innovation lie in knowing the technologies available and knowing how to use them to solve a problem or meet a need of a group of people.

Practical Advice for Product Managers

To make life easier with the product engineering team, here are some practical tips:

• Don’t get into the technical solution unless you have earned the right to meddle. A product manager should have some technical knowledge of your product, but this is not your area of expertise. The experts are in the product engineering team. Therefore, avoid presenting technical solutions to the engineering team unless this team is open to receive your suggestions, and even so, the more time you spend thinking and discussing about the technical aspects of your product, the less time you will have to learn about your companies’ objectives and your clients’ problems and needs.
• Take engineers into conversations with customers and users. As part of your daily life as a product manager, you should always talk to your customers and users to understand how your product solves their problems or meets their needs, and how you can make your product look even better. Engineers love to go to these conversations very much. It is a very cool experience for them to see real people using software they have developed. They will be even more engaged in the mission of making a better product.
• Always make data-driven decisions. Whether it’s data from your product access and usage, or data from your customer and user conversations, use data to make your decisions and present it to the team. This will give more consistency to the items you will place on your product roadmap.
• Learn to take out the excess. Always look for the minimum product or the minimum functionality, ie try to implement as little as possible to achieve your business objective.
• Be present. It is critical to be with the product engineering team or at least as accessible as possible to the team. During product development, doubts will inevitably arise and if you are not present, either the team stops, or they will implement as they think it should be, which may differ from what you had planned.
• Provide the team feedback about the product. You, as a product manager, know how your product is doing, how many users it has, what these users are thinking of it, how this product is helping the company achieve the goals. Tell this periodically to the product engineering team. As a result, you will be giving context and purpose to the team.
• Negotiate the rewriting and maintenance stories. The engineering team, if it is a good team – attuned to good software engineering practices evolution and always following what’s new in the software development industry – will always find better ways to implement each piece of the product. If it is dependent only on the engineering team, the product backlog will only have stories about technical improvement. This is good, it shows that you are working with a great engineering team. However, you should use the previous item to provide the team with product context, ie to show that there are certain definite goals for the product that you as a team have to achieve, and therefore you should always release new features in it. There must be a balance between maintenance and rewriting stories, and new features. I’ve read in many places something like: “define X% of the time for maintenance and rewriting stories”. I don’t like to make this suggestion because I believe that every moment of the product requires a different balance, and it’s up to the product manager and his engineering team to talk and mutually agree on this appropriate balance at each stage. Remember the importance of finding a good balance, as this will avoid the famous technical debt that, as it grows, will slow down the product engineering team.

Oh, and there’s one more thing!

Some product engineers end up becoming great product managers. It’s important to be able to figure out when an engineer is looking for “something else to do” and give him that career choice.

At Locaweb, we have (and had) great product managers who were product engineers. In some cases, they became product managers of the product in which they were engineers. On the other hand, there are some product engineers who have tried product management and disliked it.

For those who are used to measuring their productivity by features delivered, it may be strange at first to lose that productivity benchmark. As we have seen, a product manager’s day to day life is made up of a lot of talk with the various people involved in it, and that lot of talk can “scare” the engineer who is used to working focused on feature development. So, you have to leave the door open so that she can be a product engineer again, without any harm to her career.

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.