Feedback and performance evaluation

One of the main tools for the development of the people on your team is feedback. This word is an English term that originally means a process in which the actions of a given system are inserted back into the system for the improvement of the system itself. In people management, feedback is when a person tells another person how their behavior and actions were perceived by that person. Feedback can be given by peers, subordinates or leaders.

Feedback

As a leader, it is very important that you give feedback whenever necessary to the people you work with. Six aspects are essential for feedback to be as useful and relevant as possible:

  • Be necessary: before giving feedback, it is important to understand if it is necessary. Does what the person did affect the result negatively? Or is it just a different way of doing what needs to be done? Sometimes we give feedback on something because it was done in a different way than we expected, but it didn’t necessarily generate bad results. If the result was achieved with the same time, in an acceptable way, we need to accept these different ways of doing things and obtaining the results.
  • At the moment: it is important to give feedback as close as possible to the moment when the situation you want to give feedback about happened. In this way, the details about what happened and the motivations that led people to act the way they did will be fresh in everyone’s memory.
  • To the point: when talking about what happened, be objective, that is, go straight to the point and base your feedback on facts. Your feedback should be useful to the person receiving it, it should give clear indications about the expected behavior for that situation.
  • Transparency: feedback has to be transparent, there can be no hidden or unspoken aspects, as long as they are relevant to that feedback.
  • Empathy: being transparent and objective does not mean being rude. Rather, feedback is intended to help people understand how their actions and behavior impact others. Put yourself in the shoes of that person who will receive this feedback and think about how you would like to receive it so that it is as useful as possible.
  • Private: give feedback in a private environment, to give space and freedom for a transparent and productive conversation.

Characteristics of a good product manager

I usually evaluate product managers based on 7 main characteristics:

Empathy: is the ability that a person has to put himself in the place of another to understand his desires, motivations, needs, and problems. This characteristic is important to understand the customers and users of the product, to know how they relate to it and what problem they expect to solve or what needs they want to be met. This will help the product manager to better understand its user so that, together with UX and engineering, they can design the best product. However, empathy should not be used only with the customer or user. The product manager must also use it in his relationship with all areas of the company and must understand the impact that his product has on their work.

Communication: to be able to empathize, it is necessary for the product manager to communicate with people in the most different scenarios: in one-on-one conversations and in small groups, or making presentations to small and large groups of people, presentations which can be internal (within the company) or external (in conferences, user groups, etc.). However, it is not just about speaking. Communication is a two-way street, that is, the product manager has to be very good at knowing how to listen and understand what others are saying, and understand their desires and needs; which has to do with the first characteristic, empathy.

Time management: the daily life of a product manager can quickly fill up with tasks and she needs to be able to perceive and differentiate what is urgent from what is important, to ensure that she will always have time to learn more about the customer and the user of your product.

New technologies: the product manager must be aware of new technologies to find out how it can impact his product. Smartphone access, how does this impact the product? Does the user want to access it via smartphone? To do what? Social networks, how can the product take advantage of them? Non-relational databases, what are the benefits and shortcomings? Go, Google’s programming language, what is it better than the language used in the product? And what is it worst at? Smartwatches, smart glasses, how does this impact the product? How does the user expect to interact with the product on these new interfaces?

Business skills: the product manager must be concerned with whether his product is meeting business objectives. If the goal is margin, are revenue and costs under control? If the goal is only revenue, how is it growing? If the goal is the number of users, how is this metric evolving? In addition, the product manager must understand how each area of ​​the company works and how the product affects those areas. How does legal work? How does the product impact the legal department? And how does the legal department impact the product? These questions can be repeated for all areas of the company: support, operations, finance, HR, marketing, sales, engineering, and UX.

Keen curiosity: the product manager needs to have the ability to learn fast in order to gain insights and make judgments about the product. You must be able to learn both the soft side of the product (what is the business motivation, what customer problem the product solves, etc.) and the more technical side (what technology do we use, what is the impact of this technology, what metrics can we get, etc).

Product theme: Last but not least, the product manager needs to know about the product theme. If it is a medical product, the product manager should understand a little about medicine. If it is a financial product, you should know a little about finance. For example, at Locaweb, we have more technical products (like the Cloud Server) and less technical products (like the Virtual Store). The need for technical knowledge is quite different in these two products. The Cloud Server product manager should know technical issues in depth, while the Virtual Store product manager does not need to have as much technical knowledge, but should know a lot about online sales issues.

Do product managers need to know how to code?

This is a reasonably controversial question. As stated, depending on the product theme, it is important to know how to program, especially if what the product manager takes care of is a more technical product. Some examples of Locaweb are Website Hosting, Cloud Server and SMTP. However, even companies that do not “sell” a technical product can have a part of their product with a more technical bias. At Conta Azul we had APIs, integrations with fintechs (Iugu and Stone), and integration with the government finance systems for issuing invoices, and at Gympass we had the integration with gym management systems and HR systems. For these products, it is important to have a product manager with technical knowledge, since the main user of the product will be a technical person and the product objective is a technical objective.

On the other hand, a product like Locaweb’s Virtual Store, Gympass’ user app, or Lopes’ property search portal are products made for consumers in general. Would it be good for these products for the product manager to have technical knowledge, that is, to know how to code? In my view, it is not essential that the product manager has the technical knowledge, but it will certainly help. Technical knowledge helps you understand how the product is made, and it will help you to be a better product manager. It helps to understand the work done by the engineering team and can be useful in decisions about prioritization and scope. Two analogies that can help to better understand the benefit that knowing how to program brings to a product manager:

  • A good Formula 1 racer doesn’t need to know how the car works, but if he does, he can certainly use that knowledge to be a better driver.
  • Likewise, a guitar player does not need to know how to sing or play bass, drums, or piano to be a good guitarist, but certainly, this additional knowledge can help her be a better guitarist.

This does not mean that the product manager needs to be a coding expert. If she has no knowledge of coding, it would be interesting to take an introductory course in programming logic and experiment with making her first program. This experience will only benefit that person’s career.

SQL

If the product manager doesn’t already know, he must learn SQL. Access to data is increasingly democratic in companies and knowing SQL is essential so that the product manager can enjoy the data independently, without having to ask others to create their charts and dashboards. When we put Metabase as a data democratization solution at Conta Azul, I was so excited that I spent a whole week going to sleep at 2:00 am, because I was creating charts and dashboards to better understand how Conta Azul products were used.

Performance evaluation

Many companies use performance evaluation as the company’s official tool to collect and record feedback from their employees. Leaders assess the people on their team. People evaluate their peers and their leaders. People doing self-assessments.

Some companies use the 9-box matrix which has two dimensions:

  • Performance: analysis of the past, the results delivered by that person. Here, more than the result itself, it is important to take into account the person’s role in achieving this result, especially if we consider the results of a product development team, which are a result of a team.
  • Potential: analysis of the future, that is, how much the person is prepared to deal with new challenges. Literally, potential means “having or showing the ability to become or develop into something in the future”. As you can see, this dimension of a person’s assessment can be quite subjective. For this reason, some companies have replaced potential with culture, that is, an analysis of how the results were achieved by that person, and whether this “how” is aligned with the company’s values. It tends to be a little subjective too, but a little less than potential.

Leaders assess their subordinates based on these two dimensions. In some companies, these assessments include, with less weight, self-assessment, peer assessments, internal clients, and, if the person leads a team, their team members. It is the 360º evaluation. In other companies, self-assessment and peer, client and team member assessments serve as additional data for the leader to make the assessment but do not enter into the assessment calculation.

