Diversifying – and digitalizing – a product portfolio, a case study

During the COVID-19 we did a diversification – and digitalization – of our product portfolio in record time. We went from one offline product, access to gyms and studios, to 4 products, 3 of them fully digital, in less than a month:

  • Access to gyms and studios: access to more than 50,000 gyms and studios in 14 countries;
  • Live classes: for those who like to train in groups or want to relive the feeling of class with colleagues at the gym;
  • Personal trainers: for those who prefer a more personalized approach and like to exercise in their own time;
  • Gympass Wellness: application package with more than 60 apps for those looking for options to improve physical and mental well-being (from nutrition to the therapy session).

In this article I’ll explain how we did it.

Product Vision

When I joined Gympass, in mid-2018, one of the first things I did was to build o product vision. We had a very compelling purpose, to defeat inactivity. However, in order to build a digital product, we need more than a purpose.

This vision guided the definition of Gympass’ product development organization. We built teams around each of the participants of the marketplace, plus a central team that worked on the payment flow collecting payment from companies and their employees, making all calculations and determining the payment for each gym partner.

When I was building this product vision and discussing it with different people in the organization, it was easy to see many opportunities to expand this marketplace. There is a lot of new categories supply we could add to our marketplace:

I’ve already explained the theory behind these ideais of marketplace expansion.

Given the above dynamic, we can expand a marketplace as follows:

However, we had a lot to do in our core product back then, so we didn’t have enough energy to focus on expanding our marketplace.

New venture

In October 2019 we got to a point where our product development team was well structured and working properly to address our challenges in our core product, so we decided to focus on expanding our marketplace.

We decided to work on an idea called “Gympass end-user partnership hub”. The plan was to partner with wellness apps and provide them our users.

This new idea had too main hypothesis we needed to test:

  • willingness to partner from app providers. App providers, like gyms, are used to the recurring monthly revenue model. Are they ok to be paid by the day of use?
  • willingness to pay from our user base. Is our user base interested in paying a monthly fee to have access the apps?

To test our first hypothesis we built a deck with the value proposition we were planning to deliver to the partners and talked to some potential partners. We presented the partnership opportunity to 8 potential partners, from which 6 showed interest and 4 decided to join our proof of concept. NEOU, a workout app, 8fit, a workout and nutrition app, Tecnonutri, a nutrition app and ZenApp a mindfulness app.

Ok, our first hypothesis was validated and we needed to validate the second hypothesis, the willingness to pay. Are our user willing to pay to have access to this apps through Gympass?

To test our second hypothesis, we built a simple form, where we describe the product and asked name, email, and company. After the user gave this information, he was directed to a Paypal subscription page, where he need to provide credit card information to subscribe to the service. The user received an email with the activation link for each app. There was no real product, just a form to test interest and email with the links to the apps. Check out the experience below:

We initially called it Gympass W, the W standing for wellness. We added a beta so everyone could understand that it was not a finished product. Later we renamed it to Gympass Wellness to make its value proposition more clear.

Our plan was to test this proof of concept with 5 corporate clients in the US and 5 in Brazil, which would provide us a combined user base of 15,000 employees. Our expectation was to have around 200 subscribers. We launched internally – eat your own dog food – on March 9th and we got 66 subscribers. Then came COVID-19.


As I already explained in a previous article, when a business is hit by a crisis, it needs to look into these two perspectives:

  • preserve cash;
  • identify and adapt to changes in customer problems and needs.

Even though product managers and product development teams have an important role in the former, their main role is in the latter.

Here at Gympass we have 3 different customers and all of them deeply impacted by COVID-19:

  • gyms in many cities were closed to help in physical distancing measures applied in many cities to avoid the spread of COVID-19 and consequently are losing recurring revenues from users who are not visiting the gym;
  • users, the employees of our clients, cannot go to gyms anymore and have to stay at home, but also have to somehow stay active, but their first reaction is to cancel or pause their Gympass membership since they won’t have access to gyms for a while;
  • corporate clients, whose employees are at home and don’t go anymore to gyms, while HRs are concerned about how to keep these employees engaged and productive.

Gympass Wellness, the first digital product

We were able to adapt our Gympass Wellness pilot in record time to be offered to our entire user base so they can not only remain active but also take care of their nutrition and their minds during these very challenging times. With Gympass Wellness we were able to address both users and our corporate clients’ changing problems and needs during the crisis.

We have a corporate value that I believe all marketplaces should have, Ecosystem Mindset. This means that we should always look to all participants in our marketplace and guarantee that all benefit from using it.

Live Classes, the second digital product

With Gympass Wellness, we were able to address the needs of our corporate clients and their employees. What about the gyms? By being closed, they were losing revenue. Their customers were not visiting them anymore so the regular gym users were prone to cancel their subscription while those who used to visit gyms using Gympass wouldn’t visit the gym during the crisis what would cause a loss of revenue for the gyms as well. To help our partner gyms we decided and implemented in record time 2 solutions:

  • Provide gyms a white label app they could offer to all their members so they can deliver value to their clients helping them stay active while at home;
  • Provide a platform for gyms to schedule and stream live classes to all Gympass users so they can keep their instructors employed while providing Gympass users with exclusive content. This platform is called Live Classes.

Personal Trainers, the third digital product

Live Classes provided a platform 1:N, meaning one instructor could provide physical activity guidance to N users. We soon realized we could create another product on top of Live Classes, 1:1 physical activity guidance, which could be made available in Gympass’ higher-tier plans. We then created our third digital product, Personal Trainers.


  • Even though we had the vision of expanding our supply offer beyond physical gyms and studios quite early in our journey, we needed to have our core product stable in order to invest in this expansion.
  • Back in November 2019, we started to create our first digital product, Gympass Wellness, in a regular pace, creating controlled tests to validate or invalidate hypotheses.
  • COVID-19 dramatically increased the need for speed in developing new digital products. We went from 1 offline product (access to physical gyms and studios) to 4 products adding Gympass Wellness, Live Classes, and Personal Trainer to our product portfolio in 2 months. Prior to the crisis, this diversification and digitalization would probably have taken 2 to 3 years.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success? Check out my new bundle Digital Product Management with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.

No alt text provided for this image

Be the first to like.

Guia da Startup agora é Gyaco / Guia da Startup now is Gyaco


Guia da Startup foi um blog que criei em 2012 quando eu estava escrevendo o meu primeiro livro. Eu trouxe todo o conteúdo para esse novo site, onde centralizarei todo o meu conteúdo.

Se você quer ser notificado de novos artigos, basta assinar a newsletter:

Para quem quiser ver esse conteúdo em português, aqui está o link da tradução automática do Google Tradutor. Você também pode acessar os artigos escritos em português.


Guia da Startup was o blog I created back in 2012 when I was writing my first book. I brought all the content to this new site, which is where I will centralize all my writing.

