Product vision

Despite being only 10% of a product leader’s time, defining the product vision is the most important responsibility. Without a clear product vision, it is very difficult to work on any other product topic. What are the priorities? What product team structure is needed? Is this request from the sales team important? And this one from the customer support team? And that request from the CEO / Founder? Should we focus on having more customers or retaining the ones we already have? These questions are very difficult to answer if there is no clarity about the product vision.

When I join a new company, whether in a full-time role or as an advisor, my first concern is to understand if there is a product vision and if it is clear to everyone in the company. This is always my first focus, because from the product vision derives all product development work.

What is a product vision?

The product vision is nothing more than an understanding of what your product will look like in the future. By “the future” I mean mid to long-term, like more than 2 or 3 years. How will it achieve the objectives of the company that owns the product while solving problems and needs for its users?

Building the product vision is a collaborative work done together with several people inside the organization, as well as with input from outside people such as customers and non-customers, suppliers, competitors, market specialists, etc. This is a job led by the head of product, whether he is a VP or CPO, whether he is a GPM. If he is a VP or CPO, the vision will scope all products of the company or area, while if it is a GPM, the focus of the vision will be one of the products, or part of a bigger product, that this GPM takes care of. For the GPM to be able to build the vision, he needs to have a clear understanding of the company’s product vision.

In my book “Product management: How to increase the chances of success of your software”, I explained that to make the product vision it is necessary to be clear about the company’s objectives, as well as to deeply understand the problems and needs that customers have and that will be resolved by the product. Some examples of product visions I helped build:

Locaweb Email Product

During my time at Locaweb, we put together the following product view for the Locaweb E-mail product:

Locaweb’s E-mail product will be the most complete and flexible email solution ** in the Brazilian market.

CONTA AZUL product view

We created the Conta Azul product vision as an image, because with the image it was easier to explain all the elements that we saw as the future of the Conta Azul product.

Conta Azul product vision

Gympass product overview

Again, we prefered a picture over words. The saying a picture is worth a thousand words has a reason for existing.

Gympass product vision

Product vision creation process

Here is a step by step on how to create the product vision:

  • get the strategic company objectives: if you don’t have this information yet, go get it. Talk to company leaders, the CEO, the founders, the board. Of course, every company wants to grow and have more revenue and customers, but how? What are the company’s goals, and what is the strategy to achieve those goals?
  • get an understanding of customers’ problems and needs: if this is still unclear, there are several tools that help. In the chapter on Vision and Strategy of my book “Product management: How to increase the chances of success of your software” I mentioned empathy and personas as useful tools to obtain this information. There are several other tools such as observation, interview, research, job to be done etc. Anyway, there are several tools for you to obtain this information.
  • draw the first version of the vision: once you have both information, you can already make the first version of the product view. This is a creative job and is more productive if done alone. I already tried to do this work together with other people and the process ended up taking a long time and the result was not so good for having several people discussing something that didn’t exist yet. Based on my experience, it is more productive and produces better results when the head of product makes the first version and, from there, iterates to collect feedback and refine the vision.
  • iterate and refine: once the first version of the product vision is done, it’s time to iterate and refine the vision. First people to iterate are the people on the product development team. PMs, GPMs, designers, engineers. Listen to their feedback and refine the product vision based on that feedback. Then, present to the leaders of the other areas, managers, directors, c-level, founders, advisors, more feedback and refinement. I prefer to do these feedback and refinement sessions individually. Although it takes more work and time, it gives everyone the opportunity to speak.
  • communicate: after the iterations and refinements of the product vision in 1:1 sessions with stakeholders, the next step is to communicate this vision to the entire company and even outside the company. This must be done repeatedly. At every opportunity, remember the product vision. I usually use the product vision at all possible times. All-hands, product, board, onboarding meetings, etc. I even use it publicly in lectures and articles to explain how we see the future of the product in our company. I also use it in conversations with candidates, to help them understand what we are building and to encourage them to join us.
  • review: it is important to review the vision periodically, to check if all its elements still make sense and if something new needs to be included. My suggestion is to do this review once a year, or when something new appears, like a new competitor, or some change in the market.

