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

What about the other areas?

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


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

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

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

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

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

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

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

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

Customer support

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

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

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


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

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

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


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

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

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

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


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

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

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

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

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

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

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

Human Resources

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

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

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


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

Summing up

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

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

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

Digital Product Management Books

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

No alt text provided for this image

Product management in a crisis

I was writing a series of articles about the relationship between product management and the other areas of the company. I already wrote about:

I still have a couple of articles to write in this series, but I want to pause and write about the impact of a crisis on product management and digital product development. It not only seems to be good timing, but I also wanted to share some real-life examples I’m experiencing at Gympass.

COVID-19 crisis

Now we are facing COVID-19 crisis. Another crisis as many others, but this one with a huge impact on people’s daily lives. To help remember, here’s Wikipedia’s list of economic crisis and a list of health crisis, including the Spanish Flu that happened more than 100 years ago with 500 million people infected – about a quarter of the world’s population at the time.

Crises have a big impact on business. In a crisis, people and companies spend less, demand for certain types of products and services plummet and, depending on the crisis, some companies may even have to cease operations altogether.

That’s what’s happening now, people have to stay at their homes due to social distancing and many businesses need to stop or to change the way they operate. Some can’t remain open like barbershops, gyms, dance houses and others that require close contact, while other can operate only by delivery, like markets and restaurants.

Product management in a crisis

In a 2016 article, I explained that product management “is the function responsible for making the connection between the company strategy and the problems and needs of clients using the digital product. It must be, at the same time, helping the company to accomplish its strategic goals, and solving the problems and needs of clients.

In a crisis, what is the company strategy? What are its strategic goals? First thing is to preserve cash. As people say, “cash is king”. Good times or bad times, a company needs cash to pay wages to workers for the labor, pay suppliers for the supply and pay its tax debts.

In order to continue to receive more cash, the company needs to be solving a problem or addressing a need of its clients. In a crisis, the client’s problems and needs will probably change considerably. The company needs to identify and adapt to these changes as fast as possible.

When COVID-19 crisis hit the market, companies started to look into these two perspectives:

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

For the first measure, to preserve cash, all the usual suspects apply to many companies. Preserve or even advance revenue streams while looking into all costs with a magnifying glass.

On the revenue side, some companies, like travel agencies, offered to exchange existing travel booking for future bookings with an increased value. For instance, if you have a trip scheduled for March or April, some companies are offering that you can rebook it late for the same amount, or even for a bigger amount, say 120% of the amount you paid. Some companies are offering special discounts if you pay in advance, like a barbershop that are offering discounted prices if you book a dye hair session for July.

On the cost side, some companies are realizing some costs while keeping the offices closed, but that may not be enough. Unfortunately, that may not be enough and some companies may have to lay off part of their employees. Very sad situation but many times it’s unavailable.

The role of the product manager

The interesting side comes when the company focuses on identifying and adapting to changes in customer problems and needs. That’s the main role of the product manager.

With COVID-19, customer problems and needs changed really fast, and the product manager and the entire product development team (product managers, UX, and engineers) have to be even faster in order to adapt the product to these new needs.

I just heard about an interesting offline example. A pizza house added to its product portfolio a new type of pizza, the do-it-yourself pizza. They send the pizza disk pre-baked plus the sauce and all ingredients separately to your home, so you enjoy the pleasure of building and baking the pizza yourself.

Street stores are having to adapt themselves to e-commerce way faster than they were planning since now all buyers are at home and don’t visit stores.

Schools and art event coordinators now are adapting to e-learning and event live streaming.

Real-life example

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

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

So all 3 of our customers, gyms, user and corporate clients, had huge changes in their problems and needs and we had to be very fast to adapt to those changes.

At the end of 2019, after some product discovery work, we decided to explore the idea of offering to our users wellness services beyond access to gyms and studios.

Our first challenge was to find partners who were willing to test this new concept with us. We were able to partner with and Zen App. Thank you, partners! \o/

We built a pilot to be launched early March to a very limited audience to test real user interest in this offer. The pilot was a very simple order form, where we presented the value proposition of Gympass Wellness, the name we gave to this new service, and a place for the user to register and to put their credit card info.

We had just launched the pilot internally (eat your dog food!) when the COVID-19 crisis arrived. We were able to adapt in record time our pilot to be offered to our entire user base so they can not only remain active but also take care of their nutrition and their minds during these very challenging times.

