What type of company needs a product manager?

When we think about the product management function, we always imagine it being exercised in a company whose core business is software offered via the internet, also known as Software as a Service, or SaaS. However, in my opinion, this is not the only type of company that benefits from having one or more product managers to help with the software development process. There are 3 other types of companies that can, and should, benefit from the work of a product manager.

Companies Developing Non-Online Software

There is still a lot of non-online software that needs to be installed on a computer to run locally, or access data from a server (client-server software). Even with the strong growth of SaaS applications of various types – such as ERP, CRM, BI, Supply Chain Management, among others – there is still a lot of software from these and other categories that are not online, that is, that run on the computer, local, or networked on the client-server model, known as on-premises software, as opposed to online software.

This type of software will not cease to exist anytime soon, either due to technical needs or due to use policy issues. It is not uncommon to find companies that could use online software but that, per company policy on information security and privacy, want to keep these data and the software that manages it within the company premises.

In the future, it is very likely that business use policies and fears will soften to the point that no more companies want to have software installed in their own premises for security reasons, just as today it is quite rare to find companies or people who manage their own energy supply. However, there will always be those who choose to have software installed in their own premises for some specific reason, despite the cost this practice may incur.

On the other hand, technical issues may make it impossible to use online software. Just imagine situations where you can’t be online, such as on a plane or a boat without connectivity. Here you can also imagine a future where connectivity will be good and universal, but there may still be situations where running the software locally makes the most sense.

That is, even if there is this movement towards online software, there will still be on-premises software for a long time to come. This, like online software, is software that has to meet the needs of its owner, while meeting the needs of its users.

For this reason, companies that develop non-online software should also have software product managers on their development team.

Companies that don’t have software development as their core business

Many companies do not have software as their main business. See some examples in the following figure:

Companies that don’t have software as their core business

However, most probably all of them use software. They have computers and internal systems to support and enhance the various processes of the company. Due to the familiarity and usefulness of computers and systems to these companies, it is common to see them starting to think about having one or more digital products to help them interact with their customers.

In the examples in the picture, New York Times has a digital edition, McDonald’s has an app so their customers can order food, Toyota has its Entune App which allows you to access smartphone applications via the in-vehicle touchscreen display, Coca-Cola has an app to manage their reward program, and Bank of America has app so their customers can manage their accounts.

Even though this software is not their core business, they are part of their strategy. For this reason, they should be managed by someone who has knowledge of software product management to ensure that they meet both their owner’s and their users’ goals.

Companies that develop software on demand

The best companies that develop software on demand are always on the cutting edge when it comes to software development. They use new technologies, new programming languages, databases, and architectures; and propose new ways of making software like the agile methodologies, Scrum, Kanban, Lean.

Incidentally, the term Product Owner comes from agile methodologies. This role is responsible for building the backlog, prioritizing the work to be done according to customer demands. That is, companies that develop software on demand know the importance of having a product manager in the team that develops software. So much so that they use this function both on their products and on demand software.

Companies that develop software on-demand

However, usually, companies that make software on-demand assume that their client knows how to manage software. For this reason, these companies only work to meet their customers’ demands and requirements. They hold meetings with their customers asking what they want and expect from the software, collect the requirements, prioritize them according to what the customer demands, and start developing the software. A good company that develops software on demand will try to make frequent deliveries so that it cannot only see progress but validate what is being delivered.

The problem is that this customer doesn’t know how to manage software! If this is her first software, it will be even worse! She can run her own business, and may even know how to acquire off-the-shelf software; however, she will not have a clue about what is needed to own a software, and that the software is very flexible and must adapt to meet the goals of the company and its users. This is all news to her.

For this reason, companies that develop software on demand have an obligation to include in their development package some training or advice to prepare their clients to manage it. Only in this way can these companies increase the chances that the software being developed on demand will meet the goals of their customers and their customers’ users.


In my opinion, any company that owns software, or develops software for themselves or other companies, should have one or more software product managers on its team. This will greatly increase the chances of success, that is, meeting the goals of both the software owner and its users.