There you go, the steps to make the product vision.

Summing up

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

In the next chapter, we’ll look at how to execute your product vision.

Missing something?

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

Digital Product Management Books

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

Product management career

In my book Product Management: How to increase the chances of success of your software I comment on career progression starting with Business Analyst (BA) as the beginning of a career, with the responsibility of specifying what the product development teamwill build, then going to Product Owner (PO) which, in addition to specifying, must also prioritize what the product development team should do and, at the top of the career comes Product Manager (PM) who, in addition to specifying and prioritizing, must also define the vision and strategy of the product or piece of product that she takes care of.

BA, PO and PM

Another way that many companies have designed this career evolution is to consider the BA and PO phases as Associate Product Manager (APM), with the responsibility of specifying and prioritizing. It is the first step in a product management career.

APM and PM

Since product management is a role of great responsibility, I recommend that people entering the product career be people with some previous experience in other areas such as engineering, design, or marketing. I have also seen great product managers coming from operations, support, project management, financial, and even legal. Throughout my career I have noticed that people who have just left college do not have the necessary baggage to be able to be good product managers. It is important to have this experience in other areas to help you understand how your product impacts those other areas.

And then?

The question that remains is, what’s next? A person goes from APM to PM, then to Senior PM, but what is the next step in your product management career?

A minimum product development team is made up of a few engineers, usually starting with 2 engineers and reaching up to 7 engineers, one of whom is someone more senior, with a tech lead role, plus a product designer (PD) and a product manager (PM). When there is a need to create a second team to take care of another part of the product, there are two ways to make this team expansion:

  • expand engineers, divide and hire PM and PD: we can divide the team of engineers into 2 teams, each with a focus, and temporarily keep the product manager and product designer in these two teams until we are able to hire a second product manager and a second product designer. This model is used when the scope of work of the second team is very clear.
  • hire PM and PD to do discovery, expand engineers and divide: in this case we bring first a PM and an additional PD to work on the discovery of what we want to do with this second team. Meanwhile, more engineers are being hired to expand the first team. At a certain point in the discovery, already having some clarity of what this second team is going to do, then do the team division. This model can be useful when there is still no clarity as to what this second team will work on and it is necessary to do a work of discovery that does not fit in the day-to-day of the original PM and PD.

In both cases, if the original product manager is a more senior product manager, we can hire that second more junior product manager or even an associate product manager and give the more senior product manager the opportunity to help that junior product manager develop. It would be a first people management opportunity for this more senior product manager, if that is something she is looking for in her career. While she still takes care of a product or piece of product with the first team, she can begin to experience the leadership of another, more junior product manager.

After one to two quarters running in this configuration, it is possible to understand if the most senior product manager liked this new role, of helping a more junior PM to develop. If that role is something that makes sense to the senior PM, it is possible to think about adding more junior product managers to help her. At that point it will become increasingly difficult for this PM to manage a product or a piece of a product.

I am focusing on the career of product manager, but there is a similar path in both engineering and product design. The most senior tech lead may come to lead the other team’s tech lead, just as the most senior product designer can lead the other team’s product designer.

Group Product Manager

This is the moment when the senior PM becomes a Group Product Manager (GPM). This is the first step in a product leader career, when the product manager does not directly care for a product or a piece of a product and is responsible for helping other product managers to develop and manage their products. This usually happens when the person is leading 3 or more product managers and is responsible for a set of features or even an entire product. In some companies, this position is called head of product, or product director, or even product vice president.

At Conta Azul we had GPMs that took care of pieces of the product. A GPM was more focused on the product’s financial features such as financial reporting, issuance of bank slip, etc. while the other was more focused on accounting and tax functionalities such as registration of purchase and sale, inventory management, issuance of invoices, etc.

At Gympass we had product directors focused on each actor in our marketplace. One product director focused on gyms, another focused on our clients’ HR and a third focused on our clients’ employees.

In a small company, GPM can be the highest level of product careers. For example, in a company with up to 6 or 7 PMs, a single GPM to coordinate those PMs may be sufficient. When you go over that number, it may be interesting to have a second GPM, or even a CPO or VP of product that leads the GPM and some PMs.

