Culture and values

After talking about my leadership principles, I will talk about another fundamental theme for a head of product, organizational culture and values. There are 5 values ​​that I consider critical for the success of the product:

  • Don’t waste time looking for culprits, focus on learning.
  • Don’t compare work situations with war, nobody wants to kill anyone.
  • Profit and revenue are a consequence, they should not be the main focus.
  • Transparency, the foundation of a high performance team.
  • Diversity, the basis of the best products.

Let’s start by defining culture.

What is culture?

The word culture comes from the Latin cultus, which means “care”, and from the French colere, which means “to cultivate”. Edgar Schein, a professor at the MIT business school, was one of the first people to talk about organizational culture in the 1970s. According to him, each company had its own personality, and its own way of acting and reacting to situations; this form is passed from employee to employee since the company’s founders.

Organizational Culture

Culture is a set of premises that were learned and shared by a group of people while solving problems of external adaptation and internal integration. This set of premises works well enough to be considered valid and, consequently, to be taught to new members of the group as the correct way to perceive, think, and feel about these problems.

Source: SCHEIN, Edgar. Organizational Culture and Leadership. Jossey-Bass, 2010

The culture comes from the company’s founders. The founders have their own culture and it is natural that they impress it in the organization they are creating. As a result, it is very common to think that it is something that emerges in an organization. Schein warns that this is a mistake. Cultures can and should be planned and it is the role of the product head to help plan and promote the company’s culture. For this reason, I am sharing these five values ​​that I believe are critical for the development of successful digital products.

Don’t waste time looking for culprits, focus on learning

When mistakes happen it is common for people to try to find out who was responsible for the error. This can end up generating a culture of fear of making mistakes and, consequently, of wanting to hide mistakes, especially if there is any punishment.

The teams that not only recognize their mistakes but use them as a source of learning and improvement are the teams with the best performance. In the book The High-Velocity Edge: How Market Leaders Leverage Operational Excellence to Beat the Competition, MIT professor Steven J. Spear explains that a high-speed team has four skills:

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

According to prof. Spear, that’s the secret behind Toyota’s success for so many years. Alcoa is another good example. It had a work incident rate that was around 2% per year. In a team of 40 thousand employees, this means 800 employees per year with some work incident, more than 2 per day. 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 operating 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 less than 30 employees per year had a work incident problem after the zero error tolerance policy was implemented and Alcoa achieved an increase in productivity and quality similar to that of Toyota.

In the book Smarter Faster Better: The Transformative Power of Real Productivity, Charles Duhigg, author and journalist awarded the Pulitzer Prize, compares the performance of two ICU teams, one of whom usually meets daily to discuss problems and how to avoid them and the other that usually punishes employees who make mistakes. The team that discusses and learns from mistakes performs better, which, for an ICU team, means fewer deaths and more recovered patients.

This type of environment that learns from mistakes is known as a psychologically safe environment, that is, in which people on the team can do their job without fear of negative consequences. As the product head, it is your role to create such an environment for your team and the entire company.

Don’t compare work situations with war, nobody wants to kill anyone

I often see the use of war analogies in the daily lives of companies. We will defeat this competitor. Let’s create this war room to address this issue. This is a war, we have to beat our enemies. There is a book called The Art of War, attributed to a Chinese general named Sun Tzu who lived between the years 550 and 500 BC, which is considered one of the 10 most influential business books of all time. This book has phrases like “In the face of a long battlefront, look for the weakest point and, there, attack with your greatest strength” and “The supreme art of war is to defeat the enemy without fighting”.

Although I understand the image that we want to create by making this comparison of war with business, to generate greater motivation in the team of a common enemy to be defeated, I am deeply disturbed by this analogy. War is a very ugly and sad thing. Try writing war on Google and click on the “Images” option. You will see many pictures of pain and suffering. In a war, for someone to win, someone must lose.

In my view, business is the opposite of that. The most prosperous businesses are those that positively impact everyone around you, employees, customers, suppliers, society, and even competitors. A good competitor is one that motivates you to improve. Competitors take companies out of their comfort zone. If it weren’t for them, companies would evolve much more slowly. In addition, competitors can and should join associations to pursue common goals.

Profit and revenue are a consequence, should not be the main focus

Yes, the goal of every company is to grow and make a profit, but that should not be the focus. A company’s primary purpose should be to help its customers in some way, and revenue and profit should be used as metrics that indicate whether the purpose is being fulfilled. But they shouldn’t be the only metrics, since there is always a risk of getting bad revenue, which can happen when we keep the main focus on having more revenue.

Imagine a situation where you subscribe to a service with a monthly payment and, for some reason, you need to cancel your subscription. When you try to do this, you discover that the cancellation process is super complicated. This will certainly leave you dissatisfied. The same thing happens when you take water from the fridge in a hotel room and discover that the water bottle costs 3 times more than in a supermarket. These are situations that even generate revenue for the company, but it is bad revenue, which leaves customers dissatisfied and that will probably make these customers not return and even speak ill of your company when they have the opportunity.

For this reason I like to make an analogy between recipe and profit with food:

Revenue is like food, it is necessary, it is vital for the health and success of a company, but it is not the purpose of life. You don’t wake up in the morning and the first thing you think is “how can I get more food?”

However, both a company and a person must always be attentive to the quality of the food they are eating, to be sure that it will not cause any harm to their health.

Summing up

  • Culture is the way a group of people responds to everyday situations. It is the role of the product head to assist in the design and promotion of the company’s culture to ensure an environment conducive to the development of successful products.
  • It has five values ​​that I believe are essential to help create a culture that enables the development of successful products. In this chapter I spoke of 3 of those values: don’t waste time looking for the culprits, focus on learning. Don’t compare work situations with war, nobody wants to kill anyone. Profit and revenue are a consequence, it should not be the main focus.

In the next chapter, we’ll talk about the importance of transparency in creating high-performance teams.

Missing something?

So, did you miss something in this chapter? What else would you like me to cover?

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? While you wait for my new book, check out my Digital Product Management bundle with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.

How and when to delegate

Delegating is the act of entrusting someone with a task and/or responsibility, usually with less seniority than the person who is delegating. Leadership is an ongoing act of delegating tasks and responsibilities. It seems like a straightforward activity, but it has several important aspects to consider to increase the chances of success.

