What is digital product management?

We already have the definition of digital products, we saw many examples and many ways of categorizing these products. We also understood the difference between a product and a platform. Now we are going to define the role of digital product management:

Digital product management is the function responsible for all aspects of a software product, during the whole lifecycle of this product, from its conception to the end of its lifetime.

It is the function responsible for making the connection between the company strategy and the problems and needs of clients using the digital product. This one must be, at the same time, helping the company to accomplish its strategic goals, while solving the problems and needs of clients.

This definition clears up three important points:

  • The first one is the responsibility for all the aspects of a digital product. That means that product managers have to worry with the user experience and with the engineering of their product including the architecture, infrastructure and operation. Product managers also have to worry with legal and financial matters, client support, and product marketing and sales.

Worrying about does not mean doing all those things. In your company, there are people and departments dedicated to take care of these themes. Therefore, worrying means understanding these aspects, what are the relations with the product, and how the product impacts in each one of these areas. This will be the subject on Part III – Relation with other areas, in which I’ll approach the connection between software product management and other areas of the company.

  • The second point is that the responsibility takes place during the whole lifecycle of the product. As we will see on Part II – Lifecycle of a software product, the lifecycle of a product has different stages and each one of them requires special attention.
  • The third point is the connection that product management must build between the company’s strategic goals and the problems and needs of clients, which is what we will see next.

Aligning company strategy with customer needs

The very important third point of defining software product management is the responsibility for guaranteeing the connection between the company strategy and the problems and needs of clients. At the intersection between the business goals and the solution of problems (and needs) of clients lies the digital product management, as we can see in the picture as follows:

Digital product management

This is the theory, and everything seems simple in theory. However, as we all know, practice and theory can be quite different. The real-life digital product management is better illustrated by the picture:

Real-life digital product management on practice

In this image, we see Louis Cyr, considered the strongest man on Earth in 1890, who lifted 227kg using only 3 fingers and 1,967kg on his back!

It better represents the digital product management role because it is not always simple to conciliate the company’s goals and the solution for a problem or need of a client. A simple example is Facebook that, like any other company, needs the revenue to pay its costs and present some return to its investors. That is Facebook’s business goal. On the other hand, we find Facebook’s users, who access the system for free and are not interested in paying for that access.

Facebook’s product manager had to find a way of generating revenue without charging the users. The solution was to find another type of client, the advertisers, who were willing to pay to display ads for the users.

This image is incomplete…

The first image is incomplete. It talks about the company’s strategic goals and about the problems and needs of clients. However, a product manager cannot look just at these two items. There’s a third and very important item, which is the available technology.

The product manager must know the available technology in order to know if it’s possible to solve the client’s problem or need, attending to the company’s strategic goals. See the picture below:

Complete software product management

The core team for developing software products

The three concerns we’ve approached previously give us some taste of the ingredients to the product’s success. A successful product must be:

  • Desirable: solves problems or fits the needs of clients;
  • Viable: meets the company’s strategic goals; and
  • Feasible: there’s available technology for developing it.

These three requirements define the essential functions for creating a successful product: designer, product manager, and developer. This trio is considered the core team for developing a digital product and must be very much in sync in every stage of its development.

Software product development core team

Viable — what will sustain the business?

Product managers have two main responsibilities: to evaluate the product’s opportunities and to define the products that are going to be built. After evaluating and deciding that the development of the product will pay off, they initiate the phase of discovering exactly how it should be (along with the core team), including the necessary features, the user experience, and the criteria for launching it.

Besides, it is in their hands to determine the business model that is going to be followed, and interacting with practically every other area of the company in order to set up legal matters, accounting, financial, marketing, distribution technicalities, etc.

Desirable — what do people need?

This is where the User Experience (UX) comes in. There are many roles in a UX team, however, the one that works closely with the product manager is the interaction designer. They are responsible for searching for a deep understanding of users, discovering their motivations, behavior, and skills; for helping to define the requirements, thus designing an interface that makes the user interaction with the product as simpler and efficient as possible, while achieving the business goals at the same time.

Feasible — what can we build?

The software engineers or developers are responsible for effectively building the product. Their role is important in the stage of defining the product and clarifying what is possible to be done, the evaluation of costs of different ideas and helping to identify the best feasible solutions. It’s their responsibility to define the most appropriate technology and architecture for developing a quality product.

What is the difference between managing a product and a platform?

Regarding software products, the concern is only with one type of client. In a platform, if it is single-side, besides worrying about understanding one single type of client, it is necessary to understand the relation with him.

But if the platform is multi-sided you should worry about two or more different types of users and the relation between users of the same kind and of different kinds. In other words, the concerns, both from the product manager and from everyone who works in developing the platform, can be more complex than the ones regarding a product with one single kind of client.

A platform strategy must take into account that the client does not perceive value only in the features of the product that are 100% under the company’s control. Aside from the features, the client seeks value in interactions with third parties, and it is the company’s responsibility (the owner of the platform) to manage these relations in order to obtain the best results, both for the participants of the platform and for itself.

New concerns in platform management

Besides all concerns of product management that I’m describing in this book, those who manage platforms must also take into consideration other aspects.

The platform features depend on the participation of users. In English, we use the expression tipping for this concern, i.e., how to attract enough users to a platform so it can be useful for those who participate in it? Some strategies for this are:

  • First user: to get a first user who by himself attracts other ones. This is a tactic used by shopping malls when they sign contracts with department stores that by themselves attract enough consumers. Later, you can offer spots to other stores, that will certainly be more interested in being on the mall.
  • Social: another way of getting users is to engage on social networks and engines. Something like “tell your friends from Facebook”.
  • Leader user: discover what is the user profile that will be strongly attracted by the idea at the point of being the first one to adopt the platform. Bitcoin attracted several people from technology areas initially who fell in love with the idea of a currency not linked to any government, and they defend the idea passionately.

Think about the benefits as a product. The product itself must have enough benefits as a standalone product. Instagram, before the feature of sharing photos, was able to make photos look cool. OpenTable, before the booking feature, was a good ERP (Enterprise Resource Planning) for restaurants.

Consider lowering prices. It is a strategy valid for attracting users, but it is good to remember that it is difficult to raise the price later, especially if you lower it to zero. Sure, you can subsidize it with ads, but you need to know if your users will like those ads and if you are going to get advertisers willing to invest.

