The top-down trap

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

Top-down solutions

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

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

The trap

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

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

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

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

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

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

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

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

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

Summing up

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

Digital Product Management Books

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

No alt text provided for this image

Be the first to like.

Problem solver vs solution implementer teams

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

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

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

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

Problem vs solution mindset

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

Any digital product exists for two main purposes:

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

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

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

Problem solver vs solution implementer teams

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

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

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

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

Building problem solver teams

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

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

Summing up

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

Digital Product Management Books

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

No alt text provided for this image

Be the first to like.

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.

RASCI

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

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

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

No alt text provided for this image

How to use?

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

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

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

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

Digital Product Management Books

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

No alt text provided for this image

Be the first to like.

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 NEOU8fittech.fit 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

Be the first to like.

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

Be the first to like.

The role of the Product VP/Head

Being a head of product encompasses many different aspects and skills, and that’s the reason why I’m writing an entire book about this topic. However, since this is a question I get asked frequently, I’ll make a brief introduction to the topic that may be useful for people considering this step in their career as well as for people searching for a head of product for her company.

Expectation management

Whatever the road that got you into the possibility of filling a head of product position, either by you considering this your next career move or by you having the task to find someone to fill this position, it is important to have clear what is the mains responsibility of this role: expectation management. It will be something between 60 to 80% of the head of product time. 

I’ve heard from some product managers that they want to become head of product because they view this position as a great opportunity to have a strong say about or even lead the building of the product vision and strategy, especially if you are in a company which is purely digital or at least a born-digital traditional company. This is true, but I have to say that this is no more than 10% of the head of product job. And even these 10%, it is not a solo endeavor. You’ll have to build it collaboratively with your product’s main stakeholders, especially the company founders who are the first product managers of any company. 

The other 90% of the head of product responsibility is shared between helping product managers in their development – something between 10% to 40%, depending on the seniority of your product managers – and expectation management, which normally takes 50% to 80% of your time. By expectation management, I mean managing the expectation of all of your product stakeholders, internal and external. 

It is important to have this time sharing clear before you decide to accept the head of product role so you understand what other areas and your team will expect from you decide to take the job.

I’ve normally seen people filling out a head of product position coming from three main backgrounds, either she is someone leading engineering, or someone leading product design or marketing, or a product manager that will start to manage other product managers.

CTO/Tech head filling the product head position

If you are a CTO or an engineering leader and were asked to step in as head product, chances are that you were asked to fill this position in addition to your existing responsibilities. I advice against this role superposition. Depending on team size, and your seniority, it’s better to have the product development team with 2 or more leaders, reporting either to the CEO or some other very senior position in the company. If you have up to 30 or 40 people in the product development team, it’s ok to have only one person leading the entire team. More than that, it’s good to split at least between a head of engineering and a head of product. In this product development leadership design, the UX function reports to the head of product. Depending on the size of the product development team and the relevance of design to your product strategy, the team can be lead by heads of engineering, design, and product. Depending on the scope and complexity of your product, you may have more than one head of product, one for each distinct context. For instance, here at Gympass we have Rodrigo Rodrigues as the CTO, Claudio Franco as the head of product for consumers and me as the head of product for companies and partners.

UX/Product design or marketing leader filling the product head position

UX and marketing are 2 areas who are very close to product management. While UX works together with product management in product discovery activities, marketing works together with product management in activities to tell the world about the product and its features and to increase its user base.

As I mentioned previously, UX can report to the head of product. It is a common team design. Both for a UX leader assuming the head of product as well for a marketing lead assuming this position, it is important that the product head understands not only the similarities but also the differences between the two functions and their role and responsibilities in the success of the product.

Product manager filling the product head position

This may be a natural career path for a product manager. As she gets more senior, she may become the go-to-person for other product managers in search for advice. So the 10% to 40% of helping other product managers part of the head of product position may come naturally to her. However, there’s still the 10% of vision building and 50% to 80% of expectation management to be considered. 

The vision building should not also be something new to a senior product manager. She already does that for the product or part of the product she takes care of, so it shouldn’t be something new to her, only a bigger scope. Remember to work on building a high-level vision and let the details be worked on by the product managers. Building the details of a product vision is an important role of product managers. 

The remaining 50% to 80% of time spent in expectation management shouldn’t also be extraneous to the product manager aspiring to become head of product. Actually, she already does that for her own product or part of product that she takes care of. From her team members, to people from other areas, to C-level all the way to the founder of the company. Here again we are talking about an increase of scope. And again we need to let product managers do stakeholder anxiety management as well, so they can develop these skill. But don’t forget that as head of product you’ll be the go-to-person for C-level people and the founders.