Also, in my opinion, companies that develop software on demand have an additional obligation in this software development cycle: to teach their customers about software product management, the importance of this function in their success, and what it takes to make good digital 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? 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.

Organizing for focus and diversification

When a company opts for diversification, team organization tends to be simpler. For each product, there will be a single team of engineers (2-8 people, which can be back-end or front-end or full-stack, depending on your product needs), plus a SysAdmin (system administrator), or up to 9 people in engineering. In addition, it will have 1-2 UX people, one of whom will focus more on visual design, and ultimately a product manager. This is the core team of the product we commented in the article What is digital product management?.

Organization of a multifunctional product team

It can often happen that some people on the team are shared with other products. Top candidates to share are the visual designer, product manager, SysAdmin, and front-end engineer. Back-end engineers should not be shared.

Organization of two cross-functional teams for two distinct products, sharing PM and UX

It is important to remember that by sharing a person between two products, her attention will be shared, which has both strengths and weaknesses. The obvious downside is that she will pay less attention to each of the products she cares for. On the other hand, the fact that she lives two realities, that is, taking care of two products, can make her bring good practices from one team to the other (and vice versa).

However, even if there is this positive point, there are other ways to exchange good practices without sacrificing a shared person’s time and attention. Therefore, the best thing to do is not to share people between two products. Of course, if you have financial constraints, this division between products is acceptable, but try to consider this a temporary situation.


Sharing people between more than two products is extremely inadvisable. The maximum acceptable share is two, and this will already have a considerable impact on attention, productivity, and quality.

Another important point of this type of structure is the importance of maintaining functional cohesion. This can be done through functional leadership, or functional self-organization.

Functional cohesion is important to ensure that there is consistency between team work, and that each one learns from the other’s good practices. Otherwise, each team will make a product that will look, not only from a different team, but from a different company!

At Locaweb, we choose to maintain cohesion through functional leadership. We have leaders in UX, product management and engineering. This guarantees us a good consistency between different products. For example, we created interaction patterns, Locaweb Style, so all Locaweb products have an equal interaction pattern. An Email Marketing product customer knows that when using the Backup product, he will not have to learn the interaction all over again. Locaweb Style is available as open source.

How to organize big teams?

When your product grows – whether in a single-product company or one with a diverse portfolio – the questions begin about how to get organized. This usually takes longer in companies with a diversified product portfolio, because whenever a particular team grows a little, there is a desire to get some people from it to focus on a new product.

In a single product-focused company, the need to organize large teams happens very quickly. It is not difficult to imagine more than 8 engineers available to work on a product and, as we saw earlier, each product team must have a maximum of 6 to 8 engineers. How to organize with larger teams?

The product should be broken into subsystems. These will certainly have some kind of integration and interdependence, but their architectures should be such that interdependence is minimal to make the integration layer as simple as possible. Each of these teams will need back-end and front-end engineers, UX, SysAdmin, and product manager. Because they are subsystems of the same product, these teams may eventually share the same product manager, the same UX, and the same SysAdmin. Here, sharing is a bit more acceptable and sharing may exist in up to 2 subsystems.

However, you must be careful that these people shared between more than one subsystem do not see bottlenecks. The ideal is to have people 100% dedicated to each one. In this ideal scenario, where each member of the teams taking care of each subsystem is 100% dedicated, it is very important for someone to have an overview to help coordinate work between teams. As mentioned, it is important to minimize the interdependence of these subsystems, but some dependency will always exist, and this will need to be coordinated. Eventually, a product manager may be needed to help with this coordination. Ideally, we should have a product manager, an engineering manager who tracks the work of all engineering teams, and a UX manager to help coordinate the work of each subsystem’s UX designers.

Organizing multiple multifunctional teams for a single product, with Product Manager, UX and Engineering Manager

For example, the Website Hosting product is divided into 7 developer teams that focus on different product subsystems. One team works on the development of the hosting control panel; and another works on the provisioning subsystem, which is responsible for installing, suspending, and uninstalling the components that make up Locaweb Website Hosting, that is, the hosting itself – which may be Linux or Windows, the database, and the email.