If you want to get notified about new content, just subscribe to my newsletter:

For those who want to access the content in Portuguese, you can access Google Translate automatic translation. Also, there are many articles written in Portuguese.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success? Check out my new bundle Digital Product Management with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.

No alt text provided for this image

Be the first to like.

The top-down trap

In my last article, I’ve discussed the differences between problem solver teams and solution implementer teams, why these teams yield better results, and how to build them.

Top-down solutions

When discussing these types of teams, I normally hear things like “we want to be a problem solver team but in my company all solutions are top-down, and the only thing we can do is to implement them”.

These situations get aggravated when under pressure came. The most recent pressure many companies are under is the COVID-19 crisis. In the urge to solve the problems as fast as possible, managers ask teams to implement this or that solution fast, super fast.

The trap

Let me now tackle the elephant in the room, the top-down decision-making environment. This has a huge impact on any team since in this type of environment. Without being part of the decision about this solution, the people that implement the solution will eventually get demotivated.

Why am I calling it the top-down trap? Because many of the so perceived top-down decision-making environments are what I just wrote, a perception.

Let’s use the main characteristic that every product manager must have, empathy. The ability someone has to walk on someone else’s shoes in order to understand her aspirations, motivations, needs, and problems. People to whom I had the opportunity to talk about the essential characteristics of a product manager, know how important I consider empathy as a critical trait for successful PMs.

Here are 2 tips to help product team members empathize with the so-called top-down decision-makers and escape the top-down trap:

  • Understanding the situation: put yourself in the solution implementation requester shoes. People are problem solvers, it’s people’s nature. Whenever faced with a problem, people jump to solution mode and try to find and implement solutions as fast as possible. Under increased pressure, like the COVID-19 crisis we are facing now, the urge to find and implement solutions is exacerbated. In the majority of cases, people don’t want to be top-down decision-makers, they simply have an urge to solve the problem as fast as possible.
  • Changing the status quo: ask questions about the solution implementation request. What problem is it solving? For whom? Why is it important to solve this problem? Why now? Why do we need to deliver something fast, even jeopardizing quality? If you are asked why so many questions, explain that you are trying to better understand the problem to see if there are other cheaper and faster solutions.

These tips will help everyone in the product team to make the change to a more collaborative decision-making process.

More often than not, people understand the benefits of a collaborative decision-making process. Even under pressure, collaborative solutions will yield better results. Solutions devised in a collaborative process are normally cheaper and faster to implement because more people got a chance to discuss solution options and the team who will implement the selected solution will be truly committed to its success.

In order to build, maintain and improve problem solver teams, and avoid turning them into solution implementers teams, especially when under increased pressure, it is paramount to avoid the top-down trap.

Heads of product have the role and responsibility to foster these behavior changes to help build a more collaborative and, consequently, more effective decision-making process.

Summing up

  • The top-down trap is the perception of the decision-making process being done in a top-down manner.
  • This perception is exacerbated when a company faces increased pressure, such as the COVID-19 crisis we are in now.
  • People are solution-oriented and the bigger the pressure, the faster people want solutions to be implemented.
  • To help cope with this situation, use empathy to understand the solution implementation requester point of view and ask her why there’s a need to implement the requested solution.
  • Heads of product have the role and responsibility to foster these behavior changes to help build a more collaborative decision-making process.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success? Check out my new bundle Digital Product Management with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.

No alt text provided for this image

Be the first to like.

Problem solver vs solution implementer teams

Marty Cagan, a well-known reference in the digital product community, wrote some time ago an interesting article about Product vs Feature Teams where he explains the difference between three types of product teams, Delivery Teams, Feature Teams, and Product Teams. He wrote a follow-up article where he summarizes the definition of each team type:

  • Delivery teams are not cross-functional (basically just developers plus a backlog administrator product owner), they are not focused on outcome (they are all about output), and they are not empowered (they are there to code and ship).
  • Feature teams usually are cross-functional (at least some form of designer and some form of product manager), but they are still all about output and not empowered.
  • Product teams are cross-functional, focused and measured by outcome, and empowered to come up with solutions that work.

He explains that the best results for the organization that owns the product and the users of that product come from the teams he calls Product Teams. He has been using a lot the empowered word to describe these teams.

In this article, I want to provide a new perspective to help people understand the differences between these types of teams, why empowered product teams yield the best results, and some tools to help you build these teams.

Problem vs solution mindset

I’ve already explained the difference between problem vs solution mindset. When we learn about a problem, it’s human nature to jump into solution mode and try to come up with solutions to this problem. However, the more time we spend on understanding a problem, its causes, its context, and the motivation people have to solve it, the bigger the chances to find the best solution for the problem.

Any digital product exists for two main purposes:

  • To help the company who owns the digital product to achieve its objectives.
  • To solve the problems and fulfill the needs of its users.

So any digital product and its features are solutions to problems from the company that owns the product and solutions to solve user problems and fulfill their needs.

In this digital product context, when I say that spending more time understanding the problem yields the best solutions, I mean that we are able to deliver as fast as possible the best product and features to solve the problem at hand with good software quality and good user experience.

Problem solver vs solution implementer teams

What Marty describes as delivery teams and feature teams are solution implementer teams. These teams work on implementing a solution devised by someone else. This someone else is normally someone from the so-called “business area”, which can be someone from sales, marketing, client success, customer support, finance, operations, a C-level, or a founder. In such a team, the product manager mainly manages the backlog and helps the team deliver the requested solution, the product designer is mainly focused on designing a nice interface, and the engineers have to code and deploy the requested solution. The solution implementer teams implement what was asked, with little to no commitment to the quality of the solution, or even if the implemented solution actually solves the problem.

On the other hand, what Marty describes as empowered product teams are problem solver teams. These teams work on deeply understanding the problem’s causes, context, and the motivation people have to solve it. By doing so, they are able to implement the best solution to the problem at hand.

There are 3 main reasons why problem solver teams are more effective than solution implementer teams:

  • Digital product literacy: There’s no one better than the problem solver team members to find the best digital product solution to a problem. A solution that is delivered as fast as possible, with good software quality and good user experience. This happens because a problem solver team is a multi-functional team composed of engineers, who understand the technology available, product designers, who have a deep understanding of the users, their pains and their needs, and product managers, who have a good understanding of the business context of the problem to be solved.
  • Two heads are better than one: this old saying means that it’s easier for two people who help each other to solve a problem than it is for one person to solve a problem alone. A problem solver team will not discard any solution suggestion from the “business areas”. Actually, these solution suggestions are very insightful to help the team gain a better understanding of the problem, but these solution suggestions should be considered as what they are, suggestions. A problem solver team first deeply understands the problem and then analyses solution options.
  • Commitment: an additional side-effect of a problem solver team is that the members of this team are deeply committed to the success of the solution implementation since they are deeply involved in the solution-finding process.