With Gympass Wellness we were able to address both users and our corporate clients’ changing problems and needs during the crisis.

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

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

As I mentioned, all these solutions were implemented in record time, which was needed to provide solutions as fast as possible.

Perfect is the enemy of good

As mentioned earlier, when a crisis hit the market, companies need to look into these two perspectives:

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

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

In order to identify and adapt to these changes in customer problems and needs, the product development team needs to change its behavior with the rule in mind that “perfect is the enemy of good”. In all moments of product development, this rule is valid. The most important thing is to have your product in front of real users in their own context so the product development team can deliver value to their users as fast as possible and can learn from real users using their product.

However, in a crisis, this rule is even more critical and key. We need to deliver solutions to our users’ changing problems super fast. It doesn’t matter if we didn’t do the best discovery process, or that the solution is a very simple web form that we will have tons of manual work afterward, or that the solution will generate many technical debts. The main thing is that we are able to deliver a solution to the new problems and needs that our users are facing in a crisis.

That’s the role of the product manager and the product development team in a crisis.

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

What is the difference between project management and product management?

In this series of articles where I write about the relationship between product management and the other areas of the company, I wrote about:

Now I want to write about the relationship between project management and product management.

As with the functions of product marketing and product management which, as we saw in the previous article, are quite distinct but overlapping, project management and product management functions are also quite distinct, but they also have a lot in common.

Before talking about the difference between these functions, we need to make clear the difference between project and product. I will turn to Wikipedia once again:


A project in business and science is usually defined as a collaborative venture, often involving research or design, that is carefully designed to achieve a particular goal.

Source: Wikipedia


The term product is defined as “something produced by work or effort” or as “the result of an act or process” and has its origin in the Latin verb produce(re), ‘make exist’.

Source: Wikipedia

  That is, while the project is a process with a beginning, middle, and end; product is the result of a process.

So, managing projects and products are two distinct functions?

Yes. While one manages a project, her concern is with the process and everything that surrounds it, i.e., if it is on time, has everything that is needed and is being done with the expected quality.

On the other hand, when building a product, the main concern is to ensure that it solves a problem of the customer to whom it is intended, and meets the company’s objectives.

In a 2007 article at How To Be A Good Product Manager, author Jeff Lash recalls some important points to keep in mind when thinking about project management and product management:

  1. Just as every product needs a product manager, every project needs a project manager.
  2. The fact that product managers believe they are capable of managing their own projects does not mean that they should manage their own projects.
  3. The skills, talents, and knowledge involved in project management are very different from those involved in product management.
  4. Just as it is difficult to find a person capable of doing product management and product marketing at the same time very well, it is difficult to find a person capable of doing product management and project management at the same time.
  5. Project management is not a step in the product management career, nor is product management a step in the project management career.
  6. Good project managers are as valuable as good product managers.
  7. Having a good project manager to manage your projects will help you be a better product manager.
  8. The less time a product manager spends managing projects, the more time she spends managing the product.
  9. To avoid conflicts between project management and product management, project managers, product managers, and the entire team involved in the project should agree on the goals shared by the team as much as possible.

Marty Cagan makes clear the need to separate these roles in one of his posts:

“For internet companies, it’s really important that the roles are separated. You’ll have trouble managing your releases if you don’t separate those roles, and your releases will always be late and longer than they should be.”

And how do agile methodologies view these functions?

Agile methodologies, specifically Scrum, have two clear roles in the team: one more focused on the project, the Scrum Master; and another one more product-focused, the product owner (PO):

  • Product Owner: the person responsible for maintaining the product backlog, which represents the interests of stakeholders.
  • Scrum Master: the person responsible for the Scrum process, ensuring that it is used correctly and maximizing its benefits.
  • Team: Multifunctional group of people responsible for managing themselves to develop the product.
  • Scrum Team: Product Owner, Scrum Master and the Team.

There is an article on InfoQ written by Mark Levison in 2008 entitled Can Product Owner and Scrum Master be Combined? – where the theme of having a single person managing project and product is discussed. Both in the opinions that make up the text – and include testimonials from people like Mike Cohn and Ken Schwaber – as in the comments made by readers of the article, it is unanimous that, although it is possible to combine the two roles – and if the team is very small, it is even acceptable – the most recommended is that they are performed by different people.

And in real life?

All the reports seen are based on actual facts, but we know that each company has its own reality and context. So, what is better to do: leave these roles separate or combined?