So, another team takes care of the e-mail control panel and webmail, and finally 4 more teams take care of the subsystems connected directly to the infrastructure, which are the Linux, Windows, database, email and database infrastructure teams. We have two product managers for all of these teams: one focused on website hosting subsystems, the other focused on email subsystems. We also have two UX designers, with the same focus separation, plus a product manager, one UX designer, and one engineering team.

Another good example on a considerably larger scale is Spotify, a music streaming application created in Sweden in 2008, which has over 75 million users according to June 2015 data. The company has over 1,500 employees, all dedicated to one product, and most of them are part of the product development team.

They posted two videos telling a little about their culture and how they organize themselves. It’s worth watching them! They can be found at https://vimeo.com/85490944 and https://vimeo.com/94950270.

Spotify Engineering Culture – part 1 from Spotify Training & Development on Vimeo.

Spotify Engineering Culture – part 2 from Spotify Training & Development on Vimeo.

About QA (and Front-End and BA)

When this chapter was published on my blog, I received some comments about the lack of QA (Quality Assurance) role in team organization. Therefore, I decided to include some considerations on the subject here.

However, before considering, I would like to quote a very nice phrase I once heard that should be remembered whenever conversations about different points of view take place: the fact that we disagree does not necessarily mean that one of the two is wrong.

What’s the point?

In my view, processes, methodologies and ways of organizing a team are not the goal itself, but the means, the tools to achieve a goal. In the case of software, the goal is usually to meet the strategic goals of the software owner while solving problems and needs of users of that software.

QA (and Front-End and BA) at Locaweb

Until the middle of the second half of 2015, we had product engineering teams at Locaweb, one team for each or two products. We also had two separate functional teams from these product engineering teams, the front-end and QA teams. At the end of 2015, we decided not to have a front-end team or QA anymore.

About the Front-End Team

  • The team had 5 developers, while Locaweb had 12 product and system development teams. Since back-end developers didn’t mess with the front-end, the front-end team ended up becoming a bottleneck.
  • The team had developed, along with UX, Locaweb Style, a front-end behavior and style framework that we use in our products and made available for anyone to use in their projects. Locaweb Style aims to facilitate front-end programming of our product interfaces. Locaweb Style makes it easier for back-end developers to front-end, thereby reducing the bottleneck.
  • As a result, we decided to no longer have the front-end team and front-end developers went to product teams where front-end is most relevant. Front-end developers also started to work on back-end, just as back-end developers started to work on front-end. Always respecting Locaweb Style.
  • The front-end functional team coordinator became a product engineering team coordinator. This gave him and the front-end team members (who are now developers assigned to a product team) a greater sense of purpose as they deliver a complete product and not just interface programming.

About the QA Team

  • When QA function is separate from software development function, it is common to hear phrases such as “feature is ready, now in QA”. This denotes a waterfall culture, which can greatly increase development time and negatively impact software quality.
  • When there is a separate QA function from the software development function, it is also common to hear phrases like “Why didn’t QA catch this bug?” This denotes a culprit-seeking culture that can be very detrimental to the team’s climate and consequently negatively impact software quality.
  • Quality should not be the concern of one person or team, it should be the concern of all the people working on the software.
  • Quality is a non-functional requirement, that is, a requirement that specifies a criterion for judging the operation of software, which is different from a functional requirement, which specifies software behavior. Performance, scalability, “operability”, “monitorability” are some examples of non-functional software requirements that are as important as quality. Even so, there are no roles of * performance assurance *, * scalability assurance *, * operability assurance * and * monitorability assurance *. Why is quality the only non-functional requirement that has a specific function in place to ensure it?
  • QA focuses on ensuring the quality of the software development process. If a separate role is required to ensure this quality, why there is no need for a separate role to ensure the quality of the product management process, the UX design process, the product marketing process, the sales process, and the financial process?
  • At Locaweb, we had around 12 QAs, some more developer profiled and some more SysAdmin profiled. As we proposed the extinction of the role of QA, some of the QAs became devs of a product while others took on the role of SysAdmin.
  • There was concern among devs that if the dev itself will now have to test, deliveries will take longer to get ready. This concern existed as devs considered their work to end when they passed the story for QA to test. However, this ready-made view of dev is incorrect, as it only passed the story to the next phase, the test. From the software user’s point of view, the story is only ready when the user can use the new feature. And what happens when the story goes through QA, is rejected and needs to go back to development?

