Organizing for focus and diversification

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

Organization of a multifunctional product team

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

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

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

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

Attention

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

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

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

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

How to organize big teams?

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

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

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

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

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

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

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

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

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

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

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

About QA (and Front-End and BA)

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

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

What’s the point?

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

QA (and Front-End and BA) at Locaweb

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

About the Front-End Team

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

About the QA Team

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

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

About BA

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

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

Concluding

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

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

Digital Product Management Books

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

No alt text provided for this image

Be the first to like.

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

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

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

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

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

How can we improve the quality of our product?

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

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

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

For instance, say the team started Q2 with 220 bugs in our inventory and we aimed at a target of less than 150 by the end of the quarter, a decrease of almost 31%. Setting targets and discussing it every week helped the team understand and decrease our bug inventory. We do this by focusing not only on resolving bugs in our inventory, but also controlling the number of new bugs per week. In our example, let’s consider that in the previous quarter we had an average of 25 bugs created per week and in Q2 the team was able to reduce the average to 15 new bugs per week and got to the end of the quarter with a bug inventory of 135 bugs, 15 below the target. This looks like a very good improvement, right? But there’s plenty of room for improvement there.

Let me explain the math of bug management:

If the team were able to reduce the bug inventory from 220 to 135, this means the team solved at least 85 bugs. However, during the same quarter the team had an average of 15 new bugs per week, they created 15 new bugs per week x 13 weeks in the quarter totaling 195 bugs. So the team solved 85 + 195 = 280 bugs during the quarter, that’s a lot of bug correction work. If the team had generated 60 new bugs during the quarter, an average of 4.6 new bugs per week, instead of the 195 new bugs, the team could have zeroed the bug inventory.

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

Why quality is so important?

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

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

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

Summary

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

Digital Product Management Books

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

No alt text provided for this image

Be the first to like.

Focus or diversification?

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

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

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

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

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

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

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

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

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

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

So what is the best strategy?

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

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

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

Focus

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

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

Diversification

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

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

How to choose?

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

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

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

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

So a single product company will…

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

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

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

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

Feature lifecycle

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

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

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

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

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

Concluding

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

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

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

Digital Product Management Books

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

No alt text provided for this image

Be the first to like.

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.