In addition to leading PMs, the GPM also has the role of coordinating the definition of the vision and strategy of a group of products or features. For example, the HR product director at Gympass has to lead the PMs who work on pieces of the HR product, which we called the HR Portal, as well as to define the future vision of this HR Portal, that is, where we wanted to get with the HR Portal and the strategy, that is, the way to get there. And with PMs, he is responsible for executing this strategy.

Interim leadership

I imagine that you have already seen some situation in which the person is an excellent individual contributor, receives a promotion to lead people and, for not being prepared or even for discovering that he does not like to lead people, he ends up having a bad performance as a manager. But this person understands that he cannot go back, returning to a position as an individual contributor can be seen as a setback in the person’s career, as a failure.

An interesting tool to prevent situations like this is the concept of interim. Instead of the person already assuming a permanent position of GPM and leading one or more people, the concept of interim GPM can be used, that is, the person takes on this role temporarily, as a test for him to see if he likes and feels comfortable doing the role of leader. This tool can be used in any career, not just in the product management career. From engineer to engineer leader, from product designers to UX leader, etc.

This tool creates a safeguard, a safety net for people who have never led people and want to try this career option. With this tool there is room to go back if the person does not like it or does not feel prepared to perform this function. It is the famous concept of change rollback or undo that allows to undo a change and return to the previous version if we notice that the change made is not working as expected.

CPO or Product VP

The Chief Product Officer (CPO) or Vice President, Product is the highest product position in a company. Leads GPMs or product directors and is responsible for coordinating the definition of the vision and strategy of all the company’s products, as well as for the execution of this strategy, together with the GPMs and product directors. In some cases it may make sense for the UX area to report to the CPO. Ideally, given the importance of digital strategy in companies, the CPO position should report to the CEO and have access to members of the Board.

Product management career

The nomenclature can be a little confusing. Some companies call this position head of product, others call product director or product vice president or CPO. Although the nomenclature is confusing, the important thing is that the structure is clear to everyone inside and outside the product development team.

There are two models of leadership structure for product development teams, each with its pros and cons depending on the context where this team is:

Unique leadership

At both Locaweb and Conta Azul, I had the role of CPO with the responsibility of leading the entire product development team, that is, product managers, product designers and engineering.

Unique leadership works when you have senior people to help with engineering management as well as design and product management. At Conta Azul, the team had 130 people and I had an engineering head, 4 GPMs and a design head to help me. At Locaweb with a team of 100 people I had two senior engineering managers, 5 senior PMs and a UX head.

I like this configuration because I have always seen the product development team as a single team, with common goals of delivering the best product to meet the company’s objectives while solving problems and user needs. This configuration helps with alignment and this single team vision.

This type of setup works very well for small teams, up to 80 to 100 people. When it reaches that size, there is a risk of overloading this unique leader responsible for the entire product development team. It is a multitude of different themes, hence the importance of having senior people helping in leadership.

In some companies, instead of CPO, this unique leadership is called Chief Technical Officer (CTO) or Vice President of Product Development.

It may make sense to think of dividing the area into two leaders when the team grows to more than 100 people, with a CPO and a CTO doing the shared leadership. It is worth remembering that shared leadership, despite being beneficial in the sense of sharing responsibilities, can have harmful side effects if it is not well managed by the CEO.

Shared leadership

At Gympass we ran for 18 months with a CTO and two CPOs, one of which was for consumer productsand I focused on products for companies and partners. We opted for this configuration because we expected a considerable growth of the team. When the team was still with 60 people, we already saw growth of up to 400 people. Being able to share responsibility, especially when the team grows fast to numbers above 100 people, helps to put more attention and go deeper into the themes that each leader takes care of. This avoids the overhead that I mentioned above.

Product development leadership structure in Gympass

At Gympass, the UX team reported to the consumers CPO while I had, in addition to the product teams for companies and partners, a Professional Services (PS) team that was responsible for making customized integrations with gym and training systems. our customers’ HR systems. This professional services work is more project-oriented, with a clear definition of scope and well-defined deadlines, so we created a separate area to take care of these integrations.