Building problem solver teams

Now that I explained why problem solver teams are the best type of product teams a company can have, I’ll explain how to build problem solver teams. There are three aspects that need to be considered:

  • environment: it’s critical that the entire organization understands the power of having problem solver digital product teams. The speed and quality of the solutions delivered by a digital product team that always start solving problems by having a deep understanding of the problem is way better than solutions delivered by solution implementer teams. Consequently, the business results will be better and will be achieved faster. It’s the role and responsibility of the VP/head of product to help the organization understand this.
  • what is the problem: a very effective way to focus the entire organization away from solution mindset and into problem mindset is to constantly ask “what is the problem we are trying to solve?” and “why is it important to solve this problem?”. This will help people from the entire organization change their perspective and, consequently, realize the importance of deep problem understanding prior to implementing a solution. This is a behavior change that the entire digital product team can help their organization to make. Whenever someone asks the product team to implement something, ask “what is problem”.
  • trust: this is a critical aspect for building successful problem solver digital product teams. Normally people from “business area” believe they have a better understanding of the business the people from the product team. This behavior is even more visible when the digital product team is new in the organization. How can a new person in the organization understand more about the business than the people that are in the company for years? Probably this new person can not, especially if this person comes from a different market. However, the people that are part of the digital product team normally have a lot of experience in building digital products, probably more experience than anyone else in the organization. For this reason, it is essential that the “business area” educate the digital product team on the business aspects of the organization. This education seeking is the role and responsibility of the product managers, who must learn from the “business area” and educate the product designers and engineers about the business. One practical way to accelerate this learning is to bring people from the “business area” to the problem understanding sessions. This is how the product team earns the trust of the other areas of the organization.

Summing up

By now I believe it’s clear the benefits of having problem solver vs solution implementers digital product teams. The entire organization needs to understand the difference in order to push for having more and more problem solver teams. The VP/head of product has this as one of her biggest responsibilities, to help build the environment and the trust needed for problem solver teams thrive.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success? Check out my new bundle Digital Product Management with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.

No alt text provided for this image

Be the first to like.

Customers do know what they want!

I’m currently reviewing the translation of my first book, called “Startup Guide: How startups and established companies can create profitable digital products” and I came across this interesting chapter which discusses the common belief that customers don’t know what they want.

It is common to hear in conversations about product development that the customer does not know what he wants. At some point, someone will say the famous phrase from Henry Ford, the inventor of the car:

“If I had asked people what they wanted, they would have said faster horses”. Henry Ford

Incidentally, the one who liked to repeat this phrase to exhaustion was Apple’s eternal CEO, Steve Jobs.

People know what they want, a solution!

Yes, people do know what they want. They want a solution to their problems. What they do not know, or sometimes think they know but do not know, is what is the solution to these problems. This is where Henry Ford, Steve Jobs, and us, the rest of mortals, come in, who want to develop products to solve these problems.

The first steps to create a good product are:

  • Realize that there are people with a problem or need to be solved;
  • Understand very well what this problem or need is;
  • Understand what motivates people to want this problem or need to be solved.

When you talk to people with problems or needs, some will even say that they think this problem could be solved this way or that way. But right now, the important thing is to find out if there is a problem or need to be solved. You must separate the problem from the solution suggestion your interlocutor is trying to pass on.

Problem: People took too long to move around

That was the problem that people wanted someone to solve for them in Henry Ford’s time. No matter how. It could be with more horses in front of the cart, it could be with horses trained for roller skating, it could be with genetically modified horses to ride faster, it could be with the invention of the automobile, it could be with the invention of the airplane, it could even be with the invention of teleportation.

Note that, for those who had the problem of being late, how it would be resolved did not matter as long as it was resolved. Some people may have suggested solutions, such as the fastest horses of Henry Ford’s famous phrase, but that was just a suggestion for a solution. The problem to be solved was that people were spending too much time moving around.

Problem: parents want to go to the restaurant with their young children and want to have a quiet lunch

This is a problem that many parents have. There are several ways to solve it. One of them is with an iPhone, iPad, or any touch device loaded with games and movies for kids. This is certainly a solution to this problem that no one had imagined before this technology existed. I do not think even Steve Jobs had thought of that kind of use.

But as our focus is on the problem, not on the product, it is easy to see that this is not the only solution. There are others, such as the restaurant handing out children’s kits with activity books and coloring pages, or the restaurant having a reserved area with educators to play with the children while the parents can have a quiet meal.

Problem: people want to re-educate nutritionally so they can have a more balanced diet, lose weight, and feel better.

Whenever you go to doctors or nutritionists, those diet leaflets and various menu suggestions come up. Anyone who has been on a diet knows: restricting something in food consumption is very difficult. We keep counting the days to end the diet and be able to eat again what we have been restricted from. And in the rush of everyday life, following menu suggestions is impractical.

One day I met a nutritionist who made no restrictions, just asked me to make a food diary, that I write down what I ate and how much so that we could then analyze together what needed to be adjusted, which “slips” did not do much harm and which ones should be avoided. Finally, a control that was more adaptable to my daily life. She told me that people who keep a food diary lose up to twice their weight than those who do not have a record.

Hence, the idea of looking for some calorie counter system. I found several ones, all with some interesting points, but none of them good enough to keep me motivated to keep using it. To meet my need, I decided to create ContaCal.

Many times people do not know what the problem is

When we search for problems to solve and talk to people to understand what they are, often what they describe to us is not necessarily the problem, but the way they see the problem or, what is even more difficult, the way they imagine it to be the solution.

For example, going back to Henry Ford’s car and cart, imagine an imaginary dialogue between Henry Ford and a hypothetical Mr. Smith, a potential buyer of his future product:

  • Mr. Smith, what mostly afflicts you?
  • Mr. Ford, what mostly afflicts me is that I spend little time with my family.
  • And why is that?
  • Because I spend too much time in the cart going around. If I could include one more horse pulling my cart, it would go faster and I could spend more time with my family.
  • Oh, I understand your problem, and I have an even better solution for you, it is called an automobile.

Did Henry Ford really understand the problem? Or did he understand the solution Mr. Smith presented to him? Was not Mr. Smith’s real problem that he spent little time with his family and might need to review his to-do list outside home?

Anyway, this was a hypothetical dialogue, but I think we could get an idea of how easily we want to cling to the solution right away without spending enough time trying to figure out exactly what the problem is. A good understanding of the problem will greatly help make a good software product.

And sometimes people do not know they have a problem

Imagine a person using an internet banking system. It is common when someone is going to use a software to do something before using it as a preparation for it, as well as something after, with the result of using that software. The person may be so used to perform these tasks that he just does not see a problem with it. This is the time when a person with the knowledge of what can be done with the available technology comes up with the idea of a solution to a problem that has not yet been realized, but that exists.