If you don’t want to manage other people, that’s fine. It’s always possible to have space in your team for a more senior product manager position. Some companies call it principal product manager. I’ll talk more about this role in a future article.

The first step for a product manager to become a head of product is when she continues to work with her own team (product engineers and designers) and oversees the work of a product manager in another team. One possible name for this new position is group product manager, since she is managing a group of product or parts of a product. As all goes well, the next step is to hire her replacement for the existing role she still plays as product manager. Freed from her daily job of managing a product, she will be able to manage 2 or more product managers.

Leading Product Development: the art and science of leading digital products

Even though I’m talking about digital product development, which is based software engineering, normally considered a science, I do believe there’s a part of art leading product development teams. Asking Google what is art, we get some interesting answers:

  • “the expression or application of human creative skill and imagination, typically in a visual form such as painting or sculpture, producing works to be appreciated primarily for their beauty or emotional power.” To develop a digital product we need creativity and imagination in order to build a product that will empower its users to do something. Empowerment is the process of becoming more cofident, which is an emotional power. And digital products have interfaces with humans, which can be admired. So it’s easy to see the process of building a digital product is a work of art.
  • “a skill at doing a specified thing, typically one acquired through practice.” Building good digital products requires practice, lots of practice.

On the other hand, when asking Google what is science, we also get interesting answers:

  • “the intellectual and practical activity encompassing the systematic study of the structure and behavior of the physical and natural world through observation and experiment.” Many product development teams have been building digital products, sharing their experiences and creating and improving the body of knowledge on how to build digital products.
  • “a systematically organized body of knowledge on a particular subject.” we are building this body of knowledge as we experience new processes and refine existing ones. Digital product development is a brand new science, and there’s a lot we don’t know yet, but we’ve been putting a lot of energy on building this body of knowledge so the next generations of digital product developers can always start one step ahead. This is how all sciences are built, one step at a time, one generation building on the steps of the previous generation.

The book is focused on the head of product role, but it will be useful to anyone within a digital product development team as well as for anyone who is not in this team but works in a company that has, or plans to have, a digital product development team.

The book will be divided into 3 mains sections:

  • Concepts: people who know me, know that I’m a big fan of starting any new endeavor with a ubiquitous language, a term Eric Evans uses in Domain Driven Design for the practice of building up a common, rigorous language between developers and users – in my case, between author and readers. For this reason, I’ll start the book defining some concepts such as roles and responsibilities of a head of product, team structure, career ladder, and Y career for product managers.
  • Principles: every company has its own culture and within each company, every department has its own culture as well. Here I’ll talk about the culture I believe it’s mandatory to create successful digital products. And also, what are the 2 key values that every product development team must have.
  • Tools: here I’ll talk about the tools I’ve been using in my almost 30 years of product development leadership career and passing to other leaders so they can use with their teams. The tools I’ll talk about include vision, strategy, team structure, metrics, and ceremonies. 

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

Be the first to like.

The need for domain experts

Conta Azul is a platform that connects Brazilian small businesses to their accountants and everything they need to run their businesses. It connects small business owners to their bank in order to provide centralized finance control of their businesses. It connects them to the government in order to generate invoices and better control the taxes they need to pay. It connects them to fintechs in order to provide financial services like payments and credit. And it also connects them to many types of systems such as CRMs, e-commerce providers, and niche specific ERPs through it APIs. For the accountants, it provides a CRM so they can manage their customers as well as a cloud-based accounting system, so they can work in the same version of the finance and accounting data their customers are managing.

In order to cope with all the complexity of accounting and tax management, Conta Azul has some Product Managers who are expert in taxes and accounting. Some of the product managers there have a business accounting degree and before joining Conta Azul they worked as accountants and made the career change to product manager at some point in their work life.

Complex domains may require dedicated domain experts

Accounting, finance and tax management are very complex domains. Even though we had at Conta Azul some product managers with expertise or even a degree in those domains, we perceived that’s not enough. We needed someone dedicated to helping us cope with this complexity. And when I mention “we”, I’m not talking only about the product managers, or the product development team, who needed someone to talk to about the complexities of these domains so they can implement it into the product. I’m talking about the entire company. Customer support needed a go-to person to talk about complex issues that the customer brought. The marketing team needed someone to help “translate” the technical wording of accounting, finance and tax management to a more understandable language. Salespeople needed to talk to an expert to understand the complexities and be able to fit customers’ needs and problems into the product they are selling.

For this reason, we created what we called the compliance team, with experts in accounting, finance and tax management. In my view, it makes sense to have this team as close as possible to product managers. This team will serve many areas of the company such as customer support, marketing, and sales, but being closer to the product development team will make it easier for the team to build a product not only more compliant to regulations but also easier to understand and to use. 

