Release early and often

In the previous chapters we saw my personal leadership principles:

We also saw what corporate culture is, a set of ways to solve problems and react to the situation shared by a group of people working together. And we saw the 5 values ​​needed to create successful digital products:

Product culture

It turns out that these values ​​are necessary, but not sufficient. There is a set of four values ​​that are in fact the core of the entire digital product development team. These are the values ​​that make up the product culture, which is nothing more than the set of behaviors of the digital product development teams that produce the best results. The four values, which will be the subject of this and the following chapters, are:

  • Release early and often
  • Focus on the problem
  • Result delivery
  • Ecosystem mindset

Let’s start with the first one: Early and frequent launch.

The sooner we present the product to our users, the better, as we can receive feedback from real users who will be able to use the product in their own context. There are 3 reasons that justify this need to launch your product or functionality as soon as possible and frequently.

Moment of truth

It doesn’t matter how much research, interviews, and prototypes you do, the moment of truth, that is, the moment when you will know if your product is, in fact, the solution to a problem of a group of people, is when the product is in your customers’ hands, in the context where they need the product.

The longer it takes you to get your product out on the street, the longer it will take to learn from real people if you are on the right track. And if that’s not enough, the more steps you will be taking in the wrong direction.

You will only know if the product you made really solves some people’s problems if they use it. The longer it takes for this to happen, the longer it will take to know whether or not it is the solution to the problem.

And if not, what do you do? Fix, adjust, change! The sooner you know that what you are developing is not on the right track, the better because the less time, energy, and money you will waste going the wrong direction.

Too many features

There is a limit of features that the user can understand. When we add too many features, instead of creating a solution to the customer’s problem, we end up creating a new problem for the customer.

Kathy Sierra, recognized programming and user experience instructor, has created a feature chart that illustrates in a clear and fun way how user satisfaction decreases as we increase the amount of functionality in a product.

Featuritis
User satisfaction curve as a function of the amount of functionality

Return on investment

The longer your product takes to have users and, consequently, customers who will at some point pay for your product, the more you will have to invest out of your own pocket. Below is a typical graph of a product’s return on investment (ROI).

During the period that you are building the product and don’t release it to users, all you will have is cost. That is, you will be in the investment part of the curve. This only changes when you start earning revenue and it is greater than your monthly costs. Then you enter the area described below as monthly profitability. Only after a few months in this area will you have a return on your investment. See how long the road is.

Return on investment

Now take a look in the graph below, how a 3-month delay in obtaining revenue can delay the return on investment by 6 months. Are these 3 months of delay in earning revenue worth it? What will you do in those 3 months really make up for 6 months of delayed return on investment?

Postponed return on investment

On the other hand, see what you get if you can accelerate the development of your product and launch it 3 months ahead of schedule. You get 6 months of return on investment! And the explanation for this is not just because you get to the revenue early, it’s because you spent less to be able to launch the product faster. See the chart below.

Antecipated return on investment

If you are not ashamed of your first version, you took too long to launch

LinkedIn founder Reid Hoffman once said that:

“If you are not ashamed of the first version of your product, you took too long to launch”.

To illustrate this phrase, which in a way summarizes the value of release early and often, I decided to take screenshots of the first version of some well-known services.

Facebook 2005
Facebook 2005
Google 1998
Linkedin 2005
Twitter 2006
Locaweb 2002
Conta Azul 2011
Agil ERP (Conta Azul) 2008
Gympass 2014
Lopes 1998

MMF – Minimal Marketable Feature

Minimal Marketable Feature or MMF comes from a 2003 book called Software by Numbers, by Mark Denne and Dr. Jane Cleland-Huang. In this book, they introduce the concept of:

Incremental Funding Methodology (IFM), an ROI-based approach (Return on Investment) for software development in which the software is developed and delivered in carefully prioritized blocks of functionality valued by the customer. These blocks are known as Minimum Marketable Features – MMFs.