The big issue in these cases is that the problem was not noticed by the people who might be interested in a solution. In such cases, it is very important to make sure that they really acknowledge the problem you just discovered as a real problem, for which they will want a solution. Otherwise, there is no solution to be sold.

Whose problems should I solve?

The closer you are to the people you are going to research and to whom you will eventually solve a problem for, the better. The optimal situation is when you are solving your own problem, in which case you know exactly what to expect from the solution. And it is easier to discover problems you did not realize from yourself than from others.

There are several cases of startups that were born as solutions to their own problems. ContaCal is an example. If you solve a problem of your own, when your product is ready and you are using it, you will clearly understand the interaction flow of your system and know what can be improved.

The only caution is that you will quickly become an advanced user of your own product. And you should not forget that there will always be new users who have never seen your product and will need a user experience that is quite different from the one required for an advanced user like yourself.

What a cool technology!

Cool technology is nothing if it does not solve a problem. As we are increasingly surrounded by new technologies, it is common to find people who see a new technology and soon think it would make a good product. This is very common in the startup world: having a cool idea based on a new technology and making a product with it simply because now it is possible.

“Startups don’t fail because they lack a product. Startups fail because they lack customers willing to pay.” – Steve Blank

A technology, as incredible as it may be, if it does not solve a problem, will never become a product.

Summing up

Bottom line: problem + technology = solution = product idea

In short, when we put together a problem, which is not always easy to figure out – but the closer you get to it, the better -, with the technology that can solve that problem, we have a possible solution that can turn into a product idea.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success? Check out my new bundle Digital Product Management with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.

No alt text provided for this image

Be the first to like.

How to manage a product portfolio?

In my previous two articles, I explained why a company should worry about having more than one product and how a software product company can diversify its portfolio. In this article, I will talk about managing a product portfolio.

When you have two or three products, it is reasonably easy to manage your product portfolio. However, when it comes to about 4 or 5, it is interesting to have some tools to help. Imagine Locaweb, with over 35 products, between active and discontinued products, or Google, with over 250.

The BCG Matrix

At Locaweb, we use the BCG matrix. BCG Matrix is a graphical analysis tool developed by Bruce Henderson in 1970. In 1963, Bruce Henderson founded the American Business Consulting Company Boston Consulting Group (BCG), of which he was chairman until 1980 and chairman of the board until 1985. It is not a new tool, but it is very useful, as you will see in a moment.

No alt text provided for this image

Its goal is to support product portfolio analysis based on the product lifecycle concept. It is used to assist in resource allocation decisions across different products.

No alt text provided for this image

It is made up of two axes. On the Y-axis is represented the growth of the market, and on the X-axis is represented the participation of your product in this market.

No alt text provided for this image

This divides the matrix into four quadrants:

  • Bets: In the original, it is called a “question mark”, “questioning” or “problem child”. I prefer the name “bet” to be a little more positive! 😛 In the bets quadrant, this is where all startups should be trying solutions to a problem of a set of people. And this is where all new products should start, because, on the one hand, you always start with a small market share. On the other hand, in terms of the market you are entering, it is always better to enter a market that is booming. If you are considering entering a low growth market, you can be sure that you will have much more work. Products in this quadrant have two options: they become stars, or they become dogs when they do not cross the chasm. When following a product portfolio diversification strategy, it is important to have a good amount of bets, as a considerable amount of bets will not cross the chasm and become a dog.
  • Stars: When the bet works, you start to get more market share, and that makes that bet a star. Stars are the main growth element of your business, as they are the products with the highest absolute growth in user numbers and revenue.
  • Cash Cow: Usually, here are the oldest products of a company. As the market no longer grows so much and the company has a sizable chunk of this market, there is no need for big investments, and the revenue from these products usually finances the development of stakes and stars.
  • Dogs: They are products that haven’t crossed the chasm of the technology adoption curve. It is very important to realize when a product enters this quadrant, because in most cases when this happens the product must be discontinued.

Placing the technology adoption S curve in the respective quadrants of the BCG matrix, we will have the bets as the moment of innovation, the stars as the moment of growth, the dairy cows as the maturity of products, and the dogs as the products that do not cross the chasm between the early adopters and the early majority.

No alt text provided for this image

A relevant point to note is the distribution of products in the different quadrants. At Locaweb, we have a huge concentration of bets because, as many methodologies as there are to develop better and better products, the truth is that many products still do not cross the chasm and become dogs. That’s why it’s important to test new product ideas quickly. Later I will show a simplified version of Locaweb’s BCG Matrix.

Effort allocation and investment

From the company’s resource standpoint, we should allocate them as follows:

No alt text provided for this image

That is, for each phase of the product, your investment in development, operations and marketing will be different.


During the betting phase, you should allocate your efforts as follows:

  • Development: Bets require high development effort. The market is growing fast, and your product needs to adapt and gain a relevant space in this market because only then it can go to the star phase.
  • Operations: In a bet, operational concerns should be small. It is even acceptable to have some manual processes. And you should not create an infrastructure for millions of customers if you are placing a bet. After all, it’s just a bet that may or may not work.
  • Marketing: Marketing investment follows the development investment. In a bet, you must invest to win the market.

When the product is no longer a bet and becomes a star, the points of concern change:

  • Development: Stars also require high development effort. The market is still growing fast, and your product still needs to adapt to that market. Besides, you just made a minimal product to find a market. You will certainly need to add features to make your product more complete.
  • Operations: When your bet becomes a star, you should be concerned about the scalability of your product. So, you need to think about doubling, tripling or even multiplying your customer base by 10. What do you need to do with your infrastructure to reach this size? And manual processes should be minimized or preferably eliminated. Manual processes, besides being subject to random errors, do not scale.
  • Marketing: In a star, you should also invest because the market is growing fast and, although you already have a good market share, you need to keep investing to keep up with your growth.
Cash Cows

Eventually, your star could become a cash cow. At this point you should direct your efforts as follows:

  • Development: Cash cows need a moderate development effort, only the development required to keep the product stable and with as little manual operation as possible. You may also use development to optimize certain metrics, like engagement and churn.
  • Operations: When a product becomes a cash cow, its scalability should be excellent. No manual processes and no headaches.
  • Marketing: When your product becomes a cash cow, your growth is organic, you are already the market leader (or one of the leaders), and you no longer need to invest so much marketing for these products.

When a product turns into a dog, either by not crossing the chasm or after maturity (as seen in the End of life article), effort and investment allocations should be adjusted as follows:

  • Development: In dogs, you must take out all the development effort. If you have yet to develop something for a dog product, something is wrong. Probably not a dog yet.
  • Operations: The main source of dogs are the bets. In this case, the product did not have large investments in scalability. And so, it must go on! If he has reached the dog stage after maturity, his client base is likely to be shrinking and, as a result, his scalability concerns as well.
  • Marketing: In a dog, it is no longer necessary to invest in marketing.

Real-life examples