Ideally, you should experiment and at some point you will find a combination that suits you, the team you work with, and your business. Note that each group of people has its own dynamics, and what works in one group of people may not work for another.

At Locaweb, we have several teams developing different products, and each one has its own dynamics where the product manager assumes different responsibilities with respect to the team. In some, the responsibility for technical project management tasks – that is, taking care of product development, deployment and operation issues – is handled by a project manager, while at other times this responsibility is shared between the engineering leader and product manager.

On the other hand, in all teams, the product manager plays the role of project manager for all non-technical tasks. That is, she coordinates with the marketing team product communication, coordinates with legal and finance areas the product’s legal and tax requirements, supports marketing in training for sales teams and takes care of passing knowledge to the customer support team.

You must find a balance that makes sense to you, your team, and the company you work for. Be careful not to absorb all project management responsibilities. Try to share them with someone, especially the technical issues; otherwise, there will be no time left for you to manage your product.

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

Product marketing and product management

In this series of articles where I write about the relationship between product management and the other areas of the company, I wrote about:

Now I want to write about the relationship between product marketing and product management.

What is the difference between product marketing and product management?

Outside the technology and software industry, it is common to find the product marketing function as one of the product management functions. That is, product management is seen as part of marketing, so much so that the term product management in Wikipedia says:

Product Management on Wikipedia

Product management is a function of a company’s organizational life cycle that deals with planning, budgeting, and disseminating a product or set of products at all stages of that product’s life cycle. This role is comprised of two roles, product development and product marketing, which are different but complementary efforts to maximize revenue, market share, and margins. The product manager is usually responsible for analyzing market conditions and defining the functionality of a product.

In the technology and software industry, especially in the digital product industry, these functions, while still closely linked, are usually separate. Product management is responsible for product definition and development, along with the UX and engineering teams, while product marketing is responsible for telling the world about this product.

Product Management

In order to define in detail the product or feature to be developed, the product manager needs to know the users of their product, their problems and needs very well. With this information in hand, she can tell in detail how it should be. With the help of an interaction designer, they can draw what it will look like, and how it will solve the problem or meet the needs of users.

One can imagine that, throughout the process of defining and building the product, many decisions will have to be made by the product manager, who is responsible for making them always think about what is best for their user, making them reach their needs and goals with that product, and also for the company that owns the product, which also has its goals. The product is a way for the company to achieve these goals, as explained in the article about what is a roadmap.

Product Marketing

In order to tell the world about the product, the product marketing person must also know its users, their problems and needs. This knowledge is critical to help the marketing manager define the content and shape of his product message.

Another important element to help define this message is the knowledge of the market where the product is inserted, ie, which competitors have similar products, and who has products that, even if not similar to yours, can replace it. What are the differences of your product in relation to these others? Why should your users choose your product, not the competitors one? These are the issues that the product marketing has to worry about.

Product Marketing and Product Management

Although the functions are quite distinct, there are many areas of contact and even much overlap. In 1960, Edmund Jerome McCarthy, a marketing professor at Michigan State University, proposed the concept of Marketing Mix, popularized by Philip Kotler, which is a set of tools used by the marketing function, with the famous 4 Ps:

  1. Product: refers to the product itself and how it solves a problem or meets a need for a set of people.
  2. Price: at what price this product will be sold. Here we are not talking only about the list price, but also promotional launch price, discount for resellers and so on. Ie, all pricing and pricing conditions for the product.
  3. Promotion: how are we going to tell the world about this product, and how it is able to solve the problem or meet the needs of a set of people. When we think about promotion, the first tool that comes to our minds is advertisement. However, there many other tools like webinars, events, and even naming. The name of the product, or feature, is a very important promotion tool, especially when we think that people search for products in search engines.
  4. Place: where this product will be made available and sold. Through web? Only through sales team? Resellers? A combination of the 3 options? Embedded in someone else’s product?

The product is clearly the responsibility of the product manager, but that does not mean that the marketing manager cannot follow the process of its development. By the way, following this process will give your product marketing many important elements to help her tell the world about it.

In some companies, the product manager is responsible for pricing, but usually, this definition, as well as the definition of pricing conditions, is the responsibility of product marketing. They should work closely with the product manager on these settings, as she has a lot of information that can help, which includes not only pricing but also whether there are more expensive or cheaper versions or even additional paid features. Knowledge of the customer and how much he values the solution to his problem, or the fulfillment of his needs, is essential for defining pricing conditions.