After the assessment is made, a calibration process is usually carried out, where leaders compare the assessment of their subordinates to understand whether the assessment criteria used by each leader are equalized. This entire evaluation process is led and coordinated by the company’s HR team, and this calibration is facilitated by someone from HR. The people evaluated are plotted in the 9-box matrix and with that we have a map of the company’s people.

9-box matrix and its quadrants

With this calibrated assessment in hand, the manager returns to the team and then the consequence management work begins, which is the work that needs to be done after the team receives their assessment:

  • Well evaluated: people who are in one of the 4 upper quadrants are those who were well evaluated. Usually, it is people who are considered for increases and promotions. They are usually happy with the feedback and are motivated to continue doing the job in the best possible way. However, if the person’s self-assessment is higher than the assessment received, even though they are well assessed, there is a risk that they will experience some frustration. This only does not happen if she is evaluated in the upper right quadrant of the 9-box matrix.
  • Poorly evaluated: people who are in any of the 3 left quadrants or any of the 3 lower quadrants are below expectations in terms of performance and/or potential (or values, if there was a decision in the company to change this axis of the matrix 9-box). These people will need to do something to receive a better evaluation in the next cycle. This situation can cause some discomfort in the person evaluated because he feels that his job may be at risk. For some people, this situation can serve as an incentive for them to seek to improve and, in fact, be better evaluated in the next cycle. On the other hand, some people may feel unmotivated by this assessment and decide to look for an opportunity in another company. This situation is aggravated if the person self-evaluated better than the evaluation he received.

Criticism of the performance evaluation process

The performance evaluation process seeks to classify the employees of a company in order to facilitate the understanding of who are the best people and who are the people who need to improve. However, as I explained above, there are many opportunities for frustration in this assessment process, especially when there is a disagreement between self-assessment and the assessment received. This frustration is usually compounded by the fact that the evaluation process is liable to:

  • Subjective: how to measure a person’s potential? How to measure your adherence to the company’s values? How to measure your participation in achieving results?
  • Bias: distortion due to different aspects of the appraiser’s judgment in relation to the appraised person. Usually, the appraiser remembers an appraisee’s most recent actions. It is also common for actions with negative consequences to be perceived more intensely than actions with positive consequences.

In addition, we are increasingly understanding and respecting human diversity, not only in physical matters and preferences but also in the diversity of perspective, history, and context. With this greater clarity on human diversity, it becomes increasingly difficult to fit all people in a company into just 9 boxes based on two dimensions (potential vs results). To better understand the complexity of the people who make up a company, we will probably need to think in a multidimensional way.