The first example is Google, which I mentioned in the article Are you thinking about your new product? No? So you are already late. First of all, I need to make it clear that:

  1. I don’t know if they use BCG matrix for portfolio management of their products; and
  2. If they do, I don’t know if the classification I made matches how they see their products.

Well, caveat made, let’s go to the BCG matrix. I did not include all 177 active products plus 79 discontinued products because it would be too much to see. I selected some products in each quadrant to give you an idea. Some bets:

  • Google App Engine: Cloud market, competing head-on with Amazon, and PaaS market, competing with Heroku and Jelastic Cloud Locaweb.
  • Google Driverless Car: There is no strong growth market here as there is not even one market. Google is trying to create a new market.

Among the stars, we can mention YouTube, where Google is the market leader and it is still growing fast. Besides YouTube, there is also Android, which came to compete with iOS and today already has a relevant position in the market.

Google’s big cash cow is Search with AdWords ads. The search ad market is completely dominated by Google, and if you do a Google search (!), you can find some stories talking about growth of that market of around 15%.

Finally, some discontinued dogs are Google Wave, the “real-time” email-killing collaboration system, Google Health, which allowed people to store and manage their medical information in one place, and Google Reader, an RSS newsfeed reader.

No alt text provided for this image

Now, something I can talk about with more authority, Locaweb. We used the BCG matrix and some of our products are in the following example. I preferred not to put all the products to make it simpler, but in our BCG matrix we had over 25 products.

As bets we had in 2015:

  • Jelastic Cloud: PaaS we launched to compete with Amazon, Google App Engine and Heroku.
  • Eventials: live event broadcast startup.
  • TrayCheckout: payment service, similar to PayPal and PagSeguro.

Our stars are Cloud Server and Email Marketing products, whose markets are growing fast. Our cash cow is our first product, Website Hosting, and a dog we discontinued in 2015 is WebChat.

No alt text provided for this image

2019 update: Jelastic was discontinued since it didn’t cross the chasm. Traycheckout grew to become Yapay, a star in Locaweb’s product portfolio, as well as Eventials is now a star.


So now you not only know why you need to diversify your product portfolio and how to diversify it, but you also know how to manage a product portfolio with several products. The BCG matrix, while an old tool, is very useful for understanding at what stage your product’s life cycle is, as well as what kind of investments and efforts to make in each product.

We used the BCG matrix at Locaweb since 2012, and it’s a really useful tool. Each quarter, we revisit our BCG matrix to understand if any movement is necessary and, consequently, reallocate our efforts and investments.

In the next chapter, I’ll talk about the option of not diversifying – that is, focusing on one product – and looking at the advantages and disadvantages of each strategy and when each strategy is most appropriate.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success? Check out my new bundle Digital Product Management with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.

No alt text provided for this image

Be the first to like.

How to diversify your product portfolio?

In my previous article, I talked about why companies should diversify their product portfolio. Now, I will show you how to do this.

New Markets

The first option is the search for new markets. When we think about it, we remember the Google map, which we saw in the previous chapter, which shows the presence of its offices in various countries.

This is the most common way of thinking about looking for new markets, and – again, in due proportion – is what Locaweb and Caelum have also been doing. Both Locaweb and Caelum are still nationally searching for new markets in Brazil, but it is nonetheless similar, that is, the search for new geographic markets. Gympass is another good example of a company that decided to diversify by opening operations in new countries. As of 2019, besides Brazil, Gympass operates in 13 countries in Europe, Latin America, and the US.

However, when we think of new markets, we should not restrict ourselves to geography. There are other characteristics that define new markets:

  • Age range: If you have a product for young people, can you fit it for older people? Will these be of interest? And the kids?
  • Individual vs. Legal entity: If your product is made for business, could it also be used by end consumers?
  • Business size: Is your product suitable for small businesses? What would it take to suit it for large companies? Or is your product made for large companies? Is it possible to do something to suit you for small businesses? It was precisely the pursuit of this new market that motivated Locaweb to acquire All In. As I explained in the article about how to prioritize the roadmap, Locaweb had the Email Marketing Locaweb product focused on small businesses. Often, we received demands for features typical of large companies that trigger large volumes of email. It was a new market that was opening for us. We looked at the options we had to do: do nothing, evolve the product, develop a new product to serve this new market, or acquire a company that already had a product that would serve this new market. We opted for the third option and acquired All In, which has an email marketing product made for large companies.
  • Niches: Do you have a product for dentists? Can it also serve doctors? What about physical therapists?

That is, it is not just geographical differences that characterize new markets. Ethnographic, social, and cultural differences also help define market segments, and a product manager must be able to understand and identify these differences in order to explore new opportunities for her products.

Remember that when you are going to explore a new market with your existing product, there is a good chance that you will need to make adjustments to it so that it can be accepted in that new market. Just see what I described about Email Marketing Locaweb. In the search for a new market of larger customers, it became clear that we needed to adapt our products to meet these new market segments. Hence comes the second option for product portfolio diversification.

New products

The other option is to develop new products to serve the market you already know or even to serve a new market, as I described in the case of Locaweb Email Marketing.

The articles from Innovation: what is it? to Innovation: next steps talk exactly about the topic of developing a new product, and present the techniques for discovering a problem or need for a group of people and how to develop a product to solve such problem or serve them.

Just remember, here comes again the importance of empathy, understanding well your customer, and the problems and needs he has. This is the way to find new product opportunities. A very simple but very powerful technique for discovering new opportunities is to keep track of one or a few days of your client. What does he do during that day? When does he get frustrated to do a certain task in his day? What makes him happy? What tasks could be accelerated, improved, or even eliminated with the help of software?

Caelum is a great example to illustrate new product development for existing customers. Initially, they had face-to-face software development courses in Sao Paulo. They then expanded to Rio de Janeiro and Brasilia, meaning they seek to diversify new geographic markets. Over time, they began to notice demand in other cities, but it was a very scattered demand, with no specific focus on one city or region. Hence came the idea of launching Caelum’s online course service, which was most recently renamed Alura.

Over the course of several years giving training to developers, or people who wanted to learn about software development, Caelum people realized the demand for quality books on software development and related topics in Portuguese. This gave rise to the idea of founding Casa do Código, a publisher of technology books.

In addition to the techniques I have cited in the innovation chapters, there is yet another strategy used by many companies for product portfolio diversification, including Google and Locaweb, which is the company acquisition strategy. Several of Google’s products were not developed within Google, but rather by small companies that developed a product that caught the eye of Google product managers and motivated them to purchase them. Some well-known cases are Waze, YouTube, and Android.

Locaweb has also started doing this recently. Locaweb always had products for customers who wanted to have their online store. We started with a Payment Gateway product, launched at the beginning of Locaweb in 2006, so that website developers could create online payment shops. In 2010, we launched WebStore, a complete e-commerce product, and in 2012 we met a company called Tray, the founder of another e-commerce company, Pagamento Digital, which was acquired by Buscapé and recently renamed bCash.