Defining the form and content of product communication, which also includes defining the name, is the responsibility of product marketing, as is the definition of sales channels, ie where the product will be sold: via the web, by the sales force, by sales channels, or a combination of these 3 ways.

Thus, using the 4 Ps of Marketing Mix, we could illustrate this division of responsibilities as follows:

No alt text provided for this image

Shared Metrics

I’ve talked a lot about metrics in many articles. All metrics discussed will be shared between the product manager and product marketer.

The product manager should have a strong focus on product usage metrics such as NPS, churn, and engagement. Marketing will focus more on revenue metrics such as CAC, LTV, revenue, and new sales. The important thing to know is that the product manager and product marketing have different focuses, but the metrics are shared. That is, product marketing must also monitor and care about engagement metrics, just as the product manager must monitor and care about revenue metrics.


As seen throughout this article, product marketing, and product management are very distinct functions, being the first responsible for defining how the product will be commercially offered and telling the world about it, while the second has a responsibility to define in detail what the product will be. Although they are quite distinct, they must work very closely together, because the work of one is the input of the work of the other (and vice versa).

As I commented throughout the book, the product *core team* is a multidisciplinary team, containing the trio of product manager roles, UX people and engineers. At Locaweb, we added a fourth element to this team: product marketers, so that they participate in the process of developing their inputs, and take some of the elements that will be useful in doing their job of communicating to the world about him. 

Upon entering ContaAzul, I realized that although there was marketing, there was no product marketing and it was easy to see the lack that this function makes in product development. Before we had people playing the role of product marketing, we intended to develop an app for the small business owner to take pictures of his tax documents and send them to his accountant to keep in the company’s accounts.

Each person I spoke to referred to this new product under a different name. File Manager, Document Manager, File Exchange were some of the names I heard. The name of a product is a communication tool that the product marketing manager has to communicate to the world about his product. A more self-explanatory name helps the customer understand the new product and can greatly improve SEO.

At Gympass we felt the same need and recently hired product marketers that sit together with product managers and help tell the world, external and internal, about new product features.

My recommendation is that you keep these roles separate — that is, having different people taking care of these two roles — but keep them working closely, as a collaboration between them is very beneficial for the product, the team that develops it, and the whole company.

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

UX and product management

I spoke previously about the relationship between Engineering and Product Management.

The next area I want to comment on is the UX area which, along with product engineering and product management, forms the core product development team.

What is UX?

Here’s a good definition of UX from Nielsen Norman Group:

User experience encompasses all aspects of end-user interaction with the company, its services, and its products.

This is a fairly simple definition, but it does cover all aspects of UX. Software developers tend to think that UX is the interface of the digital product, both from the point of view of planning user interaction with the product and from a visual point of view. Yes, UX is that, but not only that. UX is also concerned about what this product causes for those who use it.

According to ISO 9241-210, entitled Ergonomics of Human-System Interaction, which provides guidance on human-system interaction throughout the life cycle of interactive systems:

User experience is “a person’s perceptions and responses that result from the use or anticipated use of a product, system or service.” According to the ISO definition, user experience includes all user emotions, beliefs, preferences, perceptions, physical and psychological responses, behaviors and achievements that occur before, during and after use. ISO also lists three factors that influence the user experience: the system, the user, and the context of use.

UX in the Product Development Process

In the product development process, UX is responsible for thoroughly understanding the user and the problem to be solved for that user. The following figure illustrates well the role of UX as well as product engineering and product management in the development process.

No alt text provided for this image

In product discovery, UX has a central role. The first step is to understand the user, the person who will use the digital product. For this, UX uses a tool called persona, which represents a group of users with similar behavior patterns, attitudes and motivations in terms of purchasing decision, use of technologies or products, lifestyle, etc.

Personas are used to:

  • Know and understand customers and users of products and services;
  • Bring the user to the project focus;
  • Make design decisions more humane and less abstract.

The following figure shows how to build a persona:

No alt text provided for this image

The first step is to define a name and some characteristics of this persona. This helps in conversations about the product. In the name, it is cool to give a hint of the main characteristic of the persona. For instance, Maria, the cool girl or Michelle, the busy woman.

If you are making a product for Michelle, the busy woman and want to insert a new feature, the question is: “Can Michelle, the busy woman be able to use this feature? Will she find it useful enough to find time to learn how to use it.?” In addition to the name and basic characteristics, it is also important to describe the behaviors and problems. The following examples will clarify the concept of persona.