When I joined Conta Azul in August 2016, I learned that they had also extinguished their role as QA earlier that year. The motivation was a series of visits they made to Silicon Valley companies and realized that they did not use QAs and that everyone on the team was responsible for the quality of the software developed. At Conta Azul, QAs made the career change to BAs.

About BA

Another question I received when I published the text of the previous chapter was about the absence of BA (Business Analyst). I did not explicitly state BA, as BA and PO are similar roles in software development. The differences were explained in the BA, PO and PM article. However, both have the same goal: to help the team make software that meets the software owner’s goals while solving their users’ problems and needs.

In some organizations, it may happen that BA is focused exclusively on business, that is, understanding only what the business objectives are, leaving aside the problems and needs of users. In this case, it is important for BA to also take into account the problems and needs of software users, balancing them with business objectives.


In this article, I showed you how to organize your product development team depending on whether your strategy is to diversify your product portfolio or focus on a single product. I even explained the absence of QA and BA in my recommendations on organizing product and system development teams.

Remember that processes, methodologies, and ways of organizing a team are not the goal in itself, but the means, the tools to achieve a goal. In the case of software, the goal is usually to meet the strategic goals of the software owner while solving problems and needs of the users of that software.

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.

Focus or diversification?

Okay, I convinced you that those who do not diversify can get into a difficult situation, because a single product company ends up dying sooner or later. I also explained strategies for portfolio diversification and showed how to manage a product portfolio.

On the other hand, there are several examples of companies that have opted for focus. A very interesting story of focus strategy is 37signals. They were a website development company. To help them follow their website development projects, they developed software that allowed for greater visibility into project progress for everyone involved, including the client.

Customers enjoyed interacting with this software and asked 37signals to use this software on other projects at their companies. At that time, 37signals decided to turn this software into a product, and they named it Basecamp. After some time, they stopped developing on-demand software projects and focused all their attention on the Basecamp product.

Later, following the portfolio diversification strategy I described in the previous articles, they launched more products: Highrise, a contact management system; Backpack, internal communication system; and Campfire, the corporate chat system.

In early 2014, 37signals decided to adopt a new strategy. They decided that from that time on they would focus 100% on Basecamp. The other products would no longer accept new customers. And the “icing on the cake” of this strategy was the change of company name, which would no longer be called 37signals to become Basecamp. These changes turned out to be the subject of a Harvard Business Review article titled “Basecamp’s Strategy Offers a Useful Reminder: Less Is More” 2014 Basecamp Strategy offers a useful reminder: less is more – in which the author says:

“It’s a natural tendency for humans to want to do more. Most of us have difficulty moving away from tempting opportunities, whether at the dinner table or at work. That’s why we end up with indigestion at home, or overworked at work. That’s why it takes a lot of discipline, and even courage, to lose weight both physically and strategically.” – Ron Ashkenas

Focus is not such a rare strategy. Some other examples from the software world:

  • Facebook: Despite having a people profile, group page and company page, as well as an ad system (which could be considered as products), these systems are nonetheless different views of a single product. Yes, they have diversified their product portfolio, but always through acquisitions like Instagram and WhatsApp. These acquisitions continue to function as independent companies, each one is also 100% focused on their respective products.
  • Twitter: Another company that is a sizable company that remains 100% focused on its single product. It also focuses on a second group of customers, the advertisers, but always focusing on their one product.
  • LinkedIn: Another company that is of considerable size and still 100% focused on its unique product. They have also focused on a second group of customers, the advertisers, but always focusing on their unique product.
  • Spotify: Example of a company 100% focused on its only product, music streaming.
  • MailChimp: Email marketing software company. This company usually makes acquisitions, but all of their acquisitions are within the same theme, email marketing and email sending.
  • DigitalOcean: VPS (Virtual Private Servers) company which is also a good example of a company 100% focused on its single product.
  • Airbnb: intermediation company between people who want to rent real estate or rooms for short periods, and people who are looking for accommodation. It is a platform 100% focused on your only product.