At Conta Azul, when I left there in mid-2018, we were starting to think about dividing the roles between CTO and CPO. So much so that now in 2020 there is this structure with the shared leadership of the product development team.

Product development leadership structure at Conta Azul

Another possibility for shared leadership of product teams is to have head of engineering, products and UX.

Shared leadership has the side effect of the inherent risk of creating silos, that is, of having teams working in isolation and without the necessary collaboration. At Gympass, we had a strong concern to avoid this behavior. We sat 3 side by side and reserved at least three hours a week to talk about topics of the product development team, one hour between the three of us, one hour the three of us together with an HR business partner, and one hour with the CEO. In addition, we sought to set goals in a common way for teams and treated the budget as a single budget for the product development area.

However, despite our efforts, there were still situations of lack of collaboration between members of different teams. For this reason, I prefer configurations with a unique leadership of the product development team, despite the possible overload that this may cause in this leadership. One way to reduce this burden is to have senior leaders.


As I mentioned earlier, the product development area is a single area, with the common goal of creating the best product to tend to the company’s strategic objectives while solving customers’ problems and needs. Having two or more leaders for this area requires a lot of coordination between these leaders to ensure that the teams are collaborating and evolving in the same direction. The most common way to share this leadership is to have two people, CPO and CTO, to lead the product development team. While the CPO leads product and UX people, the CTO leads engineering people.

Division of responsibilities between CTO and CPO

The image above illustrates well the responsibilities of each leadership. The CTO takes care of the actual development of the product, that is, it has to be concerned with the quality of what is being developed, as well as with the speed of development. It also takes care of infrastructure and operational issues such as product stability, performance and availability.

The CPO takes care of the product from both the business and the customer’s point of view. From the business point of view, the CPO is responsible for defining the product vision in line with the strategic objectives of the business. From the customer’s point of view, he needs to ensure that the product solves a customer’s problem or need with quality and, for that, he needs to understand the customer’s satisfaction and engagement with the product.

Together, CTO and CPO must define and evolve the structure of the product development team, normally composed of product teams and structural teams (SRE, Data, etc) as we will see in a future chapter, as well as define and evolve the processes that this team will use in their day-to-day activities.

Y career

Career Y is the option given to people to choose the managerial career or to continue in the specialist career. Some senior PMs may not want to manage people, just products. Does this mean that there is no room for her to evolve in her career, since the path of progression seen above goes through the leadership of other PMs? Not necessarily. In companies with more complex products or even with a portfolio of more than one product, there may be room for a role little known in the Brazilian market, but that can help a lot in this context, the Principal Product Manager. This is a role that does not manage people but that, due to its seniority, has a relevant impact on the organization. Its main responsibilities are:

  • Help connect the work of GPMs: as the company grows and we have more than one product development team, each with their own GPM and often focused on the day-to-day life of that team, without looking a lot for what the other teams are doing. It is usually the role of the CPO to maintain the connection between the work of the different teams and their GPMs, but in some structures, it may make sense to have some very senior PM playing this role.
  • Ensuring synchrony and consistency between product teams: regardless of whether we try to structure product teams, there will always be situations in which a team will depend on the work of another team. An example in Gympass are the product teams for the gym and for the end user. The gym team makes a feature that allows the gym manager to create the class schedule, and the team focused on the end user needs to make that class schedule available in the app so that users can view and schedule classes. This coordination is usually done by the PMs of these two teams, but they can benefit from having a third person helping in this coordination. That third person can be a GPM, CPO or even a more senior PM, in this role of Principal Product Manager.

Note that these responsibilities are a subset of the responsibilities of a product head or even a CPO, without responsibility for the management and development of PMs, which can be attractive as a career progression for people who do not want to manage other people. This role is still new. Some companies see this role as just a very senior PM, but I think it makes sense to think about that role with a greater contribution than just a team.

Summing up

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

In the next chapter we will look at one of the main responsibilities of the product head, the creation of the product vision and strategy.

Missing something?

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

Digital Product Management Books

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

Roles, responsibilities, and seniority