Tray was a complete e-commerce company with e-commerce, payment gateway, checkout and marketplace products. They were way ahead of our e-commerce products, with more mature products that we didn’t even have in our portfolio. Therefore, at the end of 2012, we announced the acquisition of Tray, an e-commerce solutions company. Another area we have always been interested in is online video streaming, an important addition to our customers who want to have an online presence. As a result, in late 2012 we acquired the webinar startup Eventials.

So, there are two ways to diversify your product portfolio. One is looking for new markets. We should not restrict ourselves to new markets from a geographical point of view. We should also think about new markets thinking about other parameters such as company size, customer age, niche market etc.

The other form of diversification is the creation of new products for existing customers.

It is worth noting that these two strategies are not exclusive. Many times it is necessary to create a new product to be able to serve a new market.

How to expand a marketplace?

To answer this question we need to understand the dynamics of a marketplace. Basically, there are 3 types of elements in a marketplace:

  • Supply: goods or services available for consumption
  • Demand: people or businesses that may need goods or services offered by the supply
  • Marketplace: where demand finds supply and a transaction happens

These 3 elements relate to each other in the following manner:

  • Value delivery: marketplace delivers value to both demand and supply. The value delivered to supply is people or businesses interested in its goods or services. The value delivered to demand is a varied number of goods and services suppliers.
  • Payment: in order to have access to the goods and services offered by the suppliers, the demand pays the marketplace and marketplace pays the supply. Normally the marketplace retains a fee per transaction. This fee can be fixed or a percentage of the payment.
No alt text provided for this image

Let’s analyze Uber as an example. Supply is the drivers. Demand is the riders. The marketplace is Uber. Uber delivers new riders to drivers and delivers transportation services to riders through its supply of drivers. Riders pay Uber who then pay drivers and retain a fee.

Another example is Uber Eats, a 3-sided marketplace where supply is both the restaurants and the drivers who deliver the food to the user. Demand is the users who order food through Uber Eats, which is the marketplace. Uber Eats delivers demand to both restaurants and drivers and delivers a food ordering service to its users. Uber Eats charges the user and pays both restaurants and drivers, retaining a fee. In this case, Uber Eats connects 2 types of supply (restaurants and drivers) to one type of demand (users).

A 3rd example is Gympass, a 3-sided marketplace where supply is gyms and studios and demand are companies and their employees. Gympass delivers new users to its supply while delivering a network of gyms and studios that are offered by the companies as a corporate benefit to their employees. Companies and employees pay a fee to Gympass, which pays gyms and studios. In this case, Gympass connects one supply (gyms and studios) to two interconnected types of demands (companies and their employees).

Expanding the marketplace

So you run a marketplace and want to expand it. There are some different paths you can take to expand your marketplace:

  • Demand diversification: you can offer the goods and services of your marketplace to new segments and geographies. Uber did that in its international expansion. Uber also offered its transportation services to companies, besides its regular offer to end-users.
  • Supply diversification: you can offer new goods and services to your demand. Uber did this with Uber Eats. Amazon started out offering only books. Now it offers almost anything.
  • New value delivery: you can offer new value to both your supply and your demand. Uber offers many services to its drivers like car rental, car maintenance, phone plans, and health insurance. iFood, a Brazilian company similar to Uber Eats, offers a PoS system to its affiliated restaurants. MercadoLibre, an Argentinean marketplace similar to eBay, offers to its sellers MercadoShops, an eCommerce site builder and becommerce, a back-office management solution.
  • Payment financial management: since the payment from demand to supply goes through the marketplace, you can offer financial services to both your demand and your supply like advance payment and credit, and you can manage the spread. iFood is offering through its app the ability for its users to pay the bill when they are in the restaurant. Uber partnered with Intuit to offer financial management services to its drivers. Both MercadoLibre and eBay offer a payment solution for its sellers and buyers. MercadoLibre offers MercadoPago and eBay acquired Paypal. Most recently MercadoLibre decided to offer loans to its sellers in Brazil and Mexico.

The image below shows the 4 types of marketplace expansion.

No alt text provided for this image

So there you have it, 4 types of marketplace expansion. These 4 types are not excluding. You can explore all 4 options simultaneously, but remember that each can be a new business on its own, so be careful not to distract too many resources from your existing marketplace business.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success? Check out my new bundle Digital Product Management with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.

No alt text provided for this image

Be the first to like.

Are you thinking about your new product? No? So you are already late…

Did you know that Google has 177 active products in addition to 79 discontinued products? These are the statistics from Google just before it announced Alphabet in August 2015.

And how many offices has Google spread around the world? I tried to count on the map below, but couldn’t. It looks more like a map of the board game War, with Google conquering the world.

No alt text provided for this image

Locaweb, in due proportion, also has a similar strategy. Back in 2016 we had over 25 products and we have already discontinued over 10. In addition, Locaweb has offices in Porto Alegre, Marília, and Blumenau.

Another example is Caelum, which has in-house software development consulting and software development classes in Sao Paulo, Rio de Janeiro, and Brasilia. It had an on-demand software development service that was discontinued and created an online e-learning service and they also became a publisher.

Why do these companies use this strategy of portfolio diversification and new markets?

As I explained in the article How does the lifecycle of a software product work?, we need to review the concept of the technology adoption curve. This concept first appeared in a 1962 book called Diffusion of Innovations, written by Everett M. Rogers, a sociologist, and professor at Iowa State University. In this book, Rogers explains that technological innovations are adopted along the following curve.

No alt text provided for this image

In the beginning, innovators are the first to be interested in new products and innovations. They even come up with incomplete and defective products for the pleasure of being the first to use this new product. Next up are the early adopters, also known as visionaries or enthusiasts, who take the risks of testing a new product, not for the pleasure of being the first, but because they see the potential of that new product. They usually have an influence on the organizations and communities they are part of. The early majority, also called pragmatists, buy new products only after having references. Late majority are the conservatives, i.e., those who buy only after the price has dropped considerably. Finally, there are the laggards, which only buy a new product if this is the only option available.

Doing the integral of this curve (who remembers calculus classes?) we get the famous S-curve of technology adoption.

No alt text provided for this image

This S curve can be broken down into 3 phases: the slowest start, which is the innovation phase, then comes the growth phase when early majority and late majority adopt the product, and finally the maturity phase, where the product has already conquered virtually the entire market.

The Abyss

There is always a “but”. In 1991, Geoffrey Moore wrote a book entitled Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers.

In this book, he explains that between early adopters and the early majority (pragmatists) there is a chasm that many products cannot cross. This is because pragmatists need good referrals in order to buy a new product and enthusiasts are usually not good referrals. Hence the difficulty of some products crossing this chasm.

No alt text provided for this image