On the other hand, we already talked about Google with its 177 products and its more than 70 discontinued products. This vast portfolio eventually led them to revise their brand strategy, and to create a “parent company” called Alphabet, of which Google would be just one company, and several companies of Google’s other products would become independent. This is a strategy of increasing focus, but nonetheless, Google remains a multi-product company (Search, Adwords, Gmail, Google Apps, App Engine, Youtube, Android, etc.).

Another extreme example of portfolio diversification is 3M, which has over 55,000 products in its portfolio. That’s right, you read that right, over 55,000 products in its portfolio. Just imagine 3M’s BCG matrix. ūüėõ

So what is the best strategy?

With the examples given, the question remains: what is the best strategy, diversification or focus?

As I was preparing a presentation on this topic, I was struck by the spelling of the two words. Focus is a very short 5 letters word, while diversification has 15 letters. I found it curious that the complexity of the spelling of words is all about their meaning, at least in this case.

To understand which strategy is best, we must first understand the negative aspects of each strategy.


When a company is focused on a single product, it loses the opportunity to solve its customers’ other problems, which can be bad for two reasons. The first (and quite obvious) is the fact that you miss an opportunity to earn new revenue. The second (not so obvious) reason is the risk of losing the customer, because when she looks for who can solve this other problem, she may find someone who not only solves this other problem, but also the initial problem that your product already solves, and this customer may decide to move all her needs to this new supplier.

Also, as we saw in the article Are you thinking about your new product? No? So you are already late, a single product company may eventually die, either because its product has not crossed the chasm or because the product has reached maturity.


On the other hand, diversification also has its disadvantages. The first is that more investment is required to take care of more than one product. You will need a development team for each of your products, and this can be costly.

Another disadvantage is the waste inherent in the structure of different groups working on similar things. For example, at Locaweb we have several products designed to allow customers to send emails; the email product itself, website hosting, reseller hosting, email marketing and SMTP. Because there are different teams that take care of each of these products, their architecture does not necessarily leverage the learning and infrastructure of each other.

How to choose?

To be able to choose between these two strategies, one has to look at both internal and external factors.

The internal factor to be looked at and understood is the company culture. If your company has a culture that values ‚Äč‚Äčentrepreneurship highly, it is very likely that diversification is most appropriate. On the other hand, if the company’s culture values ‚Äč‚Äčexcellence very much, it is most appropriate to adopt a single product focus strategy. In Locaweb’s case, we have always had a very strong entrepreneurial spirit from the founders. While excellence is important to Locaweb, entrepreneurship is more. On the other hand, Conta Azul culture was always focused on excellence, which is clear in the focus on one product.

However, looking at the internal factors alone is not enough. You also need to look and understand the factors external to your company, i.e., the market. If you are in a small, low growth, or very competitive market, diversification is most appropriate. If you are in a poorly served market, focus is the best option.

In Locaweb’s case, we face competition across all our product lines. Recently, we have started to have international competition operating in Brazil in all our main lines of business. Therefore, diversification is the most appropriate strategy for us. On Conta Azul’s case, even though there’s competition, there’s a lot of room to grow. We have more 14.5MM micro and small enterprises in Brazil, enough market for more than one competitor. And Brazil’s bureaucracy creates an entry barrier against international competitors.

So a single product company will…

As I explained at the end of the article Are you thinking about your new product? No? So you are already late, a single product company will eventually die, because either its product will not cross the chasm or, if it does, it will eventually reach the end of its life.

However, as we have seen, there are several companies that choose to focus on single product rather than portfolio diversification. Does this mean that these companies are bound to die? Yes, but the fact that they know this makes them think better about the future, and what happens is that they not only prepare for the end of life, but also plan the end of life and new versions of their product that will come next.

That’s what I explained in the article Lifecycle of a software product, where I told how the TV market matured some 30 years after the TV was invented and that its manufacturers are always inventing it all the time. Something new to make us buy a new TV: first they were in black and white until they hit SmartTV. All of this so that they could continue to earn new revenue from their customers after the end of the previous product’s life.