Jurgen Appelo, author of the aforementioned book Management 3.0: Leading Agile Developers, Developing Agile Leaders, comments that delegating is not a binary decision to which you delegate or do not delegate. There are other levels of delegation between these two extremes and each of these other levels should be used depending on the context, that is, the problem to be solved and who will be working on the problem. According to him, there are seven levels:

  • Say: you make decisions and announce them to your team. In fact, this is not delegation. (=
  • Sell: you make decisions, but try to “sell” your idea to your team.
  • Consult: you invite your team to comment and consider their contributions.
  • Agree: you invite your team to participate in a discussion and reach a consensus as a group. Your voice is just like the others.
  • Advise: you try to influence your team by giving them advice, but let them decide what to do with your opinion.
  • Ask: you let the team decide. And then you ask about their motivations or ask them to actively keep you informed.
  • Delegate: you leave it entirely to the team to handle the matter, and you don’t even need to know what decisions they make.

I confess that in my day to day I don’t think about what kind of delegation I’m doing in each situation, it’s something more intuitive, but it’s good to be aware of and to remember these different levels of delegation. I have the impression that between “saying” and “delegating” there are more than 5 options. We navigate between these options fluidly according to the seniority of the team, the specific experience of the team with the topic in question, and how much this topic implies in any kind of risks.

The concept of delegation goes hand in hand with the concept of micromanagement:

Micromanagement

Micromanagement is the management style in which the manager closely observes or controls the work of his subordinates or employees. Micromanagement generally has a negative connotation.

Source: Wikipedia

Micromanagement shows the leader’s inability to delegate. There are usually two reasons for a leader to micromanage his team:

  • Insecurity: the leader is insecure, concerned with doing everything right, so he wants to follow every detail of everything that is being done. In some (many) cases, this leader will do the work of a person on your team to ensure that it is being done “the right way”. This type of leader often creates many rules and procedures to ensure that things are being done the way he takes for granted.
  • Personality: It is the leader’s personality to enjoy seeing people suffering under pressure. This leader tends to be abusive on a daily basis with the team. He won’t do anyone’s job, but he will follow all the details closely to see them uncomfortable under this constant scrutiny.

The most common is to find leaders with insecurity, usually people who are leading for the first time, but who eventually end up understanding their role and exercising delegation. Leaders who micromanage because of their personality are rare and unlikely to change.

People on a team that is being micromanaged tend to quickly disengage. Once they are doing things the manager’s way, they do not perceive themselves as responsible for the result obtained, whether the result is good or bad. If the result is good, the leader will probably attribute success to his way of doing things. If it goes wrong, the person who did the job will not feel responsible, as he “just followed orders”.

Ways to do

One of the biggest barriers to delegation is the leader’s certainty that his way of doing things is the right one. When he was an individual contributor he did things that way and the result came. So much so that he was promoted to manager for doing things that way. So, what he understands that he has to do as a manager is to make sure that all the people on his team do things the way he does. At that moment, this leader’s need for micromanagement appears.

A leader must always focus on the expected result. The way in which this result is achieved is less important than obtaining the result. If a person on your team does things differently than you usually do, it does not mean that the way they do it is wrong (of course, as long as it is not an illicit way and does not harm people). It’s just a different way of doing things. Perhaps even more efficiently. The leader needs to respect this diversity of ways of doing things and only present his way of doing it when he realizes that the person is not managing to evolve alone.

Learning opportunity

Every time we delegate something for someone to do, if it is the first time that person is doing it, it will be a learning opportunity. For this reason, the person is very likely to make some mistakes, and here comes one of the most difficult trade-offs of a leader. How much error is acceptable? This depends a lot on each situation, it is up to the leader to understand if the mistakes are acceptable to allow learning, or if given the criticality of the work to be done, mistakes must be minimized. We must always create an environment conducive to learning from mistakes, as this will be the most effective learning. That’s what I try to do with the teams I lead.

Summing up

  • *Delegating is the act of entrusting someone with a task and/or responsibility. Leadership is an ongoing act of delegating tasks and responsibilities.
  • Between not delegating and delegating there are several levels of delegation that are used according to the context, that is, the problem to be solved and who will be working on the problem.
  • The concept of delegation goes hand in hand with the concept of micromanagement, a management style in which the manager closely observes or controls the work of his subordinates or employees.
  • There are different ways of doing things to achieve the same result. New leaders often think that only their way of doing things is right.
  • Mistakes are incredible learning opportunities. Hence the importance of tolerating mistakes at work.

Okay, with this chapter we conclude the part about my personal principles of leadership (people: priority # 1 – always, leading is like being a doctor, leading under pressure, mentoring is a two-way street, and how and when to delegate). In the next chapters, we will see what culture is and what values ​​I believe are mandatory to create successful digital products.

Missing something?

So, did you miss something in this chapter? What else would you like me to cover?

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? While you wait for my new book, check out my Digital Product Management bundle with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.

Mentoring

Mentoring is one of the most important responsibilities of a head of product: helping your team to evolve. As I said earlier, between 10% to 40% of the head of product’s time should be focused on helping people on your team on their development.

People who know me know that I like clearly defined terms, so here’s Wikipedia’s definition of mentoring:

“Mentoring is a process of informal transmission of knowledge, social capital, and psychosocial support perceived by the recipient as relevant to work, career or professional development; mentoring involves informal communication, usually face to face and over a period, between a person who is perceived as having more knowledge, wisdom or relevant experience (the mentor) and a person who is perceived as having less (the mentee) ”.

From this definition, the unidirectional nature of mentoring is clear, that is, knowledge flows from the “mentor” person to the “mentee”.

I received and gave guidance throughout my career. Even when I was a student, I gave and received guidance. I think someone has received guidance since she was born. Since the beginning of my career, I have had the opportunity to give guidance to the people I lead and, more recently, I have been invited to guide entrepreneurs and product managers to help them in the next stages of their ventures and careers. I am very happy to know that I can help someone by sharing my experience.

A two-way street

However, my experience as a mentor has shown me that Wikipedia’s definition is incomplete. Wikipedia defines mentoring as the transmission of knowledge. My understanding is that mentoring is more than a transmission of knowledge. It is an exchange of knowledge. Even considering that one of the people involved in the mentoring process is more experienced in a certain aspect, topic, or area, the other person may have experience and knowledge in another aspect, topic, or area that can bring new insights. Or the other person can use her novelty in the topic she is being mentored to bring a new perspective that the mentor has missed.

Therefore, the next time you are in a mentoring situation, especially if you are in a mentor position, think of it as an exchange of knowledge, social capital, and relevant, useful, and valuable psychosocial support for both the mentee and the mentor. I have a feeling that you will enjoy your next mentoring session even more.

Summing up

  • Mentoring is one of the most important roles for a product head. It is through mentoring that a head of product helps his team to develop.
  • Mentoring is a two-way street. The person in the role of mentor should be open to new learning from his mentoring sessions with his mentor.

In the next chapter, we will understand a little more about culture, what values ​​are essential for a company to have successful products, and the role of the head of product in creating and maintaining the company’s culture.

Missing something?

So, did you miss something in this chapter? What else would you like me to cover?

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? While you wait for my new book, check out my Digital Product Management bundle with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.

Leading under pressure

There is no work environment without pressure. I don’t know of any workplace where people say that goals are easy, that there is no risk in achieving the goals, or that the project will be delivered on time with 100% confidence. If the company is growing rapidly, people need to sustain or improve that growth rate. If the company is in crisis, people need to get the company out of the crisis.

And that’s good! In fact, this is the only way to do things! People need pressure to get things done.

What do leaders need to know about pressure? People, including leaders and the people they lead, receive pressure from outside (the objective, the expected delivery date, the lack of resources), as well as from within (motivation, drive, inner strength).

Think of people and teams as balloons

A good analogy that I like to use, especially when the external pressure increases, is that people and teams are similar to balloons. We need to balance the external pressure with the internal pressure, with some tendency to have a little more pressure on the outside to guarantee the best performance. If we put too much pressure on the outside, without providing people with the necessary tools to increase the internal pressure, the balloon will explode, that is, performance will decrease, people will be uncomfortable, sometimes they will even get sick (burnout) and will probably leave the company. Sometimes we can see some increase in performance right after an exaggerated increase in external pressure, but we should not be fooled by these initial results. They will not be sustainable if the internal pressure is not increased. This increase in performance will last for a few days and performance will decline to even lower levels than when we increased external pressure.

How can we improve internal pressure? No one can directly impact anyone’s internal pressure. This can only be done indirectly. Here are some tools:

  • We need to hire people with the right motivation, drive, and inner strength, and we must create the environment so that these people can maintain the right motivation, drive, and inner strength. Think about aligning objectives, vision, values, culture, and financial and non-financial incentives.
  • We must support the right balance between moments with and without pressure. We can do this by encouraging people to step away from pressure in the workplace and to do other things they enjoy, such as exercise, yoga, meditation, music, reading, spending time with loved ones, cooking, partying, etc. On the other hand, we should avoid working long hours, at night, on weekends and holidays. Note that working long hours is a tactic that can and should be used, but only when necessary. If this becomes the norm, rather than the exception, we are not supporting the right balance between moments with and without pressure.

The balloon analogy works for both individuals and teams. Too much pressure on a team without the proper internal pressure will cause the balloon to explode. In the case of a team, it will begin to malfunction, team members will begin to point fingers at each other and performance will drop. To increase a team’s internal pressure and help them deal with increased external pressure, we need to create an environment that promotes the creation of stronger ties between team members so that they are more effective in responding to external pressure, being more resilient, and more adaptive at the same time. More effective responses to external pressure require a combination of resilience and adaptation.

The balloon analogy is also good for explaining why the best people decide to leave a company. We can think of this situation as if there is more internal pressure than external pressure. If a person or team has more motivation, drive and inner strength than what the leader asks of them or the company’s strategy requires of them, they will inflate the balloon until it explodes. Then they will leave the company. Remember priority #1: people, always.

Summing up

  • There is no work without pressure environment. People and teams need external pressure (the goal, the expected date, the lack of resources) and also from within (motivation, drive, inner strength) to exist and do things, like a balloon.
  • The internal pressure and the external pressure need to be balanced with some tendency to have a little more pressure on the outside to have continuous improvement.
  • Under pressure, a person and a team explode or become stronger. It is the leader’s role to help the person or team to realize this and work together with them to support increased internal pressure.

In the next chapter I will talk about mentoring.

Missing something?

So, did you miss something in this chapter? What else would you like me to cover?

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? While you wait for my new book, check out my Digital Product Management bundle with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.

Leading is like being a doctor

In February 2011 I underwent cervical spine disc replacement surgery. The doctor performed the surgery on February 25th. However, the healing process took months. According to the doctor, it could take a year for all the symptoms that motivated the surgery to disappear.

What caught my attention is that the surgeon only makes an intervention, but the entire healing process is done by the body. The same happens when a doctor prescribes a medicine, which is also an intervention, but, again, the body is in charge of the entire healing process.

Leading a team is very similar. The leader must make some interventions when necessary, but it is up to the team to do the work to achieve the goals.

Agile leadership

In one of my readings on leadership, I found an interesting comparison between leadership and gardening by Jurgen Appelo, author of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders:

I tend to compare managers to gardeners. An unattended garden is usually full of weeds, not beauty. From a biological perspective, there is no difference. Either way, the ecosystem in the garden is self-organizing. It takes a gardener (authorized by the garden owners) to transform an anarchist garden into something that the owners will enjoy. Likewise, a manager (authorized by the shareholders) is needed to lead the self-organized teams in a direction that adds value to the shareholders.

Even though I like this comparison, he considers that the gardener / manager must constantly interfere, which I do not believe is a suitable behavior for a manager. In my opinion, a manager’s interference should only be done when necessary and, after the interference, the team should work on its own to resolve things with little or no intervention from that manager. Hence my comparison with a doctor who interferes only when necessary, prescribing changes in habits, medicines, physiotherapy and / or surgery and who lets the body do the work and take responsibility for the healing process.

Summing up

The next time you are on a team, either as part of the team or playing the role of leading the team, think of the doctor’s leadership role and teamwork similar to the body’s healing process. It helps to understand the roles and responsibilities of the leader and the people on the team.

In the next chapter, we will understand how to lead under pressure.

Missing something?

So, did you miss something in this chapter? What else would you like me to cover?

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? While you wait for my new book, check out my Digital Product Management bundle with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.

People: priority #1, always

Every company has its own culture and, within each company, every department also has its own culture. In addition, each person also has their principles and values ​​that guide their steps through life. In this part of the book, part 2 of 3, I will talk about the culture, values ​​and principles that I believe are mandatory to create successful digital products. Also, what are the 4 main values ​​that every product development team and, consequently, every company that has digital product development teams should have.

I’m going to start this part of the book by sharing my personal leadership principles. There will be five principles:

  • People: priority # 1, always
  • Leading is like being a doctor
  • Leading under pressure
  • Mentoring is a two-way street
  • How and when to delegate

I will talk about these principles throughout this and the next chapters, starting with the principle that people are priority #1, always.

People: priority #1, always

I often see companies claiming that company valuation, revenue, growth, profit, number of customers, or customer satisfaction is their number one priority. All are good priorities and each is appropriate for specific contexts in which a company can be. However, I argue that they should be priority number 2, 3, 4 and so on, because our number 1 priority should always be the people who are part of our team. Without the people who work with us, it will be very difficult, if not impossible, to achieve any other goal that we have.

People are people (source: Flickr)

We spend money and energy attracting the best people and convincing them to join our company to build what we intend to build to achieve the goal we have set. We pay these people to be with us throughout the construction process. We are usually upset when we lose people on our team, especially if they are really engaged and aligned with our goals. Therefore, the people on our team are like customers, we spend money and energy to acquire and retain them. But they are even more important than our customers, because without our team, there is no way for us to be able to deal with our customers and achieve our goals.

This does not mean that we need to be “nice” to our team, or that we should give everything they ask for. What we need to do is to balance external and internal pressures so that people can continually improve. If the external pressure is increasing, we need to create the environment and provide the tools for people to be more motivated, have more drive, and increase their inner strength. And if we have people or teams with excess motivation and energy, we need to give them more responsibilities and higher goals. In the chapter Leading under pressure, I will talk more about this balance.

Rotten apples

The term rotten apple, although quite strong, serves to describe a very delicate situation in the formation and management of teams. We call the person who negatively clashes with the rest of the team and who, with his behavior, may spoil the team.

InfoQ (https://www.infoq.com/news/2009/01/handling-your-underperformer/) talked a lot about the technically rotten apple theme, the under-performer, the one who is technically below the rest of the team, and how the team can help this person to improve.

What to do when we come across a rotten apple from a behavioral point of view? Someone who is technically good, but who has behavioral problems? Technically this person can have enough to contribute to the team but his behavior makes the team unable to have a good relationship with that person.

In such cases there are two paths to follow:

  • The simplest is to remove that person from the team. This is an easy solution for both the team and its leader. The tendency in such a situation is for the team to isolate the difficult person until he, by himself or by the leader’s decision, leaves the team.
  • The most difficult path, but which will certainly bring more benefits to the team, is to help this difficult person to belong to the team to the point where the person is no longer a bad apple.

It is easy to welcome people who are easy to deal with. The challenge is to receive a difficult person and help them join the team. The values ​​of the team must be stronger than the values ​​of the difficult person to the point that the values ​​of the team are absorbed and assumed by the difficult person.

Frank conversations with the whole team and with the difficult person are a good tactic. Transparency is essential. If there are goodwill and willingness from both the team and the “rotten apple”, chances are good that the situation will be reversed.

It is worth remembering that, in most cases, a rotten apple does not want to be a rotten apple. He may not realize that her behavior is harmful to the team. He may have had previous experiences where her behavior would be considered normal. So it is worth investing in helping the team and the difficult person to understand each other. However, it is not possible to try indefinitely to make things right. It is important to set a deadline to reevaluate the situation and, if it has not been resolved, there may be no other option but to make a more difficult decision: dismiss one or more people from the team.

Summing up

  • People are, and should always be, the #1 priority of any company. We spend money and energy to acquire and retain the best people. Having people as #1 priority is the key to achieving any other goal. This does not mean being “nice” to people giving everything they want, but that we must be able to balance the challenges that we give people with their abilities so that people can continually improve.
  • Rotten apples can drain and harm your team. You must help these people to fit into your team and, if that is not possible, you must make the most difficult decision: get that person out of the team.

In the next chapter, we will understand what a leader’s job should be like through the analogy that leading is like being a doctor.

Missing something?

So, did you miss something in this chapter? What else would you like me to cover?

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? While you wait for my new book, check out my Digital Product Management bundle with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.

Leadership anti-patterns

An anti-pattern is a common but ineffective and counterproductive response to a problem. This term was coined by Andrew Koenig in 1995, inspired by the 1994 book Design Patterns: Elements of Reusable Object-Oriented Software by Gamma Erich, Helm Richard, Johnson Ralph, and Vlissides John, who lists a series of software development design patterns that their authors found simple, succinct and effective for the most common problems.

The term was popularized by the book AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis by Raphael Malveau, William Brown, Hays McCormick, and Thomas Mowbray, which extended its use beyond the software design field to refer informally to any bad solution to a problem.

Wikipedia anti-pattern page lists over 70 antipatterns. I will list below the anti-patterns that I have encountered most often in my career. These anti-patterns that I quote below happen when the company’s leadership does not have enough experience in digital product development and is advised by people who have been successful in managing software development in the past, but who have not updated themselves.

As I explained in the introduction, software development is a very new science, especially when compared to other sciences like astronomy, medicine, mathematics, chemistry, civil engineering, etc. The first time a computer stored software in memory and successfully ran it was at 11 am on June 21, 1948, at the University of Manchester, on the Manchester Baby computer. This means that software product development is in its infancy. If a professional does not keep up to date, the knowledge and experience that has made him successful in the past may not be the most suitable to make him successful in the future.

Documentation

Excessive use of documentation will undoubtedly slow down the product development team. It is not for nothing that in the Agile Manifesto, written in 2001, we say that we value “Software in operation more than comprehensive documentation”. Unfortunately, for some leaders documentation is even more important than the product itself. Nothing can go into production if it is not properly documented.

The last time I wrote a PRD (Product Requirement Document or Product Requirements Document) was in 2005 right when I joined Locaweb. A very time-consuming job, where I documented in detail everything we needed to implement in the product. I passed to engineering and sometime later the implementation was made with many errors because the engineers ended up not understanding what was written in some parts and decided to implement it as they saw fit. From that, we started to decrease the use of extensive documentation and increased the interaction between product managers, product designers, and engineers.

Marty Cagan has a very cool article called How to write a good PRD where he comments at the beginning:

I provide this document here mainly for historical purposes. It was written in 2005 to reflect best practices from previous decades.

I have not advocated the use of PRDs for many years, starting around 2007. It is not that PRDs are so bad. However, if the product manager is spending his time writing the PRD, then it is unlikely that he or she is doing the actual product discovery work.

Recommended pattern: just follow the agile manifest, product in the hands of customers brings more value to customers and the company than comprehensive and detailed documentation.

Focus on data

It happens when the head of product and other leaders only make decisions if there is an abundance of data, reports, charts. There are two dangers with this anti-pattern:

  • time: sometimes it takes a long time to gather all the necessary data. It is the situation known as analysis paralysis. Nothing happens until the data is meticulously obtained and analyzed. Often, after a first analysis, more data is requested and more time is invested in the search for this new data, and this cycle can be repeated over and over again. And, while this cycle is repeated, no decision is made. Hence the paralysis of the analysis.
  • errors: when we rely solely and exclusively on data there is a great chance that we will incur errors. How can we be sure that we have all the data needed to complete the analysis? How can we be sure that the data is correct? It is common to hear that decisions must be data-driven, that is, based on data. However, as stated above, the data may be incorrect and / or insufficient to describe a particular situation. Thinking about it, more recently the concept of data-informed decisions has emerged, that is, decisions are based on data, but not only on data. They take into account qualitative information, previous experience, and intuition in addition to data.

Recommended standard: make decisions based on data, but always understanding that the data is incomplete, and always take into account qualitative information, previous experience, and intuition.

Big rewrite

Every company has legacy systems. Even a startup that was just created, in a few months will be able to look at its code base as a legacy and something that needs to be improved. At that moment we start to hear phrases like:

  • It is increasingly difficult to deal with the code.
  • If I were to do it from scratch, it would be much faster.
  • If we don’t rewrite, it will get slower and more dangerous to change the code.

And at that moment, the great solution of rewriting was born. And this major rewrite will, at some point, cause a product evolution freeze. Why write something for the legacy, if the new system will replace it? And there is also migration or transition. How will we go from the legacy system to the new one?

Normally, in the initial estimates, the rewriting will take about 2 or 3 months and when we move forward we realize that it will be a little longer, and may take years. At Locaweb we made the decision to rewrite the central system that managed customer data and collection. The original project was forecast to take 9 months and ended up taking more than two years. In addition, when the new system came in, our customer billing did not work for about 2 months and stayed for another 6 months running incorrectly until we finished all the necessary adjustments. That is, the rewriting that originally would take 9 months ended up taking 3 years.

Recommended pattern: avoid major rewrites at all costs. Most of the time, there will be ways to replace the legacy system gradually and progressively, without causing disruption to the company and customers.

Wishlist

When a new head of product joins a new company, it is common during the onboarding process, during the numerous conversations with people from various areas of the company, to hear a series of requests and complaints regarding the product that this new head will take care. To “score points” with these people, who will eventually give feedback on the head of product’s work, he may be tempted to build his list of what to do based on these reported requests and problems. It is the company’s “wish list”. Then, this product head will prioritize this list or even outsource this prioritization to a leader in the company’s sales or business area. I’ve seen situations where the product head collects the “wish list” and presents it at a meeting with leaders from various areas of the company and says “now I need you to prioritize what you want the product development team to do first “.

Although it is somewhat tempting because the “wish list” will actually help the head of product to score points with the leaders of other areas, this behavior will make the product development team become a mere order taker and feature factory, inhibiting the innovation potential that this team can bring to the business. When the head of product focuses the team on delivering the “wish list”, it ends up focusing the team on being an implementer of solutions that are given by other people, taking the team’s focus on the problems to be solved. It is the difference between the team that implements solutions that are already envisioned by other areas of the company versus a team focused on deeply understanding the company problems and then finding the best solutions to solve these problems. I’ll talk more about this in the part about principles.

Recommended standard: product development team works to understand problems and then evaluate possible solutions. So go find the list of problems to work on, not the list of things that other areas want the product development team to do.

Summing up

  • Anti-patterns are common but ineffective responses to problem-solving. There are many well-documented anti-patterns in the world of digital product development. The 4 most common anti-patterns in product development leadership are documentation, focus on data, big rewriting, and wish list.
  • Documentation, which should be kept to a minimum, for certain leaders is even more important than the product itself. Nothing can go into production if it is not properly documented.
  • Focus on data is when any and all decisions have to be made with data, without taking into account qualitative information, previous experience, and intuition.
  • Big rewrite happens when a new product head finds a system written some time ago and identifies that it will be better to rewrite a new system from scratch than to improve the current system.
  • Wishlist comes from the need for the new product head to please all stakeholders, focusing on the product development team to only implement what is requested, delegating prioritization to other areas of the company.

With this chapter, we finish part 1 on the Concepts needed to understand the roles and responsibilities of a product head. In the next part, we will see which Principles should guide the work of a head of product and his team.

Missing something?

So, did you miss something in this chapter? What else would you like me to cover?

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? While you wait for my new book, check out my Digital Product Management bundle with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.

Developing the team and managing expectations

As I commented in the chapter Roles, responsibilities and seniority, in addition to defining and implementing the product vision and strategy, it is the responsibility of the head of product to develop his team and manage expectations. In the third part of this book on Tools, I will talk about several useful tools to help the head of product to fulfill these two responsibilities. However, before talking about these tools, I wanted to talk about three very important concepts for a head of product.

As I described in the book “Product management: How to increase the chances of success of your software“, the 7 main characteristics of a product manager are empathy, communication, time management, new technologies, business skills, keen curiosity, and product theme. As you can imagine, these characteristics are also fundamental for a head of product. However, I would like to highlight and remember 3 of them, since I consider them essential for the day-to-day of a head of product:

Empathy

Empathy is the ability of a person to put himself in the shoes of another person to understand his expectations, 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 problems they hope 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 develop 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 to help him understand what the expectations these areas have regarding the product, and what impact his product has on their work. Did legal problems increase due to some new functionality in the product? What is the impact for the sales, support, operations, finance and marketing team? Even in relation to the product team, engineers and UX designers, how does the product interfere with the work of these professionals?

Empathy is also very important so that the head of product can understand how he can help his team to develop. Which of the 7 characteristics mentioned above needs more attention at this moment and why? What is the best way to help this person develop this skill?

The head of product also needs to put himself in the shoes of the owners of the product, to understand their expectation about the product and the results it will bring to the company.

Communication

The ability to communicate is fundamental so that the head of product can manage expectations and help his team to develop. The head of product needs to communicate with people in the most different scenarios: in conversations one by one and in small groups, or making presentations to small and large groups of people, presentations that can be internal (within the company) or external (in conferences, user groups, etc.).

He must also be good at written communication (e-mail, blog, documentation, chat, social networks, etc.), and be able to discern which form of communication is most appropriate for each moment, audience, and means of communication; and to communicate in a way to be understood by different audiences: technical and non-technical. As if that were not enough, he also needs to be able to communicate with confidence and confidence in what he is communicating; after all, the head of product is not only the spokesperson for the product but also the most senior reference in the entire company for the product.

It is important to remember that communication is a two-way street, that is, the head of product must be very good at knowing how to listen and understand what others are saying, and understand their problems and needs; which has to do with the first characteristic, empathy.

Business skills

The product manager must be concerned with whether his product is meeting the business objectives, as the achievement – or not – of the business objectives is the main source of people’s expectations regarding the product. How will the product help the company to achieve its business goals? 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.

Summing up

  • To develop your team and manage expectations, the product head must have the 7 characteristics of a good product manager: empathy, communication, time management, new technologies, business skills, keen curiosity, and product theme
  • Three of these characteristics are essential for the work of the head of product. Empathy to understand where expectations come from and what elements need to be developed in your team. Communication to make you understand and make yourself understood when you are talking to the people of the company to manage your expectations and when you are developing your team. Business skills that will help the head of product understand the goals of the company that are important components of the expectations that people have regarding the product.

In the next chapter, we’ll look at the leadership anti-patterns we can find in product development teams.

Missing something?

So, did you miss something in this chapter? What else would like me to cover?

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? While you wait for my new book, check out my Digital Product Management bundle with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.

Team structure

The product development team is the one who will execute the strategy and achieve the objectives to achieve the product vision. Therefore, an essential part of your strategy definition is to design and implement your team structure. In order to design the team structure, it is important to understand the different ways of organizing a product development team and to define which one is most appropriate for your strategy.

Product Teams

The minimum product development team that we saw in the chapter on Product management career is composed of a product manager, a product designer, and two or more engineers. This minimum team can also be called squad. This team should have a maximum of about 7 people. The larger the team, the greater the difficulty of coordination. At Amazon there is the famous rule of two-pizza teams, i.e., the maximum size of the team is one that can be fed by two large pizzas. The rationale behind the advantage of small teams is based on the same concept that I presented when I talked about platforms in the chapter “What is digital product and product management?“. The amount of interactions between team members increases rapidly with the size of the team, following the formula n * (n-1) / 2. Thus, while a team of 5 people has 10 possibilities of interaction between its members, in one of 7 people that number grows to 21.

When we join two or more squads ​​we have a product team, which can also be called tribo.

This product tribe can have one, two, or three leaders. If it has one leader, he will be responsible for leading product managers, product designers, and engineers. If there are two leaders, usually one will lead product managers and product designers, and the other will lead engineers. If there are three leaders, one leads product managers, another leads product designers, and the third leads engineers. I have already had the opportunity to work in structures with one, two, and three leaders in each product tribe, and each one of these structures has its pros and cons, as I explained in the chapter on Product management career where I talk about unique leadership and shared leadership.

Product teams may also have some roles shared between the squads. Having them shared instead of dedicated per squad has three main objectives:

  • squad size: preserving the small squad is important to preserve the agility of this team. As explained above, the larger the team, the greater the need for coordination between team members.
  • ownership: as soon as you have a person in the squad with a specific role, that role is no longer the responsibility of the other team members. For example, if we have a person taking care of the quality, that topic becomes that person’s responsibility, and the other people in the squad will be less concerned with this topic. The exceptions are the three primary functions of a squad which are engineering, product design, and product management.
  • resource allocation: in addition to the squad getting big if we put these roles inside each squad, needing more coordination and having the risk of slowing the squad down, each squad will cost more. With smaller squads, we have the possibility to allocate the resources that you have available for product development in more squads that build products.

Examples of roles that may exist in a product tribe shared between different squads:

  • Agile Coach: helps the squads in their agile processes and culture. Instead of a scrum master per squad, there is an agile coach per tribe who helps the squads on this topic, but the processes and agile culture of each squad are the responsibility of each member of the squad.
  • Quality Assistance: just as processes and agile culture are the responsibility of each member of the squad, so does quality. Instead of a quality assurance per squad, we can have a quality assistant per product tribe, which will help each squad with quality issues.
  • Data Analyst: every squad generates a lot of data and needs to understand what that data means. Again, understanding what this data means is a squad’s responsibility. However, when the data structure is very complex, it may make sense to have one person per product tribe assisting your squads in the more complex data needs of each squad.
  • SRE: for products with a lot of integration with third-party systems it may be interesting to have a Site Reliability Engineer (SRE) per tribe helping the squads to define and implement stable, well-performing, and resilient architectures. At Conta Azul, as we had integration with banks and with the systems of the Secretaries of Finance of each state for issuing invoices, it made sense to have a person with this knowledge in each tribe.
  • User Research: this is the responsibility of the product designers, with support from the product managers of each squad. In some cases, it may make sense to have a research-focused person in the product tribe to help with each squad’s research.
  • Product Marketing: While the product manager’s mission is to build the product or functionality that solves users’ problems, product marketing’s mission is to tell the world about the product or functionality and the problem it solves. This “world” refers to both existing users of the product and new users that we want to bring in to use the product. Thia role is responsible for designing and implementing the product’s go-to market (GTM) strategy. In many companies, this responsibility falls to the product manager. This works in many cases, but it can take product manager’s focus off building the best product or feature.

There are other roles that can be shared but remember that the more shared roles you have, the more difficult it will be to coordinate the people of the tribe. My recommendation is to have a maximum of 3 shared roles. These shared roles can be led by the tribe leader(s) or by the structural tribe leader corresponding to their role.

Organizing product teams

There are 4 possible ways to organize product teams, by product or feature, by user type, by user journey, or by objective. It is also possible to use two different types of organizations thus creating a hybrid organization. I will describe each of these forms of team organization below.

By product or feature

This is one of the most common ways of organizing product teams. For each product or feature, we have a tribe. At Locaweb we had a product team for each product, Email Marketing, Virtual PABX, Cloud, Website Hosting, and so on. At Conta Azul, we also used this model, with a team called Spartans focused on features related to financial management and the other team called Underground focused on tax and accounting features. At Lopes, when I joined, we had a team focused on the Portal, another on the CRM used by real estate agents and franchises and a third focused on the app for real estate agents.

The main advantage of this form of organization is that the part of the product that is the responsibility of the tribe is very clear, but on the other hand, with the focus on the product, we may lose the perspective of the person(s) for whom the product solves problems.

By user type

This is a very useful model in marketplaces and platforms. Each tribe focuses on one actor of the platform. For example, at Gympass, where we had gyms, HR, and employees, we had 3 tribes, each focused on these three marketplace actors. At Conta Azul we had two tribes focused on the owner of the small business and two focused on the accountant.

The advantage of this organizational model is that the focus of each team is well defined, aiming to improve the experience and solve the problem of each actor on the platform. If the systems architecture is closely coupled, there can be a lot of dependency between the teams. Another point of attention is that some journeys can be divided between two tribes. For example, at Gympass there is a journey to check in at a gym. This journey happens when the user goes to the gym, checks in and the front desk validates that check-in. In a team organization by user type, both the gym team and the end-user team are responsible for this journey and must coordinate themselves to make changes in this part of the product.

BY USER journey

In this model, teams are organized according to each user’s journey. Searching, buying, scheduling classes and so on are journeys that your user can go through when using your product. I confess that I have never seen a team 100% organized by user journey, but I have seen teams that are organized by product or type of user who have one or more tribes focused on some journey. For example, at Conta Azul we had a team called Hubble that took care of the user’s journey until he could use financial features, taken care of by Spartans and tax and accounting features, taken care of by the Underground team. At Gympass, in addition to the company’s employee, gym and HR teams, we had a team, called Cross Features, which took care of registering each of the marketplace participants (users, gyms, and HRs) and receiving payment made by HRs and users, and for calculating the payment to the gyms. At Locaweb we created the central systems team, later renamed to enterprise applications, responsible for the customer center, where Locaweb customers can view and manage all their products.

The main advantage of this structure is that the focus on a journey increases the chance of providing a great experience in that specific journey. On the other hand, normally one squad is enough to take care of a journey so you may end up with many one squad tribes.

By objective

An organization based on objectives means that the tribe focuses on a specific objective. Conversion, retention, usage experience, etc. I don’t know any team 100% structured only by objectives. At Gympass we used this mode of organization in the end-user team, where we divided it into two tribes, one focused on growth, which aimed to ensure that Gympass customers’ employees downloaded the app, created a free account and became subscribers, and another focused on digital experience to ensure that users use and get the most out of the app, ensuring user satisfaction and retention.

In this type of organization, the main benefit is the focus on where you want to get, the objective. The drawback is that you may have two squads with different objectives tackling with the same area of the product, which may cause a weird experience for the user. Another drawback is that If the systems architecture is closely coupled, there can be a lot of dependency between the teams.

Hybrid

These different ways of organizing product teams can be used together. They are not exclusive. Actually, I’ve never seen a product development team using exclusively one type of organization. Teams are structured in hybrid organizations. Here are some examples of hybrid organizations.

At Locaweb we had teams organized by product (Hosting, Email Marketing, Cloud, etc.) and a team focused on the customer journey (Customer Center)

At Conta Azul we used organization by functionality. One team for the financial management of small business (Spartans) and another for tax and accounting management (Underground). One for the tax, accounting, and payroll management of the accountant’s clients (Area 42) and another for the management of the accountant’s clients (Babilônia). We also organized by type of user (teams focused on the business owner and the accountant) and by journey (Hubble).

At Gympass we created teams by type of user (end-user, gyms, and HR), but we also use the organization by user journey to create the Cross Features team, responsible for registering each participant of the marketplace (users, gyms, and HRs) and getting paid by HRs and users, and for calculating the payment to the gyms. We also used the organization by objectives when we broke the end-user team into two tribes, one for growth and the other for digital experience.

It is important to note that these examples are from the time I worked at these companies. As the product vision, strategy and objectives evolve, the team structure must also evolve.

Organizing squads in a product team

These forms of organizing product teams serve both to define the tribe organization, as well as the organization of a tribe’s squads. Some examples:

  • Hosting (Locaweb): Within the Locaweb hosting team we had 3 squads, one focused on Windows hosting, another on Linux hosting, and a third as a focus on the hosting management control panel.
  • Gyms (Gympass): In the team focused on Gympass gyms we had squads focused on APIs for integration with gym management systems for integration of the check-in process in gyms and for booking classes and squads focused on the experience of the gym manager so that he could have access to reports and configure how his gym would appear in the user’s app.
  • Financial (Conta Azul): In the team focused on financial management of Conta Azul, we had a team focused on integration with banks to receive bank statement data from customers, another focused on the financial management interface, with reports and a system for categorizing the entries of the bank statement and a third one focused on a feature that had its own name, the Easy Collection (Receba Fácil in Portuguese), a bank slip issuing system.

Structural Teams

Structural teams are teams that work in the necessary structure for product teams to be able to do their job.

Some types of structural teams needed in the development of digital products:

  • SRE or DevOps: SRE stands for site reliability engineering. This area, sometimes called DevOps, is responsible for the infrastructure where the product will be hosted and served to customers. Also responsible for monitoring the product and the infrastructure where the product is hosted to ensure that it operates with optimal performance.
  • Data: here we usually have 3 disciplines that need to be taken care of by the data team. First, a data engineering team is needed to take care of the necessary infrastructure for managing the company’s data. Then a data analysis team is required, responsible for generating reports and dashboards based on the data and for showing the product performance. Finally, it is interesting to also have a team of data scientists able to take insights from the data and eventually create machine learning algorithms that can evolve as more data is collected and analyzed.
  • Architecture / Tools / Foundation: a team that helps product teams to define software architecture standards. This team can also work on topics that are common to all teams, such as authentication and authorization, and API infrastructure.
  • Design Ops: central design team that takes care of creating and maintaining the Design System, library of components, and interaction patterns. This team can also take care of the operational efficiency of the designers, giving them tools, empowering the managers and leaders to evaluate designers’ performance, helping with the onboarding. This team can also have user research and UX writing professionals.
  • Information Security: responsible for all aspects of information security, such as GDPR, PCI certification, ISO 27001 certification, BYOD (bring your own device) policies to allow employees to use their own devices for the job.
  • Internal Systems: responsible for taking care of third party systems, such as Google Suite, Office 365, Slack, etc., as well as the company’s equipment.
  • Sales Engineering: this area makes a lot of sense in companies that develop products for other companies. It is a team with technical knowledge capable of discussing details of implementation and integration of your product with the customer’s systems.
  • Professional Services: If the implementation and integration needs of the new client deviate from the standard, or the client is not prepared to make this implementation or integration, it may be interesting to have a professional services team that does this job. It is recommended that this team be very lean and use third parties as required to do the implementation and integration work.
  • HRBP and hiring: As seen above, product teams and their structures are complex, with a lot of collaborative work and matrix structures. It is essential to have an HR team nearby to help manage the team, with two focuses. HRBP, or human resources business partners helps in the day-to-day activities of teams and leaders in all matters related to HR. Hiring, or talent acquisition is responsible for the entire process of attracting and hiring people for the team.

Implementation

The implementation of the product structure that was designed can happen in two ways. You are either creating a structure from scratch, or you are adjusting an existing structure.

Creating a new structure

When you create a structure from scratch, you have the opportunity to grow as needed. You can start with a single squad, then create the second squad, and so on. It is important to keep in mind where you want to go with this structure. Will you have structural teams? Which ones? What product teams do you intend to have? I also recommend starting to assemble these teams by their leaders, so that they can have the opportunity to hire and form teams according to their needs, as long as they are aligned with the vision you have designed.

Changing an existing structure

When you arrive to lead an already formed team, it is important to be clear about the product vision, the current structure, and the people who are part of that team. You will need to make several conversations to better understand these three aspects before proposing changes to the current structure. As soon as you design the first version of your proposed new structure, present it as work in progress to some people to collect feedback and adjust your proposed structure. Once the new structure has been agreed, coordinate with the team members to make the change. It may be that some teams that are going to be mixed up are finishing doing some things, so it is important to align with these pending tasks to allow a smoother transition from the current structure to the new structure.

What is the best ratio between Eng, UX and PM?

We can find many articles from different product development teams around the world showing Eng:PM and UX:PM ratio benchmarks. There is a recent article by Ken Norton, a partner at Google Ventures and a former product management leader at Google and Yahoo!, where he shares the results of an informal survey he run on Twitter:

A significant majority of tweets recommended something in the range of 5 to 9 engineers for every PM. There were reasons why people recommended going higher or lower, but it seems like a sweet spot. Thinking of my own experience, my best performing teams also fell into this range.

When it comes to designers, I prefer a 1:1 ratio with PMs for user-facing products. Product teams work best when the dedicated triad of PM, designer, and technology leader forms the core.

Therefore, it appears that the general recommendation is 5 to 9 engineers per PM and 1 UX per PM. Here, when we count engineering people, we must also consider people from structural teams.

Some real-life numbers

At Gympass, we worked to increase the number of engineers per product manager. In our efforts, increasing the team from 32 to 85 people in 5 months has already increased the Eng / PM ratio and also the UX / PM ratio. Our plan was to reach the end of 2019 with almost 200 people on our product development team, with even more engineers per product manager and a better balance between UX designers and product managers, as it turned out.

All benchmarks are clear when they explain that each product manager must be paired with a UX, especially for customer-oriented products. In the case of Gympass, there are 3 different types of customers (end-users, gyms, and corporate customers), which reinforces the need to maintain the recommended ratio of 1 product designer per product manager.

At Conta Azul we had a good Eng:PM ratio when I joined in August 2016. However, the UX:PM ratio was below market standards. Especially if we take into account that one of the 4 fundamental values ​​of the Conta Azul is to deliver Wow to customers. For this reason, we worked to increase the ratio of user experience designers to product managers so that we can increase the Wow delivered to customers.

At Locaweb, many of the products we built were for software engineers. Website hosting, database hosting, SMTP, Cloud servers, and dedicated servers. For this reason, the number of engineers per product managers is greater than that of Conta Azul and Gympass. It is even higher than the recommended upper limit of 9 engineers per product manager. However, we can see an interesting fact in the ratio of UX designers to product managers. As seen in the August 2015 figures, a higher proportion of Eng:PM forces an increase in UX:PM compared to the recommended 1:1 ratio. When we look at the numbers for July 2016, we have more engineers per product managers, reaching almost 12 Eng:PM, which increased the UX PM ratio to almost 2:1. We had to assign 2 UX designers to each product manager so that they could handle all the discovery work that needed to be done so that engineers could build the right product. Considering engineers as responsible for delivery and UX and product managers responsible for discovery, this shows us that we had about one person from discovery for every 4 people from delivery.

Conway’s Law

Conway’s Law was created by Melvin Conway, an American computer scientist, and published for the first time in April 1968, in an Information Technology magazine well known at the time called Datamation. Conway’s Law says that:

*Conway’s Law

Any organization that develops a system will produce a system whose structure is a copy of the organization’s communication structure.

I have already seen situations in which a product development team is organized in parity with the business areas, that is, a team focused on the needs of customer service, another focused on the sales team, another focused on the financial, plus one focused on the marketing, and so on. I do not recommend this type of structure, as it reduces the focus on the customer.

Tuckman’s stages of team evolution

Bruce Tuckman, an American researcher on group dynamics, proposed in 1965 4 stages that a group of people going through when they begin to work together, and how these stages impact on the effectiveness of that group.

  • forming: at this stage people in the group are getting to know each other, understanding common objectives, and looking for ways to work together.
  • storming: then there are some confrontations when the group starts to discuss how the work will be done. It is time to define the role and responsibilities of each member of the group.
  • Norming: this is the moment when the group members define the work process and the roles and responsibilities of each team member. In this phase, the team members already know each other and respect each other’s skills.
  • Performing: this is when the team actually starts to produce and deliver results. The team already knows each other well, the work process is clear and agreed upon by all team members.

There is no better way to structure a product team. There is one that makes the most sense for the strategy and objectives defined to achieve the product vision. Therefore, the team structure is not written in stone, if there is a need, due to a change in objectives or strategy, it may make sense to change the team structure. However, I don’t recommend doing this very often, due to the time it takes for a newly formed team to go through the Tuckman stages. I heard certain people commenting that they work for companies that changed the product development team structure every 3 or 6 months. It is not enough time to go through Tuckman’s stages.

Business units

In some situations, instead of having separate product teams within the same organization, it may be interesting to create reasonably independent business units. In business units, we have not only a separate product development team but also all the areas necessary for the business to happen independently, such as marketing, sales, customer service, etc.

At Locaweb, we opted for the model of independent business units when we acquired companies. Tray was an e-commerce solutions company that became part of Locaweb’s product portfolio. As Tray already operated as an independent company, we chose to keep it that way, only having the areas of office management, finance, and HR in common. This is a very common way of creating business areas, through acquisitions of companies.

At Gympass we saw the opportunity to create a new product called Gympass Wellness, which offers wellness services such as workout, nutrition, and meditation apps for employees of Gympass customers. We chose to start this new product as a business unit, with a product, marketing and sales teams independent from Gympass, aiming to give greater autonomy and agility to this team.

At Lopes we have CrediPronto, a business unit that is a joint venture between Lopes and Itaú Bank to offer credit to real estate buyers. Due to the nature of the business being completely different from the main business of real estate transactions and also because we have a new partner, the business unit model was chosen.

What makes a group of people behave as a team?

It’s not enough to organize people in the teams structure described above for them to behave as a team. In order for them to perceive themselves as a team and start acting as such, they need common objectives.

A very common issue I see in product development teams is that, even being very well organized into tribes and squads, with structural tribes and product tribes, and right people with the right roles in each team, the objectives are set per function. Product managers have a set of objectives that is different from product designers objetives that is different from engineers objectives. That simply doesn’t work, because each person will focus on his objectives.

If we define all objectives as being common to all members of the team, they all work together to achieve the objectives. Even if the objective seems more related to one of the aspects, like more business related (product manager) or more user experience related, or more engineering related, all members of the team must have the same objectives.

So, the short answer to the question “What makes a group of people behave as a team?” is common objectives.

Summing up

  • Product development teams are organized into minimal teams, also called squads, composed of engineers, product designers, and product managers. It is important to keep these teams 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 user journey, or by objective. It is also possible to use two different types of organizations thus creating 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.
  • The implementation of the designed team organization can be done either by creating a new structure or by adjusting an existing team. In both situations, it is important to know the product vision, strategy, and objectives in order to design and implement a team structure aligned with that vision.
  • The most suitable ratio between people in engineering and product managers is 7 +/- 2 engineers for each product manager. And a product designer for each product manager.
  • Two important concepts in the design of your team structure are the concepts of Conway’s Law, which says that organizations tend to create systems that are a copy of the company’s communication structure, and Tuckman’s 4 stages of team evolution, forming, storming, norming and performing.
  • It is also possible to organize product teams by business units that have other functions besides those included in a product development team, such as marketing, sales, and customer service. The motivations for creating business units instead of product teams may be due to acquisition of a company, or to give more agility to the new business, or even because it is a new product line completely different from the original product.
  • What makes a group of people behave as a team is common objectives.

In the next chapter we’ll see a little more about developing the team and managing expectations.

Missing something?

So, did you miss something in this chapter? What else would like me to cover?

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? While you wait for my new book, check out my Digital Product Management bundle with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.

Strategy and objectives

What needs to be done to get your product closer to the product vision? This is your strategy and product objectives. We are then talking about defining what to do, how to do it, in what order to do it, and what metrics tell us that we are going in the right direction once the why to do it has already been defined in the product vision.

The strategy and objectives provide a path to be followed and metrics that show whether or not we are in the right direction. Without a clearly defined strategy and objectives, it is very difficult to define the most appropriate team structure and what needs to be done to achieve these objectives.

Creating your product strategy

As you already have your product vision, you need to understand what you need to do to execute your product vision, that is, to get where you want to go.

Below are some tools that will help you create your product strategy:

Market analysis

As explained in my book “Product management: How to increase your software’s chances of success“, to create your strategy, you need to have a good understanding of your market in five aspects:

  • competitors: both direct and indirect, that is, those who compete for the time and attention of your users. For example, a competitor of physical activity is streaming services, which motivate its users to watch more and more videos.
  • potential and accessible market: how much market, that is, how many people could be your customers? In order to be your customer, are there any minimum requirements? For example, if you sell an online course to medical interns preparing for the assessment process to join a medical residency program, your potential market is all medical students in their final years of graduation. This is your potential market. And out of that total of people, how many people can you actually talk to and who will want to use your product? In the example above of the online course for medical students, how many can you talk to and show your product? This is your accessible market.
  • market growth: is the number of people with the potential to use your product growing, stable, or decreasing? And how many people can you talk to about your product? It is very important to understand if the market you see for your product is growing, stable, or decreasing, and if this movement is in the short or long term. Understanding how your market is moving is fundamental to help you define your strategy.
  • disruptors: as important as knowing your direct and indirect competitors, you need to know which products can disrupt your product, that is, replace the benefit that your product delivers in a better and more attractive way for your users. For example, people are using less and less email due to the communication options that direct messaging products like WhatsApp and Slack have offered.
  • regulation: is your market regulated? Do you know this regulation? Were there any changes in this regulation? For example, at the Conta Azul, we monitored tax and accounting regulations on a daily basis to ensure that the product was in line with those regulations.

This work must be coordinated by the head of product in conjunction with the marketing leadership. Probably this type of analysis has been done in a timely manner. My recommendation is to make market analysis a permanent discipline, that is, once the first version with the items above has been created, update monthly to ensure you have the most up-to-date information about your market.

SWOT Analysis

From your market analysis, the next step is to understand your product’s position in this market. Both the current position and the position you want to occupy when you have executed your product vision. A good tool to help with this understanding is to do SWOT analysis, which stands for Strengths, Weaknesses, Opportunities, and Threats.

SWOT analysis

Strengths and weaknesses are internal items (from your product development team, or your company) over which you, your team, or your company have some control, items that help or hinder your product to achieve your vision. Opportunities and threats are the elements external to the organization, that is, over which the organization has no control, and which can positively or negatively influence the achievement of the product’s vision. It has to do with the market analysis described above.

Filling in the SWOT should be a team effort. The heads of product must have one or more sessions together with people who can contribute to this analysis. Leaders of your team and other areas are the right audiences for this type of session. How to organize a SWOT analysis session:

  • Homework: ask everyone to complete a SWOT analysis. Limit to a maximum of three items per quadrant. It is common, especially in the weakness quadrant, for people to create a very large list of items, often with more than 10 weaknesses. When asking to limit by 3 items per quadrant, people will be forced to do a first prioritization.
  • Consolidation: combine all SWOT analyzes into one analysis. There will be some overlaps and some differences. Place items in each quadrant with the number of people who placed each item in their individual SWOT analysis. This amount can serve as the first indication of prioritization.
  • Final version: bring people together in a conversation to evaluate the consolidated version. The goal now is to make the consolidated version also have a maximum of 3 items per quadrant to force everyone to prioritize once again. Usually, a single session can be enough to build this final version.

Once you have your final version of the SWOT analysis, you have 12 items that can serve as the focus of your strategy. I say “can” because you don’t have to work on all the items at the same time. Here, once again, the ability to prioritize comes in. Bearing in mind that SWOT was designed to help us show the path that needs to be taken to achieve our product vision.

  • Strengths: how to keep them relevant? Do you need to do anything to reinforce them? Are any of your strengths more important than the others?
  • Weaknesses: How to reduce the impact of weaknesses? Which of these weaknesses has the greatest impact?
  • Opportunities: is it possible to explore opportunities? What can we do to explore opportunities? Which of the opportunities is most relevant to the execution of the product vision?
  • Threats: What should we do to protect ourselves from threats? How do these threats impact the execution of the product vision?

These discussions should also be held in groups, and can even be done in the continuation of the creation of the SWOT analysis. With these discussions, you will already have an alignment between the leadership of the different areas regarding the product strategy.

OKR

OKR means Objective and Key Results. It is a management tool that serves to align and monitor the execution of the strategy. This tool has been used at Google since its inception and was brought there by John Doerr, an employee of Intel, the company where this tool was created. Several technology companies today use OKRs, such as Locaweb, Conta Azul, Gympass, Linkedin, Amazon, Adobe, Baidu, Dropbox, Facebook, Netflix, and Spotify. OKR is a framework derived from a management technique called Management by Objectives, a term created by Peter Drucker in his book The Practice of Management, from 1954.

It is a very simple yet powerful tool. 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. Each objective can address one or more items in your SWOT analysis or represent something that you want to execute from your vision.

For example, let’s say one of your goals is “Achieve record purchases per month in our website”. To achieve this goal, you can define the following key results:

  • Increase from 15,000 to 20,000 visits per week
  • Improve the conversion rate from 4.5% to 6%
  • Lower the bounce rate from 35% to 20%
  • Improve page load times to less than 2 seconds

The team should look at the OKRs every week to see if the metrics are moving in the right direction and understand if there are any impediments to be removed or something to be done to accelerate the achievement of the objectives. More frequent deliveries and measurements help to achieve objectives. If there are only monthly deliveries and measurements, the team will only have two chances in the quarter to test their idea of ​​how to move the metric. If there are weekly deliveries and measurements, there are 12 opportunities to evaluate and change course if necessary.

There, you now have your product strategy, the objectives you want to achieve, and the metrics that will tell you if you are reaching your objectives. Your next step will be to define the most appropriate team structure to execute your strategy and achieve your goals, a topic for the next chapter.

Reviewing your product strategy

Your product evolves as the team works on it and you get closer to your product vision. Much is learned about the users of the product, their problems, and needs. New alternatives may appear to help its user to solve their problems and needs. The owner of the digital product can also revisit his strategic objectives and, consequently, revisit the objectives defined for the digital product.

In addition, strengths and weaknesses can change over time, and opportunities and threats can appear or disappear. So it is important to understand that neither the vision nor the product strategy and objectives are written in stone. They can and should be revisited periodically.

My suggestion is that they be revisited annually, or when some relevant event happens, such as when there is a change in the company’s strategic objectives, or when an alternative appears that solves the user’s problem or need in a different way than yours. product, or when a crisis like the COVID-19 pandemic occurs.

For OKRs, my suggestion, as mentioned above, is that they are defined quarterly and reviewed weekly. This will give your team a good execution cadence.

Summing up

  • Product strategy is nothing more than the path you will take to arrive at your product vision.
  • To create the product strategy you need to have a good understanding of your market, that is, the competitors, the potential and accessible market, the growth of this market, if there are disruptors, and regulation of that market.
  • Use SWOT analysis to help you define which points you will work on in your product strategy.
  • Use OKRs to help you define your strategic objectives and metrics that will tell you if you are on the right track.
  • Review at least annually, or when there are relevant events in the market, your strategy, and your product vision. The market changes, your product evolves, so your product vision and strategy must also evolve.

In the next chapter, we will see different ways to structure the development team in order to execute the product strategy in order to achieve the product vision.

Missing something?

So, did you miss something in this chapter? What else would like me to cover?

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? While you wait for my new book, check out my Digital Product Management bundle with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.