It is a concept prior to that of MVP, which has the advantage of this mentality of implementing the minimum necessary for each feature of the product. The basic difference between MVP and MMF is that, while MVP talks about a minimum viable product, that is, it needs a complete product, even if minimal, in order to be presented to possible users, MMF brings the minimal concept down to the level of each feature.

To illustrate MMF, they used a very simple example: imagine that you have to build an internet banking system on the web. There are many features and it can take many months or even years for this product to be delivered with all “mandatory” minimal set of features. When thinking in terms of MMF, we should look at those “mandatory” features and find out if we can launch them independently, that is, if a particular feature, if launched independently, would bring some value to the customer. In an internet banking system, we could choose to release it only with an account statement and no other resources. This would be a very simple internet banking system, but if launched as soon as it is ready, and not after some other features are also ready, it will bring value to the customer sooner. And whenever you deliver value to the customer, you also deliver value to your company. In addition to the satisfied customer, in this example you have probably reduced the cost that your company has in serving these customers, because if users do not obtain their account statements over the internet, they will certainly use another way of obtaining this information and probably this other way is not as economical as internet access, like going to an agency or an ATM.

Minimum marketable functionality (MMF) is minimal, because if it were smaller it would not be marketable. And an MMF is marketable because, when launched as part of a product, people use (or buy) the functionality.

The next time you are planning a new product or feature set for an existing product, try to think in terms of MMF. It can bring a lot of value to you, your customers and your company.

Summing up

  • There is a set of four values ​​that are in fact the core of every digital product development team. These are the values ​​that make up the product culture, which is nothing more than the set of behaviors of the digital product development teams that produce the best results.
  • The three reasons for you to launch your product soon are that (i) this is the moment of truth, (ii) so you avoid the excess of features and (iii) accelerate the return of the investment.
  • If you are not ashamed of your first version, it took too long to launch.
  • Minimal Marketable Feature or MMF is a concept prior to that of MVP, which has the advantage of bringing this mentality of implementing the minimum necessary for each product functionality.

In the next chapter we will see the importance of focusing on understanding the problem to be solved before thinking about solutions.

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? 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 leading digital products

Diversity, the basis of the best products

I have seen demonstrations of diversity with increasing frequency. I’m not much into watching TV, but one day in 2017 I ended up watching a little bit of TV Globo, the biggest Brazilian TV network. I watched the end of Jornal Nacional and the beginning of the soap opera. In Jornal Nacional, I saw a report about PUC in São Paulo opening unisex bathrooms – remembering that PUC is Pontifical Catholic University, a university linked to the Catholic religion. Then, in the soap opera, a character was telling her parents and family that she was born in the wrong body, that he was a man who had been born in a woman’s body, that is, that he was transgender. Then, during the break, came the Globo campaign entitled “Everything starts with respect” about respecting gender identity.

That’s really good! Accepting and respecting differences is the basis for evolving as a society and building an ever better future for us, for our children and for all of humanity.

When respect and the ability to accept diversity are lacking, very bad situations can happen, for example, of parents rejecting their own child. I was very impressed when I read the report by Daniela Andrade, a senior consultant at ThoughtWorks, where she says:

“As I was expelled from my parents’ house, for being transsexual – and here I say that the first great violence that we suffer is at home – for many years I have no relatives to count on in times of need, everyone turned their backs on me.”

How is it possible for a parent to reject his own daughter? I am a father and I know how the love of a parent is something very intense, capable of overcoming any problem so that we can always help and support our children. I was talking the other day with my wife about this story and about the difficulty people have in accepting differences, to the point of rejecting their own children. It was at that moment that my wife said a phrase that marked me. She said that ultimately, everyone is different. Transgender, cisgender, heterosexual, homosexual, bisexual, asexual, black, white, yellow, young, adult, middle age, senior citizen, brazilian, canadian, french, vietnamese, fluminense, paulista, carioca, belo-horizontino, runner, cyclist, swimmer, engineer, architect, lawyer, who likes pop, rock, jazz, classical and so on. Even identical twins are different.