Consequently, a single product company will eventually:

  • Not cross the chasm: The company cannot make its product go beyond enthusiasts and therefore will have no customers to survive. This is one reason for the premature death of many startups.
  • Mature: Your product will work and the company will eventually reach the top of the S curve, and it will slow down until some other company invents a product that replaces your product. An example is Kodak, which has not yet recovered from the invention of digital cameras, as it had its revenue primarily from the sale of film and photographic material.

To quote once again the “Queen of Sciences”, the mathematics: Q.E.D.


Quod erat demonstrandum is a Latin expression meaning “as one wanted to demonstrate”. It is usual to appear at the end of a mathematical demonstration with the abbreviation Q.E.D., or in the Portuguese version C.Q.D.

Source: https://en.wikipedia.org/wiki/Quod_erat_demonstrandum

No alt text provided for this image


By understanding the technology adoption S curve and the gap concept that exists between this enthusiast and the pragmatic curve, it is easy to see the need for portfolio diversification that companies have. However, some questions remain unanswered:

  • What options are there to diversify the product portfolio?
  • How to manage a product portfolio?
  • Why do some companies choose to focus on a single product even though it is clear (as described above) the need for product portfolio diversification for their survival?

These questions will be answered in the next articles.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success? Check out my new bundle Digital Product Management with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.

No alt text provided for this image

Be the first to like.

Defining roles with RASCI

In the series of articles, I talked about the relationship between the product manager and engineeringUXproduct marketingproject management, and all other areas of the company. 

To close this series of articles about the relationship between product management and the other areas of the company I’ll present a tool to help define the roles and responsibilities of each person involved in the product development tasks.

These teams need to work closely together for the success of the products they develop and manage. However, this proximity may present a lot of overlap between areas and often raises some questions such as: “Who is responsible for this task?”, “Whom do I need to consult before moving this other task forward?” and “Who needs to be with me so I’ll be able to complete this other task successfully?” Often, these situations become jump balls: one thinks she is responsible for a particular task and the other person thinks the same. Or worse, one thinks the other is responsible, and that other thinks the first one was, and no one does anything.


To solve this kind of situation, there is a very useful tool called RASCI Responsibility Matrix. RASCI is an abbreviation of the first letters of the possible roles that a person, area, or role may play in a task:

  • Responsible: is the person responsible for performing the task, ie who has to lead the effort to plan, do and complete the task. There can be no more than one task owner. We must avoid the “everybody’s business is nobody’s business” situation.
  • Accountable: is the person who is responsible for the task, has the power to delegate the task to be done to the person responsible, and has control over the resources to do the task. Responsible and accountable can be the same person. It is also true that there can be no more than one accountable per task. If responsible and accountable are two different people, accountable can be seen as the sponsor.
  • Support: are the people or teams that work together and under the coordination of the responsible person for performing the task.
  • Consulted: are the people or teams who do not participate in the task execution but who need to be consulted before or while the task is being performed, as they can provide relevant inputs to its execution. Consulted can be seen as advisors.
  • Informed: are the people or teams who do not participate in the task execution, nor need to be consulted before or while the task is being performed, but who need to be informed when the task is completed.
No alt text provided for this image

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

No alt text provided for this image

How to use?

The first step is to build the responsibility matrix. My recommendation is to fill it out with all the people involved in a room, so you can discuss if the division of responsibility makes sense to everyone and if you have any tasks missing. Most likely, some jump balls will emerge, but this is a great opportunity to discuss them and define who is responsible.

Then you should try doing the tasks following the responsibility matrix for a while, like one or two months. Then it is important to look back to see if everything is all right or if any adjustments are needed.

Thereafter, the use becomes automatic and people no longer need to refer to the responsibility matrix. Every 12 to 18 months, or when any doubt arises, or even when a new task arises, you should revisit it.

