Engineering and product management

Engineering and product management

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


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.


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”.

  • 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?

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.

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:



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Joca Torres

Joca Torres


Digital product development advisor, coach, and board member. Also an open water swimmer and ukulelist.