No alt text provided for this image
No alt text provided for this image

Maria, the cool girl is one of the personas we used at Locaweb. Given the different products we had in our portfolio, we ended up building eight personas. However, for each product in our portfolio, we have about 3 or at most 4 personas, one of which is the primary product persona, that is, for whom all your software product decisions are made.

Then, based on a lot of research to fully understand the problems and needs of these personas, UX builds the prototype that will begin to materialize the product idea. This prototype should be used in conversations with customers and users to validate if the idea makes sense, as well as conversations with the product engineering team so that they can already understand what lies ahead and whether technology is available to do so.

It is very different to hear a product or feature description. For example: imagine someone telling you that “you will see a screen with login and password, and an enter button. You will also see a link if you have forgotten your password”. It’s not easy to picture this without a real image. The first version can be a paper or whiteboard drawing:

No alt text provided for this image
No alt text provided for this image
No alt text provided for this image

The prototype is also very important as a communication tool with product engineering. Showing the prototype makes it easier for engineers to evaluate the difficulty of implementing each feature.

When I made ContaCal, as my drawing skills are not the best, I chose to use PowerPoint as my tool for drawing the prototype:

No alt text provided for this image
No alt text provided for this image
No alt text provided for this image
No alt text provided for this image

Once the basic features are agreed upon, this prototype can be made on a computer. The first version of the prototype made on the computer is usually only in black and white, with only the contours of the elements, and no images. This version is often called wireframe:

No alt text provided for this image
No alt text provided for this image

The next step is the UX team preparing a usable prototype (or wireframe), that is, one that already has the interacting behavior for you (product manager and UX analyst) to show customers and users so that they can test and interact. Next, the UX visual designer begins to put color and shape on these screens to make them the version the users will actually see.

With a prototype in hand, usability testing can be done to identify usability issues or validate interface solutions. To do this test, users are invited to perform certain tasks on the prototype. During the test, you can observe user behavior when performing a set of proposed tasks, and identify the difficulties and motivations behind some of their decisions when interacting with the product. The user is encouraged to verbalize his actions, opinions and feelings so that we know the mental model created by him.

This prototype will guide the engineering team in developing the product. It is the specification of the product, but remember that it is not written in stone. For this reason, the UX team doesn’t deliver the prototype to you and the engineering team, and then they go do something else. The UX person who designed the prototype should continue with the product manager and engineering team as it is being built to adjust the prototype (if necessary), discover improvements, and bring the engineering team closer to the user’s needs.

What else do UX people do?

Another point where UX people actively participate is in defining and tracking metrics. As I said in the What is a roadmap? article, every item in a roadmap must have its motivation and its metric. The UX designer should know very well what this motivation is when she designs the prototype and should work closely with the product manager and engineering team to define which metrics to follow to measure if the motivation has been hit.

The UX person also talks a lot with the user. She will be your primary companion in these conversations and interactions with the user, and will always be focused on what is best for the user. Your role will always be to bring the rest of the context, that is, besides being good for the user, it needs to be good for the company that owns the digital product you are developing.

It must also create interaction patterns. Every time a new feature is developed, you shouldn’t be drawing it from scratch. It is important to have an interaction and design pattern library. At Locaweb, we created Locaweb Style, with our interaction patterns, and published it as open source.

What is the relationship between UX and product management?

As I mentioned in the previous chapter, the fact that the product manager is responsible for defining the product to be made can give the impression that UX reports to product management. This is an incorrect view, and if the areas see it with this reporting structure, the chances of the product failing increase because people who feel subordinate have less commitment to the outcome. UX and product management, as well as software engineering, should be viewed as a team, with no reporting relationship and functioning as collaborating partners to produce the best product possible.

UX will always feather their own nest focusing on the user’s side, and will always want to do what is best for them from both function (interaction) and form (visual) points of view. And that’s good! If the UX team is a good team, they will always be feathering their own nest to make the most perfect product from the user’s point of view, just as the engineering team will be feathering their own nest to the technical side, always proposing to rewrite the product and each feature since they just found a better technical solution. It will be up to the product manager to defend the interests of the company that owns the software and find and proposes a balance between these needs.

Oh, and there’s one more thing!

Like product engineers, some UX designers turn out to be great product managers. It’s important to be able to figure out when a designer is looking for “something else to do” and give him that career choice. At Locaweb we have great product managers who were UX designers. In some cases they ended up becoming product managers of the product of which they were responsible for UX. On the other hand, there are also some UX designers who try product management and don’t like it.