Wikipedia brings a good definition of this role:

A subject-matter expert (SME) or domain expert is a person who is an authority in a particular area or topic. The term domain expert is frequently used in expert systems software development, and there the term always refers to the domain other than the software domain. A domain expert is a person with special knowledge or skills in a particular area of endeavor (e.g. an accountant is an expert in the domain of accountancy). The development of accounting software requires knowledge in two different domains: accounting and software. Some of the development workers may be experts in one domain and not the other.

At Conta Azul this team reported into one of our Group Product Managers, who was responsible for leading other product managers, so leading people was not an issue for him. Actually, it was an interesting new challenge, to lead other people that were not product managers. 

Even though I recommend this team reporting the product development team, it is ok the have it reporting to another area in the organization, as long as it stays as close as possible to the product development team.

What types of product may require domain experts?

Recently I talked to some people from companies that also have the need for domain experts. One offers credit to users and the other one offers insurance, both very regulated markets that require dedicated experts to support the entire company to deal with their markets complexity. Other examples are banking, medicine, aviation, law and so on.

Besides being complex, some markets probably are regulated by the government and may be subject to auditing and changes by the governing entity. This only supports the need for a dedicated person or team to help cope with this complexity and constant change. It may be tempting to join the two roles, product manager and domain expert in one person but I recommend not doing this for two reasons. First, it is not easy to find someone who is both a good product manager and a deep expert in a certain domain. The second reason is that each of these roles has a lot to do in their day-to-day jobs.

If you are in a traditional company who is building their digital product, most certainly you already have domain experts in your company. You just need to bring them closer to the product development process.

On the other side, there are markets that are less complex and minimally or not regulated at all. If your digital product is within these markets, normally the product manager can be also the expert in the domain. Some examples are content publishing, advertisement, marketplaces, CRM, etc. Note that I said that the product manager CAN be the domain expert. However, if you believe that your product and the context where your product is used are complex, even being in a non or minimally regulated market, feel free to add domain experts to your team.

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.

No alt text provided for this image

Be the first to like.

More on diversity

I’ve already written about diversity and why it is so important for product development. As a quick summary of that article, there are two main reasons that motivates building diverse product development teams:

  • Diversity brings new points of view. 
  • Just as the customer group that uses your software is diverse, so should your team. 

The second reason was discussed at length in my previous article and in many other articles about diversity on the internet, specially on gender diversity. For this reason, I’d like to go a bit deeper on the first reason.

Perspectives diversity

In my previous article I explained that “having a more diverse product development team brings new insights and new ways of thinking, which will help you develop a better product. It is no wonder that the product development team is made up of software engineers, user experience designers and product managers. Each one has a different perspective of what a good product is and these differences are what help create a better product, when the differences are well worked out by the team.”

Sometime ago I heard the following phrase:

The fact that two people disagree doesn’t necessarily mean that one of them is wrong.

It really made me thing on diversity of perspectives. This has to do with empathy, one of the 7 essential characteristics of a product manager. Empathy is the ability someone has to walk on someone else’s shoes in order to understand her aspirations, motivations, needs and problems. What is her context? How does she see and hear things? What makes her understand things in that perspective?

There’s a nice tool called empathy map that has the purpose to help teams gain a deeper insight into their customers. 

No alt text provided for this image

People have different backgrounds, different histories, different knowledge. We must recognize and respect these differences and understand that sometimes we won’t get to an agreement, but that is ok, as long as we respect each others perspective. Maybe we can create a third perspective from the two different ones. Maybe we can decide to try one of them, or both and see and compare the results.

As long as there are respect and empathy, diversity brings lots of good results for everyone.

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

Be the first to like.

Seniority levels

That’s one topic we hear almost daily in every company: seniority levels. There are many situations when this topic arises. Hiring, performance evaluation, raises, promotions, bonus, etc. The more senior and employee, the more you expect from her. After all, she has experience and knowledge to deal with the toughest situations at work. My experience has shown me that we need to analyze seniority based on 3 dimensions:

Time

We normally assess seniority based on time. For instance, if a person has 10+ years of experience, she is senior. However, time alone is not enough. If she did the same thing during those 10 years, without questioning herself and continuously searching to improve, to get better and to try new things, she didn’t evolve as a professional. She didn’t put new tools in her professional tool belt, so she won’t be able to face new situations and use her tools, acquired through her experience, to face the new situations.

Knowledge

So, besides time, we should also consider knowledge. We can translate knowledge as the set of tools a professional has in her tool belt. If a person as only one tool, she will only use that tool to solve all problem. Is like that saying that for a hammer, everything looks like a nail.

No alt text provided for this image