In the previous chapter we just reviewed some basic concepts of digital products. Now let’s understand what a head of product is, what its roles and responsibilities are.

As I mentioned in the introduction to the book, the role of the product leader is divided into 3 major areas:

  • product vision and strategy: usually takes around 10% of a head of product’s time. Defining the product vision is defining what the product will look like in the future. What do you want the product to be when it grows? And strategy is the way to reach the vision. Building product vision and strategy is a job that the head of product does in collaboration with the company’s founders, senior management, and the board, with input from all areas of the company and the customer. I will talk more about building vision and strategy in the following chapters.
  • help product managers in their development: depending on the seniority of your team, this will take around 10% to 40%. The more junior and inexperienced, the more time you will have to dedicate to the development of your team. I will talk later about some of the Tools important for the development of your team. 1: 1 meetings, team meetings, evaluation and feedback, product council, product review, and team organization.
  • expectations management: at least half of your time will be devoted to expectations management, reaching up to 80%. In ​​product development and, mainly, when leading digital products, there is no “excessive communication”. There will always be someone who has expectations about the product and is not yet aware of its vision and strategy. With many companies with whom I talk about digital products, I hear a very common complaint that the area of ​​product development is a black box. And that generates a lot of expectations from other areas, which need their product pains to be resolved. On the other hand, the product development team also has expectations, wants to know what the product vision is, what is the strategy, the roadmap, the priorities. The best way to manage these expectations is through communication. As mentioned above, the Tools that will be presented later will be very useful for managing expectations.

Asking people who want to grow in their careers to become head of product why they want this career progression, many answers that they want to be able to have a more active voice and even guide the definition of the product’s vision and strategy. Well, I’m sorry to frustrate you but, as I mentioned earlier, this is only 10% of the work for a product leader.

The other 90% of a product leader’s time is devoted to helping product managers in their development and managing expectations. As I said above, the more junior and inexperienced your team is, the more time you will have to dedicate to the development of your team, which can take up to 40% of your time. On the other hand, if your team is junior and inexperienced, more work will need to be done to manage expectations, which can take up to 80% of your time.

Imagine that you have a junior and inexperienced team, that takes 30% of your time, and that, as a result, you have a lot of expectation management to do, like 70% of your time. That is, 100% of your time will be spent helping your team to develop and managing expectations. Therefore, it is important that you take great care with the seniority of your team, otherwise there will be no time in your day-to-day to take care of the vision and strategy of the product you lead.

Seniority levels

This is a topic that we hear almost daily at all companies: seniority levels. There are many situations in which this topic comes up. Hiring, performance evaluation, increases, promotions, bonuses, etc. The more senior a person is, the more you expect from him. After all, she has experience and knowledge to deal with the most difficult situations at work. My experience has shown me that we need to analyze a person’s seniority based on three dimensions:


We normally assess seniority based on time. For example, if a person has more than 10 years of experience, he is a senior. However, time alone is not enough. If she has done the same thing in these 10 years, without questioning herself and without continually looking to improve and try new things, she has not evolved as a professional. She didn’t put any new tools on her utility belt. Therefore, you will have a lot of difficulty when facing new situations since you do not have the necessary tools.


Therefore, in addition to time, we must also consider knowledge. We can translate knowledge as the set of tools that a professional has in his utility belt. If a person knows only one tool, he will use it to solve all problems. It’s like the law of the hammer, for a hammer, everything looks like a nail. This law is attributed to Abraham Maslow, an American psychologist well known for the pyramid of hierarchy of needs concept.

Maslow’s hammer law

The more tools someone has, the easier it will be to face new situations and find solutions. That is why consultants are so versatile. They work for short periods of time on different clients, facing different problems and need to create ways to solve new problems, since each new client they work for has different problems and contexts.

Sometimes, a consultant with 3 years of experience, working with 6 different clients, will have many more tools in her tool belt than someone who has been with the same company for 10 years. The consultant is likely to be more senior than the person who spent 10 years in the same company, doing the same job and solving the same problems without question and continually seeking to improve, improve and try new things.

To assess someone’s seniority – even when we are self-evaluating our own seniority – we need to look at years of experience and the quality of the knowledge accumulated during those years.