This situation is less common because, unlike the product engineer, the UX designer is normally used to talking a lot with the user and other product-related areas, so product management work is not so foreign to him. Even so, you have to leave the door open for him to be able to become a UX designer again, without prejudice to his career.

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

2 hacks to foster your digital product culture

I’ve been leading product development at Gympass for 1,5 years now. Prior to Gympass I always worked in companies where technology was the main product of the company. In this type of company, digital product culture is part of the organizational culture. However, if you are in a traditional company, or even in a “born-digital traditional company” as I explained in this article, building and maintaining a digital product culture can be quite a challenge.

What is digital product culture?

First, let’s remember what is culture. As I explained in another article:

Culture is a set of premises that have been learned and shared by a group of people while they were solving problems on external adaptation and internal integration. This set of premises works well enough to be considered valid and, consequently, be taught to the new members of the group as the correct way of perceiving, thinking and feeling regarding those problems. (SCHEIN, Edgar. Organizational Culture and Leadership. Jossey-Bass, 2010.)

Digital product teams have two main premises when they build products to meet companies strategic objectives while solving a problem or addressing a need for the company’s clients and users:

  • Release early and often: the early I present my product to its users, the better since I’ll be able to get feedback from real users who will be able to use the product in their own context. I explained the motivations behind release early and often in this article
  • Problem mindset: it’s human nature to solve problems. Whenever we hear about problems we almost immediately jump into solution mode, i.e., searching for solutions. However, if we are able to understand better the problem, the motivation to have the problem solved, the context where the problem occurs, there are good chances that we will be able to find simpler and easier to implement solutions. This was the topic os another article I wrote some time ago.

When traditional company culture clashes with digital product culture, and how to hack this clash

In traditional companies, and even in some digital companies and traditional born-digital companies, the sales team is always talking to prospective customers, understanding their problems and pains and figuring out where the product can be a good solution for these problems and pains. For this reason, new releases from the product development team are almost always not only welcomed but also anticipated. 

As soon as a new release is available, salespeople want to offer it to all new prospects. That happened and still happens a lot here at Gympass. The problem is that, following the release early and often premise of digital product culture, the first versions of a feature or a product is somewhat clunky, either missing functionalities, or mal-functioning in certain use cases, or even both. We need the customer feedback in order to improve the product in future versions. The issue is that if prospective customers decide to become new customers of these early versions, which may not work in certain scenarios and may not offer the best experience, these new customers will probably be quite upset. 

Another issue that happens frequently when we release early and often is customer support complaining that the new feature or product is not working properly and they have to provide assistance. At Conta Azul, the product development team constantly received the complaint from customer support that we constantly launch unfinished features and products, i.e, that we constantly launch half-baked features or products. And they were correct, that’s the natural consequence of release early and often way of work. 

Hack #1: alpha, beta, and go-live terminology

For this reason, I decided to use what I call hack #1 to foster a digital product culture, alpha, beta, and go-live terminology. I started using this terminology to explain in which stage a product or a feature is. In the alpha stage, the product may not work properly. If it’s in alpha, it should be offered only to customers who understand the issues of using a new product and can cope with these issues without bigger burden. So this should be a handful of clients, no more than that. At the beta stage, major issues of the product are fixed, but the errors may still occur and the user experience can and will improve. In this phase, it is possible to offer the product or feature to tens of customers. Then, when all known errors are fixed, and the user experience is working properly, then its time to move the product into the go-live stage, where the product can be offered to all prospects and existing clients. This certainly helps sales and customer support teams understand the release cycle of new features and new products.

The other area where traditional company culture clashes with digital product culture is new feature requests. It’s common to see other areas asking the product development team to implement feature A or B because we need this feature to close a deal, or to not lose that big customer. A common example these days is “we need to implement Apple Pay and Google Pay as a new payment method”. The issue here is that talking about solutions, we lose the focus on the problem that originated that solution. As explained in this article, if we invest more time learning about the problem, the motivation to have the problem solved, and the context where the problem occurs, good chances are that we will be able to find simpler and easier to implement solutions.

Hack #2: problem mindset

