The role of a product manager in the development process

Photo by Scott Graham on Unsplash

This article reviews the Product Manager’s role in technical aspects and presents the conflicts that may arise between Product Managers and Developers. The article also offers practical tips on how a Product Manager can integrate into the roadmap’s system the reliability handling with maintenance and how to perform a measurement process.

In his role, the product manager works with many teams dealing with various disciplines, including development, marketing, sales, support, and more. In the technical aspects, the product manager will most often work with the development team, the architect, the CTO, and the QA team. The typical approach between the Product Manager and the development team is that its success defines our work as successful. Sometimes, there is a gap in the point of view on how the product’s success is set.

In his role, the product manager deals with planning and thinking about the “next thing” strategically. For example, where the product will be one or two years from now and current and future competitors’ status. So similar to how the development team thinks about the continuity and delivery of new features. The product manager also deals with features delivering, receiving customer feedback on the features, and delivering additional features to improve the product continuously.

On the other hand, the development team puts much effort into defining the system’s realization in the present to make things work all the time. The action is reflected in the system design, how to save the information in the DB, and the choice of writing the code with future thinking based on how easy it will be to maintain it. This effort is because when things do not work correctly in the system, they will eventually turn back to the developers.

From this, it can be seen that there is a difference between the two approaches mentioned above. So the solution is to find a balance between the need to deliver features and the need to produce a stable and robust system. As a product manager, the goal is for the system to know what response he will receive in each action he takes. Sometimes as product managers, we tend to characterize many new features within the system. Still, it is essential to note that sometimes, the user will not experience the features’ value for several reasons.

1. The first reason is that many bugs prevent proper use of the system and perform the appropriate flow.
2. The second reason is that the system’s performance and response times are prolonged, adversely affecting the user experience.
3. The third reason is that the system is inconsistent in its actions; for example, pressing a button once does one thing, and the next time, it does something else.

The conclusion is that no matter how good the product is, if the user fails to do what he wants to do, then the situation is problematic. The product manager’s task is to make sure all requirements are complied with, talk to customers, and get feedback. If the system is slow, then the QA team’s task is to discover it, and the mission of the development team is to solve it. As a product manager, we need to take responsibility for the feature, end-to-end functionality, delegates authority, and commitment to the teams.

The Product Manager regularly performs KPI and user behavior measurements, but it must be remembered that many measurable technical parameters affect these KPIs. Here are some examples that illustrate the argument:

1. How long the system is down and not allowing proper system use.
2. The number of errors or system problems that arise during working with the system at a particular time.
3. How many bugs there are in the system forces the user to bypass the flow it is supposed to make.
4. How long the system is not functioning well enough.
5. What are the response times of the system or certain features?

All of these examples illustrate the direct technical impact on product KPI. So once the product manager is aware of these technical parameters, they can be measured regularly and pinpointed where the problems are. As a result, it is much easier to address issues in a targeted manner. At this point, the Product Manager’s responsibility is not to check every feature at this level.

Here are some practical tips for implying technical insights into the product manager’s ongoing work:

First of all — reflect all insights to the QA team, understand what the test program is, and test the technical parameters within the test program.

Second — set as part of the system’s non-functional requirements the response times required for each feature.

Third — after the feature is released to customers (post-release stage), share the QA team with its feedback. For example, a breakdown of all the bugs, time response issues, and functional issues. Next, analyze how to “discover the problems” next time and make this process better.

Fourth — in the process of building the roadmap, the product manager is responsible for planning the strategic part of the product that includes

1. To characterize and define the status of the product a year ahead, investigate the competitors (direct and indirect), examine the state of the market, and think about the positioning of the company in the market.
2. To treat the feedback received from the customers of the product, prioritize them, and put in the roadmap what is relevant. Examples: feature request, some requests for flow update.
3. To consider the maintenance and stabilization of the system — at this point, sit down with the development team or the CTO and allocate time to be devoted to system stabilization and maintenance. Time can be a complete sprint dedicated only to this area or to define that each sprint will be devoted to supporting.

In effect, the product manager allows the development team to be a full partner in the process, to feel that they are part of the roadmap, to comply with the difficult things in the system, and in fact, to be fully expressed. This may reduce the conflict mentioned at the beginning of the article related to the work interfaces between the product manager and the development team. At this point, the development team will define the actions it takes. For example, to change the system architecture structure, improve the DB, perform more system testing, debug, or do refactoring. Here comes the Product Manager’s full responsibility that our systems will look good not only on the features and customer’s side but also on being correctly maintained.

Fifth thing — to be ready to deliver a technical version, at this stage, as part of the feature’s ownership, the Product Manager should lead the process of announcing whether the release of the product is ready and in what situation. The method of preparing for a release includes the following parts:

1. To ensure that the QA team has completed system testing and verified the correctness of all the technical parameters mentioned earlier in the article, version stability, response times, and error messages.
2. To meet with the developer of the feature, the architect, Scrum Master, or whoever led the feature’s development at the technical level. At this meeting, the Product Manager should explain that we are preparing to release a version. Also, ask the team to think together and make sure that something is missing in the system? Is there something technical that needs to be solved before release and cannot be given up? Is there something in the technical aspect that is still open and cannot wait for the next version? Or to do action to reduce technical debt that lack of care will cost many resources later?
3. Record all insights and status of the product before its release. It is essential that all stakeholders are up to date and involved in the process. For example, VP Product, CTO, VP R&D, and QA team will be aware that this is the list of remaining industrial actions to take, and the release of the feature will only happen once all these things are ready.

Sixth thing — to deal with bugs after the release (each system has many different faults). Any malfunction that affects the customers in the system is essential to the product manager. The product manager’s task is not to fix the fault but to understand the impact of the customers' failure by understanding how many customers experienced the error and for how long. The product manager should then communicate this to customers through Customer Success and Support.

In summary, the technical aspects that the product manager experiences in his role are many and varied. From interface and working relationships with development and research teams, through understanding the importance of system stabilization and ability to establish proper maintenance infrastructure, through measuring technical parameters that affect product KPIs, and implementing system requirements and roadmap, all from a broad perspective of product ownership To endow and provide real value to the customers of the product.

Written by Maayan Galperin