Okay, everyone knows their role and their responsibilities. Now it’s execution time! (=

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success? Check out my new bundle Digital Product Management with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.

No alt text provided for this image

Be the first to like.

What about the other areas?

In previous articles, I talked about the relationship between the product manager and engineeringUXproduct marketing and project management. The question that remains is: what about the other areas of the company? How is the product manager’s relationship with operations, service, legal, sales, administrative finance, and human resources?


The operations area is responsible for maintaining the product. For online products, ops is responsible for ensuring that all the infrastructure is available and with good performance.

The operational quality of a product has to do with two operational characteristics of the product:

  1. The product must have a good performance: Each customer request to the product must respond in less than X seconds. The definition of this X is the performance definition of this product. It is important to know that X is not an integer; it can and ideally should be a fractional number less than 1 (for example, the product must answer requests within 0.3 seconds). Different product features may have different performance expectations.
  2. The product should be available for use as long as possible: This is the SLA (Service Level Agreement), defined as a percentage number, for example, 99.9%. This number can be measured in a day, month or year. Within a month, 99.9% availability means 43.2 minutes of unavailability, while 99.5% means 3 hours and 36 minutes of unavailability. When we look at the availability of a product, we must take into account two factors. (1) Frequency of problems: the time between each outage. Imagine that your product has 99.9% availability, which means a maximum of only 43.2 minutes per month of unavailability. If this unavailability happens on a particular day for 1 minute every 10 minutes, this means the product will be unstable for more than 7 hours that day. There is an operational metric that should be tracked that helps to measure the frequency of problems. This is MTBF, or mean time between failures. (2) Duration of the problem of unavailability or malfunction: here the rationale is simple. If there is a problem with the product, the problem should last as little time as possible. There is also an operational metrics that must be tracked that helps you measure the duration of the problems. This is MTTR, or mean time to resolve, or average time to resolve.

The definition of good operational quality is a definition that has to be made by the product manager in conjunction with engineering, UX and operations. Of course, we always want to offer the highest quality possible to our customers, but the higher the quality, the higher will be the cost to maintain the product.

It is important for the product manager to define, together with engineering, UX and operations, what is the acceptable quality level and acceptable operating cost for the product. This is what we call a non-functional requirement, as it is not a product feature. It is a feature that impacts its use.

In order for operations to operate the product, it is important that the product be “operable”. It seems kind of redundant what I just wrote, but it is not uncommon to see practically ready-to-release products that have to go back to development, because some simple operational points were not taken into account, such as: what to monitor, how to monitor it, what to do if monitoring finds something not functioning as expected.

Ideally, this should be considered before you start developing the product. If you fail to do that and think about these points only after the product is ready, there is a good chance that you will have to redo something in the product to fit these operational standards. In order to discuss what operational issues should be considered before and during product development, it is a good idea to have someone from operations to participate more closely in product development.

Although the operations relationship should be closer to engineering than to the product manager, it is the latter’s role to follow that relationship and to help wherever possible, especially in defining non-functional operating requirements.

Customer support

Ideally, your product does not require phone, chat, or email customer service. This is what we call no-touch or low-touch products. However, as much as you work with UX to make this true, there will always be customers who want to talk to someone at your company for some reason related to your product. Therefore, you should prepare your customer support team to talk to your customers and to solve their problems.

Before launching your product, you should prepare and deliver training to your service team so that they are prepared to answer key questions. Once it is released, you should follow up on all the calls not only to see the quality of the answers given by the customer support team, but also to understand what are the main questions they have when using the product.

Your goal should be to minimize these contacts by trying to resolve these questions directly in the product. This is a task that you will need to do with the UX people working on the product. Every time you launch a new feature or an improvement to an existing feature, you must communicate to the support team in advance to get them ready so they can fully support questions about these new features.


Your business legal area can be internal, external, or even a hybrid of these two options. Regardless of the model, it is important that it has good knowledge in the digital field, and is constantly updating itself, as many laws and regulations are still being created. New laws and regulations related to software products, digital products, and online products come up quite often, and it is important that your legal department monitors and knows the details of these new laws and regulations.

The legal area has two main functions linked to your product:

  • User Agreement: In this agreement, the main product features are documented, including service level, service type, data privacy policy and payment methods. In addition, this contract must contain the rights and duties of both your customer and your company, ie the rules that must be respected for the proper functioning of the product. For example, at Locaweb we decided at a given time to provide our Website Hosting product with unlimited disk space. To be able to do this, we have contractually agreed what can and cannot be done on our Unlimited Disk Space and Hosting Website Hosting product to ensure the product works well for all customers. We’ve created the unlimited policy explaining that “having unlimited space doesn’t mean you can use your hosting in a way that impairs the operation of the server, for unlawful purposes or otherwise violates applicable law”. In addition to writing the contract, the legal handles all claim that your clients make in the legal context, usually through lawsuits against your company; therefore, you should use empathy to understand the concerns your legal area certainly will have about your product and how it is used.
  • Vendor Agreement: In this agreement, the focus is on how your company’s relationship with the software vendors that will be part of your product will be managed. For example, at Locaweb we have the Web Hosting product, which can be on Linux or Windows. On Linux, we have to understand the open-source software use agreements to see if the Linux Website Hosting product can be built using such software and if there are any restrictions we should consider. On the Windows platform, we must constantly check Microsoft’s software licensing agreement to make sure that we are offering the Windows Site Hosting product in accordance with Microsoft policies.


The sales team needs to be trained by you and the product marketing person about the product to be launched. After that, it is important to make training updates whenever you release news about your product.

Another important point regarding sales teams is that they can provide a lot of important feedback regarding your product. New features, adjustments to existing features, price and business model adjustments are all topics that the sales team can certainly contribute to. But here it is worth remembering empathy again, that is, remember what the sales team’s goal is: to sell. They see your product from the perspective of “how to sell more”. You need to use your discernment and customer knowledge to judge if the sales input is valid for the product, or if it may eventually hinder your goals.

For example, it is fairly common for a salesperson to come up saying that he has enormous potential to make a big sale, but for the customer to make the deal, he needs some new feature, and if it is not implemented that sale will be lost. It is up to the product manager to have insight into the importance of this new feature for the product and for other product customers.

As seen in the article about Special Requests, when I commented on the difference between the Email Marketing Locaweb and All In Mail products, the product context makes clear this need for product manager insight. Accepting these special requests in the Email Marketing Locaweb product makes no sense. In the All-In Mail product, these requests from the sales team should drive your roadmap.


Finance is the area that will allow product managers to understand if the product they manage is a good product for the company; that is, if the return on the product is bigger than its costs. Of course, you and product marketing will keep track of your product revenue on a daily basis, but the costs aren’t as simple to track. Finance can help you calculate and track product costs.

You can divide your cost into two broad groups: the cost of maintaining your product and the cost of attracting customers to your product.

The cost of keeping your web product up and running is what we call **operational cost**. In this category we have cost with the infrastructure and people needed to keep the product running. Here in this group, you should also consider your development team, that is, the UX people, the product engineers, and you.

Another operational cost that should also be considered here is the financial cost, ie the taxes you pay. Finance, along with the legal department, is best suited to define the best tax structure for your product.

Marketing and sales investments are the cost of attracting new customers. Whether you spend on AdWords or other forms of online and offline advertisement, you will have a cost and it’s very important that you measure the return it will give you. How much money do you need to invest in marketing to bring in a customer? How much revenue does this customer bring? Is it enough to pay the cost of attracting it, plus the operational costs, and still have a little left to pay for the investment made in developing the product?

This category also includes the cost of sales and marketing teams, and the commissions that are given to the sales team if your company chooses to pay them a sales commission. If you use indirect sales channels, such as selling through partners, partner compensation will also come as part of the cost of attracting new customers. If the marketing team decides to run promotions, such as a first-year discount, it also comes as the cost of attracting new customers.

When you price your product, it is important to consider its cost structure, as the revenue serves to cover these costs and generate some profit. If you do not get enough revenue, your product will not succeed.

Human Resources

At first, it may seem that HR has nothing to do with the product and its management, but it’s all about it. HR is essential to product success, as it will be part of the process of finding and attracting new professionals to work with.

In addition, HR should help with onboarding the new employee, that is, in his or her early days at the company. HR can also assist in training and evaluating people on product development teams. Hence its importance in the success of the product.

Both at ContaAzul as well as at Gympass, the product development teams have dedicated HR people working with the teams, with two main functions: talent acquisition and HR business partner. At Gympass, the dedicated HR team sits together with the product development team.


This is another team that seems far from the product and the team that develops the product, but it is not. The administrator maintains the necessary infrastructure for the business to continue to function. Office, meeting rooms, furniture, office supplies, office services (cleaning, snacks, meals, coffee, deliveries, etc.) are all necessary for your business to function and, consequently, for the product development team to be able to do their work.

Summing up

I chose to put all of these areas in one chapter rather than devoting one to each, as I did to talk about engineering, UX, product marketing, and project management because interaction with these areas is not as intense. However, keep in mind that these areas and the product manager’s good relationship with them are essential for the success of your product.

Recalling what I said in the article Main characteristics of a product manager, the most important characteristic every product manager needs to have is empathy, that is, the ability to put yourself in someone else’s shoes to understand her motivations, needs, and problems. This characteristic should be used not only with the customer and users of your digital product but also with people from different areas of the company. The product manager must understand the impact his product has on their work so that they can make working together as fruitful as possible.

As we have seen in this and previous chapters, the product manager interacts with virtually every area of the company, and with many of them, roles and responsibilities may overlap. In the next chapter, we’ll look at a valuable tool to help clearly define the roles of each area in the different tasks related to a product’s life cycle.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success? Check out my new bundle Digital Product Management with my 2 books where I share what I learned during my almost 30 years of experience in creating and managing digital products.

No alt text provided for this image

Be the first to like.