However, this is not enough.


Behavior is a dimension of seniority that is not normally discussed when assessing someone’s seniority, but it is just as important as time and knowledge. Sometimes I have the impression that it is even more important than time and knowledge.

Behavioral seniority means that the person knows how to behave properly:

  • be ethical, be a person with integrity and the right intention;
  • have alignment with the company’s values ​​and culture;
  • have alignment and commitment to the company’s purpose;
  • have alignment and commitment to the company’s strategic objectives.

I will give some examples and counter-examples of behavioral seniority to make the concept clearer:

  • Objectives: all companies have objectives. All companies have quantifiable objectives and targets are set to help achieve those objectives. A well-known method for setting objectives and quantifying results is OKR. Some companies even use these targets to define their employees’ variable compensation, also known as bonus policy. Invariably, once targets are set, things change. And even when everything is stable, it may be necessary to do work unrelated to the targets. Someone with behavioral seniority understands that things change, that their work is not limited to previously agreed targets, and will do whatever is necessary. Someone without behavioral seniority will say that she cannot change or do anything other than what is defined as her target.
  • Complaining: as we all know, sometimes things do not go as we expect. That’s how life is. And there are always people who complain. And it is always someone else’s fault and there are always many excuses to explain why things did not go as we expected. Complaining without doing anything to help resolve the situation is typical behavior for someone who has no behavioral seniority. A senior person, when facing problems, tries to understand what happened, without looking for the culprits. She searches for a solution to the problems and tries to understand how to prevent these problems from occurring again.

I believe that with these two examples and counterexamples, it becomes clearer what I meant by behavioral seniority.

In my opinion, this is the most important dimension of seniority. If you have someone with seniority in knowledge and many years of experience, but without behavioral seniority, she will not only be more likely to perform poorly, but will also interfere with your team’s performance.

What is your seniority?

So, the next time you are assessing someone’s seniority level – including when you are evaluating your own seniority – evaluate years of experience, quality of knowledge accumulated during those years, and behavioral seniority. Only then can you fully assess that person’s seniority level.

Summing up

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

In the next chapter we will understand a little more about the product career.

Missing something?

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

Digital Product Management Books

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

What are digital products and product management?

As I mentioned in my article about The role of the Product VP/Head, I’m writing an entire book about the many different aspects and skills needed to be head of product.

The book will be divided into 3 mains sections, Concepts, Principles and Tools.

I’ll publish its chapters as articles so I can collect feedback. The first chapter is a review of the digital product and product management concepts.

What are digital products and product management?

In this chapter, I will review some basic concepts of product management, concepts that are necessary for the next chapters, where I will define concepts more linked to product development leadership.

Let’s start from the beginning:

Digital Product

Digital product is any software that has users.

A common way to classify digital products is by the type of audience it serves. There are products for end consumers (Netflix, Spotify, etc.) known as B2C (business to consumer), for companies (Locaweb, Conta Azul, SAP, etc.) known as B2B (business to business) and mixed products, which serve both end consumers and companies (Instagram, Mercado Livre, etc.)

Another way to classify a digital product is by looking at how the product is delivered to users (such as online, not online and embedded), or according to what it does: email, e-commerce, payment, email marketing, content management, education, communication, collaboration, reporting, entertainment, operating system, ERP, CRM, etc.

These different ways of classifying are not exclusive. For example, Netflix is ​​a digital product for end-users, but it is also an online entertainment product.

Digital or traditional?

In addition to understanding what a digital product is and how to classify it, we also need to understand the nature of the company that owns this digital product.

  • Digital: The product sold by the company is the software or technology developed by the product development team. Product Management is the company’s “core”, responsible for the company’s future vision and strategy. The product head will have a central role in defining and executing the company’s strategy. Examples: Zendesk, Instagram, Google Search, etc.
  • Traditional: The product sold by the company existed, probably for many years, without the technology, but the company begins to understand how technology can enhance the product. Product Management is an enabler, but it is not core. It is seen as the “digital area”. The head of products will have to gain her space in the company, showing the benefits that technology can bring. Examples: New York Times, Bank of America, American Airlines, etc.
  • Traditional born-digital: The product sold by the company could exist without the technology, but the technology greatly enhances the product. Product management is also an enabler, but it is not core. The head of product will play a very important role in defining and executing the company’s strategy, but it will not be central. Examples: Netflix, Airbnb, Uber, Gympass, etc.