Therefore, both focus and diversification are valid strategies. The important thing is to understand the pros and cons of each one well, and to understand in which context each one is most appropriate.

Feature lifecycle

If you decide to focus on one product, or even with a diversification strategy when you end up with one or more products that are big, with many features you think about applying the 4 phases lifecycle not only to a whole product, but also to its major features.

To give you an example, let’s imagine our whole product being Linkedin. Let’s say that we decide to develop a new feature for Linkedin, for instance, the article publishing feature I use to publish my articles on Linkedin. During the feature innovation phase, we’ll have to find the product-market fit. In this case it will be feature-market fit, and the market is the entire user base of Linkedin.

If we are able to find the feature-market fit, then it’s time to grow the feature usage, i.e., implement additional features to the publishing feature we’ve just launched so it can be a complete feature to be used by the maximum number of users possible.

After the growth of the publishing feature adoption in Linkedin user base, comes the feature maturity. In this stage, the publishing feature is complete in terms of its possibilities and since it’s used by the majority of the user base, its growth slows down.

Then, after growth comes the end of life stage for the publishing feature. It can happen if Linkedin as a whole enters this phase, or if the feature is replaced or discontinued for any reason.
Next time you decide to develop and launch a major feature for your product, you can apply the product lifecycle view to help you manage the lifecycle of this new major feature.


In this article, we saw that not only from portfolio diversification lives a software product company. It is possible to survive by maintaining 100% focus on a single product. Incidentally, several companies have chosen this path successfully.

At Locaweb, we opted for the diversification strategy, both due to internal motivators and entrepreneurial culture, as well as external motivators, such as the constant increase of competition in all our business lines.

Often, I used to receive inquiries from employees, customers, and partners about our product portfolio of over 25 products. They ask us if this really is the right strategy for us. We believe we have adopted the most appropriate strategy, not only for the reasons already explained (entrepreneurial culture + competitive market), but mainly because of the growth numbers. If Locaweb had not diversified its product portfolio and had focused only on website hosting, today Locaweb would only have 38% of its current size.

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.

Saiu a 3ª edição do livro Gestão de Produtos

Ficou pronta hoje a 3¬™ edi√ß√£o do meu livro “Gest√£o de Produtos, Como aumentar as chances de sucesso do seu software“. E como presente de lan√ßamento, aqui vai um cupom de 10% de desconto (JocaCDC10).


A primeira edi√ß√£o em portugu√™s deste livro √© de 2015. Escrevi uma vers√£o atualizada em 2017. Apenas tr√™s anos se passaram desde a sua vers√£o mais recente. No entanto, o aprendizado √© um esfor√ßo cont√≠nuo. Continuo aprendendo com minhas experi√™ncias di√°rias e publiquei o que aprendi no LinkedIn. Agora, decidi n√£o apenas traduzir meu livro para o ingl√™s, mas tamb√©m atualizar o conte√ļdo de 2017 com meus aprendizados desde ent√£o.