The more tools someone has, the easier it will be to face new situations and find solutions. That’s the reason why consultants are so versatile. They work for short periods of time in different customers, facing different problems and they have to come up with ways to solve new issues since every new customer they work at has different problems and contexts.

Sometimes, a consultant with 3 years of experience, working in 6 different customers, will have much more tools in her tool belt than someone that stayed in the same company for 10 years. The consultant will most probably be more senior than the person who stayed for 10 years at the same company, doing the same job and solving the same problems without questioning herself and continuously searching to improve, to get better and to try new things.

In order to evaluate someone’s seniority – including when we are self-evaluating our own seniority – we need to look into years of experience and the quality of the knowledge accumulated during those years. However, that’s not enough.

Behavior

Behavior is one dimension of seniority that is normally not discussed when we are evaluating someone’s seniority, but it is 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 appropriately:

  1. being ethical, being a person of integrity and having the right intent;
  2. having alignment with company’s core values and culture;
  3. having alignment and commitment to the company’s purpose;
  4. having alignment and commitment with the company’s strategic objectives.

I’ll give some examples and counterexamples of behavioral seniority to make the concept clearer:

  • Targets: all companies have targets. All companies have objectives that are quantified and targets are defined to help hit these objectives. A very well known method to set objectives and quantify the results is the OKR. Some companies even use these targets to set the variable remuneration of their employees, a.k.a, bonus policy. Invariably after targets are set, thing changes. And even when all is stable, there may be a need to do work not related to the target. Someone with behavioral seniority understands that things change and that her work is not limited to the targets previously agreed on and will do what’s needed. Someone without behavioral seniority will say that she can’t change or do anything else beyond what’s defined as her target.
  • Whining: as we all know, things go bad sometimes. This is the way life is. And there’s always some people who complain. And the fault is always someone’s else and there’s always lots of excuses to explain why things do bad. Complaining without doing anything to help solve the situation is a typical behaviour of someone who lackw behavioral seniority. A senior person when faces things going bad, try to understand what happened, without looking for culprits, try to fix it and to understand how to prevent the issue to happen again.

Hopefully, with those two examples and counterexamples, it is clearer what behavioral seniority means.

In my view, this is the most important dimension of seniority. If you have someone with knowledge seniority and many years of experience, but lacking behavioral seniority, not only she will have greater chances of being a bad performer, but she will also mess with her team’s performance.

Seniority levels

So next time you are evaluating someone’s seniority level – including when you are self-evaluating your own seniority – you need to look into years of experience, the quality of the knowledge accumulated during those years and behavioral seniority. Only then you’ll be able to fully assess the seniority level.

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

Be the first to like.

Mentoring

Few weeks ago Débora Alcântara asked entrepreneurs here at Linkedin what person would they choose as a mentor if they could pick anyone in the world. I was flattered to be cited among mentors such as Bill Gates, Oprah Winfrey, Simon Sinek, Walt Disney and Luiza Helena Trajano.

People who know me knows that I like terms clearly defined, so here’s the Wikipedia definition of mentoring:

Mentoring is a process for the informal transmission of knowledge, social capital, and the psychosocial support perceived by the recipient as relevant to work, career, or professional development; mentoring entails informal communication, usually face-to-face and during a sustained period of time, between a person who is perceived to have greater relevant knowledge, wisdom, or experience (the mentor) and a person who is perceived to have less (the protégé or the mentee)”.

From the above definition it’s clear the unidirectional nature of mentoring, i.e., knowledge flows from “the mentor” to “the mentee”.

I’ve been providing and receiving mentorship during my entire career. Even when I was a student I provided and received mentorship. I guess one receives mentorship since she is born. Since the beginning of my career I had the opportunity to provide mentorship to the people I lead and most recently I’ve been asked to mentor entrepreneurs and product managers to help them in the next steps of their endeavours. It makes me very happy to know that I can be of help to someone by sharing my experience.

However, my mentoring experience have shown me that Wikipedia’s definition is somewhat incomplete. Wikipedia defines mentoring as transmission of knowledge. My understanding is that mentoring is more than a transmission of knowledge. Mentorship is an exchange of knowledge. Even considering that one of the people involved in the mentoring process is more experienced in a certain aspect, topic or area, the other person may be experienced and knowledgeable in other related aspect, topic or area that can bring new insights. Or the other person may use her newness to the theme being mentored to bring a new aspect to light that the mentor didn’t notice.

So next time you are in a mentoring situation, especially if you are in a mentor position, think about it as an exchange of knowledge, social capital, and psychosocial support relevant, useful, and valuable both to mentee and mentor. I have the impression you’ll enjoy even more your next mentoring session.

Digital Product Management Books

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

No alt text provided for this image

Be the first to like.