Platforms are products that deliver more value the more users use the platform. It is the famous network effect, based on the number of possible interactions between its users, which is governed by the formula n * (n-1) / 2 where n is the number of users. Platforms have been around for many years in the offline world. A good example is the old markets. They are a two-sided platform, with buyers on one side and sellers on the other. The more sellers you have, the more useful the market is for buyers. And the more buyers you have, the more attractive the market will be for sellers.

There are single-sided platforms (Facebook, Instagram, WhatsApp, etc.) and multi-sided platforms, which can be of 3 types:

  • Exchange: with buyers on one side and sellers on the other side. In this type of platform, it is common for a person to enter on the buyer side and be invited to participate on the seller side. Who has never been invited to drive for Uber? Examples, besides Uber, are Airbnb, eBay, etc.
  • Content: brings together content producers, consumers, and advertisers. Content is the focus and monetization is usually done through ad serving. Examples are Facebook, Google, and news portals.
  • Technical: work as an operating system where, on the one hand, there are specialists and, on the other, users. Android and iOS are a good example, with app developers on one side and users on the other. Xero, an online accounting company from New Zealand, is another good example, on one hand, small business owners and on the other side, accountants.

On platforms, it is customary to develop a product for each platform participant, plus one or more products that take care of the interaction between those participants.

Digital product management

We have already seen the definition of a digital product, the importance of understanding whether the company that owns the product is a digital, traditional, or traditional company that was born digital and we understand what platforms are. Now let’s understand what is product management.

Product Management

Digital product management is the function responsible for all aspects of a software product, throughout the lifecycle of that product, from its conception to the end of its life.

It is the function responsible for making the connection between the company strategy and the problems and needs of customers through the digital product. This should, at the same time, help the company to achieve its strategic objectives while solving problems and meeting the needs of customers.

To know more

There, we have already seen, in a very summarized form, the main concepts of digital product management and we are ready to understand more about how to lead digital products.

In case you want to know more about the concepts I presented above, you can read my book Product management: How to increase the chances of success of your software. In it I talk in detail about these and other concepts related to digital product management, as well as about the life cycle of a software product, the relationship of the product manager with the other areas and functions of the company, product portfolio management, and where use software product management.

Missing something?

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

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 and

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

QA or no QA? That’s NOT the right question…

Back in 2016, I wrote an article about the reasons that motivated us at Locaweb to extinguish the QA function in our product development team. At Locaweb we had 12 QAs, some with a developer profile and others with a SysAdmin profile. In proposing the extinction of the role of QA, some of the QAs became devs while others have taken on the role of sysadmins. The reasons that motivated us to extinguish the QA function at Locaweb are:

  • When there is a QA function separate from the software development function, it is common to hear phrases like “the feature is ready, now it is in the QA phase”, which denotes a waterfall culture. This culture can considerably increase development time and negatively affect the quality of the software.
  • When there is a QA function separate from the software development function, it is also common to hear phrases like “why didn’t QA catch this bug?”, Which denotes a culture of finding the culprits. This culture can be very harmful to the team’s engagement and motivation and, consequently, negatively impact the quality of the software.
  • Quality should not be the concern of one person or one team, it should be the concern of everyone who is working on creating the software.
  • Quality is a non-functional requirement, that is, a requirement that specifies a criterion to assess the operation of a software product, which is different from the functional requirement, which specifies a behavior of the software. Performance, scalability, operability, monitorability are some examples of non-functional software requirements that are just as important as quality. Even so, there are no defined functions for performance assurance, scalability assurance, operability assurance, and monitorability assurance. Why is quality the only non-functional requirement that has a specific dedicated function to ensure it?
  • QA focuses on ensuring the quality of the software development process. If a separate role is needed to ensure this quality, why is there 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, the financial process of a company?
  • There was a concern among devs that, if the dev herself will now have to test, deliveries will take longer to get ready. This concern existed because the devs considered that their work was finished – and the delivery was ready – when they passed the story to the QA to test. However, this dev’s readiness concept is incorrect, as she just passed the story on to the next phase, the testing. From the user’s perspective, the story is only ready when the user can use the new feature. So the time the delivery stays in QA is still dev time, even not being in the dev’s hand anymore. And this time gets even bigger when the story goes through QA but is rejected and has to go back to development.