If all people are different, accepting and respecting differences is not only desirable, it is necessary and mandatory so that we can live in a society in a more harmonious and sustainable way. These are values ​​that must be taught to all people from birth.

And what does diversity have to do with digital product management?

In addition to the importance of accepting and respecting differences to help create a more harmonious and sustainable society, diversity will help create better digital products for two reasons:

  • Diversity brings new points of view. Having a more diverse product development team brings new points of view and new ways of thinking, which will help to develop a better product. It is no wonder that the product development team is comprised of software engineers, user experience designers, and product managers. Each person has different views of what a good product is and these differences, when worked well by the team, are what help to create a better product.
  • Just as the group of customers using your software is diverse, so should your team. Usually, software product development teams are mostly male, but the population of any country is more diverse. Both at Conta Azul and Locaweb, more than 88% of the team was composed of men. But these teams make products that will be used by the Brazilian population, which is made up of 48.2% men and 51.8% women according to IBGE (Brazilian Institute of Geography and Statistics). It is also worth remembering that the division between “men” and “women” is simplistic and that gender diversity is non-binary, that is, there are other gender identities besides female and male.

That is why it is so important to reflect and talk about diversity. Only then you will be able to think about issues so essential to the success of your product. How to improve the diversity of your product development team? How to foster discussions that bring different points of view and help to see your product and the problems it helps solve from new angles?

In all the teams that I led, I brought this topic to be discussed. Together we thought about how we could improve this diversity. An interesting example of the result of this work over 12 months was what we were able to do at Gympass, with an increase of 5 percentage points.

Gympass product development team in September 2018
Gympass product development team in August 2019
Evolution of the diversity of the Gympass product development team

At Conta Azul, we achieved something similar between 2016 and 2018 with an increase of 6.1 percentage points.

Conta Azul’s product development team in 2016
Conta Azul’s product development team in 2018
Evolution of the diversity of the product development team of Conta Azul

Diversity of perspectives

The product development team is comprised of software engineers, user experience designers and product managers. Each has a different perspective of what a good product is and these differences are what help to create a better product, when the differences are well resolved by the team.

Some time ago, I heard the following phrase:

The fact that two people disagree does not necessarily mean that one of them is wrong.

It really got me thinking about the diversity of perspectives. This has to do with empathy, one of the 7 essential characteristics of a product manager. Empathy is someone’s ability to step in someone else’s shoes to understand their aspirations, motivations, needs, and problems. What is her context? How does she see and hear things? What makes her understand things from this perspective?

There is a great tool called the empathy map, which aims to help teams gain a deeper view of their customers.

Empathy map (adapted from this source)

People have different backgrounds, different stories, different knowledge. We must recognize and respect these differences and understand that sometimes we will not reach an agreement, but that’s okay, as long as we respect each other’s perspective. Perhaps we can create a third perspective from the two different ones. Perhaps we can decide to try one, or both, and see and compare the results.

As long as there is respect and empathy, diversity brings many good results for everyone.

Summing up

  • There are two main reasons that motivate the construction of different digital product development teams. The first is that diversity brings new points of view. The second reason is that just as the group of customers using your product is diverse, so should your product development team.
  • People have different backgrounds, different stories, different knowledge. We must recognize and respect these differences and understand that sometimes we will not reach an agreement, but that’s okay, as long as we respect each other’s perspective.
  • It is in our hands to make the digital product development environment more inclusive. The way for this to happen is to bring up the topic and make it part of the conversations.

With this chapter, we finish to see what culture is and what, in my opinion, are the 5 main values ​​that the whole company must have to develop successful products:

  • 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, should not be the main focus.
  • Transparency, the foundation of a high-performance team.
  • Diversity, the basis of the best products.

In the next chapters, we will see four additional values ​​that, based on my experience, are the heart of digital product 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? 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 leading digital products

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.