For these reasons, there is a worldwide tendency to abandon the periodic performance evaluation process and replace it with more frequent conversations between leaders and followers about career, performance, potential, and values. According to some estimates (https://hbr.org/2016/10/the-performance-management-revolution), more than a third of American companies have already abandoned the periodic performance evaluation process and have adopted these more frequent conversations as an alternative.

Retrospective, an alternative to the performance evaluation process

In addition to the most frequent conversations between leader and team member about career, performance, potential, and values, I think it is important every 6 months to do a retrospective with the team about what happened in that period. In the same way that in product development we have retrospective ceremonies, it is a time to revisit what happened and evaluate what went well, what can improve, and the challenges ahead.

I do a first version, based on the history I have with the person. If there is a formal performance evaluation process in the company where I am working, I use this opportunity to do the retrospective and consider all information generated through this process, self-assessment, peer review, internal clients, and team members, if any.

This first version has 3 sections, strengths, improvement opportunities, and challenges for the next semester, which include not only the main objectives for the next semester but also focus on the points for improvement. If there is a formal performance evaluation process in the company where I am working, place my initial suggestion for classification in the items measured in this formal process (results, potential, or adherence to values).

The next step is to use one of the 1:1 meetings to talk to each team member about this retrospective, listen to how she sees it, and eventually adjust the retrospective in agreement with her. It is an excellent time to have a broader conversation and a joint reflection on the semester that has passed and what lies ahead.

If there is a formal performance evaluation process in the company where I am working, I make this conversation before inserting the data into the company’s evaluation system, as I think it is important for the evaluation to contain this retrospective built together with the person. If there are calibration sessions, I advise the team member that the assessment may still undergo adjustments due to the calibration and, after the calibration, I tell in a transparent way what happened in the calibration, to help the person understand how other people perceive her.

EXAMPLE of a GPM retrospective

Strengths

The first semester was particularly difficult for Philippa, with many uncertainties and huge pressure to deliver the Avengers Project. Given all this, Philippa managed to navigate the situation very well and find good solutions, including recommending a company acquisition, as well as keeping her tribe engaged in the process.

Opportunities for improvement

Your PM team is still junior, with little experience in product management, despite having good technical knowledge of the product theme. It is important to look for ways to accelerate this seniority of the team.

Challenges for the next semester

You must work to increase your PMs’ seniority as they still demand a lot of your time, preventing you from having a more strategic role.

Promotions and salary increases

In the chapter “Hiring the right people” I commented that, when making the offer for a person to join your team, it is important to balance short-term (salary and benefits), medium-term (bonus) and long-term (stock options) incentives. From time to time, while that person is on your team, it is important to assess whether these incentives need to be revised, that is, whether he deserves a raise or a promotion. There are two important aspects to consider, when and how to give salary increases and promotions.

When

It is common for companies to define a period of the year for promotions and salary increases, usually just after the period of performance evaluation or periodic retrospective. I recommend not doing this, because in the hierarchy of needs of most people, the need for recognition and financial reward comes before the need for personal development. Therefore, if in the same conversation we put the topic on promotions and salary increases along with the feedback topic and what points he needs to improve, the person’s attention will be much more focused on the topic of promotions and increase. For that reason, I recommend separating these two conversations. When talking about promotion and salary increases, focus only on that topic. And when talking about hindsight, again just focus on that topic.

How

There are two ways to promote a person. The first way is to expect her to be demonstrating skills from at least 70% of the next career level to promote her. This is what I call a “pushed promotion”, that is, she must push to get her promotion. The other way is to assess the person’s potential, that is, whether he has the capacity to develop the skills necessary to operate at the next career level and, if he has, to promote it. I call this form “pull promotion” because the person is pulled to operate at the skill level of the next career level.

I prefer the pulled promotion model, as it generates a very motivating challenge for the person, who will feel that he owes the necessary skills and will rush to develop them as soon as possible. There is, of course, a risk that she may not be able to develop these skills, but in most cases, I see that people with potential usually develop them very quickly. In the pushed promotion, the main advantage is that there is no risk, the person who is promoted already demonstrates the necessary skills. However, precisely because he already has the necessary skills, this person may feel that the promotion is not coming, or that it is taking too long and may want to look at the market, increasing the risk of you losing him from your team because it takes too long to give him recognition.

Summing up

  • Six essential aspects of good feedback are: checking if feedback is necessary, giving it when it happens, being objective, being transparent, empathizing, and giving feedback in private.
  • The seven main characteristics of a good product manager are empathy, communication, time management skills, knowledge of new technologies, business skills, keen curiosity, and knowledge about the product theme.
  • If the product is not a technical product, it is not necessary to know how to program it. However, having some sense of programming can be useful in understanding how your product works. Knowing SQL is also useful, as it will help the product manager to better understand the metrics of their product.
  • Formal performance appraisal processes have been increasingly seen by companies as something that does not bring as many benefits as expected. Several companies are replacing this process with more frequent conversations between leaders and followers about career, performance, potential, and values.
  • A semi-annual retrospective is a good way to have a structured conversation with the team member about the results achieved and how they were achieved, and the challenges to come. This retrospective must be built together with the team member. If there is a formal performance appraisal process in the company where you are working, use the retrospective process to create the performance appraisal.
  • Regarding promotions and increases, there are two aspects to consider, when and how. I recommend separating the salary increase and promotion conversations from the feedback conversations to maintain full focus on the topic of each of these conversations. I also recommend promoting the person when he has the potential to develop the skills necessary to occupy the next career level, and not expect him to already demonstrate the skills necessary for that next career level, as this will motivate the person more.

In the next chapter, we’ll look at the ceremonies I usually use with the teams I lead.

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 almost 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

Hire the right people

As I mentioned in the chapter “People: priority # 1, always” we spend money and energy to attract, hire and retain the best people. Having people as the number one priority is the key to achieving any other goal. And the first step in having the best people on your team is hiring.

The work of hiring people must be done in conjunction with HR. It’s teamwork. I have seen situations where this process is fully delegated to the HR team, and the person who is hiring is just asking “where are the candidates?” and “why is HR taking so long to fill this position?” Defining a profile, finding candidates, interviewing, selecting, and onboarding is as much the responsibility of HR as the head of product and her team.

DEFINE THE PROFILE

The first step in hiring the right people for your team is to define the profile of who you are looking for to join the team. When I speak of a profile, I am thinking not only of technical knowledge but also of behavioral seniority and cultural fit, that is, what values ​​one needs to have to work in this team. It is important to build this profile in collaboration with more people on the team. From that profile, the job description will come out.

ATTRACTING CANDIDATES

Having the profile defined, it is necessary to advertise the vacancy to bring candidates. It is the work of attracting people. Here marketing can help. Just as we need to tell the world about the problem we solve with our products and how the product solves it to find the right people who will be interested in becoming our customers, we need to tell the world about the type of people we need in our team.

For this reason, it is important to work on your employer branding, to tell the world why your company is an interesting company to work for. Tell on social networks and at events about the work done by the team, the challenges and achievements, the environment and culture of the team. This is all part of employer branding and helps to attract people interested in working on your product development team. This is a work done in partnership between HR, marketing and the product development team.

Another excellent source of new applications is internal referrals. Ask people on the team to refer people they have worked with elsewhere and who they would like to work with again. It is even possible to encourage these referrals by giving prizes to the referee if the referred person is hired.

INTERVIEWING

It is important to have a well-defined interview sequence. Who are the people who are going to interview? In what order? Will there be individual or group interviews? Will there be a case to be solved? Usually, in the companies where I worked, the first interview is done by HR, to present the opportunity and the company and to understand a little more about the candidate’s behavioral profile. HR may use some behavioral testing for this.

Then there are the interviews with the people on the product development team. If you are hiring for a position that will interact a lot with other areas of the company, it is important that the candidate is also interviewed by people from those other areas. I usually suggest that the direct leader be the first to interview, then the person should be interviewed by peers from the product development team and other areas, if applicable.

If the person is going to lead a team, I suggest the opportunity for some people on the team to also interview the candidates. Despite making the process longer, I find it more interesting for more people to interview for two reasons: first, it gives the opportunity for more people to get to know the candidates and, when the decision is made, more people are committed to the success of this new team member; second, it gives the candidate the opportunity to get to know the company and the people who this person may work with if she gets an offer.

An important piece of advice for interviewers is to try to ask the same questions to all candidates, so you can compare the answers to choose the one that best fits the profile you are looking for. Regarding what kind of questions to ask, I usually listen to the person’s story and ask about successes, mistakes, relationships with other team members and with people from other areas.

During the interview process, it may be interesting to ask the candidate to solve a problem at home and then present the solution. This process is quite common in both product management, UX and engineering jobs. The purpose of this test is to better understand the ability to solve problems, the thought process and the ability to present solutions. And this presentation of the solution is a good opportunity to understand how the person expresses himself and how he deals with questions.

I prefer that the case to be solved is a practical case of the company, in which the team is working or intends to work at some point. I have heard criticism that this is free consulting and that later the company will use the best solution. It is important to make it clear that case resolution has two objectives, to give the people who are hiring the opportunity to get to know the candidate better, how he solves problems and presents his solutions, as well as giving the candidate the opportunity to know what kind of problems he will find in everyday life if he joins the company.

It is worth mentioning that when asking for a case resolution, there is a danger of losing candidates. Therefore, it is important to make it clear that the process will have this phase, and it is important to enchant the candidate before presenting the case to be solved to make him willing to resolve the case.

As I mentioned, this is a long process, with several interviews and tests, which can make you lose good applications. That is why it is important to keep this process attractive, to tell the candidate how she is doing, what stage she is in and what remaining steps needed to reach the end of the process. I’ve heard reports of companies that manage to do this whole process in one day, reaching the end of the day with candidates receiving an offer, but I never had the opportunity to witness such a process.

SELECT AND MAKE THE OFFER

After the interviews and tests, it was time to select the best candidate. The best way to do this is to bring together the people who interviewed the candidates to share their impressions of each candidate so that the leader of the position can make the decision on who to choose. The decision of who to hire is of the leader who has the position open, but this time to exchange perceptions and interview notes is important. I usually call this meeting the “hiring committee”, which gives the opportunity not only to choose the best candidate, but also to better understand how people are doing the interview process and, eventually, align some points in relation to this process. This makes team members more engaged with the success of the person to be hired.

Once you have defined who the person is, you need to design the offer that will be made for them. It is important that the offer is financially relevant. It is not common for a person to accept receiving less than he is currently receiving. And it is important to balance short-term (salary and benefits), medium-term (bonus) and long-term (stock options) incentives. Be careful not to make an offer that is too inconsistent with what the current people on the team already have, so as not to create differences that can undermine teamwork.

ONBOARDING

Assuming that the candidate accepted the offer, we reached a new phase of the process, onboarding, that is, that of bringing the person to the team and becoming part of that team. HR will take care of the most bureaucratic part of this process, but it is also necessary to design with HR all the onboarding steps to ensure that the new hire feels welcomed and understands more about the company, the team and the challenges she will face.

At Conta Azul, we had a very cool onboarding process, coordinated by HR, where all new employees went through a week of immersion to get to know all areas of the company and the main members of those areas. Then, people had a local onboarding in the team that they would be part of. At Gympass, in addition to onboarding, everyone was invited to participate in some “activations”, which was the moment when we went to a customer to present the Gympass corporate benefit to their employees. It is important to give the new person who is joining the team the opportunity to learn more about the other areas of the company and the customer before they start working.

HR conversations with the person after 45 and 90 days after the person was hired can help to perceive points of improvement in the onboarding process. These first days of the person in your new team are fundamental to the success of the future relationship, so it is important to monitor closely.

FEEDBACK

The title of this chapter is “Hiring the right people”, but it is not enough to just hire, it is also necessary to take care of people for the entire time that she is on the team.

I wrote an entire chapter on “Feedback and performance evaluation”, but I want to mention this topic here since feedback is something very important for the people who are part of your team. How can they know they are on the right track? How can they improve? What are they doing and what should they continue to do? What are they not doing that they should start doing? What are they doing that they should stop doing?

It is very important to make it clear to each person on your team about these points. And it is very important to remember that feedback is a two-way street, meaning you should also look for what you can do to help the person.

ENDING A CYCLE

Eventually, you can make the decision to terminate someone, what is known as involuntary turnover. Or someone on your team can make the decision to leave your team, the voluntary turnover. This is always a difficult moment, a rupture, but it is important to understand the reasons that ended up building this decision. Could it be avoided? If inevitable, could it have happened in a more planned way, avoiding disruption for the team?

Summing up

  • The work of hiring people must be done in conjunction with HR. It’s teamwork.
  • The hiring phases are defining the profile, attracting candidates, interviewing, choosing and making the offer, onboarding.
  • The life cycle of a person on your team does not end with onboarding. It is important to constantly give and receive feedback from her, to ensure that the relationship works well for both the team and the new person on the team.
  • Finally, the last phase of the person’s life cycle on the team is when the person leaves the team. It is necessary to understand the reasons that led to this decision to understand how these themes can be worked on in the future.

In the next chapter, we will understand how to provide feedback and performance management.

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 almost 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

Relationships

As I commented in the chapter Roles, responsibilities and seniority, expectations management is something that occupies between 50 to 80% of the time of a head of product. Your daily routine revolves around your relationships and interactions with many people inside and outside your organization who are interested in the product you lead. In corporate jargon, these people are called stakeholders:

In the last decades of the 20th century, the word stakeholder has been increasingly used to mean a person or organization that has a legitimate interest in a project or entity. When discussing the decision-making process for institutions – including large companies, government agencies and non-profit organizations – the concept was expanded to include everyone with an interest or stake in what the entity does.

Source: https://en.wikipedia.org/wiki/Stakeholder_(corporate)

Evolution of the use of the word stakeholder in the literature (Source: Google Ngram Viewer)

A product manager with some experience knows the importance of maintaining good relationships with product stakeholders. I will share here two tools that help to better map these stakeholders and how your relationship with each one should be.

RASCI

RASCI is a very useful tool to help define and understand the roles and responsibilities of each person and function. It is the abbreviation of the first letters of the possible roles that a person, area or function can have in a task:

  • Responsible: is the person responsible for executing the task, that is, who has to lead the effort to plan, do and complete the task. There cannot be more than one responsible. Remember the saying that a dog with two owners dies of hunger.
  • Accountable: is the person responsible for the task and who has the power to delegate to the responsible the task to be done. Responsible and accountable can be the same person. The rule also applies that there cannot be more than one accountable per task. If responsible and accountable are two different people, the accountable can be seen as the sponsor.
  • Support: are the people or teams that work together and under the coordination of the responsible for the execution of the task.
  • Consulted: are the people or teams who do not participate in the execution of the task, but who need to be consulted before or while the task is being performed, as they can provide relevant inputs for its execution.
  • Informed: are the people or teams who do not participate in the execution of the task, nor need to be consulted before or while the task is being performed, but who need to be informed when the task is completed.

The following is an example of a RASCI responsibility matrix between engineering, UX, product marketing and product management that we used at Locaweb:

Locaweb’s RASCI responsibility matrix

How to use

The first step is to build the responsibility matrix. My recommendation is to fill this table by bringing together in a room all the people involved, so you can discuss whether the division of responsibility is ok for everyone and if there is a task missing. Most likely, some “shared responsibilities” will appear, but this is a great time to discuss them and define who is responsible. There can be only one person responsible for any task.

Then, the team should try to do the tasks following the responsibility matrix for some time, like one or two months. Then, it is important to do a retrospective to see if everything is ok, or if any adjustment is needed.

From then on, the use becomes automatic and people will no longer need to refer to the responsibility matrix. Every year or when a question arises, or even when a new task arises, it is good to revisit it.

Power-Interest Grid

The Power-Interest Grid is a concept first developed in the 90s by Aubrey L. Mendelow, and later explained in the book “Making Strategy: Mapping Out Strategic Success”, by Fran Ackermann and Colin Eden. Based on the power and interest that a person or team has in your product, you can classify them into 4 main categories.

Power-interest grid
  • The players are those who have great power and interest in your product. You need to collaborate with them often. The users and customers of your product are players, you need to collaborate with them to build the best product that solves their problems and meets their needs. In some companies, probably the closest founder to the product is also a player. You should invite these people to any meeting where strategic decisions are made. Schedule individually to present the decisions and ask for their comments and contributions.
  • The subjects are those with little power, but high interest in your product. They do not have the power to veto or change decisions, but they do have a deep interest in your product. In some companies, we can think of customer support, sales and marketing as examples of areas that play the role of subjects. They have great interest, but they do not have the power to change the product. You can communicate with them via weekly status email and product demos. It is important to collect their opinions, but remember that they do not have the power to change your decisions.
  • The context setter are those with the power to change your product, but little interest in your product. Examples of areas that can play a role of context setter are HR and Legal. If HR doesn’t help you build the team, you won’t have a team to build your product. If Legal is not aware of and aligned with the legal aspects of your product, it has the power to block or delay its launch. A CFO and a controller are also two functions that have the power to change decisions that affect your product. It is important to keep context setters well informed about product decisions. Consult with them before making important decisions. Keep them informed weekly.
  • The crowd is the one with low power and little interest. Even if they have little power and interest, it is important to keep them informed. Usually, a monthly update on the progress of the product is sufficient. It can be by email or in a monthly general meeting with product demos – I’ll talk about this and other meetings in another chapter. Usually it is people in the HR, Legal, Administrative and Financial areas who are not in the context setting group.

It is important to note that each company has its own dynamics, therefore, an area or person that plays a specific role in the power-interest grud of a given company may have another role in a different company.

Empathy

These two tools are very useful for the head of product to better understand how to relate to their stakeholders and how to manage their expectations, which, as I already said, will take 50% to 80% of her time.

Empathy is a fundamental tool for the head of product to be able to manage its stakeholders. As I commented in the chapter “Developing the team and managing expectations”, empathy is the ability of one person to put himself in the place of another to understand his expectations. Their desires, motivations, needs and problems.

This characteristic is important for the head of product to understand the customers and users of the product, to know how they relate to it, and what problems they expect to solve or what needs they want to be met. It also helps to understand the impact of your product on your team and people in other areas. Last but not least, the head of product also needs to put herself in the shoes of the owner of the product, to understand their expectations on the results the product will bring to the company.

Summing up

  • Expectation management is anywhere from 50 to 80% of a head of product’s time.
  • RASCI is a very useful tool to help define and understand the roles and responsibilities of each person and function.
  • The Power-Interest Grid, together with RASCI, is a great tool to help you better understand and interact with your stakeholders.
  • But don’t forget, the main tool that a head of product needs to better understand and, consequently, have improved and fruitful interactions with its stakeholders is empathy.

In the next chapter we will understand more about how to hire people for the team.

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 almost 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

Metrics

By now you should have realized how much I like metrics. In my first book, Startup Guide: how startups and established companies can create profitable digital products, I dedicated 6 entire chapters in addition to talking about metrics in the other chapters. In my second book, Product management: how to increase the chances of success of your digital product, there are 5 chapters dedicated to the theme of metrics, in addition to this theme appearing in other parts of the book again. It is no different here, the last two chapters talked a lot about metrics and I have also spoken in some other chapters about OKRs, objectives, data, and results.

Metrics are fundamental tools for any head of a product development team. Without metrics it is impossible to know if the team is progressing, evolving and fulfilling its mission. However, it is very easy to get lost in huge amounts of metrics.

In this chapter I want to share a little bit about how I usually work with metrics.

Metric types

I classify metrics into 3 major groups:

Internal metrics

These are the metrics that show how the product development team is at the moment and has evolved. The previous two chapters showed the metrics of productivity and quality. These are metrics that help the head of product and the team to understand how the work process is doing and where they should focus the energy to improve on these metrics. How can we increase productivity? How do we decrease the number of bugs? How do we guarantee the best product performance for our users?

Still within the theme of internal metrics, there are others that are more “soft” but also very important for you to understand the health of your product development team. They are metrics that help you understand if people are happy working in this team, if they are aligned with the culture and purpose of the team and the company.

A very simple metric to follow is the entry, exit and average time of the people of the team each month. If more people leave than enter, there may be a problem with the team. If people stay a few months and then leave, it is another point of attention. You can also run an NPS survey (Net Promoter Score) with team members periodically to understand whether they would recommend working on your team for others and why they answered this way.

The following are two examples from Gympass. The first is the evolution of the total number of people on the team month by month, with total new and total people who left, also showing how many of those left voluntarily, that is, asked to leave. The second is the eNPS (employee NPS), which shows whether people were willing to refer the Gympass product development team to their friends to join us.

volution of the Gympass product development team
NPS from Gympass product development team

User metrics

These are the metrics that show that your product is being used by users, that is, that it is fulfilling its objective. These are the metrics of engagement and user satisfaction with the product. What is your user’s ideal engagement with the product?

At Conta Azul we wanted the product to be the first window he opened in his browser in the morning and the last he closed at night. We tracked the number of invoices issued per user per week, per month, and the amount of the invoices. At Gympass, we monitored how many users went to the gym per month, how often they visited gyms, and so on. At Lopes, we are monitoring the use of the new CRM by brokers. We want them to use it at least 4 times a week and that’s the number we’re tracking.

Another user metric that can be useful is satisfaction metrics. This metric tends to be a little more subjective, in addition to being laborious to measure. You should send a mini-survey to a portion of your customers every day. Therefore, before measuring and monitoring it, I recommend closely monitoring the engagement with the product. If the user is engaged, using the product at the expected frequency, there is a good chance that he will be minimally satisfied.

Business metrics

These are the metrics that show the product development team is actually delivering value to the business owner. What was the goal that the business owner had for the product? Increase sales, decrease costs? These goals vary with the type of company where the digital product is located. Is it a digital company, a traditional company, or a traditional born-digital company?

At Conta Azul, as the product sold was the digital product, user metrics and business metrics mix a lot. The number of users that use several times a week are those that will certainly continue to pay the monthly subscription and, consequently, will continue to generate revenue.

At Gympass, a traditional company born-digital, and at Lopes, a traditional company, revenue exists without the need for a digital product. So, what can the digital product do to increase revenue or decrease costs? At Gympass, at the same time that we wanted to reduce operating costs by automating most manual tasks, we also used the product as a revenue enhancer, helping the HR of our customers and their employees to understand and, consequently, become subscribers to the service. At Lopes, the main focus is on increasing sales, but we also have a focus on how to lower operating costs.

A very important point to monitor every month is the comparison between the value delivered by the digital product – revenue increase and cost reduction – and the cost of product development. What is expected is that the value delivered will be greater than the development cost. And managing this is the role of the head of product.

Tracking metrics

Metrics can be tracked daily, weekly, monthly, quarterly and yearly. Of course, the longer the update period, the more difficult it is to understand the metric’s behavior and make decisions about how to impact it. I prefer metrics that we can monitor daily and weekly. With weekly metrics, in a quarter we have 13 opportunities to evaluate a metric, understand how we can work on it and remove any impediments that are hindering us in reaching any objective linked to it. And the daily metrics give the pulse of the business. How many new users per day? How many users canceled?

At Locaweb, we always followed these numbers daily and, if something was out of the expected, positively or negatively, we tried to understand what had happened that had impacted the number. When we did something with the intention of changing these numbers, such as a new marketing or retention campaign, we could monitor these results daily. It is even possible to measure even more frequently in the case of products with large scale, such as Google Search.

On the other hand, there are metrics that are less frequent, such as the example above that I gave of new people joining or leaving a product development team. Even with monthly metrics or less frequent ones, I recommend monitoring the partial of this metric at least weekly. If you only follow up monthly, in a quarter you will have only 2 opportunities to assess progress and correct the course.

Summing up

  • The metrics of a product development team can be classified into 3 major categories: internal, user, and business metrics.
  • Internal metrics show how is the health of the team. User metrics show the relationship of the user with the product. Business metrics are those that show whether the product is, in fact, delivering value to the business.
  • Metrics should be monitored as often as possible, at least weekly. Even if it is a monthly metric, try to follow the weekly or even daily partials of this metric, so you can have more opportunities to act earlier when there is a course variation.

In the next chapter, we’ll look at how to manage relationships with different areas.

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 almost 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

Measuring and managing quality

In 2015, we decided to extinguish the Quality Assurance (QA) function of our Locaweb product development team. We had 12 QAs, some with a developer profile and others with a SysAdmin profile. In proposing the extinction of the QA role, some of the QAs became devs, while others took on the role of system administrators. The reasons that led us to extinguish Locaweb’s QA function were:

  • When there is a QA function separate from the software development function, it is common to hear phrases like “the functionality is ready, now it is in the QA phase”, which denotes a cascading product development culture. This culture can considerably increase development time and negatively affect the quality of the software.
  • When there is a QA function separate from the software development function, it is also common to hear phrases like “why didn’t QA detect this bug?”, Which denotes a culture of finding the culprits. This culture can be very detrimental to the engagement and motivation of the team and, consequently, negatively impact the quality of the software.
  • Quality should not be the concern of a person or team, it should be the concern of everyone working on creating the software.
  • Quality is a non-functional requirement, that is, it specifies a criterion to evaluate the functioning of a digital product, while a functional requirement specifies a behavior of the software. Performance, scalability, operability, monitorability are some examples of non-functional software requirements that are just as important as quality. Even so, there are no defined functions to guarantee performance, guarantee scalability, guarantee operability and guarantee monitorability. Why is quality the only non-functional requirement that has a specific dedicated function to guarantee it?
  • Quality control focuses on ensuring the quality of the software development process. If a separate function is needed to guarantee this quality, why is there no need for a separate function to guarantee the quality of the product management process, the design process, the product marketing process, the sales process, the finance processof a company?
  • There was a concern that, if the engineer himself now had to test, deliveries would take longer to be ready. This concern existed because the engineers considered that their work was finished – and the delivery was ready – when they passed the story to the QA to test. However, the engineer’s definition of ready is incorrect, as he has just passed the story on to the next phase, the test. From the user’s point of view, the story is only ready when the user can use the new feature. Therefore, the time that the delivery remains in quality control is still development time, even though it is no longer in the hands of the engineer. And that time gets even longer when the story goes through quality control, but it is rejected and needs to go back to engineering.

When I joined the Conta Azul, they had also just extinguished the role of QA, and the ex-QAs became business analysts, mainly helping product managers.

I saw other companies also discussing the need for QAs, and in some cases, a heated debate emerges around this topic. However, having or not having QAs should not be the focus of the discussion. Having or not having this function is the solution to a problem, usually referred to as “how can we improve the quality of our product?”, And that problem should be the center of the discussion.

How can we improve the quality of our product?

A simple Google search for software quality will yield tons of definitions typically related to meeting functional and non-functional requirements. When the software does not meet a functional or non-functional requirement, it has a defect, a bug. Therefore, to improve the quality of a software product, we need to work on two things:

  • reducing existing bugs;
  • not generating new bugs.

A good way to track this is to have a weekly measurement of your bug inventory and new bug creation per week and discuss this every week with the team. We did that at Gympass. We define at the beginning of each quarter what the target is for the bug inventory and the average new bugs per week.

Total amount of bugs at Gympass

The image shows the evolution of our bug inventory during the 2nd quarter of 2019. We started the quarter with 215 bugs in our stock and we aimed for a target of less than 166 at the end of the quarter, a reduction of almost 23%. We ended the quarter with an inventory of 136 bugs, a reduction of 36%. We did this by focusing not only on resolving bugs in our inventory, but also on controlling the number of new bugs per week.

Number of new bugs detected per week at Gympass

In the first quarter of 2019, we had an average of 26.2 bugs created per week. During the second quarter, we reduced this average to 17.4 new bugs per week, to a total of 226 new bugs during the quarter. This is a 33% reduction in the number of new bugs per week.

That looks like a pretty good improvement, right? But there is a lot of room for improvement there. Let me explain the math of bug management:

If we were able to reduce our bug stock from 215 to 136, it means that we have resolved at least 79 bugs. However, we created 226 new bugs (17.4 new bugs per week x 13 weeks) during the quarter. So we solved 79 + 226 = 305 bugs during the quarter, a lot of bug fixing work. If we had generated 90 new bugs during the quarter, an average of 6.9 new bugs per week, instead of the 226 new bugs, we could have zeroed out on the bug inventory.

An additional aspect of the bug resolution to be measured is the SLA (Service Level Agreement) resolution, that is, how many days the team took to resolve a bug from the day the bug was first identified. For this, we classify the bugs by their severity, which is the impact it has on users and the business. The most serious bugs are those that we need to resolve on the same day; high severity errors, in 7 days and average severity, in 14 days. The following chart shows how we were at Gympass in the fourth quarter of 2019.

Gympass bug resolution SLA

This is not the ideal way of viewing this info because it shows only an image of the moment, and not an evolution. To understand the evolution of any metric, you need to see how it did at different points in time.

As soon as I joined Lopes, I started bringing this topic up for discussion with the teams. One of the things we noticed is that 50% of deployed items were bug fixes. I was informed that “these bugs were caught before going into production, which is a good thing”. In fact, it is a good thing that these bugs did not reach the production environment and appeared to our users. However, they reached pre-production and needed to be corrected. Wouldn’t it be better if these errors didn’t even exist, not even in pre-production?

The OKRs we defined to help us with the quality theme were 3 additional KRs in order to Increase the cadence of deploys in production that I mentioned in the previous chapter:

  • KR: Reduce the number of new bugs to 5% in pre-production.
  • KR: Reduce the number of total bugs to 10% in pre-production.
  • KR: Keep the number of total bugs below 5% in production.

And we add the following OKR:

  • Objective: To improve the quality of the deliveries to the squads.
  • KR: Review 100% of new stories to find poorly defined and / or ambiguous requirements.
  • KR: Perform a 25% review of the Pull Requests of the squads.
  • KR: Measure the Pull Requests volume of the squads.

Another example of bug tracking

At Conta Azul, we doubled the product development team in a period of 8 months between November 2017 and July 2018. This growth was aimed at increasing the team’s productive capacity.

Number of deliveries and people per week at Conta Azul

In addition, we divided the quantity of deliveries by the total number of people on the team to assess whether we were managing to increase our productivity individually.

Number of deliveries per person at Conta Azul

However, with the increase of people on the team, it ended up increasing the amount of bugs. So much so that the team that had already had 40% of its deliveries as a bug fix ended up having to increase this proportion to 60%. That is, despite having increased individual and total productivity, this increase in productivity was not being felt by the user, as it ended up being used for bug correction.

Percentage of bug fixes at Conta Azul

To control this problem, we increased our focus on fixing these bugs within the SLAs, which were:

  • 85% of tickets resolved within 7 days
  • 98% of tickets resolved within 30 days
7 day bug fix SLA at Conta Azul
30 day bug fix SLA at Conta Azul

See that the quality has worsened and the customer suffered from it. But, after some time, we managed to return to the defined SLA levels. We looked at this metric weekly and, whenever we discussed this metric, we agreed that the best way to comply with the SLA was not to create bugs!

Quality is not just bug control

In addition to bug control, there are several other aspects that impact the quality of the digital product that we deliver to users. Performance, scalability, operability, monitorability are some examples of non-functional requirements.

When I joined Gympass, on my second Monday the system went down for users around 7 pm. I started asking people on the team what was going on and the answer was that Mondays are peak days in terms of gym visits and that the system could not handle the volume at all. As there was no monitoring, we were not alerted that the volume was higher than usual and we were unable to prepare properly. Two months later, when Rodrigo Rodrigues joined Gympass as CTO, he dubbed the event “Black Mondays”. To address the problem, we started to monitor and implement an infrastructure that could handle Monday peaks. And we set OKRs for uptime, successful HTTP requests and backend response time.

Uptime – Gympass
Successful HTTP requests – Gympass
Backend response times – Gympass

Why is quality so important?

Any user prefers to use a good quality product that behaves as expected. This is a sine qua non condition to provide a good user experience.

In addition to the user experience, there is another important aspect to consider when we talk about quality and bugs. Whenever someone needs to work on resolving a bug that was found in a digital product, that person needs to stop working on whatever they are currently working on in order to resolve the bug. This is an interruption in the workflow. If that person were able to deliver the software without that bug, they could continue to work on new things without interruption, which would make them more productive.

The relationship between productivity and quality

I had the opportunity to participate in an MIT course on how to create high-speed organizations. The course was taught by Professor Steven J. Spear, author of the book The High-Velocity Edge: How Market Leaders Leverage Operational Excellence to Beat the Competition. This is one of those very dense courses, full of content, but which can be summarized in one paragraph:

High-speed organizations are able to learn very quickly, especially with their failures, and to absorb that learning as an integral part of the organization’s knowledge.

A high-speed organization works by following the 4 steps ahead:

  • Be prepared to capture knowledge and encounter problems in your operation.
  • Understand and solve these problems to build new knowledge.
  • Share the new knowledge with the entire organization.
  • Lead to develop skills 1, 2 and 3.

The classic example is Toyota, with lean manufacturing and the concept of stopping production whenever there are failures, correcting them and using them as a learning opportunity so that they no longer happen. This ability to learn from failure is what gives Toyota the ability to stay ahead of its competitors for so long.

Another good example is Alcoa, which had a work incident rate of 2% per year, which was considered normal. Alcoa has more than 40,000 employees, so 2% of work incidents per year means that 800 employees per year have some type of work incident. This is a very impressive and worrying number.

To combat this problem, they implemented a zero error tolerance policy. Before implementing this policy, mistakes were seen as part of the job. Employees are now encouraged to report operational errors within 24 hours, propose solutions within 48 hours and report the solution found to their colleagues to ensure that knowledge spreads throughout the organization.

This caused the risk of incidents to drop from 2% to 0.07% per year! This reduction in the incident rate meant that fewer than 30 employees per year had any work incident problems after the zero error tolerance policy was implemented and Alcoa achieved an increase in productivity and quality similar to that of Toyota.

Fail fast vs. learn fast

An important factor in the Toyota and Alcoa examples is that recognizing and learning from failures must be part of the company’s culture. This is somewhat more common in the culture of technology companies, but not so common in traditional companies. During the MIT course I shared a table with a Brazilian executive from Grupo Globo, the major TV company in Brazil, a Spanish executive from AMC Networks International (Walking Dead, Breaking Bad and Mad Men), a German project manager living in Azerbaijan who works for Swire Pacific Offshore (oil and gas industry) and an MIT postdoctoral student in solar energy from Saudi Arabia.

All of my table mates were from more traditional industries. I was the only one at an internet company. The executives at Globo and AMC were there because they saw Netflix with its streaming video on demand and YouTube with its huge catalog of user-generated videos as major threats, stealing their audience very quickly and they wanted to understand how they could defend themselves.

Although the theme is somewhat obvious for internet companies, especially with the culture of technology startups that value fail fast. That’s what makes Netflix and YouTube a threat to traditional media companies like Grupo Globo and AMC Networks. However, even though this is part of the culture of internet companies, sitting and discussing it with people from more traditional companies was a great opportunity to reflect on the relationship between failure, failure recognition, learning and high speed:

  • Recognizing the flaws and using the flaws as a learning opportunity must be well rooted in the organization’s culture. If people are not careful, as a company grows, it may lose the ability to accept failures as learning opportunities. It is very common for companies, as they grow, to become more and more averse to failure and to create a culture that ultimately encourages people to hide mistakes and failures.
  • Another important aspect of learning from failures is to make this process a company standard. There is no point in failing, acknowledging the error, stating that you will no longer make that mistake and, some time later, making it again. This learning process with failures must be part of the company’s culture. Whenever a fault is identified, learning should happen as quickly as possible to prevent it from happening again. If the same failure happens again, something is broken in the learning process with the failure.
  • Even in Internet companies, I realize that learning from failures is more common in the product development team, as retrospectives and continuous learning are part of the culture of agile software development. In other areas of the company, learning from failures is less common. This ability to systematize learning from failure must permeate the entire company.

Even though we hear a lot about the culture of internet companies to fail fast, talking about failing fast diverts our focus from what is really important, learning fast. We must put our energy into learning, not into failure itself. It is the learning process that makes people and companies evolve. And it is the ability of an organization to learn fast, especially with its failures, that will allow it to move at really high speeds.

Summing up

  • Questioning whether or not product development should have a dedicated QA team is not the right question.
  • The problem you are trying to solve is how to improve the quality of your product.
  • A good quality proxy metric is the bugs. Bug inventory, new bugs per week and bug resolution SLA.
  • A product development team must have all its members following these metrics and taking action to improve them.
  • Managing bugs is not enough to manage the quality of the digital product. Performance, scalability, operability, monitorability are some examples of non-functional requirements that directly impact the quality of the digital product.
  • Quality is at the forefront to provide a good user experience. In addition, it is essential to increase the speed of your product development team. The less bugs a team has to fix, the more time it has to focus on new things.
  • High-speed organizations are able to learn very quickly, especially with their failures, and to absorb that learning as an integral part of the organization’s knowledge.

In the next chapter we’ll see a little more about metrics.

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 almost 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

Measuring and managing productivity

How can we deliver faster? How can we deliver more with the same team? Why do we have the impression that the team is slow? When the team was smaller, it seemed that it could deliver more. These are very common questions and statements that I hear about product development teams. Every company that has a digital product development team would like this team to be faster. In this chapter, I will show you the two essential tools to achieve faster and more productive teams.

Measurement

There is no way to improve something that is not measured. What is product development speed? It is important to have a clear definition of this metric and have it measured.

In my last year at Locaweb, we were focusing a lot on productivity, that is, on how Locaweb’s product and software development teams could produce more, without having to add more people to the teams, and without dropping quality levels.

The following graph shows our numbers. We count quantities of deliveries per week and, as you can see, in a few weeks we were able to more than quadruple the quantity of deliveries per week.

Amount of deliveries per week at Locaweb in 2016

This increase in productivity happened when the team grew only 10% in number of people, so it is not possible to credit this increase in productivity to the increase in number of people in the teams.

When there is such an increase, in addition to the natural question about whether the increase in productivity is due to the increase in the number of people in the teams, another question that exists is whether there was a drop in the quality of deliveries. One of the quality measurements we had was the number of rollbacks. As you can see below, even with the increase in productivity, the number of rollbacks was reduced by 40%!

Number of rollbacks per week at Locaweb in 2016

At Locaweb we made estimated calculations of deliveries per week from September 2015 to February 2016. The calculation was very simple, total deployments made in the period divided by the number of weeks. We then started to communicate the entire company about the week’s deliveries.

After I arrived at Conta Azul, we decided to implement the same type of control of weekly deliveries and ended up also achieving a good increase in productivity.

Amount of deliveries per week at Conta Azul in 2017

Both at Locaweb and Conta Azul, each product manager sent me the deliveries of the week on Friday, I compiled the data and wrote down the quantity for each week, generating these graphs. From the moment we started measuring, it became clearer the level we were at, and the actions we started to take in order to increase productivity began to show results on the graph. In addition, the teams started to use a single measurement tool, JIRA, which gave them a better view of each team’s progress and allowed comparisons with the exchange of experience, that is, something like “look how interesting your graph is, how did you manage to increase this indicator? ”.

At Gympass, as we scaled the team very quickly, we decided to control the number of deliveries per person per week. We considered people who joined 2 months before since people need 1 to 2 months after they joined Gympass to become productive. In one quarter, we managed to increase our productivity per person by 16%. The number of deliveries was extracted directly from JIRA.

Amount of deliveries per week at Gympass in 2019

At Gympass, we also measure the number of deploys, both in our core, aka monolith, and in microservices. We also achieved a considerable increase in one year.

Number of deploys per week at Gympass in 2019

At Lopes, as soon as a deploy was done, an email was sent with a list of deployed items. One of the first things I did when I joined the company was to compile these reports in a spreadsheet to build the chart below. Hence it was easy to notice that the deploys did not happen every day. They happened once per week on average. As soon as we noticed this, we defined OKRs to increase the frequency of deploys, which has been yielding results. The OKRs we defined were:

  • Objective: Increase the cadence of deploys in production;
  • KR: Increase the number of deploys per week to at least 3 (the more the better);
  • KR: Reduce the maximum number of new features per deploy to a maximum of 10.
Number of deploys per week at Lopes

What impacts productivity

The productivity of a product development team is impacted by several factors. I once found a very interesting article written by Michael Dubakov, founder of the company Targetprocess where he shows a mind map with all the elements that can positively or negatively impact the productivity of a product development team. This article is no longer available, but thanks to the Wayback Machine website (http://web.archive.org), you can access it at:

http://web.archive.org/web/20150827162352/http://www.targetprocess.com/articles/speed-in-software-development/

The mind map is this one:

Number of deploys per week at Lopes

This diagram shows things and activities that affect the speed of development in some way. Green means that the activity increases speed. The more you have, the better. Yellow indicates that there is some maximum. For example, you can accumulate technical debt and increase speed, but if you accumulate too much, it will significantly delay you. Red shows things that slow development, the less you have, the better. The green arrow indicates an increasing effect. For example, focused work increases the speed of development. The red arrow indicates a decreasing effect. For example, better development skills decrease the complexity of the system (good engineers create less complex systems).

What I like about this image is that it shows how complex this theme is and how many things can positively or negatively impact the team’s speed. At Conta Azul, we followed this topic every quarter at the Product Council, a meeting where we talked about the quarterly planning of the product development team with the leadership. There was a slide where we listed all the topics that could impact the speed to discuss what we were doing about each of these topics.

Themes that impact the speed of the Conta Azul product development team

Place the topic of productivity at the center of the discussion

There is no silver bullet, with each team I’ve worked on there were several actions we took and we were always sure that there are always more actions that could be taken to increase productivity even more.

The only silver bullet that exists is we made productivity into an important topic in our conversations. Everyone started talking about productivity and what we could do to improve it.

This movement made us initiate several changes and experiments that helped us to increase our productivity considerably. If you also want to increase the productivity of your product development team, place this topic at the center of your conversations and experiment a lot. You will see how there is room to greatly improve the productivity of your software development team.

Another important point: be sure to discuss the topic of productivity frequently. My recommendation is that you do it weekly. Creating a weekly cadence will give you the opportunity, each week, to experiment with something new and discuss the results with the team.

Summing up

  • There is no silver bullet to increase the productivity of a product development team. However, there are two essential tools to help achieve this goal.
  • The first tool is measurement. There is no way to improve something that is not measured. What is product development speed? It is important to have a clear definition of this metric and its measurement.
  • The second tool is to bring the topic of productivity to the center of the discussion. Everyone on the product development team is responsible for the team’s productivity. Therefore, by bringing the topic to the center of the discussion, everyone will be able to collaborate to improve productivity.

In the next chapter we will see another metric that has a direct impact on productivity, quality.

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 almost 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

Vision, strategy, objectives, and team structure

This is the beginning of Part III of the book, about Tools, I’ll talk about the tools I’ve been using in my almost 30 years of product development leadership career and passing them to other leaders so they can use them with their teams. The tools I’ll talk about include vision, strategy, objectives, metrics, relationships, hiring, feedback, and ceremonies.

You will notice that the tools that I’ll comment on here are not software such as spreadsheets, presentations, documents, Slack, JIRA, Confluence, etc. These apps are normally very useful, but they are only a vehicle for documentation, communication, and metrification of the tools that we will see in the following chapters.

Vision, strategy, objectives, and team structure

All of these items are, in addition to very important concepts, essential tools for any head of product. In all the opportunities that I started as head of product, these were the first topics that I dealt with, always starting with a product vision and then moving on to the themes of strategy, objectives, and team structure. This is also my first focus when I start any advisory work. I try to understand what’s the vision, strategy, objectives, and team structure. If any of these elements is missing, I help people in the company to create them.

I have already explained what they are and how to create each of these items in their respective part I chapters, so I will just do a quick review of these tools.

Vision

As I explained in the chapter Product vision, to make the product vision, it is necessary to be clear about the company’s objectives with the product, as well as to deeply understand the problems and needs that customers have and that will be solved by the product. The 6 steps to build a product vision are to obtain strategic objectives of the company, gain an understanding of the problems and needs of customers, design the first version of the vision, iterate and refine, communicate and review.

I usually document and communicate the product vision in a presentation. If necessary, I put some theoretical introduction explaining the concepts of platform and marketplace. In every presentation I make, I usually present the product vision as an introductory topic to set the context and to make it clear to everyone.

Strategy and objectives

The product strategy is nothing more than the path you will take to reach your product vision. To create your product strategy you need to have a good understanding of your market, that is, the competitors, the potential and accessible market, the growth of that market, if there are disruptors, and how it is regulated. You also need to understand your strengths and weaknesses, opportunities and threats. A SWOT analysis can help. With this information in hand, you define what you and your team will do to achieve the product vision, what goals you need to achieve, and what metrics will tell you that you are achieving those goals. OKRs are a great tool for working on your goals and metrics.

There are some books and courses talking about how to define and use OKRs. So I’m not going to go into too much detail here. In a very succinct way, you define together with the team some objectives for a period – usually a quarter or a year – and define which metrics you will use to show that the objective is being reached.

I usually document the OKRs in spreadsheets, which I use to follow the evolution every week with leaders of my product development team, and also present and discuss the OKRs with other leaders and areas of the company. The following is an example:

Exemple of an OKR worksheet

Note that every week the KRs are updated. Each team leader updates their KRs with their teams every Monday, and then leaders and heads of product go through the KRs to see how they are doing and if there are any impediments where energy can be put in to remove. I like to do it on Monday because it helps the team organize the work of the week. The weekly cadence is essential to help the team review performance at least weekly and make adjustments if necessary. If the cadence is higher (biweekly or monthly), valuable opportunities to correct problems and remove impediments are lost.

The column T0 indicates the initial value of the metric. The responsible column has the name of the person who is responsible for that KR and who will lead the effort to make it happen. And the support column lists the people or areas that will help the person in charge.

It is worth remembering that the closer to the company objectives and business metrics the OKRs are, the better it will be for the team, as they will be working to help the company with its objectives and results.

Team structure

In the chapter Team Structure I said that product development teams are organized into minimal teams, also called squads, composed of engineers, product designers, and product managers. It is important to keep the team as lean as possible to help your productivity. These minimum teams are grouped into product teams called product tribes.

There are 4 ways to organize product teams: by product or functionality, by type of user, by journey or by objective. You can also use two different types of organization to create a hybrid organization. There are also the structural tribes, which create the necessary structure for the product tribes to perform. Teams that make up the structural tribes are SRE / DevOps, Data, Architecture / Tools / Foundation, Design Ops, Information Security, Internal Systems, Sales Engineering and Professional Services.

To help organize the team, I usually use a simple spreadsheet template like the following:

Example of team structure worksheet

This worksheet contains the team structure and the people who are part of it. Note that we are not documenting functional leadership, but the leadership of each team. In the example, we have John as GPM leader of PM Lucy and PD/UX Patricia, Mary as GPM leader of PD Rafa and Sandra as leader of the structural teams of SRE / IT, Data and Peter, who leads the engineering of 2 squads of the tribe A and tribe B squad.

An important point is that it is not enough to just create these elements and then not use them. These tools are useful the more you use them. I use OKR worksheet at least every week. Whenever I have the opportunity I talk about Vision and strategy. Whenever I talk with my leaders about hiring or changes in the team, I use the team structure spreadsheet I showed above.

Summing up

  • Vision, strategy, objectives and team structure are, in addition to very important concepts, essential tools for any product head.
  • For vision and strategy, a presentation with a few slides is sufficient. For OKR and team structure, spreadsheets do the trick.
  • More important than the software you use to document Vision, strategy, objectives and team structure is what you do with these tools. I use OKR worksheet at least every week. Whenever I have the opportunity I talk about Vision and strategy. Whenever I talk with my leaders about hiring or changes in the team, I use the team structure spreadsheet I showed above.

In the next chapter, we’ll look at how to measure and increase the productivity of a product development team.

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 almost 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