For this reason, I decided to use what I call hack #2 to foster a digital product culture, problem mindset. Whenever a new feature request came to the product development team, they should thank the requester for the input and they must always ask for the underlying problem that generated the request. Each and every member of the product development team needs to have this behavior whenever a feature request is received. By practicing this behavior, soon the requests will come not only with a solution but also with a lot of information about the problem. It’s interesting to see this cultural change, but it requires the discipline of the product development team members to always ask for the problem. And when I mention product development team members I’m referring to everyone, not only the product managers but also product designers and engineers.


So here they are, 2 hacks to foster your digital product culture:

  • Hack #1: Alpha, beta and go-live terminology
  • Hack #2: what’s the problem?

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

Projects vs problems

The new year is time for retrospective and planning. What is normally done every quarter by most product development teams is done more intensely during the turn of the year, together with other areas of the company, and for the entire new year. It is the yearly planning process, that normally comes together with the budgeting process. What will we do this year that is just beginning? What are the main projects we will work on during the year?

Even though planning is super important to have clarity about what projects are most important for the new year, this list of projects may make you lose sight of a very important aspect of planning, the “why”.

It’s not uncommon to see the new year planning for a product development team, and even for the entire company, as a list of projects. To help you see your list of projects in a different angle, add 2 columns:

  • one to describe what are the problems you are trying to solve with each project;
  • and another one to describe for whom you are trying to solve this problem.

I already discussed the issues of having a solution-oriented mindset vs a problem-oriented mindset but when it comes to new year planning, this issue gets even more troublesome. The benefits of having clarity about the problems you want to solve and for whom are you planning to solve these problems are:

  • Making sure the problems are aligned with the company’s vision and strategy: when we focus on projects, it is easy to lose sight of the problems we are trying to solve, for whom are we planning to solve these problems and if these problems are the ones that we really need to solve.
  • Defining what problems are more important to solve: prioritizing projects without knowing what problems these projects solve and for whom may make the priorities not aligned with what’s really important for the company. However, to be more effective in bringing the desired result, we should prioritize the problems to be solved and guarantee that the prioritization is aligned with the company’s vision and strategy.
  • Solving more than one problem with the same project: Sometimes you may figure out that you are trying to solve more than one problem with a project, and that may be ok. But you need to know that. Maybe you can have simpler solutions if you treat each problem separately. Maybe not all of them are worth solving at this moment.
  • Checking if projects are the best solutions: when we move our focus from projects to problems and have clear visibility about problems priority, it is easier to check if the projects listed are the best solution for the problem at hand. Sometimes we may be able to find solutions that are easier to implement when we change our focus to understanding the problems.

So grab your list of projects and create these two columns, problems to be solved with each project and for whom the problems will be solved. This will help you focus on the most important things for this new year.

I wish you a happy and problem-oriented 2020!!! \o/

Here’s a list of the most read and commented articles of 2019:

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

What’s the best ratio between Eng, UX, and PM?

There are many articles we can find from different product development teams around the world showing benchmarks of Eng:PM and UX:PM ratios. There’s a recent article from Ken Norton, partner at Google Ventures and formerly head of product management at Google and Yahoo!, where he shares the results of an informal survey he did on Twitter:

“A significant majority of the tweets recommended something in the range of 5-9 engineers for every 1 PM. There were reasons why people recommended going higher or lower, but it seems to be a sweet spot. Thinking back on my own experience, my highest-performing teams also fell within that range.”

“When it comes to designers, I’ve preferred a ratio of 1:1 with PMs for user-facing product surfaces. Product teams work best when the dedicated triad of PM, designer, and tech lead form the core.”

So it seems the general recommendation is 5 to 9 Eng per PM and 1 UX per PM. 

Some real-life numbers

At Gympass we’ve been working to increase the number of engineers per product managers. In our recent efforts, growing the team from 32 to 85 people in 5 months already increased the Eng/PM ratio as well as UX/PM ratio. Our plan is to reach the end of 2019 with almost 200 people in our product development team, with even more engineers per product manager and a better balance between UX designers and product managers.

No alt text provided for this image

All benchmarks are clear when they explain that every product manager should be paired with one UX, especially for customer-facing products. In our case, we have 3 different types of customers (end users, gyms, and corp) what reinforces the need to keep the recommended 1 UX designer per product manager ratio. 

At ContaAzul we already had a good Eng/PM ratio when I joined in Aug/16. However the UX/PM ratio was below market standards. Especially if we take into consideration that one of the 4 core values at ContaAzul is to deliver Wow to customers. For this reason, we worked on increasing the UX designers to product managers ratio so we could increase the Wow delivered to customers.