There are also features that depend on users’ behavior. In English, the term used for that is coring, i.e. how to guarantee that they are not taking unfair advantage of each other, ensuring that every participant has benefits? Some strategies for taking care of coring:

  • Promote trust: auction and online payment sites usually do this, holding up the buyer’s money until he confirms that he received the product sold to him.
  • Offer quality information: usually, those user-made ratings. The big risk here is to manage false ratings; or a positive evaluation made by the analyzed person or company, and negative ones made by competitors.
  • Restrict the use: turn the subscription and the use more restricted, so that will bring fewer users, but quality ones. That’s what the online dating website eHarmony does. It charges a fairly expensive monthly fee (US$ 50.00) and gives you a very extensive form for you to fill up. In addition, even if its matchmaking algorithm finds several options, it will only present you a limited number in order to ease up the process of choice.

Concluding

It is important to understand if you are working on a product or on a platform because there are some differences in managing each one of them.

A platform needs a strategy for attracting the first users, and this is equally or more important than the features. As software product managers, we tend to get excited with technical features, however, in platforms, the focus is concentrated on users, on their relations, and on how to attract the first users. In addition to that, managing a platform requires control and relation governance inside the platform itself, in order to guarantee that all participants are benefiting from it.

Once we understand what software product management is and what are the differences between managing software and managing platforms, what we need now is to understand what a software product manager is. That’s the subject of our next chapter!

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my almost 30 years of experience in creating and managing digital products:

  • Startup Guide: How startups and established companies can create profitable digital products
  • Product Management: How to increase the chances of success of your digital product
  • Leading Product Development: The art and science of managing product teams

What is a digital product?

Even before defining digital product management, let’s start from the beginning, that is, defining what is software and what is a digital product. Later, I’ll talk about what is digital product management and what are the main characteristics of being a good product manager.

I’ll also approach the differences between a product manager and a product owner, as well as when is the right time for the company to have a product manager. Lastly, I’ll give some leadership tips for product managers who are responsible for leading without being no one’s “boss”.

Are you ready? 🙂

What is a digital product?

Before defining a digital product based on software, I think it would be good for us to define what is software. According to Wikipedia on Software:

Software is any set of instructions that directs a computer processor (hardware) to perform specific operations.

In this Wikipedia article, there’s even a comparison between software and music, in which the author compares musical instruments to hardware, and the music (performed in these instruments) to software. I find this comparison very interesting.

Great, we already have a definition of software but what is a digital product?

You have certainly used some digital products; after all, the internet is made of them. Google, Facebook, and Twitter are good examples of what you’ve used or maybe use on a daily basis. When you shop on Amazon or on eBay, you are using a software product as well. The internet banking system from your bank can also be considered one, such as Netflix, that you can access from your computer, smartphone, tablet, or even directly from your TV.

The smartphone operational systems iOS and Android are software products. There are also the offline software products: the best known are the Microsoft Office, AutoCAD, SAP, and others; the least known, the embedded software inside hardware that is not computers, nor tablets, nor smartphones, but printers, TVs, videogame consoles, voting machine, network equipment such as routers, switches, hubs, and firewalls, etc.

A digital product is any software that has users.

So, can any software can be considered a digital product? No, because there is software that doesn’t have any users. They are the software that interfaces with other ones. Some examples are:

  • Hardware drivers that translate the information between the device and the applications or operational system.
  • Firmware, which is the set of operational instructions programmed directly into the hardware of an electronic equipment.
  • Compatibility layer, that allows software to run in an environment in which it was not originally programmed to run, such as a host system.

However, even this kind of software benefits from the concepts and practices of digital product management that I’ll approach in this book.

Types of digital products

Digital products can be categorized in different ways, depending on how we see them. We can look, as described previously, to the way that the product is delivered to users (online, offline, embedded), or according to what it does: e-mail, e-commerce, payment, e-mail marketing, content management, education, communication, collaboration, reports, entertaining, operational system, ERP, CRM, etc.

Another way — my favorite, because puts the user in the center — is to look and categorize products according to for whom it solves the problem. From this point of view, we can have three types of software products:

  • For end customers: in this type of product, a problem is solved for end customers who are willing to pay in order to use the software. Some examples are Netflix, LinkedIn and online games. There are also software products for end customers who pay indirectly, i.e., customers pay for another service and the software product is only a small part of this service. Some examples are internet banking, school or college intranets, access to lab exams and embedded software in general. E-commerce websites also belong to this category, since their use is free and the fee is paid by the products you buy and are delivered to you.
  • For companies: this type of product solves companies’ problems, who are more willing to pay for a software than the end customer. Some examples are Locaweb, Google AdWords, SAP, AutoCAD and Microsoft Office.
  • Mixed: in this case, the product solves the problem both for end customers and companies. Usually, this type of product doesn’t have any cost for the end customer; companies pay the bill. The most common model for revenue generation in this type of product is advertising, paid for the company when the final customer sees it, clicks on it or buys something because of it. A great example is Google Search, which is a software product for end customers, and Google AdWords, a software product for companies.

Note that, while describing each type, I had the concern of getting clear who’s paying the bill. This is very important because every software product has costs. Even though the costs might be hidden, they do exist; ergo, every software product needs to generate income in some way.

Even though I prefer to categorize software products while understanding to whom it solves the problem, there are other ways of classifying them. For example, Netflix is a software product for the final user, but also an online software product for entertainment.

These categorizations have a direct impact on the daily work of the product manager, i.e., different types of products require different types of product management skills. Managing an ERP is different from managing an e-mail marketing product. Managing an online product is different from managing a mobile app product. Managing a consumer product is different from managing a product for companies.

Digital or traditional?

Most recently I realized another way to categorize not only the software product but also the company that owns the software product, and this categorization has a HUGE impact not only on how a product manager manages her product but also on the role of the product manager in the organization that owns the product.

Digital companies

We all know digital companies. Google with its main product, Google Search and GMail. Amazon Web Services. Facebook. Instagram. WhasApp. SAP. Salesforce. Zendesk. The companies I worked for (Locaweb and Conta Azul). All of these companies sell their software products to their customers. The product is the core of the company. If there’s no software product, there’s no company. Can you imagine Google without Google Search software? Or Instagram without the Instagram app? Or Zendesk without Zendesk software?

In these companies, product management is the core of the company. Product management is responsible for defining a good portion – if not all – of the vision and the strategy of the company. The role of the product manager in this company is central.

Traditional companies

In the other end of the spectrum, there are what we can call the traditional companies. These companies sell products and services that are not software. However, all of them are in a way or another passing through some sort of digital transformation, i.e., learning how to use digital technology to improve their business. Examples of improvements that can result from the use of digital technologies are:

  • enhanced customer relationship.
  • data gathering and insights.
  • innovation through rapid experimentation.
  • increased process speed and quality through automation.

I’ll give some known Brazilian examples. Itau, one of the biggest Brazilian banks founded in 1924, is investing a lot to become digital, with internet banking and its app. From time to time they launch TV campaigns to show this transformation. Itau is 91 years old. Magazine Luiza, a physical retail chain founded in 1957, has also been investing a lot in its digital presence. They are well known in Brazil for their online presence and their app.