When I joined Conta Azul, they had also just extinguished the QA role, and the former QAs became business analysts, mainly helping product managers.

I’ve seen other companies also discussing the need for QAs and in some cases a heated debate emerges around this topic. However, having or not having QAs should not be the center of the discussion. Having or not having this role is a solution to a problem, normally stated as “how can we improve the quality of our product?”, and this problem should be the center of the discussion.

How can we improve the quality of our product?

A simple Google search about software quality will yield tons of definitions normally around meeting functional and non-functional requirements. When software does not meet a functional or non-functional requirement, it has a defect, a bug. So, to improve the quality of a software product, we need to work on two things:

  • reducing its existing bugs;
  • not generating new bugs.

A good way to control this is having a weekly measurement of your bug inventory and new bugs per week and discuss this every week with the team. We did this at Gympass. We defined at the beginning of every quarter what’s the target for bug inventory and average new bugs per week.

Image for post

The image above shows the evolution of our bug inventory for Q2 of 2019. We started the quarter with 215 bugs in our inventory and we aimed at a target of less than 166 by the end of the quarter, a decrease of almost 23%. We were able to end the quarter with an inventory of 136 bugs, a 36% decrease. We did this by focusing not only on resolving bugs in our inventory, but also controlling the number of new bugs per week.

Image for post

In Q1 2019 we had an average of 26.2 bugs created per week. During Q2 we reduced this average to 17.4 new bugs per week, to a total of 226 new bugs during the quarter. That’s a 33% decrease in the number of new bugs per week.

This looks like a very good improvement, right? But there’s plenty of room for improvement there. Let me explain the math of bug management:

If we were able to reduce our bug inventory from 215 to 136, this means we solved at least 79 bugs. However, we created 226 new bugs (17.4 new bugs per week x 13 weeks) during the quarter. So we solved 79 + 226 = 305 bugs during the quarter, that’s a lot of bug correction work. If we had generated 90 new bugs during the quarter, an average of 6.9 new bugs per week, instead of the 226 new bugs, we could have zeroed the bug inventory.

An additional aspect of the bug resolution to be measured is the resolution SLA, i.e., how many days the team took to solve a bug from the day the bug was first identified. To do this, we classified the bugs by its severity, which is the impact it causes to the users and to the business. Highest severity bugs are the ones that we need to solve in the same day. High severity bugs in 7 days and medium severity in 14 days. The chart below shows how we were at Gympass in Q4 2019.

Image for post

This is not the ideal visualization because it only shows a picture of the moment, and not an evolution. In order to understand the evolution of any metric, you need to see how it performed in different points in time.

Why quality is so important?

Any user prefers to use a product with good quality, i.e., that behaves as expected. This is front and center to provide a good user experience.

Besides the user experience, there’s also another important aspect to consider when we talk about quality and bugs.

Whenever someone needs to work on solving a bug that was found in a software product, this person needs to stop working on whatever she is currently working to be able to work on the bug. This is an interruption in the workflow. If this person were able to deliver the software without that bug, she could continue to work on new things without interruptions, which will make her more productive.


  • Questioning if a product development should or should not have a dedicated QA team is not the right question.
  • The underlying problem you are trying to solve is how to improve the quality of your product.
  • A good proxy metric for quality is bugs. Bug inventory, new bugs per week and bug resolution SLA.
  • A product development team should have all of its members following these metrics and acting on how to improve them
  • Quality is front and center to provide a good user experience. But it is also key to increase the speed of your product development team. The fewer bugs a team has to fix, the more time it will have to focus on new things.

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

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

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

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

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