No alt text provided for this image

At Locaweb many products we built were for software engineers. Web hosting, database hosting, SMTP, cloud and dedicated servers. For this reason, the number of engineers per product manager is bigger than ContaAzul and Gympass. It’s even bigger than the recommended upper limit of 9 engineers per product manager. However, we can see an interesting fact in UX designer per product manager ratio. As seen in Aug/15 numbers, an increased ratio of Eng/PM forces an increase in UX/PM compared to the recommended 1:1 ratio. When we look at Jul/16 numbers, if we add more engineers per product manager, getting to almost 12 Eng/PM, we had to increase the UX/PM to almost 2:1. We had to pair 2 UX designers for every product manager so they can cope with all discovery work that need to be done so engineers can build the right product. Considering engineers as delivery and UX designers and product managers as discovery, that makes me think that we need around one discovery person for every 4 delivery people.

No alt text provided for this image

Share your numbers!

In your company, how many engineers per product managers and UX designers per product managers do you have? Share your numbers in the comments below so we can build more data to help us discuss product development team structure best practices.

Digital Product Management Book

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 book Product Management: How to increase the chances of success of your digital product, based on my almost 30 years of experience in creating and managing digital products.

Product Management book

We can’t stand it, we need to rewrite everything…

This article was originally published in Portuguese in June 2017.

I have heard this phrase several times throughout my career. Software developers know that invariably comes a moment when this kind of discussion comes up, which usually has phrases like: “it’s getting harder and harder to deal with the code”; “if it were to do it from scratch, it would be much faster”; “if we do not rewrite, it will become increasingly slow and dangerous to deal with the code”.

At Locaweb, we had an Email Marketing product for sending and managing email marketing campaigns, which used MongoDB as a database, a nonrelational database known for its ability to store large databases. However, probably because of our limited experience in software development using this type of database and in managing non-relational databases, as the database grew, the system became slower and slower.

So, it was necessary to rewrite the product to use PostgreSQL. We designed this rewrite to be transparent to customers. That is, the client would not be migrated from one database to another, thus avoiding going through a period of unavailability or possible data loss. The rewrite was a success. The entire rewrite process, including putting all existing clients (over 15,000 at the time) into the new database, allowing the MongoDB database to be shut down, took six months, a reasonable time for such an initiative.

However, during these six months, the team delivered nothing new to the customer. No new features. To lessen our customers’ frustration, we decided to hire a third party to build iOS and Android apps on top of existing product APIs. This enabled us to deliver new functionality to our customers while the product team focused on rewriting. If this option did not exist, we would have to find other ways to deliver user value that did not depend on the engineering team.

If you are a software developer, rest assured that if you have not experienced this situation in your career, you surely will. The problem with rewriting software is that by rewriting it, the team stops doing new things for its user, as I showed in the example of Locaweb’s Email Marketing product. From a business standpoint, when software does not evolve, customers see no evolution, may lose interest in using the product and will start looking for better options in the market. Therefore, I would like to make some considerations on the subject.

1) New and better technologies will always appear. In the past, systems were developed with everything in the same code base. Then it was the MVC concept (model, view, controller) separating software code into layers according to their function. More recently, the concept of microservices was created, breaking the application into small, loosely coupled applications, preferably done via APIs and facilitating maintenance. If with every new technology that comes along we are going to rewrite the software, we will certainly do nothing but rewrite software.

2) Software rewriting must have a clear business motivation, ie it must somehow meet the strategic goals of the software owner company as it fulfills a user’s need or solves a customer problem. If there is no clear business motivation, the recommendation is not to rewrite.

3) If rewriting is unavoidable (are you sure?), it is important to think about this rewrite initiative from a business perspective, that is, what is the impact of this rewriting on customers and the software owner. Understanding this is the responsibility of the product manager. Some questions to help you reflect with your team on this impact:

  • What will this rewrite look like?
  • While rewriting is going on, will new features be delivered?
  • How will the new system coexist with the old system?
  • When new features are implemented, will they be implemented on the new system and the old system, or only on the new system?
  • When can new clients be installed on the new system?
  • When will existing customers be migrated to the new system?
  • If there is a proposal to make a synchronizer, so that customer data exists simultaneously on the old system and the new system, what is the cost of this proposal compared to not making this synchronizer?
  • If the difference between the old system and the new system can be perceived by customers, how will this difference be communicated?

There you go, some considerations about software rewriting, a very important topic for any product manager.

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