Neste Changelog, registro o que mudou desde a edição de 2017:

  • Estou usando software, produto e produto digital de forma intercambi√°vel. Para o contexto deste livro, esses termos s√£o equivalentes.
  • Atualizei as estat√≠sticas ao longo do livro, para manter os dados relevantes, com coment√°rios sobre a evolu√ß√£o dos dados.
  • Paulo Caroli teve a gentileza de escrever o pref√°cio desta terceira edi√ß√£o! (=
  • Mais exemplos, n√£o apenas da Locaweb e Conta Azul, mas tamb√©m do Gympass, um marketplace de tr√™s lados que conecta parceiros de fitness a empresas e seus funcion√°rios. No Gympass, liderei uma equipe de desenvolvimento de produtos, juntamente com Rodrigo Rodrigues e Claudio Franco. Temos o desafio de criar um produto global usado por parceiros, empresas e usu√°rios de fitness em todo o mundo. Como somos l√≠deres nesta categoria, temos o desafio adicional de ser os primeiros a enfrentar certos problemas, o que √© bastante empolgante.
  • No cap√≠tulo ‚ÄúO que √© um produto digital?‚ÄĚ, descrevo a diferen√ßa entre empresas digitais e tradicionais e apresento o conceito de empresas tradicionais que j√° nasceram digitais. √Č muito importante para um gerente de produto entender com que tipo de empresa e produto ele est√° lidando, para saber como desempenhar melhor seu trabalho.
  • Tamb√©m no cap√≠tulo “O que √© um produto digital?”, descrevo uma maneira diferente de categorizar plataformas. Al√©m de toda categoriza√ß√£o que j√° apresentei na 2¬™ edi√ß√£o, podemos categorizar plataformas como plataformas de transa√ß√£o ou de inova√ß√£o.
  • Em “Dicas de lideran√ßa para gerentes de produto”, adicionei mais informa√ß√Ķes sobre porque √© t√£o importante definir o contexto, e alguns exemplos de obst√°culos que um gerente de produto pode remover para sua equipe.
  • Adicionei um novo cap√≠tulo intitulado “Dois hacks para promover e fortalecer sua cultura de produto digital” onde conto um pouco de minha experi√™ncia em gerir produtos em uma empresa que n√£o tinha cultura de produto digital e o que fiz para ajudar a promover e fortalecer essa cultura.
  • Adicionei a se√ß√£o “Foco no problema vs foco na solu√ß√£o” ao cap√≠tulo “Inova√ß√£o: foco no problema” com alguns exemplos pr√°ticos de solu√ß√Ķes simples encontradas quando se foca em entender bem o problema.
  • No cap√≠tulo “Crescimento: o que √© um roadmap?”, adicionei uma se√ß√£o inteira descrevendo uma ferramenta que utilizo com sucesso na Conta Azul e Gympass, o rolling roadmap de 12 meses.
  • Tamb√©m no cap√≠tulo “Crescimento: o que √© um roadmap?”, adicionei uma se√ß√£o inteira sobre quando usar OKRs e quando usar roadmaps.
  • No cap√≠tulo “Crescimento: como priorizar o roadmap?”, adicionei mais informa√ß√Ķes sobre como lidar com solicita√ß√Ķes especiais, especialmente se voc√™ gerencia um produto digital B2B com grandes clientes.
  • Adicionei uma se√ß√£o de exemplo em “O que √© e como criar a vis√£o e a estrat√©gia do produto?” para ilustrar diferentes tipos de vis√Ķes de produtos digitais, incluindo uma vis√£o hipot√©tica do produto digital do banco, e tr√™s vis√Ķes reais do produto: vis√£o de produto da Locaweb E-mail, vis√£o de produto da Conta Azul e vis√£o de produto da Gympass.
  • Na se√ß√£o SWOT de “O que √© e como criar a vis√£o e a estrat√©gia do produto?”, adicionei mais t√©cnicas para ajudar voc√™ a preencher um SWOT mais √ļtil para dar suporte ao design da sua estrat√©gia de produto.
  • Adicionei um novo cap√≠tulo intitulado “Crescimento: reunindo tudo – vis√£o, estrat√©gia, roadmaps e OKRs”, onde explico como usar juntas as diferentes ferramentas que devem ser usadas durante a fase de crescimento de um ciclo de vida de produto digital – vis√£o, estrat√©gia, roadmap e OKRs.
  • Adicionei um cap√≠tulo intitulado “Projetos vs problemas”, onde explico o que acontece nos ciclos de planejamento, principalmente nos ciclos anuais, quando acabamos nos focando em fazer uma lista de projetos e nos esquecemos de que problemas queremos resolver com aqueles projetos.
  • Adicionei um cap√≠tulo intitulado “Crescimento: como gerenciar produtos durante crises”, onde conto qual √© o papel de um gestor de produtos em uma crise.
  • Adicionei uma nova se√ß√£o sobre as diferentes op√ß√Ķes para expandir um mercado no cap√≠tulo “Como diversificar seu portf√≥lio de produtos?”.
  • No cap√≠tulo ‚ÄúFoco ou diversifica√ß√£o?‚ÄĚ, adicionei uma se√ß√£o explicando quando e como usar o ciclo de vida de quatro fases para os recursos individuais do seu produto.
  • Adicionei duas novas se√ß√Ķes ao cap√≠tulo “O problema da TI”. Uma sobre a ThoughtWorks, uma empresa de consultoria de desenvolvimento de software conhecida por estar sempre um passo √† frente na ind√ļstria de software, sugerindo que apliquemos o gerenciamento de produtos a plataformas internas. E a outra sobre a ‚Äúfal√°cia do cliente interno‚ÄĚ, onde questiono o conceito normalmente utilizado em algumas organiza√ß√Ķes de cliente interno ou usu√°rio interno ao discutir o trabalho realizado entre as √°reas.
  • No cap√≠tulo ‚ÄúOnde est√° o gerenciamento de produtos de software em uma empresa?‚ÄĚ, adicionei uma se√ß√£o explicando como um gerente de produto pode ganhar mais autonomia.
  • Na “Conclus√£o”, adicionei uma se√ß√£o para explicar como fazer uma mudan√ßa de carreira para gerenciamento de produtos.

Boa leitura! \o/

Be the first to like.

Stakeholder relationships

A product manager’s life is all about relationships. Any product manager has to interact with many people inside and outside her organization that have an interest in the product she manages. In the corporate jargon, these people are called stakeholders:

In the last decades of the 20th century, the word “stakeholder” became more commonly used to mean a person or organization that has a legitimate interest in a project or entity. In discussing the decision-making process for institutions‚ÄĒincluding large business corporations, government agencies, and non-profit organizations‚ÄĒthe concept has been broadened to include everyone with an interest (or “stake”) in what the entity does.

Source: Wikipedia

I wrote a series of articles about the relationship between the product manager and engineeringUXproduct marketingproject management, and all other areas of the company – Operations, Customer Support, Legal, Sales, Finance, HR, Administrative. I also suggested the use of a tool called RASCI to help define roles and responsibilities.

I also wrote about the main characteristic any product manager needs to be successful, empathy. This is the ability someone has to walk on someone else‚Äôs shoes in order to understand her aspirations, motivations, needs, and problems.

There’s another interesting tool that can be helpful to help product managers understand how to interact with many different stakeholders of her product.

Power-Interest Grid

The Power-Interest Grid is a concept first developed in the 90‚Äôs 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 the interest that a person or a team has in your product, you can classify them in 4 main categories.

Players are the ones with high power and interest in your product. You definitely need to collaborate frequently with them. Your product’s users and customers are definitely players, you need to collaborate with them in order to build the best product that solves their problems and addresses their needs. In some companies, probably the founder closest to the product is also a player. You should invite these people to any meeting and dynamic where strategic decisions will be made. Schedule one-on-ones to present the decisions and ask for their feedback and input.

Subjects are the ones with low power but high interest in your product. They don’t have the power to veto or change decisions, but they have a deep interest in your product. In some companies, we can think about customer support, sales, and marketing as examples of areas that play the role of subjects. They have high interest, but they don’t have the power to change your product. You can communicate with them through weekly status email, product demos. It’s important to gather their input, but remember that they don’t have the power to change your decisions.

Context setters are the ones with power to change your product but low interest in your product. Examples of areas that can play a role as context setter are HR and Legal. If HR doesn’t help you staff the team, you won’t have a team to build your product. If Legal is not aware and aligned with the legal aspects of your product, they have the power to block or delay your launch. A CFO and a controller are also two roles that have the power to change decisions that affect your product. It’s important to keep context setters well informed about your product decisions. Consult them prior to making major decisions. Keep them informed on a weekly basis.

Crowd are the ones with low power and low interest. Even though they have little power and interest, it’s important to keep them informed. Normally a monthly update on the progress of the product is enough. Can be through email or in a monthly all-hands meeting with product demos. Normally this are the people from HR, Legal, Administrative, and Finance areas who don’t are in the context setter group.

It’s important to note that each company has its own dynamic, so an area or a person that is a specific role in the power-interest grid in a company may be another role in a different company.


  • 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 a product manager needs to better understand and, consequently, have improved and fruitful interactions with her stakeholders is empathy.

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.

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.

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.