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 chapter 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 features in the product? And what about the sales, support, operations, finance, and 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 and the following articles!

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, and 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 as 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 chapter 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 Tips 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 receiving your suggestions, and even so, the more time you spend thinking and discussing the technical aspects of your product, the less time you will have to learn about your companies’ objectives and your client’s 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 feature, 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, and how this product is helping the company achieve its 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 of 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.

We can’t stand it, we need to rewrite everything…

I have heard this phrase several times throughout my career. Software developers know that invariably comes a moment when this kind of discussion comes up, which usually has phrases like: “it’s getting harder and harder to deal with the code”; “if it were to do it from scratch, it would be much faster”; “if we do not rewrite, it will become increasingly slow and dangerous to deal with the code”.

At Locaweb, we had an Email Marketing product for sending and managing email marketing campaigns, which used MongoDB as a database, a nonrelational database known for its ability to store large databases. However, probably because of our limited experience in software development using this type of database and managing non-relational databases, as the database grew, the system became slower and slower.

So, it was necessary to rewrite the product to use PostgreSQL. We designed this rewrite to be transparent to customers. That is, the client would not be migrated from one database to another, thus avoiding going through a period of unavailability or possible data loss. The rewrite was a success. The entire rewrite process, including putting all existing clients (over 15,000 at the time) into the new database, and allowing the MongoDB database to be shut down, took six months, a reasonable time for such an initiative.

However, during these six months, the team delivered nothing new to the customer. No new features. To lessen our customers’ frustration, we decided to hire a third party to build iOS and Android apps on top of existing product APIs. This enabled us to deliver the new feature to our customers while the product team focused on rewriting. If this option did not exist, we would have to find other ways to deliver user value that did not depend on the engineering team.

If you are a software developer, rest assured that if you have not experienced this situation in your career, you surely will. The problem with rewriting software is that by rewriting it, the team stops doing new things for its user, as I showed in the example of Locaweb’s Email Marketing product. From a business standpoint, when software does not evolve, customers see no evolution, may lose interest in using the product and will start looking for better options in the market. Therefore, I would like to make some considerations on the subject:

• New and better technologies will always appear. In the past, systems were developed with everything in the same code base. Then it was the MVC concept (model, view, controller) separating software code into layers according to their function. More recently, the concept of microservices was created, breaking the application into small, loosely coupled applications, preferably done via APIs and facilitating maintenance. If with every new technology that comes along we are going to rewrite the software, we will certainly do nothing but rewrite the software.
• Software rewriting must have a clear business motivation, ie it must somehow meet the strategic goals of the software owner company as it fulfills a user’s need or solves a customer problem. If there is no clear business motivation, the recommendation is not to rewrite.
• If rewriting is unavoidable (are you sure?), it is important to think about this rewrite initiative from a business perspective, that is, what is the impact of this rewriting on customers and the software owner? Understanding this is the responsibility of the product manager. Some questions to help you reflect with your team on this impact:
  • What will this rewrite look like?
  • While rewriting is going on, will new features be delivered?
  • How will the new system coexist with the old system?
  • When new features are implemented, will they be implemented on the new system and the old system, or only on the new system?
  • When can new clients be installed on the new system?
  • When will existing customers be migrated to the new system?
  • If there is a proposal to make a synchronizer, so that customer data exists simultaneously on the old system and the new system, what is the cost of this proposal compared to not making this synchronizer?
  • If the difference between the old system and the new system can be perceived by customers, how will this difference be communicated?

There you go, some considerations about software rewriting, a very important topic for any product manager.

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.

Product leadership advisor

I’ve been helping several product leaders (CPOs, heads of product, CTOs, CEOs, tech founders, and heads of digital transformation) extract more value and results from their digital products. Check here how I can help you and your company.

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, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

• Startup Guide: How startups and established companies can create profitable digital products
• Product Management: How to increase the chances of success of your digital product
• Leading Product Development: The art and science of managing product teams

You can also acquire the books individually, by clicking on their titles above.