Other good examples of traditional companies investing in digital are airlines and hotels. They have websites and apps so customers can buy tickets, make reservations, interact with their customers.

In traditional companies, their products or services exist, and probably existed for a long time without digital technology. Executives and shareholders are beginning to understand how digital technologies can impact their businesses and are investing in digital transformation. In these companies, software product management is an enabler, but it is not the core. Normally it is part of a team named “the digital team”. Product managers will have to earn their space, showing how technology can impact the business.

The third type of company: born-digital traditional companies

These types of companies have traditional products or services that can exist without technology. However, as they have included technology since their beginning as a strategic capability, they look like digital companies.

Everyone considers them as tech companies and, in a sense, they are. Technology is at the core of their strategy. On the other hand, when we take a closer look, their product is not technology. Their product is enabled and potentialized by digital technology. Amazon’s products are goods (books, computers, cell phones, etc.). Netflix and YouTube’s product is video content. Spotify’s product is audio content. Airbnb is an advertisement business that generates leads to the advertised houses being offered for rent. Google Adwords is also an advertisement business that generates leads to whatever product or service is advertised. Nubank, a Brazilian digital bank, offers credit card and bank account services like any bank. Uber and Lyft main service is transportation. Rappi, a Colombian delivery service, and iFood and GrubHub, food delivery services, are what I just wrote, delivery services. And Gympass offers access to more than 50,000 gyms and studios around the world.

Examples of born-digital traditional companies

Their products are not technology. Their products are not software. Digital technology and software enable and potentialize their products. For this reason, product management is very important but is not central to the definition of the company vision and strategy. Product managers will have a very important role in defining and executing the company vision and strategy, but they will not have a central role.

Product or platform?

More and more we see software products that can be categorized as platforms. There are many examples from big tech companies such as:

  • Google, which with two products (Search and AdWords) created a platform connecting people who search information on internet to people who want to advertise things on internet.
  • Facebook, that started as a platform in which friends could find each other and exchange information, and then became a platform in which advertisers can talk to people through ads and fan pages.
  • LinkedIn, a platform for professionals, companies and, most recently, advertisers.
  • Apple, that connect software developers with iPhone, iPad and Macs with their AppStore. Another Apple platform is iTunes, connecting media producers with people interested in music, films, series, and books.
  • Amazon Kindle, a platform that allows publishing houses or authors to publish books for people interested in these contents.

By the way, some of those companies have more than one single platform such as Google, Apple, and Amazon.

Besides those big technology companies, there are also more recent examples:

  • Uber, connecting drivers to people who need transportation.
  • Airbnb, that connects owners of properties for short-period rental to people who want to rent properties in such conditions.
  • Bitcoin, a digital asset and payment system. The more users it has and more companies accept Bitcoin as payment, the better.

There are also examples of platforms that are not necessarily based in technology, like shopping malls, which put stores, restaurants and movie theatres next to people who want to buy, eat and have fun.

What are platforms?

Platforms are systems that get more valuable as more people use them.

In other words, they are systems strongly based on the concept of the network effect. A network effect is an effect by which a given software is more valuable when more users use the software.

Platform

There are two types of platforms:

  • Single-side platforms: are those that, the more users they get, the better. Using an old example, the FAX machine. It was not worth having one if only one person would use it; the more people using it, the better. The same is valid for social network (Facebook, Twitter, etc.).
  • Cross-side or multi-side platforms: those in which there are two or more different groups of people that use the platform in distinct ways and that benefit from this different way that each group uses it. This type can be divided in three categories:

Technologic platform: in which the platform is the operating system and, on one side we have the user and, on the other, we have operational system developers: Linux, Windows, and Android.

Exchange platform: it gathers buyers and sellers: MercadoLivre, Uber, and Airbnb.

Content platform: the content is the focus, and monetization usually takes place through ads (Google, Facebook, and news portals).

The following is an example of a technologic platform with 5 sides:

Android operation system seen as a 5-side platforma

It is important not to confuse the concept of platform in the product context with the concept of technical or computer platform. A computer platform is any computer environment where software applications are going to run at. In the product context, as we defined previously, we name it as a product platform when there are gains to users the more users are using the product.

In a 2019 book called The Business of Platforms: Strategy in the Age of Digital Competition, Innovation, and Power (https://www.amazon.com/Business-Platforms-Strategy-Competition-Innovation/dp/0062896326), the authors categorize platforms into either transaction platforms where transactions happen (marketplaces, ad networks, streaming, access to networks of houses, riders, gyms, etc.) and innovation platforms where new value is built on top of the platform (operating systems, app stores, AWS, etc.).

One important aspect mentioned in the book is that transaction platforms are somewhat easy to be copied and replaced, while innovation platforms are a bit harder to be copied and replaced due to all the technology investment that participants of the platform do to be part of the platform. Many transaction platforms evolve to become hybrid platforms, i.e., incorporate innovation characteristics to enable their users to build new value on top of the existing platforms.

In this chapter, we saw the definitions of software, digital product, and platform, let’s now uncover what is software product management.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my almost 30 years of experience in creating and managing digital products:

  • Startup Guide: How startups and established companies can create profitable digital products
  • Product Management: How to increase the chances of success of your digital product
  • Leading Product Development: The art and science of managing product teams

About the Product Management book

We are at that point in which there is software in places where a few years ago, we never imagined that there would be need and usefulness in having software: TVs, refrigerators, stoves, cars, watches, glasses, clothing, locks, tables, chairs, medical equipment and so on. Not to mention the most obvious, the phone and wristwatch that are in our pockets, purses, and wrists and from which we are becoming increasingly dependent.

The ubiquity of software is now a reality; the software permeates numerous activities and objects of our daily lives. I think one can say that 100% of the population has their lives affected by software, and much of this population has frequent contact with software. According to the Digital 2019 report, even underdeveloped regions like Africa already have more than 36% of their active population on the Internet. In 2015 it was already 25%.

Even with this evidence that software-based digital products are part of the life of every person on the planet, I still have the impression that we do not give it due attention and care. Think of all the times you used a digital product over the past seven days. Have you had any frustrating experiences with it? I’m sure you did.

I have frustrating experiences with the software on a daily basis. Even software made by experts on the topic of digital product development — such as Google, Facebook, and other companies that were born and raised making software and that are often cited as references when we discuss the software development process — cause us frustration.

Why does this happen?

Software development has evolved a lot over the years. Talking about processes, we had a waterfall where each phase of the software development occurred sequentially. The distance between the need that generated the demand of the software development and the software itself was huge.

At the beginning of this millennium, we begin experiencing agile methodologies, which turned the software development process into a cycle with short interactions that promote continuous feedback. This helped considerably to bridge the gap between the need that generated the demand for software development and the software itself.

In terms of the aspects taken into consideration in the software development, we also evolved a lot. In the beginning, software was developed by teams composed exclusively of software developers. In fact, it was not uncommon for these teams to be composed of a single person. We increasingly see multidisciplinary teams working together in the development of software; which is very good because it brings new insights to the software being developed.

On one hand, the concern with the user, her goals when using the software, and her interactions with this software are taken care of by user experience professionals, or UX.

On the other hand, the concern about software operation, i.e., where this software will run and what performance and availability it needs to have, brought system administration professionals (SysAdmins) closer to the software development process. This proximity between software operation and software development is what gave rise to the term and DevOps culture.

So, we deliver software more frequently, and brought UX and SysAdmins into the software development process; but is this really enough? How do we tell the world, or better, the people who can benefit from this software, that this software exists? How do we take care of your legal issues? When a user has a problem with the software, how do we help her? How do we manage the return it will bring? How to ensure that the software meets the objectives of its owner while it also meets the needs of its users?

Digital product management

Thinking about these issues, some companies that are considered experts on software development began to adopt new expertise in its software development process, Digital Product Management. This role aims to ensure that the software being developed meets the objectives of its owner while it also meets the needs of its users.

In addition, a person in this role has to consider all the aspects of the digital product that I mentioned earlier. Some agile methodologies such as Scrum have the role of the Product Owner, whose main responsibility is to prioritize items to be developed. In a way, this is what a Digital Product Manager does, but there’s a little bit more to be covered by this role.

That’s what I’ll talk about in this book. 🙂

Who will benefit from reading this book?

This book is recommended for anyone who works with software. It is for people who are product managers since every product manager knows that there is always plenty to learn. And even those who have good knowledge of all the topics presented in the book may benefit from reviewing the topics.

This book is also recommended for anyone who is willing to get into a product management career. I believe this book can relieve some of the anxiety of those who are considering becoming product managers and are not sure what they will do and what other people expect of them.

I believe that even people who are not planning to become product managers will also benefit from this book, understanding what a person in this position does in the software life cycle and how a product manager should relate to other areas.

Note that I said this book is suitable for anyone working with the software. Even companies that do not have software as their core business use software in their day-to-day and often have developed some software that interfaces with its customers, such as a website or a mobile application. It is important for these companies to understand the software product management role and responsibilities, so they can better manage this software and increase its chances of success.

This book does not pretend to cover all the topics extensively. If it did so, it would probably have to be in a collection of books. My goal is to talk about the main topics related to digital product management, deepening on some specific topics and providing various additional reading suggestions.

In some places, the book will refer to Agile software development and the role of PO (product owner). I believe that the knowledge of the software development process and the different roles involved in this process is not necessarily a prerequisite for reading this book, but it is certainly knowledge that will help increase the chances of success of your software. If you want to delve into the subject, I recommend the book “Learning Agile: Understanding Scrum, XP, Lean, and Kanban” by Andrew Stellman, Jennifer Greene. In addition to explaining the principles behind agile culture, it also presents Scrum, XP, Lean, and Kanban, the four most popular agile methodologies, and how to spread the agile culture throughout the company. Recommended reading.

Book structure

I wrote the book with the following structure:

  • Part I – Definitions and requirements: People who know me know that I like clear definitions before I start discussing a particular topic. This is what I call the “equalization of concepts”. Therefore, I start the book by defining some keywords such as software, product, platform, product management, among others. In this part, I will also talk about the characteristics of a good product manager, the typical career of a product manager, and what the role of a product manager is. I will also give some tips to product managers about leadership and organizational culture.
  • Part II – Life cycle of a software product: In this part, I will describe what the life cycle of a software product is like and what the phases of that cycle are: innovation, growth, maturity and end of life. Still, I’ll talk about innovation, how to find a problem to solve, how to find out if it’s really an opportunity to pursue, and how to get feedback from your software product. At the growth stage, when the product was developed and released, should we be concerned with how to manage the product during its growth, ie how to manage feedback? What is a roadmap? What is OKR? When to use roadmap and when to use OKR? How to prioritize the demands? What to do with special requests? How to say no? What metrics to track? What is it and how do you create the vision and strategy of your product? After this growth comes maturity. In this part, we will understand when maturity happens and what to do if the product reaches this stage. After maturity, or when the product is developed but not working, comes the end-of-life phase of a software product. We’ll see how to detect and what to do at this stage of the cycle. In the end, when we know all the phases of a product’s life cycle, I’ll show you the difference between startup and software product management.
  • Part III – Relationship with other areas: how product managers relate with all different business roles, such as engineering, UX, product marketing, project management, operations, sales, legal, finance, HR and administration?
  • Part IV – Product portfolio management: why do some companies decide to have more than one product? How do they manage this portfolio of products? Why do other companies prefer to focus on a single product? Focus or diversification, which is the most appropriate strategy? How to organize the product development team according to the chosen strategy? These issues are what I consider advanced topics of software product management, and that is what we will see in the chapters that make up this part of the book.
  • Part V – Where to use software product management: does software product management can only be used by companies that sell software products and only in the development teams that develop software that are commercialized as products? Or would other companies benefit from treating their software as a product and using the product management techniques to increase the chances of success of their software? And where should we put the software product management in a company? In marketing? In the technical area? These will be the themes of the final chapters of the book

This sequence has a logical order and some chapters reference topics covered in previous chapters. For this reason, I recommend the sequential reading of the book. However, the chapters can also be read independently. If you are very curious to read about a particular topic, feel free to jump straight to the relevant section.

Enjoy!

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my almost 30 years of experience in creating and managing digital products:

  • Startup Guide: How startups and established companies can create profitable digital products
  • Product Management: How to increase the chances of success of your digital product
  • Leading Product Development: The art and science of managing product teams

Conclusion

After this summary, we reach the end of the book. I have tried to document here what I have learned over the course of my career in the hope of helping others to learn more about leading digital product development.

Throughout my 30-year career, I have been experimenting with different ways to help product development teams achieve their goals, that is, to be able to create and evolve successful products. I have helped not only the teams that I dealt with directly, but also teams from other companies for whom I provide advisoring service. All of these experiences provided me with a very fertile field for experimentation and learning.

There are other ways to lead product teams, and some may even have points of disagreement with what I presented here in the book. However, there is no single way to do things and the fact that they are different or even discordant does not mean that any of them is wrong. It just means that they are different and it is up to each of us to find the way that makes the most sense for the leadership challenge we encounter.

The most important thing is that we share our learnings, even if they disagree, so that we can always evolve this discipline so new that it is the development of digital products. It was not even 100 years ago that this science started, we are a newborn compared to mathematics, engineering, medicine, astronomy and so many other sciences that have existed for millennia.

Shall we continue the conversation?

The fact that we are in the early childhood of developing digital products means that there is still a lot to learn and experience. These learnings and experiments need to be shared to help others learn more, experiment, agree and disagree so that we can make the art and science of leading digital products evolve more and more to produce better and more useful products.

I will continue to share my learnings here in this site. I encourage you to also share your experience and learnings about digital product development leadership! I look forward to learning more!

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my almost 30 years of experience in creating and managing digital products:

  • Startup Guide: How startups and established companies can create profitable digital products
  • Product Management: How to increase the chances of success of your digital product
  • Leading Product Development: The art and science of managing product teams

Summing up

In this chapter, I have transcribed the Summing up sections of all chapters in order to create a quick reference guide on all topics discussed in this book.

Concepts

I started the book by establishing some definitions, reviewing basic concepts like product and product management, and introducing new concepts like product head roles and responsibilities, team structure, career and Y career for product managers.

What is digital product and product management

  • Digital product is any software that has users.
  • Digital products can exist both in digital companies, where the digital product is the product that the company sells, and in traditional companies, which use the digital product to leverage and leverage the company’s main product .
  • Recently, traditional digital-born companies started to appear, that is, companies that sell a non-digital product, but that have the digital product as a critical part of their strategy since the beginning of the company.
  • Platforms are products that deliver more value the more users use the platform, the famous network effect. There are single-sided platforms and multi-sided platforms, which can be exchange, content or techniques.
  • Product management is the function responsible for connecting the company’s strategic objectives with the customers’ problems and needs.

Roles, responsibility and seniority

  • The head of product is responsible for coordinating the definition of the product vision and strategy, for helping product managers in their development and for managing the expectations of all people who have interest in your product.
  • A very important concept to help a product head with its responsibilities is the concept of seniority, which has 3 dimensions, two well known, time and knowledge and a third not so known, but just as important as others, behavioural seniority.

Product management career

  • The product career has progressed from Associate Product Manager (APM) to Product Manager (PM) to Group Product Manager (GPM) to Chief Product Officer (CPO). There are some variations of nomenclature depending on the company and the country, but in general it follows this progression. The important thing is that this structure and career progression are clear for the entire company.
  • When talking about the most senior product leadership in a company, there are two options with their pros and cons. One option is the unique leadership of the entire product development team (PM, UX and engineering), which works well for larger teams, but can be overwhelming when teams of more than 100 people. The advantage is having the entire team aligned with a single leadership. The other option is shared leadership with CPO and CTO, which avoids overload in large teams, but can cause a decrease in collaboration if there is no good harmony between these two or more leaders.
  • For PMs who do not want to pursue a management career, it is important to give the Y career option, with the role of Principal Product Manager, which helps in integrating and synchronizing the work of the different teams.

Product vision

  • Despite being only 10% of a product leader’s time, defining product vision is his most important responsibility. Without it all the product development work is much more difficult.
  • The product vision is nothing more than an understanding of what your product will look like in the future.
  • To make the product vision it is necessary to be clear about the company’s objectives with the product, as well as to deeply understand the problems and needs that customers have and that will be solved by the product.
  • The 6 steps to build a product vision are: obtain strategic objectives of the company, gain understanding of the problems and needs of customers, design the first version of the vision, iterate and refine, communicate and review.

Strategy and objectives

  • Product strategy is nothing more than the path you will take to reach your product vision.
  • To create your product strategy you need to have a good understanding of your market, that is, the competitors, the potential and accessible market, the growth of this market, if there are disruptors and how that market is regulated.
  • Use SWOT analysis to help define what points you will work on in your product strategy.
  • Use OKRs to help define your strategy goals 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. OKRs must be reviewed quarterly.

Team structure

  • 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 journey or by objective. It is also possible to use two different types of organization, 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 and strategy well to design and implement a team structure aligned with it.
  • 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 their team structure are the Conway’s Law, which says that organizations tend to create systems that are a copy of the companies’ communication structure, and the 4 stages of Tuckman of team formation, forming, confronting, standardizing 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 the acquisition, 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 are the common goals.

Developing the team and managing expectations

  • 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 features are essential for a head of product. Empathy to understand where expectations come from and what elements need to be developed in your team. Communication to be able to 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 you understand company goals that are important components of people’s expectations of the product.

Anti-patterns

  • 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 head of product 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 one.
  • Wishlist comes from the need for the new head of product to please all stakeholders, focusing on the product development team to only implement what is requested, delegating prioritization to other areas of the company.

Principles

Here we saw my personal leadership 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.

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. Finally, we saw four values ​​that are the core of the entire digital product development team. They 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:

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

People: priority #1, always

  • People are, and should always be, the number 1 priority of any company. We spend money and energy to acquire and retain the best people. Having people as number one priority is the key to achieving any other goal. This does not mean being “nice”, giving everything they want, but that we must be able to balance the challenges we give people so that they can improve continuously.
  • Bad apples can drain and damage 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 them out of the team.

Leading is like being a doctor

  • The next time you are on a team, either as part of it 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.

Leading under pressure

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

Mentorship is a two-way street

  • Mentoring is one of the most important roles for a product head. It is through mentoring that a head of products 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.

How and when to delegate

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

Culture and values

  • Culture is the way a group of people respond to everyday situations. It is the role of the head of product 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 about 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.

Transparency, the foundation of a high performance team

  • Every leader, to help her team perform better, needs to explain the context and remove impediments.
  • In order to explain the context, it is essential to be transparent, explain the company numbers, explain the motivations behind each decision, include the team in the decisions.
  • Transparency in the management of companies seems modern, but it has existed for some decades. Two interesting examples come from the 1980s. One at an American company called Springfield ReManufacturing Corp (SRC), which created the concept of open book management. The other in a Brazilian company called Semco, by Ricardo Semler, where Clóvis Bojikian, its HR director, implemented participatory management. Both are from the 1980s and are industries, that is, the vanguard of participatory management.
  • With transparency, it is possible to give people the necessary information so that they understand the context and motivation of the work they are doing and are able to make better decisions about that work.

Diversity, the basis of the best products

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

Release early and often

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

Focus on the problem

  • A very important step in creating a good solution is understanding the problem. When we hear about a problem, we immediately start thinking about solutions. However, the more time we spend learning about the problem, the easier it will be to find a solution and chances are good that this solution will be simpler and faster to implement than the first solution we thought of.
  • If you have a list of projects to do, create two more columns in that list, one for problems to be solved in each project and another for whom the problems will be solved. This will help you to focus on the problems to be solved, not the projects, which are the solution.
  • Solution implementation teams are teams working on implementing a solution designed by someone else. Problem solving teams are teams that work to deeply understand the causes of the problem, the context and the motivation that people have to solve it. In doing so, they are able to implement the best solution for the problem at hand.
  • The top-down trap is the perception of the decision-making process being made by the leaders of the company, with no opportunity for the rest of the employees to participate. This perception is exacerbated when a company faces increasing pressure, such as the COVID-19 crisis.
  • People are solution-oriented, and the greater the pressure, the faster people want solutions to be implemented.
  • To help deal with this situation, use empathy to understand the requestor’s view of implementing the solution and ask him why it is necessary to implement the requested solution.
  • Heads of product have the role and responsibility to promote these behavioral changes to help build a more collaborative decision-making process.

Result delivery

  • Another fundamental value for any product development team is the focus on delivering results.
  • Care must be taken when defining the result. Delivering functionality is not a result. All functionality is a means that serves an end, the achievement of a business objective.
  • Even 100% digital companies, whose digital product and technology are the company’s core, focus on business objectives.

Ecosystem mindset

  • Ecosystem mindset means making decisions that create value for all actors on a platform.
  • At Gympass, during the COVID-19 crisis, after placing Gympass Wellness for all its customers and their employees, an important part of the ecosystem was still suffering, the gyms. It was the ecosystem mentality that guided Gympass to create the Live Classes product, which allowed gyms to continue operating even though they were behind closed doors.

Tools

Here we saw the tools that I have used in my almost 30 years of leadership in product development leadership and that I have shared with other leaders so that they can use with their teams. The tools I will talk about include vision, strategy, goals, team structure, metrics, relationships and ceremonies.

Vision, strategy, objectives and team structure

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

Measuring and managing productivity

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

Measuring and managing quality

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

Metrics

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

Relationships

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

Hire the right people

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

Feedback and performance evaluation

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

Ceremonies

  • These ceremonies with different stakeholders are aimed at planning, alignment and expectation management. I emphasize that this list is not definitive, that is, depending on the company and the context, it may be interesting to create others and some of the ceremonies listed here may not be necessary.
  • 1:1 meetings are important to maintain alignment and communication with your followers, your leaders, other team members and people from other areas. 1:1 with your team members and your leader should be weekly and have an hour of conversation set aside. The 1:1 with other people may have a shorter periodicity and duration, or even be occasional. The topic of these meetings is free, and should not be limited to accountability. They involve personal issues, day to day, concerns, feedbacks, retrospectives.
  • Leadership team meetings are the meetings that the product head has with its direct followers. In addition to direct team members, it is important to have the HR person who is dedicated to helping your team. The topic is free, but it is important to periodically discuss OKRs and communication dynamics with the rest of the company. At least weekly. They can happen more than once a week, even daily if there are many topics to be discussed.
  • All-Hands are meetings with the entire product development team where the achievements are celebrated and the lessons learned are shared. The recommendation is that they are monthly.
  • Product Council are the meetings where the planning of the next quarter is presented to the senior leadership of the company, preferably in the format of OKRs. They are usually quarterly.
  • Product Updates are used to remove the black box effect from product and technology teams. That’s when the leaders of this team present what was done in the last month, what will be done in the next month, how these deliveries impact the company’s results, demonstrations of features and openness for anyone to ask what they want for the team.
  • Team structure meeting serves to discuss with the leadership of the product development team how the team will be organized, how we will use the hiring budget and what the hiring priority is.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my almost 30 years of experience in creating and managing digital products:

  • Startup Guide: How startups and established companies can create profitable digital products
  • Product Management: How to increase the chances of success of your digital product
  • Leading Product Development: The art and science of managing product teams

Ceremonies

In this chapter, I’m going to talk about the ceremonies I usually use with the teams I lead. These ceremonies with different stakeholders aim at planning, aligning and managing expectations. I emphasize that this list is not definitive, that is, depending on the company and the context, it may be interesting to create others, and some of the ceremonies listed here may not be necessary. I will talk about 1:1 meetings (one on one or one to one), leadership meetings, All-Hands meetings, Product Council, Product Update and team structure meetings.

1:1 meetings

1:1 meetings are those that the head of product has with his direct reports, his leader, other members of his team and with people from other areas.

1:1 with direct reports

The 1:1 meetings with the team members are, certainly, one of the most important meetings of the head of product. Ideally they should be every week and one hour long. If the head of product is unable to do these meetings in one week and decides to do it every other week or to shorten its duration, it is a sign that she has too many direct reports. Despite having an hour, this meeting need not necessarily take an hour. In some weeks, they may take less than an hour, in others, more time may be needed.

The theme of this meeting is free. Personal issues, day-to-day issues, concerns, feedbacks, retrospectives. It should not focus solely on the person’s accountability and progress report. During these conversations there will certainly be themes that should be discussed together with other people on your team, so suggest moving the theme to the leadership meeting. Once a month, at the beginning of a new month, it is important to stop by the OKRs to see if there are any impediments you can help with.

This meeting can be held in a room, or in a cafe or restaurant for lunch. Or even by video, in case people are not in the same place. I’ve seen people doing 1:1 walking. It is up to you and the person you are doing the 1:1 with.

I usually write down the themes as I remember a topic to be discussed in a document shared with the team member. I divide this document into new themes and, as we talk, we write down some points about the themes for future reference. After the 1:1, I mark the date when the meeting took place and open another section for new topics.

1:1 with your leader

You report to someone in the organization, so it’s also important to maintain a cadence of at least weekly conversations with that person. This meeting should serve as an alignment between the two of you, to ensure that that person always gives you the context of the company and the product that you lead in that company, and that it helps you to remove the impediments.

As a head of product, it may happen that you report to someone who doesn’t have as much experience with product development management as you do. On the other hand, that person will have experience and knowledge in other areas. It is important that this difference in knowledge and experience is clear to both, so that you can make these conversations as beneficial as possible for both of you.

Regarding where to do it, and how to write it down, the comments I made above about 1:1 with your direct reports are valid here.

1:1 with other people

In addition to the 1:1s with your team members and your leader which, as I said above, should be weekly and one hour long, you may need to do 1:1s with other people on your team and with people from other areas. This is because the rush of everyday life can be so that there is no time for these conversations to happen if they are not scheduled. Assess with each of these people whether there is a weekly, periodic or just occasional need for these conversations. The duration can also be less than an hour.

I usually have the need for 1:1 weekly with HR leaders, to talk about the needs of hiring and managing people from the product development team. I also usually have 1:1 weekly with the leader of the marketing area to talk about generating demand for product and about product marketing, that is, about how to tell the world about the problem that the product solves and how our product solves it. Less frequently than weekly, it may make sense 1:1 with the sales leader, to talk about the product sales process, with the operations leader, to understand the operational impacts of the product, and with the financial leader, to understand the revenues and costs generated by the product and the team.

Leadership team meetings

Leadership team meetings are the meetings that the head of product has with its direct reports. In addition to the direct reports, it is important to have the HR person who is dedicated to helping your team. If you don’t have someone dedicated to HR, bring the most senior HR person who has been closest to the product development team.

This is a team meeting, not the head of product meeting. In other words, topics brought by anyone on the team should be discussed, and not just topics from the head of product. Even when the head of product is not present, it should happen normally. If the topic being discussed requires the presence of someone who is not at the meeting, you must wait to discuss it when that person is at the meeting.

The topics to be discussed can be placed in a Google Docs document, shared with everyone who attends the meeting. Anyone can post topics to be discussed. They can be the most varied, as long as it makes sense to be discussed with the people present. When themes arise proposing to create a new routine or a new project that makes sense to be executed, this is an excellent opportunity for the head of product to delegate to someone on her team, who can create a subgroup to deal with the theme. Examples of such themes are Design System, Hack Day, Career Plan, among others. Some topics that should appear periodically at this meeting to be discussed with all leaders of the product development team:

  • OKRs: definition and monitoring of OKRs. Definition, once a quarter and follow-up at least once a month, ideally every week, to see if there are any impediments that need to be removed.
  • Product Council: I will talk a little later in this chapter about the Product Council, which is a quarterly planning presentation meeting of the product development team for the company’s senior leadership. It is important to plan together with your team what will be discussed at the Product Council.
  • All-Hands and Product Update: for these two meetings, which are monthly, which I will also talk about a little later, it is important to define together with the team on the topics.
  • P&L: profit and loss or revenue and cost. It is important to discuss with the team, at least monthly, how much revenue is being generated with the product and how much the product team costs, including not only people but all other costs (infrastructure, training, consulting, etc.).

Before joining Gympass, I used to have this meeting in person once a week. These meetings were one hour long and, when there were many topics, we increased to 1.5 or 2 hours to be able to talk about all the topics. At Gympass, as part of the team was in other countries, we started to do the meeting remotely, but still once a week. Still at Gympass, when the pandemic started, we decided to change the rate to daily, given the volume of issues that had to be discussed due to the crisis. After some time, we took off the Friday meeting to create a meeting-free day, that is, a day of the week without meetings. When I joined Lopes, as we are remote and have so much to talk about, we chose to hold our meetings daily. When we realize that there is not enough subject for an hour, we will decrease the frequency.

YOUR LEADER’s Leadership meeting

In addition to coordinating your leadership meeting with your team members, you will most likely participate in your leader’s team meeting, which will define the model and pace of those meetings. Take advantage of these meetings to align with your peers and your leader. Bring product development themes that may be relevant to them. If there is space, this is a good meeting to sporadically bring in some of your team members to discuss a topic. With this, you will give visibility to the people of your team, besides allowing them the opportunity to interact with other senior leaders of the company.

All-Hands Meeting

All-Hands meetings are meetings with everyone on the product development team, not just your direct reports. In addition to the people on the product development team, HR people working together with the product development team and other guests such as the CEO / founder, leaders from other areas and whoever makes sense to participate should also participate.

The objective is to celebrate the results, talk about lessons learned, discuss the progress of OKRs, introduce new team members and any other topic that makes sense to talk to the whole team.

The most recommended frequency is monthly and it’s nice to have a happy hour with the whole team after the meeting for relaxation. If the meeting is remote, happy hour will also be remote.

Product Council

The Product Council is a meeting with the leadership of your team and the senior leadership of the company in which your team presents the planning for the next quarter and, at the turn of the year, the planning for next year. The product council’s goal is to have everyone aligned in relation to the objectives to be achieved in the next quarter and in the metrics that will count that these objectives are being achieved.

It should happen quarterly, about a week before the new quarter begins. At this meeting, each leader of the product development team presents their next quarter planning to the company’s senior leadership. Often, the 3-month plan does not include some topics that may be important for the participants of this meeting. For this reason, I have recommended the use of the 12-month rolling roadmap, which allows us to show not only what lies ahead in the next quarter but also in the next 12 months. The objective is not to discuss whether what is in the fourth quarter should come before what is in the third quarter, but whether what is in the fourth quarter should be worked on in the next quarter and, if so, what should be postponed.

Example of a 12-month rolling roadmap

Note that, although we are talking about the roadmap, the first part talks about goals and results. It is essential to maintain the order of priority of the themes. More important than what is going to be done are the goals we want to achieve and which metrics indicate that we are achieving those goals. It is the role of the head of product to remember this priority of discussion of the themes.

One way to change the focus to stay 100% in objectives and results is to not use a roadmap and discuss only OKRs. Both at Gympass and Lopes, I have had the opportunity to participate in very productive Product Councils, focused exclusively on discussing OKRs.

The duration of these meetings depends on the number of topics to be discussed. I have already participated in Product Council meetings that had to be held in two days, given the number of topics and the need for necessary alignment. On the other hand, the shortest Product Council meetings I lead lasted between 1.5 to 2 hours.

The meeting’s agenda starts with the head of product making an introduction with information about the planning context for the next quarter and then each of the leaders of the product development team presents their planning.

An important point is to make a preview of the Product Council without the company’s senior leadership, to give your team members the opportunity to align themselves on their plans if they have not already done so. I once did a Product Council without this prior alignment and, in the middle of presenting a person’s planning, the other commented that he “could not have planned to do that because X and Y are not ready and will only be delivered at the end of the quarter” , which showed the lack of coordination between them.

Another important preparatory work for the Product Council meeting is 1:1 meetings that can be done between a leader of the product development team and someone from the senior leadership, to seek feedback on planning in a more reserved environment and to already take the planning for Product Council considering that feedback. The recommendation is to do as many 1:1s as necessary to obtain a good pre-Product Council alignment.

Product Council with customers

A variation of the Product Council that can be interesting to conduct is the Product Council with customers, that is, you invite some customers to work with them on a prioritization proposal for the next quarter. We did this a few times at Conta Azul, when we called some of our partner accountants to spend the day with us, to give them the opportunity to get to know our operation up close and, in a certain part of the day, we did a prioritization exercise with them, where we listed a series of features, each with a certain development cost, and let them choose within a development cost limit that they could apply.

It is very nice to see customers experiencing the same difficulty that we, product managers, have when making prioritization decisions. This prioritization made by the accountants served as another input for our prioritization work to be prepared for the next quarter and to be presented at the Product Council with the company’s senior leadership.

Product Update

This is also a monthly meeting where the product team presents to the entire company what has been done in the last month and what is planned for the next month, always connecting with the team’s OKRs. This is a very important meeting for managing expectations. At Conta Azul, since we had a company-wide All-Hands meeting every week, we took one of these meetings to be the product update. At Gympass, the All-Hands meetings took place once a month, so we created a separate meeting, called “Global Product Update Call”, which had to be a remote meeting since Gympass had teams in 14 countries at the time.

One way to organize the content is for each leader of the product development team to present their part or, each month, one of the leaders is responsible for preparing and presenting the content for the month. In addition to this content, the product head must make an introduction and there must be demos of the new features delivered. Ideally, these demos should be live. The more demos and fewer slides, the better. In the last product update that I participated at Conta Azul I was super happy because it was 100% demos and no slides. \o/

At the end of the product update it is important to open for questions, and the answers must be given by the leaders of the product development team.

This meeting is very important to report to the company about what the product area is doing. I constantly hear that the tech team is a black box, “nobody knows what they are doing and we don’t understand what they say”. To take this perception out of the black box, the best way is communication and the product update is a very effective communication ceremony.

Team structure meeting

This meeting can take place independently, or be a part of the team’s leadership meeting. The objective is very simple: decide together with the team how the product development team will be organized, how the budget for hiring people will be invested and what the hiring priority will be. Which tribes and squads should we set up? Should we only hire people for engineering, or should we also bring in designers and product managers? We must look at what we have to do, what we can do, and what we need help with. It is a collaborative meeting, which the product head should facilitate.

It is important for HR personnel to attend this meeting. Once at Conta Azul, an HR person who accompanied the operations and sales area asked to participate in this meeting to understand the dynamics and she was impressed with the meeting participants’ ability to converge on the best way to use the budget. It was when she commented to me that “your team is too mature to be able to have this type of discussion. In the leadership of operations and sales, we do not have the maturity to implement this dynamic”, to which I replied that at the beginning we did not have this maturity, but it was achieved with the constant exercise of this dynamic, that is, the team gained maturity as it learned to collaborate more, to understand the needs of other leaders and to perceive itself as a team with a common goal.

Summing up

  • These ceremonies with different stakeholders are aimed at planning, alignment and management of expectations. I emphasize that this list is not definitive, that is, depending on the company and the context, it may be interesting to create others and some of the ceremonies listed here may not be necessary.
  • 1:1 meetings are important to maintain alignment and communication with your direct reports, your leaders, other team members and people from other areas. 1:1 with your team members and your leader should be weekly and have an hour of conversation set aside. The 1:1 with other people may have a shorter periodicity and duration, or even be occasional. The topic of these meetings is free, and should not be limited to accountability. They involve personal issues, day-to-day, concerns, feedbacks, retrospectives.
  • Leadership team meetings are the meetings that the product head has with its direct followers. In addition to direct team members, it is important to have the HR person who is dedicated to helping your team. The topic is free, but it is important to periodically discuss OKRs and communication dynamics with the rest of the company. This meeting should happen at least weekly. They can happen more than once a week, even daily if there are many topics to be discussed.
  • All-Hands are meetings with the entire product development team where the achievements are celebrated and the lessons learned are shared. The recommendation is that they are monthly.
  • Product Council are the meetings where the planning of the next quarter is presented to the senior leadership of the company, preferably in the format of OKRs. They are usually quarterly.
  • Product Updates are used to remove the black box effect from product and technology teams. That’s when the leaders of this team present what was done in the last month, what will be done in the next month, how these deliveries impact the company’s results, demonstrations of features and openness for anyone to ask what they want for the team.
  • Team structure meeting serves to discuss with the leadership of the product development team how the team will be organized, how we will use the hiring budget and what the hiring priority is.

With this chapter, we finish part III on tools. In the next chapter, I will make a large summary of the book to serve as a quick reference, with all the “Summing up” of all chapters.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my almost 30 years of experience in creating and managing digital products:

  • Startup Guide: How startups and established companies can create profitable digital products
  • Product Management: How to increase the chances of success of your digital product
  • Leading Product Development: The art and science of managing product teams

Feedback and performance evaluation

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

Feedback

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

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

Characteristics of a good product manager

I usually evaluate product managers based on 7 main characteristics:

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

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

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

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

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

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

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

Product managers need to know how to program?

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

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

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

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

SQL

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

Performance evaluation

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

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

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

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

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

9-box matrix and its quadrants

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

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

Criticism to the performance evaluation process

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

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

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

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

Retrospective, an alternative to the performance evaluation process

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

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

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

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

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

EXAMPLE of a GPM retrospective

Strengths

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

Opportunities for improvement

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

Challenges for the next semester

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

Promotions and salary increases

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

When

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

How

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

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

Summing up

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

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

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my almost 30 years of experience in creating and managing digital products:

  • Startup Guide: How startups and established companies can create profitable digital products
  • Product Management: How to increase the chances of success of your digital product
  • Leading Product Development: The art and science of managing product teams

Hire the right people

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

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

DEFINE THE PROFILE

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

ATTRACTING CANDIDATES

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

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

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

INTERVIEWING

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

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

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

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

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

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

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

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

SELECT AND MAKE THE OFFER

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

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

ONBOARDING

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

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

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

FEEDBACK

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

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

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

ENDING A CYCLE

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

Summing up

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

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

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my almost 30 years of experience in creating and managing digital products:

  • Startup Guide: How startups and established companies can create profitable digital products
  • Product Management: How to increase the chances of success of your digital product
  • Leading Product Development: The art and science of managing product teams

Relationships

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

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

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

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

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

RASCI

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

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

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

Locaweb’s RASCI responsibility matrix

How to use

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

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

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

Power-Interest Grid

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

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

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

Empathy

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

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

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

Summing up

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

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

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my almost 30 years of experience in creating and managing digital products:

  • Startup Guide: How startups and established companies can create profitable digital products
  • Product Management: How to increase the chances of success of your digital product
  • Leading Product Development: The art and science of managing product teams

Metrics

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

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

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

Metric types

I classify metrics into 3 major groups:

Internal metrics

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

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

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

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

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

User metrics

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

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

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

Business metrics

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

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

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

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

Tracking metrics

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

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

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

Summing up

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

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

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my almost 30 years of experience in creating and managing digital products:

  • Startup Guide: How startups and established companies can create profitable digital products
  • Product Management: How to increase the chances of success of your digital product
  • Leading Product Development: The art and science of managing product teams