Measuring and managing quality

In 2015, we decided to extinguish the Quality Assurance (QA) function of our Locaweb product development team. We had 12 QAs, some with a developer profile and others with a SysAdmin profile. In proposing the extinction of the QA role, some of the QAs became devs, while others took on the role of system administrators. The reasons that led us to extinguish Locaweb’s QA function were:

  • When there is a QA function separate from the software development function, it is common to hear phrases like “the functionality is ready, now it is in the QA phase”, which denotes a cascading product development 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 detect this bug?”, Which denotes a culture of finding the culprits. This culture can be very detrimental to the engagement and motivation of the team and, consequently, negatively impact the quality of the software.
  • Quality should not be the concern of a person or team, it should be the concern of everyone working on creating the software.
  • Quality is a non-functional requirement, that is, it specifies a criterion to evaluate the functioning of a digital product, while a functional requirement 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 to guarantee performance, guarantee scalability, guarantee operability and guarantee monitorability. Why is quality the only non-functional requirement that has a specific dedicated function to guarantee it?
  • Quality control focuses on ensuring the quality of the software development process. If a separate function is needed to guarantee this quality, why is there no need for a separate function to guarantee the quality of the product management process, the design process, the product marketing process, the sales process, the finance processof a company?
  • There was a concern that, if the engineer himself now had to test, deliveries would take longer to be ready. This concern existed because the engineers considered that their work was finished – and the delivery was ready – when they passed the story to the QA to test. However, the engineer’s definition of ready is incorrect, as he has just passed the story on to the next phase, the test. From the user’s point of view, the story is only ready when the user can use the new feature. Therefore, the time that the delivery remains in quality control is still development time, even though it is no longer in the hands of the engineer. And that time gets even longer when the story goes through quality control, but it is rejected and needs to go back to engineering.

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

I saw 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 focus of the discussion. Having or not having this function is the solution to a problem, usually referred to as “how can we improve the quality of our product?”, And that problem should be the center of the discussion.

How can we improve the quality of our product?

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

  • reducing existing bugs;
  • not generating new bugs.

A good way to track this is to have a weekly measurement of your bug inventory and new bug creation per week and discuss this every week with the team. We did that at Gympass. We define at the beginning of each quarter what the target is for the bug inventory and the average new bugs per week.

Total amount of bugs at Gympass

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

Number of new bugs detected per week at Gympass

In the first quarter of 2019, we had an average of 26.2 bugs created per week. During the second quarter, we reduced this average to 17.4 new bugs per week, to a total of 226 new bugs during the quarter. This is a 33% reduction in the number of new bugs per week.

That looks like a pretty good improvement, right? But there is a lot of room for improvement there. Let me explain the math of bug management:

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

An additional aspect of the bug resolution to be measured is the SLA (Service Level Agreement) resolution, that is, how many days the team took to resolve a bug from the day the bug was first identified. For this, we classify the bugs by their severity, which is the impact it has on users and the business. The most serious bugs are those that we need to resolve on the same day; high severity errors, in 7 days and average severity, in 14 days. The following chart shows how we were at Gympass in the fourth quarter of 2019.

Gympass bug resolution SLA

This is not the ideal way of viewing this info because it shows only an image of the moment, and not an evolution. To understand the evolution of any metric, you need to see how it did at different points in time.

As soon as I joined Lopes, I started bringing this topic up for discussion with the teams. One of the things we noticed is that 50% of deployed items were bug fixes. I was informed that “these bugs were caught before going into production, which is a good thing”. In fact, it is a good thing that these bugs did not reach the production environment and appeared to our users. However, they reached pre-production and needed to be corrected. Wouldn’t it be better if these errors didn’t even exist, not even in pre-production?

The OKRs we defined to help us with the quality theme were 3 additional KRs in order to Increase the cadence of deploys in production that I mentioned in the previous chapter:

  • KR: Reduce the number of new bugs to 5% in pre-production.
  • KR: Reduce the number of total bugs to 10% in pre-production.
  • KR: Keep the number of total bugs below 5% in production.

And we add the following OKR:

  • Objective: To improve the quality of the deliveries to the squads.
  • KR: Review 100% of new stories to find poorly defined and / or ambiguous requirements.
  • KR: Perform a 25% review of the Pull Requests of the squads.
  • KR: Measure the Pull Requests volume of the squads.

Another example of bug tracking

At Conta Azul, we doubled the product development team in a period of 8 months between November 2017 and July 2018. This growth was aimed at increasing the team’s productive capacity.

Number of deliveries and people per week at Conta Azul

In addition, we divided the quantity of deliveries by the total number of people on the team to assess whether we were managing to increase our productivity individually.

Number of deliveries per person at Conta Azul

However, with the increase of people on the team, it ended up increasing the amount of bugs. So much so that the team that had already had 40% of its deliveries as a bug fix ended up having to increase this proportion to 60%. That is, despite having increased individual and total productivity, this increase in productivity was not being felt by the user, as it ended up being used for bug correction.

Percentage of bug fixes at Conta Azul

To control this problem, we increased our focus on fixing these bugs within the SLAs, which were:

  • 85% of tickets resolved within 7 days
  • 98% of tickets resolved within 30 days
7 day bug fix SLA at Conta Azul
30 day bug fix SLA at Conta Azul

See that the quality has worsened and the customer suffered from it. But, after some time, we managed to return to the defined SLA levels. We looked at this metric weekly and, whenever we discussed this metric, we agreed that the best way to comply with the SLA was not to create bugs!

Quality is not just bug control

In addition to bug control, there are several other aspects that impact the quality of the digital product that we deliver to users. Performance, scalability, operability, monitorability are some examples of non-functional requirements.

When I joined Gympass, on my second Monday the system went down for users around 7 pm. I started asking people on the team what was going on and the answer was that Mondays are peak days in terms of gym visits and that the system could not handle the volume at all. As there was no monitoring, we were not alerted that the volume was higher than usual and we were unable to prepare properly. Two months later, when Rodrigo Rodrigues joined Gympass as CTO, he dubbed the event “Black Mondays”. To address the problem, we started to monitor and implement an infrastructure that could handle Monday peaks. And we set OKRs for uptime, successful HTTP requests and backend response time.

Uptime – Gympass
Successful HTTP requests – Gympass
Backend response times – Gympass

Why is quality so important?

Any user prefers to use a good quality product that behaves as expected. This is a sine qua non condition to provide a good user experience.

In addition to the user experience, there is another important aspect to consider when we talk about quality and bugs. Whenever someone needs to work on resolving a bug that was found in a digital product, that person needs to stop working on whatever they are currently working on in order to resolve the bug. This is an interruption in the workflow. If that person were able to deliver the software without that bug, they could continue to work on new things without interruption, which would make them more productive.

The relationship between productivity and quality

I had the opportunity to participate in an MIT course on how to create high-speed organizations. The course was taught by Professor Steven J. Spear, author of the book The High-Velocity Edge: How Market Leaders Leverage Operational Excellence to Beat the Competition. This is one of those very dense courses, full of content, but which can be summarized in one paragraph:

High-speed organizations are able to learn very quickly, especially with their failures, and to absorb that learning as an integral part of the organization’s knowledge.

A high-speed organization works by following the 4 steps ahead:

  • Be prepared to capture knowledge and encounter problems in your operation.
  • Understand and solve these problems to build new knowledge.
  • Share the new knowledge with the entire organization.
  • Lead to develop skills 1, 2 and 3.

The classic example is Toyota, with lean manufacturing and the concept of stopping production whenever there are failures, correcting them and using them as a learning opportunity so that they no longer happen. This ability to learn from failure is what gives Toyota the ability to stay ahead of its competitors for so long.

Another good example is Alcoa, which had a work incident rate of 2% per year, which was considered normal. Alcoa has more than 40,000 employees, so 2% of work incidents per year means that 800 employees per year have some type of work incident. This is a very impressive and worrying number.

To combat this problem, they implemented a zero error tolerance policy. Before implementing this policy, mistakes were seen as part of the job. Employees are now encouraged to report operational errors within 24 hours, propose solutions within 48 hours and report the solution found to their colleagues to ensure that knowledge spreads throughout the organization.

This caused the risk of incidents to drop from 2% to 0.07% per year! This reduction in the incident rate meant that fewer than 30 employees per year had any work incident problems after the zero error tolerance policy was implemented and Alcoa achieved an increase in productivity and quality similar to that of Toyota.

Fail fast vs. learn fast

An important factor in the Toyota and Alcoa examples is that recognizing and learning from failures must be part of the company’s culture. This is somewhat more common in the culture of technology companies, but not so common in traditional companies. During the MIT course I shared a table with a Brazilian executive from Grupo Globo, the major TV company in Brazil, a Spanish executive from AMC Networks International (Walking Dead, Breaking Bad and Mad Men), a German project manager living in Azerbaijan who works for Swire Pacific Offshore (oil and gas industry) and an MIT postdoctoral student in solar energy from Saudi Arabia.

All of my table mates were from more traditional industries. I was the only one at an internet company. The executives at Globo and AMC were there because they saw Netflix with its streaming video on demand and YouTube with its huge catalog of user-generated videos as major threats, stealing their audience very quickly and they wanted to understand how they could defend themselves.

Although the theme is somewhat obvious for internet companies, especially with the culture of technology startups that value fail fast. That’s what makes Netflix and YouTube a threat to traditional media companies like Grupo Globo and AMC Networks. However, even though this is part of the culture of internet companies, sitting and discussing it with people from more traditional companies was a great opportunity to reflect on the relationship between failure, failure recognition, learning and high speed:

  • Recognizing the flaws and using the flaws as a learning opportunity must be well rooted in the organization’s culture. If people are not careful, as a company grows, it may lose the ability to accept failures as learning opportunities. It is very common for companies, as they grow, to become more and more averse to failure and to create a culture that ultimately encourages people to hide mistakes and failures.
  • Another important aspect of learning from failures is to make this process a company standard. There is no point in failing, acknowledging the error, stating that you will no longer make that mistake and, some time later, making it again. This learning process with failures must be part of the company’s culture. Whenever a fault is identified, learning should happen as quickly as possible to prevent it from happening again. If the same failure happens again, something is broken in the learning process with the failure.
  • Even in Internet companies, I realize that learning from failures is more common in the product development team, as retrospectives and continuous learning are part of the culture of agile software development. In other areas of the company, learning from failures is less common. This ability to systematize learning from failure must permeate the entire company.

Even though we hear a lot about the culture of internet companies to fail fast, talking about failing fast diverts our focus from what is really important, learning fast. We must put our energy into learning, not into failure itself. It is the learning process that makes people and companies evolve. And it is the ability of an organization to learn fast, especially with its failures, that will allow it to move at really high speeds.

Summing up

  • Questioning whether or not product development should have a dedicated QA team is not the right question.
  • The problem you are trying to solve is how to improve the quality of your product.
  • A good quality proxy metric is the bugs. Bug inventory, new bugs per week and bug resolution SLA.
  • A product development team must have all its members following these metrics and taking action to improve them.
  • Managing bugs is not enough to manage the quality of the digital product. Performance, scalability, operability, monitorability are some examples of non-functional requirements that directly impact the quality of the digital product.
  • Quality is at the forefront to provide a good user experience. In addition, it is essential to increase the speed of your product development team. The less bugs a team has to fix, the more time it has to focus on new things.
  • High-speed organizations are able to learn very quickly, especially with their failures, and to absorb that learning as an integral part of the organization’s knowledge.

In the next chapter we’ll see a little more about metrics.

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, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my almost 30 years of experience in creating and managing digital products:

  • Startup Guide: How startups and established companies can create profitable digital products
  • Product Management: How to increase the chances of success of your digital product
  • Leading Product Development: The art and science of managing product teams

Measuring and managing productivity

How can we deliver faster? How can we deliver more with the same team? Why do we have the impression that the team is slow? When the team was smaller, it seemed that it could deliver more. These are very common questions and statements that I hear about product development teams. Every company that has a digital product development team would like this team to be faster. In this chapter, I will show you the two essential tools to achieve faster and more productive teams.

Measurement

There is no way to improve something that is not measured. What is product development speed? It is important to have a clear definition of this metric and have it measured.

In my last year at Locaweb, we were focusing a lot on productivity, that is, on how Locaweb’s product and software development teams could produce more, without having to add more people to the teams, and without dropping quality levels.

The following graph shows our numbers. We count quantities of deliveries per week and, as you can see, in a few weeks we were able to more than quadruple the quantity of deliveries per week.

Amount of deliveries per week at Locaweb in 2016

This increase in productivity happened when the team grew only 10% in number of people, so it is not possible to credit this increase in productivity to the increase in number of people in the teams.

When there is such an increase, in addition to the natural question about whether the increase in productivity is due to the increase in the number of people in the teams, another question that exists is whether there was a drop in the quality of deliveries. One of the quality measurements we had was the number of rollbacks. As you can see below, even with the increase in productivity, the number of rollbacks was reduced by 40%!

Number of rollbacks per week at Locaweb in 2016

At Locaweb we made estimated calculations of deliveries per week from September 2015 to February 2016. The calculation was very simple, total deployments made in the period divided by the number of weeks. We then started to communicate the entire company about the week’s deliveries.

After I arrived at Conta Azul, we decided to implement the same type of control of weekly deliveries and ended up also achieving a good increase in productivity.

Amount of deliveries per week at Conta Azul in 2017

Both at Locaweb and Conta Azul, each product manager sent me the deliveries of the week on Friday, I compiled the data and wrote down the quantity for each week, generating these graphs. From the moment we started measuring, it became clearer the level we were at, and the actions we started to take in order to increase productivity began to show results on the graph. In addition, the teams started to use a single measurement tool, JIRA, which gave them a better view of each team’s progress and allowed comparisons with the exchange of experience, that is, something like “look how interesting your graph is, how did you manage to increase this indicator? ”.

At Gympass, as we scaled the team very quickly, we decided to control the number of deliveries per person per week. We considered people who joined 2 months before since people need 1 to 2 months after they joined Gympass to become productive. In one quarter, we managed to increase our productivity per person by 16%. The number of deliveries was extracted directly from JIRA.

Amount of deliveries per week at Gympass in 2019

At Gympass, we also measure the number of deploys, both in our core, aka monolith, and in microservices. We also achieved a considerable increase in one year.

Number of deploys per week at Gympass in 2019

At Lopes, as soon as a deploy was done, an email was sent with a list of deployed items. One of the first things I did when I joined the company was to compile these reports in a spreadsheet to build the chart below. Hence it was easy to notice that the deploys did not happen every day. They happened once per week on average. As soon as we noticed this, we defined OKRs to increase the frequency of deploys, which has been yielding results. The OKRs we defined were:

  • Objective: Increase the cadence of deploys in production;
  • KR: Increase the number of deploys per week to at least 3 (the more the better);
  • KR: Reduce the maximum number of new features per deploy to a maximum of 10.
Number of deploys per week at Lopes

What impacts productivity

The productivity of a product development team is impacted by several factors. I once found a very interesting article written by Michael Dubakov, founder of the company Targetprocess where he shows a mind map with all the elements that can positively or negatively impact the productivity of a product development team. This article is no longer available, but thanks to the Wayback Machine website (http://web.archive.org), you can access it at:

http://web.archive.org/web/20150827162352/http://www.targetprocess.com/articles/speed-in-software-development/

The mind map is this one:

Number of deploys per week at Lopes

This diagram shows things and activities that affect the speed of development in some way. Green means that the activity increases speed. The more you have, the better. Yellow indicates that there is some maximum. For example, you can accumulate technical debt and increase speed, but if you accumulate too much, it will significantly delay you. Red shows things that slow development, the less you have, the better. The green arrow indicates an increasing effect. For example, focused work increases the speed of development. The red arrow indicates a decreasing effect. For example, better development skills decrease the complexity of the system (good engineers create less complex systems).

What I like about this image is that it shows how complex this theme is and how many things can positively or negatively impact the team’s speed. At Conta Azul, we followed this topic every quarter at the Product Council, a meeting where we talked about the quarterly planning of the product development team with the leadership. There was a slide where we listed all the topics that could impact the speed to discuss what we were doing about each of these topics.

Themes that impact the speed of the Conta Azul product development team

Place the topic of productivity at the center of the discussion

There is no silver bullet, with each team I’ve worked on there were several actions we took and we were always sure that there are always more actions that could be taken to increase productivity even more.

The only silver bullet that exists is we made productivity into an important topic in our conversations. Everyone started talking about productivity and what we could do to improve it.

This movement made us initiate several changes and experiments that helped us to increase our productivity considerably. If you also want to increase the productivity of your product development team, place this topic at the center of your conversations and experiment a lot. You will see how there is room to greatly improve the productivity of your software development team.

Another important point: be sure to discuss the topic of productivity frequently. My recommendation is that you do it weekly. Creating a weekly cadence will give you the opportunity, each week, to experiment with something new and discuss the results with the team.

Summing up

  • There is no silver bullet to increase the productivity of a product development team. However, there are two essential tools to help achieve this goal.
  • The first tool is measurement. There is no way to improve something that is not measured. What is product development speed? It is important to have a clear definition of this metric and its measurement.
  • The second tool is to bring the topic of productivity to the center of the discussion. Everyone on the product development team is responsible for the team’s productivity. Therefore, by bringing the topic to the center of the discussion, everyone will be able to collaborate to improve productivity.

In the next chapter we will see another metric that has a direct impact on productivity, quality.

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, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my almost 30 years of experience in creating and managing digital products:

  • Startup Guide: How startups and established companies can create profitable digital products
  • Product Management: How to increase the chances of success of your digital product
  • Leading Product Development: The art and science of managing product teams

Vision, strategy, objectives, and team structure

This is the beginning of Part III of the book, about Tools, I’ll talk about the tools I’ve been using in my almost 30 years of product development leadership career and passing them to other leaders so they can use them with their teams. The tools I’ll talk about include vision, strategy, objectives, metrics, relationships, hiring, feedback, and ceremonies.

You will notice that the tools that I’ll comment on here are not software such as spreadsheets, presentations, documents, Slack, JIRA, Confluence, etc. These apps are normally very useful, but they are only a vehicle for documentation, communication, and metrification of the tools that we will see in the following chapters.

Vision, strategy, objectives, and team structure

All of these items are, in addition to very important concepts, essential tools for any head of product. In all the opportunities that I started as head of product, these were the first topics that I dealt with, always starting with a product vision and then moving on to the themes of strategy, objectives, and team structure. This is also my first focus when I start any advisory work. I try to understand what’s the vision, strategy, objectives, and team structure. If any of these elements is missing, I help people in the company to create them.

I have already explained what they are and how to create each of these items in their respective part I chapters, so I will just do a quick review of these tools.

Vision

As I explained in the chapter Product vision, to make the product vision, it is necessary to be clear about the company’s objectives with the product, as well as to deeply understand the problems and needs that customers have and that will be solved by the product. The 6 steps to build a product vision are to obtain strategic objectives of the company, gain an understanding of the problems and needs of customers, design the first version of the vision, iterate and refine, communicate and review.

I usually document and communicate the product vision in a presentation. If necessary, I put some theoretical introduction explaining the concepts of platform and marketplace. In every presentation I make, I usually present the product vision as an introductory topic to set the context and to make it clear to everyone.

Strategy and objectives

The product strategy is nothing more than the path you will take to reach your product vision. To create your product strategy you need to have a good understanding of your market, that is, the competitors, the potential and accessible market, the growth of that market, if there are disruptors, and how it is regulated. You also need to understand your strengths and weaknesses, opportunities and threats. A SWOT analysis can help. With this information in hand, you define what you and your team will do to achieve the product vision, what goals you need to achieve, and what metrics will tell you that you are achieving those goals. OKRs are a great tool for working on your goals and metrics.

There are some books and courses talking about how to define and use OKRs. So I’m not going to go into too much detail here. In a very succinct way, you define together with the team some objectives for a period – usually a quarter or a year – and define which metrics you will use to show that the objective is being reached.

I usually document the OKRs in spreadsheets, which I use to follow the evolution every week with leaders of my product development team, and also present and discuss the OKRs with other leaders and areas of the company. The following is an example:

Exemple of an OKR worksheet

Note that every week the KRs are updated. Each team leader updates their KRs with their teams every Monday, and then leaders and heads of product go through the KRs to see how they are doing and if there are any impediments where energy can be put in to remove. I like to do it on Monday because it helps the team organize the work of the week. The weekly cadence is essential to help the team review performance at least weekly and make adjustments if necessary. If the cadence is higher (biweekly or monthly), valuable opportunities to correct problems and remove impediments are lost.

The column T0 indicates the initial value of the metric. The responsible column has the name of the person who is responsible for that KR and who will lead the effort to make it happen. And the support column lists the people or areas that will help the person in charge.

It is worth remembering that the closer to the company objectives and business metrics the OKRs are, the better it will be for the team, as they will be working to help the company with its objectives and results.

Team structure

In the chapter Team Structure I said that product development teams are organized into minimal teams, also called squads, composed of engineers, product designers, and product managers. It is important to keep the team as lean as possible to help your productivity. These minimum teams are grouped into product teams called product tribes.

There are 4 ways to organize product teams: by product or functionality, by type of user, by journey or by objective. You can also use two different types of organization to create a hybrid organization. There are also the structural tribes, which create the necessary structure for the product tribes to perform. Teams that make up the structural tribes are SRE / DevOps, Data, Architecture / Tools / Foundation, Design Ops, Information Security, Internal Systems, Sales Engineering and Professional Services.

To help organize the team, I usually use a simple spreadsheet template like the following:

Example of team structure worksheet

This worksheet contains the team structure and the people who are part of it. Note that we are not documenting functional leadership, but the leadership of each team. In the example, we have John as GPM leader of PM Lucy and PD/UX Patricia, Mary as GPM leader of PD Rafa and Sandra as leader of the structural teams of SRE / IT, Data and Peter, who leads the engineering of 2 squads of the tribe A and tribe B squad.

An important point is that it is not enough to just create these elements and then not use them. These tools are useful the more you use them. I use OKR worksheet at least every week. Whenever I have the opportunity I talk about Vision and strategy. Whenever I talk with my leaders about hiring or changes in the team, I use the team structure spreadsheet I showed above.

Summing up

  • Vision, strategy, objectives and team structure are, in addition to very important concepts, essential tools for any product head.
  • For vision and strategy, a presentation with a few slides is sufficient. For OKR and team structure, spreadsheets do the trick.
  • More important than the software you use to document Vision, strategy, objectives and team structure is what you do with these tools. I use OKR worksheet at least every week. Whenever I have the opportunity I talk about Vision and strategy. Whenever I talk with my leaders about hiring or changes in the team, I use the team structure spreadsheet I showed above.

In the next chapter, we’ll look at how to measure and increase the productivity of a product development team.

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, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my almost 30 years of experience in creating and managing digital products:

  • Startup Guide: How startups and established companies can create profitable digital products
  • Product Management: How to increase the chances of success of your digital product
  • Leading Product Development: The art and science of managing product teams

Ecosystem mindset

This value I learned at Gympass. It was one of the company’s corporate values ​​and, in my opinion, every platform must incorporate this value in its culture. I often came across CEOs and heads of platform products who claimed that they do everything for the customer, that the entire company is customer-centric. However, when I dive deeper in this topic, I end up discovering that the client they were referring to was just one of the actors of their platform and the others were treated only as “necessary evil”.

In the description of the value on the Gympass website it is written:

Ecosystem mindset

We make decisions that create value for our Gympass ecosystem and help us achieve our mission.

The ecosystem mindset example I will describe below is the implementation of the live classes product that Gympass created during the COVID-19 crisis.

Diversifying – and digitizing – a product portfolio

During the COVID-19 pandemic, we diversified – and digitized – our product portfolio in record time. We went from an offline product, access to gyms and studios, to 4 products, 3 of them totally digital, in less than a month:

  • Access to gyms and studios: Access to more than 50,000 gyms and studios in 14 countries;
  • Live classes: for those who like to train in groups or want to relive the feeling of the class with colleagues at the gym;
  • Personal trainers: for those who prefer a more personalized approach and like to exercise in their own time;
  • Gympass Wellness: app package with over 60 apps for those looking for options to improve physical and mental well-being (from nutrition to therapy session).

Below I explain how we did it.

Product Vision

When I joined Gympass in mid-2018, one of the first things I did was to build a product vision. We had a very strong purpose: to defeat inactivity. However, to build a digital product, we need more than a purpose.

Gympass product vision

This vision guided the definition of the Gympass product development organization. As I commented in the chapter Team structure, we set up teams around each of the marketplace participants, in addition to a central team that worked in the payment flow collecting the payment from the companies and their employees, doing all the calculations, and determining the amount to be paid to each gym partner.

When I was building this product vision and discussing it with different people in the organization, it was easy to see many opportunities to expand that marketplace. There are a lot of new service categories that we could add to our marketplace:

Gympass expansion opportunitties

There are 3 types of elements in a market:

  • Supply: goods or services available for consumption.
  • Demand: people or companies that may need goods or services offered by the supplier.
  • Market: where demand meets supply and a transaction occurs.

These three elements are related as follows:

  • Value delivery: the market adds value to demand and supply. The value delivered to the supply is people or companies interested in their goods or services. The value delivered to demand is a varied number of suppliers of goods and services.
  • Payment: To have access to goods and services offered by suppliers, demand pays the market and the market pays for the supply. The market typically retains a fee per transaction. This fee can be fixed or a percentage of the payment.
Dynamics of a marketplace

Given the dynamics above, we can expand a market as follows:

  • Diversification of demand: you can offer goods and services from your marketplace to new segments and geographic regions.
  • Supply diversification: you can offer new goods and services to your demand.
  • Delivery of new value: you can offer new value to your supply and demand.
  • Financial payment management: as the demand payment to the supply passes through the marketplace, you can offer financial services for both demand and supply, such as advance payment and credit, and you can manage the spread.
Marketplace expansion opportunities

However, we had a lot to do with our main product at that time, so we didn’t have enough energy to focus on expanding our marketplace and left the plans in the drawer.

New endeavor

In October 2019, we reached a point where our product development team was well structured and working properly to address our challenges in our core product, so we decided to focus on expanding our marketplace.

We decided to work on an idea called “Gympass end-user partnership hub”. The plan was to partner with wellness apps and provide them to our users.

This new idea had two main hypotheses that we needed to test:

  • Application providers willingness to partner. Application providers, like gyms, are used to the recurring monthly revenue model. Would they accept to be paid per day of use?
  • Our user base willingness to pay. Is our user base interested in paying a monthly fee to access the applications?

To test our first hypothesis, we built a deck with the value proposition that we planned to deliver to the partners and talked to some potential partners. We presented the opportunity to 8 potential partners, of whom 6 showed interest and 4 decided to join our proof of concept. NEOU, a workout app, 8fit, a workout and nutrition app, Tecnonutri, a nutrition app and ZenApp a meditation app.

Okay, our first hypothesis was validated and we needed to validate the second hypothesis, the willingness to pay. Is our user willing to pay to access these applications through Gympass?

To test our second hypothesis, we built a simple form, where we described the product and asked for name, email and company. After the user provided this information, he was directed to a Paypal subscription page, where he had to provide his credit card details to subscribe to the service. The user would receive an email with the activation link for each application. There was no real product, no logged in area, just a form to test interest and an email with links to the applications.

Initially, we call it Gympass W, the W meaning wellness. We added a beta so that everyone could understand that it was not a finished product. Later, we renamed it to Gympass Wellness to make its value proposition clearer.

Our plan was to test this proof of concept with 5 corporate clients in the USA and 5 in Brazil, which would provide us with a potential user base of 15,000 employees. Our expectation was to have around 200 subscribers. We launched internally – eat your own dog food – on March 9, 2020 and had 66 subscribers from our 1,200 employees. Then came COVID-19.

COVID-19

When a company is hit by a crisis, it needs to look at these two perspectives:

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

Although product managers and product development teams play an important role in the former, their primary role is in the latter.

At Gympass we have 3 different clients and all of them deeply impacted by COVID-19:

  • gyms in many cities have been closed to support with physical distance measures applied to prevent the spread of COVID-19 and, consequently, are losing recurring revenue from users who were not going to the gyms;
  • users, employees of our customers, can no longer go to the gyms and have to stay at home, but they also have to remain active in some way, but their first reaction was to cancel or pause their Gympass subscription, because they didn’t have access to the gyms for a while;
  • corporate customers, whose employees are at home and no longer go to gyms, while HRs are concerned with how to keep these employees engaged and productive.

Gympass Wellness, the first digital product

We were able to adapt our Gympass Wellness pilot in record time to be offered to our entire user base, so that they can remain active, and also take care of their nutrition and their minds during these challenging times. With Gympass Wellness, we were able to address the problems and needs of users and our corporate customers during the crisis.

And here comes the ecosystem mentality. We must always look at all participants in our marketplace and ensure that everyone benefits from using it.

Live Classes, the second digital product

With Gympass Wellness, we were able to meet the needs of our corporate customers and their employees. But what about the gyms? When closed, they were losing revenue. Their customers no longer visited them, so regular gym users were likely to cancel their subscription, while those who used to go to gyms using Gympass did not go to the gym during the crisis, which would cause a loss of revenue for gyms as well. To help partner gyms cope with this very difficult situation, we decided and implemented 2 solutions in record time:

  • We provided the academies with a white-label application so that they can offer it to all their customers, regardless if they were or weren’t employees of Gympass customers, so that the gyms could deliver value to their customers, helping them to stay active at their homes;
  • We provided a platform for gyms to schedule and broadcast live classes to all Gympass users, so they can keep their instructors employed, while providing Gympass users with exclusive content. This platform is called Live Classes.

Personal Trainers, the third digital product

Live Classes provided a 1:N platform, which means that an instructor could provide physical activity guidance to N users. We soon realized that we could create another product in addition to Live Classes. Workout guidance 1:1, which could be made available in Gympass’ higher tier plans. Then we created our third digital product, Personal Trainers.

Summing up

  • Ecosystem mindset means making decisions that create value for all actors on a platform.
  • At Gympass, during the COVID-19 crisis, after offering Gympass Wellness for all its customers and their employees, an important part of the ecosystem was still suffering, the gyms. It was the ecosystem mindset that guided Gympass to create Live Classes product, which allowed gyms to continue operating even though they were behind closed doors.

There, with this chapter we conclude the second part of the book, on Principles. Here we saw my personal leadership principles:

  • People: priority #1, always.
  • Leading is like being a doctor.
  • Leading under pressure.
  • Mentoring is a two-way street.
  • How and when to delegate.

We also saw what corporate culture is, a set of ways shared by a group of people working together on how to solve problems and react to situations. We also saw the 5 values ​​needed to create successful digital products:

  • Don’t waste time looking for culprits, focus on learning.
  • Don’t compare work situations with war, nobody wants to kill anyone.
  • Profit and revenue are a consequence, should not be the main focus.
  • Transparency, the foundation of a high performance team.
  • Diversity, the basis of the best products.

Finally, we saw a set of four values ​​that are in fact the core of the entire digital product development team. These are the values ​​that make up the product culture, which is the set of behaviors of the digital product development teams that produce the best results:

  • Release early and often
  • Focus on the problem
  • Result delivery
  • Ecosystem mindset

In the next chapter we’ll start the third and final section of the book, about tools! \o/

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, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my almost 30 years of experience in creating and managing digital products:

  • Startup Guide: How startups and established companies can create profitable digital products
  • Product Management: How to increase the chances of success of your digital product
  • Leading Product Development: The art and science of managing product teams

Result delivery

Result delivery

In the previous chapter, we saw the difference between a team that solves problems and a team that implements solutions. While a problem-solving team needs to have a deep understanding of each problem it will solve, the people who are affected by it, the context in which it occurs, and the motivation people have to have this problem solved, the solution implementing team focus on implementing what is asked, no matter if what is implemented will bring any results.

The measurement of result delivery for these two types of teams is often quite different. Through the way a team reports its results, we clearly know what kind of team it is. Something like:

Tell me about the results you deliver and I’ll tell you what kind of team you are on!

While the solution implementing team usually measures its delivery of results based on the number of features delivered, the problem-solving team measures its delivery of results based on how well the problems have been solved.

Feature Factory

Solution implementing teams are those “feature factories” that we already mentioned in the previous chapter, that is, whose main metric is the quantity and speed of feature delivery. As this is its main metric, this team is now measured by its deliveries. The team said it was going to deliver that functionality that day, so that’s what the organization expects and that’s what the organization will ask the team.

This situation is not as unusual as you might think. At Locaweb, before implementing OKRs, the product development team was primarily measured by its planning assertiveness. If the team said it was going to deliver X on day Y, that was what was expected of the team, with no concern whether X was the right thing to do and whether it was actually going to bring results for the company or customers. By implementing OKRs, we managed to make the team increasingly focused on understanding and solving problems.

When I joined Lopes, I found something very similar. A portal team, a CRM team, and an app team, all of them with predefined deliveries planned up to 6 months ahead, because that was what was agreed with the company’s management. Lopes had even hired two consulting companies that, when presenting their results report, showed the number of features delivered as their main result, because that was what was demanded of them, delivery of features.

It is important to note that a situation like this does not happen solely because of the product development team. It is also the responsibility of the people who are making the demands. While the product development team must always ask what problem they are trying to solve with that demand, the people who make the demands must always contextualize these demands bringing the problem that motivated the demand.

Focus on the result

After my first 30 days at Lopes, I started working with the team to define the OKRs for the next quarter, which even motivated HR to also make its planning based on OKRs. These OKRs were then presented to the entire leadership of the company. It was the way I found to bring about a change in culture and mentality both in the product development team and in the entire company.

Most of the OKRs we defined were focused on business results. Increase in sales, increase in the conversion rate, and so on. That’s what matters to the business. Features are a means to get to an end, they are not an end in themselves, even in 100% digital companies, such as Conta Azul and Locaweb, digital products are a means to the end. Locaweb even makes this very explicit in its mission to “make businesses born and prosper through technology”, while Conta Azul wants to “boost the success of small entrepreneurs by giving small businesses more organization, control and time through technology.” Note that in both companies the technology and, consequently, the digital product is a means to an end. Both achieve their mission “through technology”.

Summing up

  • Another fundamental value for any product development team is the focus on delivering results.
  • Care must be taken when defining the result. Delivering features is not a result. All features are a means that serves an end, the achievement of a business objective.
  • Even companies that are 100% digital companies, whose digital products and technology are the company’s core, need to focus on business objectives.

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, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my almost 30 years of experience in creating and managing digital products:

  • Startup Guide: How startups and established companies can create profitable digital products
  • Product Management: How to increase the chances of success of your digital product
  • Leading Product Development: The art and science of managing product teams

In the next chapter, we’ll look at the value of ecosystem mentality.

New book: Digital products leadership

I used the year-end low workload to finish translating my book “Digital products leadership: The science and art of managing product teams” into English. Enjoy! \o/

Here’s a special launch discount coupon:

https://leanpub.com/leadingproductdevelopment/c/launch

And happy 2021, full of amazing results brought to you by the products you manage!

Focus on the problem

It is human nature to solve problems. Whenever we hear about problems, we go into solution mode almost immediately: we start looking for solutions to the problem. However, if we are able to get a better understanding of the context in which the problem occurs and the motivation to solve it before jumping into solution mode, there are more chances of finding solutions that are simpler and easier to implement.

It is common to see other areas in the organization asking the product development team to implement feature A or B because we need it to close a deal or to not lose that big customer. A common example I have heard for sometime back in 2019 was “we need to implement Apple Pay and Google Pay as a new payment method”. The issue is that, talking about solutions, we lose focus on the problem that originated that solution.

What is the problem?

To help people focus on the problem, always ask “What is the problem?” When a new feature request arrives for the product development team, we must thank the requester and then ask about the problem that generated the request. Each member of the product development team must have this behavior whenever a request for a new feature is received.

By putting this into practice, requests will soon come with not only a solution but also a lot of information about the problem. It is interesting to see this cultural change, but it requires discipline from members of the product development team to always ask about the problem. And when I mention the members of the product development team, I’m referring to everyone, not just product managers, but also designers and product engineers.

Problem vs. solution mindset

The main advantage of focusing on better understanding the problem is that the more time we invest in it, the easier it will be to find a solution and there are good chances that this solution will be simpler and faster to implement than the first solution we thought of.

Here is a great quote from Albert Einstein:

“If I had an hour to solve a problem, I would spend 55 minutes thinking about the problem and five minutes thinking about solutions.”

Einstein believes that the quality of the solution you generate is in direct proportion to your ability to identify and understand the problem you are trying to solve.

Let me tell you a little story to illustrate this. During the space race, scientists were faced with the problem of writing in space where there was no gravity to make the ink fall into a ballpoint pen. The Americans started their R&D efforts and after some time and a few million dollars, they built a pen with a small engine that pumps ink onto paper, even without gravity. Meanwhile, the Russians decided to use pencils.

Pen that writes in weightless environments

This story shows a good example of how jumping straight to the solution can make us spend unnecessary time and money to come up with incomplete or exaggerated solutions. It is a cultural issue, that is, a behavior that we can and must change. And the first step in changing a behavior is to recognize when it happens. When a member of the product development team receives a request to implement something, he must ask the person who brought the request what is the problem that this “something” should solve and why it needs to be solved.

Here are some examples of the companies I worked for.

At Locaweb, a web hosting provider in Brazil, hosting and e-mail services may stop working due to external factors such as the domain that is associated with hosting and e-mail not being renewed.

First solution: Registro.br, the Brazilian registrar of .br domains launched an API to allow Locaweb to charge the customer’s domain on behalf of Registro.br. At first, the idea seemed good, as Locaweb charging the domain seemed to be the easiest way to ensure that the customer knows that they have to pay for the domain registration to keep hosting and email services working properly. However, when we analyzed further, we saw that this solution could cause some problems. The customer would be charged twice for the same domain registration because Registro.br would continue to charge the domain. What happens if the customer pays both bills? What if he only pays for Registro.br? What if he only pays Locaweb? In addition, implementing a new type of billing in which we would charge for a third party service was something new for the Locaweb team. New processes would have to be carefully designed.

Implemented solution: we started to wonder if there would be simpler ways to solve the problem of helping our client not to forget that he has to pay for the domain registration at Registro.br. As it would be possible to charge for Registro.br services, it was possible to access information about the domain about to expire. We decided to design a simpler solution: implement a communication sequence with the client warning him of the importance of paying Registro.br to ensure that the email and hosting services continue to function normally. This is a much simpler solution than implementing a double billing process. If Registro.br provides us with the billing URL, we can send the information from this link to the customer and the chances of solving the problem will increase even more. And a communication sequence is much simpler and faster to implement than a duplicate billing process.

At Conta Azul, a SaaS ERP for MSBs (micro and small businesses), we used accountants as one of our distribution channels and we wanted to increase sales through accountants.

First solution: batch purchases, where accountants would acquire a fixed number of Conta Azul licenses to resell to their customers. A batch purchase management system would take about 3 months to implement, as it should allow accountants to purchase Conta Azul licenses in bulk, but it should only start charging the accountant’s customer when that customer actually activates the license.

Implemented solution: accountants didn’t care about batch purchases. What they wanted was to give a discount to their customers so that they could subscribe to Conta Azul with this exclusive discount provided by their relationship with us. The cost to implement this was zero, as the system already had a discount management feature.

At Gympass, a fitness partner who was joining our network asked us to present his waiver to all users who checked in to their facilities.

First solution: change our app to ask users who go to this fitness partner to read their waiver on our app and click a checkbox stating that they have read and agreed.

Implemented solution: no changes to our app. We use a customizable text field when configuring a gym in our system that is typically presented to users who will check in at that gym to present the following text: “By checking in, you agree to the terms and conditions located at http://fitnesspartner.com/waiver”.

Don’t get me wrong, it’s great that everyone brings solutions whenever we want to discuss something to be done by the product development team. The more solution ideas we have, the better. However, we need to educate ourselves to have a deeper understanding of the problem behind this solution, so that we have a chance to find simpler and faster solutions to implement. And it is ultimately the job of the product manager and all the members of the product development team to ask what the problem is and why we need to solve it.

Projects vs. problems

The New Year is a time for retrospective and planning. What is normally done every quarter by most product development teams is done more intensively at the turn of the year, in conjunction with other areas of the company. It is the annual planning process, which usually comes with the budgeting process. What will we do in this new year that is coming? What are the main projects that we will work on throughout the year?

Even though planning is super important to be clear about which projects are priorities for the new year, this list of projects can make you lose sight of a very important aspect of planning, the “why”.

It is not uncommon to see new year planning for a product development team, and even for the entire company, as a list of projects. To help you see your list of projects at a different perspective, I recommend you add 2 columns:

  • one to describe what problems you are trying to solve in each project;
  • and another to describe who you’re trying to solve this problem for.

I have already discussed the issues of having a problem-oriented mindset versus a solution-oriented mindset, but when it comes to New Year planning, that problem is even more evident. The benefits of being clear about the problems you want to solve and for whom you plan to solve them are:

  • Ensuring that problems are aligned with the company’s vision and strategy: When we focus on projects, it is easy to lose sight of the problems we are trying to solve, for whom we plan to solve, and if these are the problems we really need to solve.
  • Define which problems are most important to solve: prioritize projects without knowing which problems these projects solve, and for whom, it can make priorities unaligned with what is really important for the company. However, to be more effective in bringing the desired result, we must prioritize the problems to be solved and ensure that the prioritization is aligned with the company’s vision and strategy.
  • Solve more than one problem with the same project: Sometimes you may find that you are trying to solve more than one problem with a project, and this may not be a problem. But you need to know that. Perhaps you can have simpler solutions if you address each problem separately. Perhaps not all are worth resolving at this point.
  • Check if the projects are the best solutions: when we change the focus of the projects to the problems and we have clear visibility of the priority of the problems, it is easier to check if the projects listed are the best solution for the problem in question. Sometimes, we can find solutions that are easier to implement when we shift our focus to understanding problems.

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

Problem solving teams vs. solution implementing teams

Marty Cagan, a well-known reference in the digital products community, wrote an interesting article some time ago about product teams x feature teams, where he explains the difference between three types of teams, delivery teams, feature teams, and product teams. It defines each type of team as follows:

  • Delivery teams are not multifunctional (basically just developers plus a product owner who manages the backlog), are not focused on the result (people are all oriented towards delivering features) and have no autonomy (they are there to encode and deliver).
  • Feature teams are usually multifunctional (they have at least one designer and a product manager), but are still concerned with the production and delivery of features.
  • Product teams are multifunctional, focused and evaluated by the result, and have the autonomy to present solutions that work.

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

Any digital product exists for two main purposes:

  • Help the company that owns the digital product to achieve its goals.
  • Solve problems and meet the needs of its users.

Therefore, any digital product and its functionalities are solutions to problems of the company that owns the product and solutions to solve the user’s problems and meet their needs.

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

solve problems vs. implement solutions

What Marty describes as delivery teams and feature teams are teams of solution implementers. These teams work on implementing a solution conceived by someone else. And that other person is usually someone from the so-called “business area” who can be someone from sales, marketing, customer success, customer support, finance, operations, a director, a vice president, or a founder. In such a team, the product manager mainly manages the backlog and helps the team to deliver the requested solution, the product designer focuses mainly on designing a pleasant interface, and engineers have to code and deploy the requested solution. The solution implementation teams do as they are asked to do, with little or no commitment to the quality of the solution, or even if the solution implemented really solves the problem. They may also be called a “feature factory”. Its performance is measured by the amount of functionality that the team produces.

On the other hand, what Marty describes as empowered product teams are problem-solving teams. These teams work to deeply understand the causes of the problem, the context, and the motivation that people have to solve it. In doing so, they are able to implement the best solution for the problem at hand.

There are three main reasons why problem solving teams are more effective than solution implementing teams:

  • Digital product knowledge: There is no one better than team members to find the best digital product solution to a problem. A solution delivered as quickly as possible, with good software quality and good user experience. This is because a team of problem solvers is a multifunctional team made up of engineers who understand the technology available, product designers, who have a deep understanding of users, their pains and 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 is easier for two people to help each other to solve a problem than for one person to solve a problem alone. A team of problem solvers does not rule out any suggestions for solutions from “business areas”. In fact, these solution suggestions are very useful in helping the team to better understand the problem, but they should be considered suggestions. A team of problem solvers first understands the problem and then looks at the solution options.
  • Commitment: An additional side effect of a problem-solving team is that members of that team are deeply committed to the successful implementation of the solution since they are deeply involved in the process of finding the solution.

Creation of problem solving teams

Now that I have explained why problem-solving teams are the best type of digital product team a company can have, I will explain how to build problem-solving teams. There are three aspects that need to be considered:

  • Environment: It is essential that the entire organization understands the power of having problem-solving digital product teams. The speed and quality of the solutions delivered by a digital product team that always starts to solve problems from a deep understanding of the problem are much better than the solutions delivered by teams of solution implementers. Consequently, business results will be better and faster. It is the role and responsibility of the product head to help the organization understand this.
  • What is the problem: A very effective way to focus the entire organization away from the solution mindset and closer to the problem mindset is to constantly ask “What problem are we trying to solve?” and “Why is it important to solve this problem?”. This will help people across the organization to change their perspective and, consequently, realize the importance of a deep understanding of the problem before implementing a solution. This is a behavior change that the entire digital product development team can help your organization make. Whenever someone asks the product team to implement something, ask “What problem are we trying to solve?”
  • Trust: This is a critical aspect of building successful problem-solver teams. Usually people in the “business area” believe they have a better understanding of the business than those of the product team. This behavior is even more visible when the digital product team is new to the organization. How can a new person in the organization understand more about the business than someone who has been with the company for years? She probably cannot, especially if she comes from a different market. However, those who are part of the digital product team usually have a lot of experience in building digital products, probably more experience than anyone else in the organization. Therefore, it is essential that the “business area” educate the digital product team about the business aspects of the organization. This search for education is the role and responsibility of product managers, who must learn from the “business area” and educate product designers and engineers about the business. A practical way to accelerate this learning is to bring people from the “business area” to the discussion sessions on the problem. This is how the product team gains the trust of the other areas of the organization.

I believe that the benefits of having digital product teams versus solution implementers teams are clear. The entire organization needs to understand the difference in order to push for more and more problem-solving teams. The head of product has this as one of her greatest responsibilities, helping to build the environment and the trust needed for the success of problem-solving teams.

The top-down trap

When I talk about the differences between problem solving teams vs solution implementing teams, I usually hear comments like “We want to be a problem solving team, but in my company all solutions are top-down and the only thing we can do is implement them “.

These situations worsen when a crisis arises. The most recent crisis that many companies are experiencing is the COVID-19 crisis. In an eagerness to solve problems as quickly as possible, company leaders ask teams to implement this or that solution quickly, very quickly.

The trap

Let me now approach the elephant in the room, the top-down decision-making environment. This has a huge impact on any team in this type of environment. Without being part of the decision about the solution, the people who implement the solution will end up discouraged and demotivated.

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

Let’s use the main characteristic that every product manager should have, empathy. The ability of someone to put themselves in someone else’s shoes to understand their aspirations, motivations, needs, and problems. People I had the opportunity to talk to about the essential characteristics of a product manager know how important I consider empathy to be a critical trait for successful PMs.

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

  • Understanding the situation: Put yourself in the place of the solution implementation requester. People solve problems, it is their nature, and whenever they encounter a problem, they jump into solution mode and try to find and implement solutions as quickly as possible. Under greater pressure, such as the COVID-19 crisis, the desire to find and implement solutions is exacerbated. In most cases, people do not want to be top-down decision-makers, they simply have a need to solve the problem as quickly as possible.
  • Changing the status quo: ask questions about the solution implementation request. What problem are we solving? For whom? Why is it important to solve this problem? Why now? Why do we need to deliver something fast, even while compromising quality? If you are asked the reason for so many questions, explain that you are trying to better understand the problem to see if there are other cheaper and faster to implement solutions.

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

Most of the time, people understand the benefits of a collaborative decision-making process. Even under pressure, collaborative solutions will produce better results. Solutions designed in a collaborative process are usually cheaper and faster to implement because more people have had a chance to discuss solution options and the team that will implement the selected solution will be truly committed to your success.

To build, maintain and improve problem solving teams and avoid turning them into solution implementation teams, especially when under greater pressure, it is essential to avoid the top-down trap.

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

Summing up

  • A very important step in creating a good solution is understanding the problem. When we hear about a problem, we immediately start thinking about solutions. However, the more time we spend learning about the problem, the easier it will be to find a solution, and chances are good that this solution will be simpler and faster to implement than the first solution we thought of.
  • If you have a list of projects to do, create two more columns in that list, one for problems to be solved by each project and another for whom the problems will be solved. This will help you to focus on the problems to be solved, not the projects, which are the solution.
  • Solution implementation teams are teams working on implementing a solution designed by someone else. Problem-solving teams are teams that work to deeply understand the causes of the problem, the context, and the motivation that people have to solve it. In doing so, they are able to implement the best solution for the problem at hand.
  • The top-down trap is the perception of the decision-making process being made by the leaders of the company, with no opportunity for the rest of the employees to participate. This perception is exacerbated when a company faces increasing pressure, such as the COVID-19 crisis.
  • People are solution-oriented, and the greater the pressure, the faster people want solutions to be implemented.
  • To help deal with this situation, use empathy to understand the requestor’s view of implementing the solution and ask him why it is necessary to implement the requested solution.
  • Product heads have the role and responsibility to promote these behavioral changes to help build a more collaborative decision-making process.

In the next chapter, we will understand more about the focus on delivering results.

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 Digital Product Management bundle with my 3 books where I share what I learned during my almost 30 years of experience in creating and managing digital products:

  • Startup Guide: How startups and established companies can create profitable digital products
  • Product Management: How to increase the chances of success of your digital product
  • Leading Product Development: The art and science of managing product teams

Release early and often

In the previous chapters we saw my personal leadership principles:

We also saw what corporate culture is, a set of ways to solve problems and react to the situation shared by a group of people working together. And we saw the 5 values ​​needed to create successful digital products:

Product culture

It turns out that these values ​​are necessary, but not sufficient. There is a set of four values ​​that are in fact the core of the entire digital product development team. These are the values ​​that make up the product culture, which is nothing more than the set of behaviors of the digital product development teams that produce the best results. The four values, which will be the subject of this and the following chapters, are:

  • Release early and often
  • Focus on the problem
  • Result delivery
  • Ecosystem mindset

Let’s start with the first one: Early and frequent launch.

The sooner we present the product to our users, the better, as we can receive feedback from real users who will be able to use the product in their own context. There are 3 reasons that justify this need to launch your product or functionality as soon as possible and frequently.

Moment of truth

It doesn’t matter how much research, interviews, and prototypes you do, the moment of truth, that is, the moment when you will know if your product is, in fact, the solution to a problem of a group of people, is when the product is in your customers’ hands, in the context where they need the product.

The longer it takes you to get your product out on the street, the longer it will take to learn from real people if you are on the right track. And if that’s not enough, the more steps you will be taking in the wrong direction.

You will only know if the product you made really solves some people’s problems if they use it. The longer it takes for this to happen, the longer it will take to know whether or not it is the solution to the problem.

And if not, what do you do? Fix, adjust, change! The sooner you know that what you are developing is not on the right track, the better because the less time, energy, and money you will waste going the wrong direction.

Too many features

There is a limit of features that the user can understand. When we add too many features, instead of creating a solution to the customer’s problem, we end up creating a new problem for the customer.

Kathy Sierra, recognized programming and user experience instructor, has created a feature chart that illustrates in a clear and fun way how user satisfaction decreases as we increase the amount of functionality in a product.

Featuritis
User satisfaction curve as a function of the amount of functionality

Return on investment

The longer your product takes to have users and, consequently, customers who will at some point pay for your product, the more you will have to invest out of your own pocket. Below is a typical graph of a product’s return on investment (ROI).

During the period that you are building the product and don’t release it to users, all you will have is cost. That is, you will be in the investment part of the curve. This only changes when you start earning revenue and it is greater than your monthly costs. Then you enter the area described below as monthly profitability. Only after a few months in this area will you have a return on your investment. See how long the road is.

Return on investment

Now take a look in the graph below, how a 3-month delay in obtaining revenue can delay the return on investment by 6 months. Are these 3 months of delay in earning revenue worth it? What will you do in those 3 months really make up for 6 months of delayed return on investment?

Postponed return on investment

On the other hand, see what you get if you can accelerate the development of your product and launch it 3 months ahead of schedule. You get 6 months of return on investment! And the explanation for this is not just because you get to the revenue early, it’s because you spent less to be able to launch the product faster. See the chart below.

Antecipated return on investment

If you are not ashamed of your first version, you took too long to launch

LinkedIn founder Reid Hoffman once said that:

“If you are not ashamed of the first version of your product, you took too long to launch”.

To illustrate this phrase, which in a way summarizes the value of release early and often, I decided to take screenshots of the first version of some well-known services.

Facebook 2005
Facebook 2005
Google 1998
Linkedin 2005
Twitter 2006
Locaweb 2002
Conta Azul 2011
Agil ERP (Conta Azul) 2008
Gympass 2014
Lopes 1998

MMF – Minimal Marketable Feature

Minimal Marketable Feature or MMF comes from a 2003 book called Software by Numbers, by Mark Denne and Dr. Jane Cleland-Huang. In this book, they introduce the concept of:

Incremental Funding Methodology (IFM), an ROI-based approach (Return on Investment) for software development in which the software is developed and delivered in carefully prioritized blocks of functionality valued by the customer. These blocks are known as Minimum Marketable Features – MMFs.

It is a concept prior to that of MVP, which has the advantage of this mentality of implementing the minimum necessary for each feature of the product. The basic difference between MVP and MMF is that, while MVP talks about a minimum viable product, that is, it needs a complete product, even if minimal, in order to be presented to possible users, MMF brings the minimal concept down to the level of each feature.

To illustrate MMF, they used a very simple example: imagine that you have to build an internet banking system on the web. There are many features and it can take many months or even years for this product to be delivered with all “mandatory” minimal set of features. When thinking in terms of MMF, we should look at those “mandatory” features and find out if we can launch them independently, that is, if a particular feature, if launched independently, would bring some value to the customer. In an internet banking system, we could choose to release it only with an account statement and no other resources. This would be a very simple internet banking system, but if launched as soon as it is ready, and not after some other features are also ready, it will bring value to the customer sooner. And whenever you deliver value to the customer, you also deliver value to your company. In addition to the satisfied customer, in this example you have probably reduced the cost that your company has in serving these customers, because if users do not obtain their account statements over the internet, they will certainly use another way of obtaining this information and probably this other way is not as economical as internet access, like going to an agency or an ATM.

Minimum marketable functionality (MMF) is minimal, because if it were smaller it would not be marketable. And an MMF is marketable because, when launched as part of a product, people use (or buy) the functionality.

The next time you are planning a new product or feature set for an existing product, try to think in terms of MMF. It can bring a lot of value to you, your customers and your company.

Summing up

  • There is a set of four values ​​that are in fact the core of every digital product development team. These are the values ​​that make up the product culture, which is nothing more than the set of behaviors of the digital product development teams that produce the best results.
  • The three reasons for you to launch your product soon are that (i) this is the moment of truth, (ii) so you avoid the excess of features and (iii) accelerate the return of the investment.
  • If you are not ashamed of your first version, it took too long to launch.
  • Minimal Marketable Feature or MMF is a concept prior to that of MVP, which has the advantage of bringing this mentality of implementing the minimum necessary for each product functionality.

In the next chapter we will see the importance of focusing on understanding the problem to be solved before thinking about solutions.

Missing something?

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

Digital Product Management Books

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

  • Startup Guide: How startups and established companies can create profitable digital products
  • Product Management: How to increase the chances of success of your digital product
  • Leading Product Development: The art and science of leading digital products

Diversity, the basis of the best products

I have seen demonstrations of diversity with increasing frequency. I’m not much into watching TV, but one day in 2017 I ended up watching a little bit of TV Globo, the biggest Brazilian TV network. I watched the end of Jornal Nacional and the beginning of the soap opera. In Jornal Nacional, I saw a report about PUC in São Paulo opening unisex bathrooms – remembering that PUC is Pontifical Catholic University, a university linked to the Catholic religion. Then, in the soap opera, a character was telling her parents and family that she was born in the wrong body, that he was a man who had been born in a woman’s body, that is, that he was transgender. Then, during the break, came the Globo campaign entitled “Everything starts with respect” about respecting gender identity.

That’s really good! Accepting and respecting differences is the basis for evolving as a society and building an ever better future for us, for our children and for all of humanity.

When respect and the ability to accept diversity are lacking, very bad situations can happen, for example, of parents rejecting their own child. I was very impressed when I read the report by Daniela Andrade, a senior consultant at ThoughtWorks, where she says:

“As I was expelled from my parents’ house, for being transsexual – and here I say that the first great violence that we suffer is at home – for many years I have no relatives to count on in times of need, everyone turned their backs on me.”

How is it possible for a parent to reject his own daughter? I am a father and I know how the love of a parent is something very intense, capable of overcoming any problem so that we can always help and support our children. I was talking the other day with my wife about this story and about the difficulty people have in accepting differences, to the point of rejecting their own children. It was at that moment that my wife said a phrase that marked me. She said that ultimately, everyone is different. Transgender, cisgender, heterosexual, homosexual, bisexual, asexual, black, white, yellow, young, adult, middle age, senior citizen, brazilian, canadian, french, vietnamese, fluminense, paulista, carioca, belo-horizontino, runner, cyclist, swimmer, engineer, architect, lawyer, who likes pop, rock, jazz, classical and so on. Even identical twins are different.

If all people are different, accepting and respecting differences is not only desirable, it is necessary and mandatory so that we can live in a society in a more harmonious and sustainable way. These are values ​​that must be taught to all people from birth.

And what does diversity have to do with digital product management?

In addition to the importance of accepting and respecting differences to help create a more harmonious and sustainable society, diversity will help create better digital products for two reasons:

  • Diversity brings new points of view. Having a more diverse product development team brings new points of view and new ways of thinking, which will help to develop a better product. It is no wonder that the product development team is comprised of software engineers, user experience designers, and product managers. Each person has different views of what a good product is and these differences, when worked well by the team, are what help to create a better product.
  • Just as the group of customers using your software is diverse, so should your team. Usually, software product development teams are mostly male, but the population of any country is more diverse. Both at Conta Azul and Locaweb, more than 88% of the team was composed of men. But these teams make products that will be used by the Brazilian population, which is made up of 48.2% men and 51.8% women according to IBGE (Brazilian Institute of Geography and Statistics). It is also worth remembering that the division between “men” and “women” is simplistic and that gender diversity is non-binary, that is, there are other gender identities besides female and male.

That is why it is so important to reflect and talk about diversity. Only then you will be able to think about issues so essential to the success of your product. How to improve the diversity of your product development team? How to foster discussions that bring different points of view and help to see your product and the problems it helps solve from new angles?

In all the teams that I led, I brought this topic to be discussed. Together we thought about how we could improve this diversity. An interesting example of the result of this work over 12 months was what we were able to do at Gympass, with an increase of 5 percentage points.

Gympass product development team in September 2018
Gympass product development team in August 2019
Evolution of the diversity of the Gympass product development team

At Conta Azul, we achieved something similar between 2016 and 2018 with an increase of 6.1 percentage points.

Conta Azul’s product development team in 2016
Conta Azul’s product development team in 2018
Evolution of the diversity of the product development team of Conta Azul

Diversity of perspectives

The product development team is comprised of software engineers, user experience designers and product managers. Each has a different perspective of what a good product is and these differences are what help to create a better product, when the differences are well resolved by the team.

Some time ago, I heard the following phrase:

The fact that two people disagree does not necessarily mean that one of them is wrong.

It really got me thinking about the diversity of perspectives. This has to do with empathy, one of the 7 essential characteristics of a product manager. Empathy is someone’s ability to step in someone else’s shoes to understand their aspirations, motivations, needs, and problems. What is her context? How does she see and hear things? What makes her understand things from this perspective?

There is a great tool called the empathy map, which aims to help teams gain a deeper view of their customers.

Empathy map (adapted from this source)

People have different backgrounds, different stories, different knowledge. We must recognize and respect these differences and understand that sometimes we will not reach an agreement, but that’s okay, as long as we respect each other’s perspective. Perhaps we can create a third perspective from the two different ones. Perhaps we can decide to try one, or both, and see and compare the results.

As long as there is respect and empathy, diversity brings many good results for everyone.

Summing up

  • There are two main reasons that motivate the construction of different digital product development teams. The first is that diversity brings new points of view. The second reason is that just as the group of customers using your product is diverse, so should your product development team.
  • People have different backgrounds, different stories, different knowledge. We must recognize and respect these differences and understand that sometimes we will not reach an agreement, but that’s okay, as long as we respect each other’s perspective.
  • It is in our hands to make the digital product development environment more inclusive. The way for this to happen is to bring up the topic and make it part of the conversations.

With this chapter, we finish to see what culture is and what, in my opinion, are the 5 main values ​​that the whole company must have to develop successful products:

  • Don’t waste time looking for culprits, focus on learning.
  • Don’t compare work situations with war, nobody wants to kill anyone.
  • Profit and revenue are a consequence, should not be the main focus.
  • Transparency, the foundation of a high-performance team.
  • Diversity, the basis of the best products.

In the next chapters, we will see four additional values ​​that, based on my experience, are the heart of digital product culture.

Missing something?

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

Digital Product Management Books

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

  • Startup Guide: How startups and established companies can create profitable digital products
  • Product Management: How to increase the chances of success of your digital product
  • Leading Product Development: The art and science of leading digital products

Culture and values

After talking about my leadership principles, I will talk about another fundamental theme for a head of product, organizational culture and values. There are 5 values ​​that I consider critical for the success of the product:

  • Don’t waste time looking for culprits, focus on learning.
  • Don’t compare work situations with war, nobody wants to kill anyone.
  • Profit and revenue are a consequence, they should not be the main focus.
  • Transparency, the foundation of a high performance team.
  • Diversity, the basis of the best products.

Let’s start by defining culture.

What is culture?

The word culture comes from the Latin cultus, which means “care”, and from the French colere, which means “to cultivate”. Edgar Schein, a professor at the MIT business school, was one of the first people to talk about organizational culture in the 1970s. According to him, each company had its own personality, and its own way of acting and reacting to situations; this form is passed from employee to employee since the company’s founders.

Organizational Culture

Culture is a set of premises that were learned and shared by a group of people while solving problems of external adaptation and internal integration. This set of premises works well enough to be considered valid and, consequently, to be taught to new members of the group as the correct way to perceive, think, and feel about these problems.

Source: SCHEIN, Edgar. Organizational Culture and Leadership. Jossey-Bass, 2010

The culture comes from the company’s founders. The founders have their own culture and it is natural that they impress it in the organization they are creating. As a result, it is very common to think that it is something that emerges in an organization. Schein warns that this is a mistake. Cultures can and should be planned and it is the role of the product head to help plan and promote the company’s culture. For this reason, I am sharing these five values ​​that I believe are critical for the development of successful digital products.

Don’t waste time looking for culprits, focus on learning

When mistakes happen it is common for people to try to find out who was responsible for the error. This can end up generating a culture of fear of making mistakes and, consequently, of wanting to hide mistakes, especially if there is any punishment.

The teams that not only recognize their mistakes but use them as a source of learning and improvement are the teams with the best performance. In the book The High-Velocity Edge: How Market Leaders Leverage Operational Excellence to Beat the Competition, MIT professor Steven J. Spear explains that a high-speed team has four skills:

  • Be prepared to capture knowledge and encounter problems in your operation.
  • Understand and solve these problems to build new knowledge.
  • Share the new knowledge with the entire organization.
  • Lead to develop skills 1, 2 and 3.

According to prof. Spear, that’s the secret behind Toyota’s success for so many years. Alcoa is another good example. It had a work incident rate that was around 2% per year. In a team of 40 thousand employees, this means 800 employees per year with some work incident, more than 2 per day. To combat this problem, they implemented a zero error tolerance policy. Before implementing this policy, mistakes were seen as part of the job. Employees are now encouraged to report operating errors within 24 hours, propose solutions within 48 hours, and report the solution found to their colleagues to ensure that knowledge spreads throughout the organization. This caused the risk of incidents to drop from 2% to 0.07% per year! This reduction in the incident rate meant that less than 30 employees per year had a work incident problem after the zero error tolerance policy was implemented and Alcoa achieved an increase in productivity and quality similar to that of Toyota.

In the book Smarter Faster Better: The Transformative Power of Real Productivity, Charles Duhigg, author and journalist awarded the Pulitzer Prize, compares the performance of two ICU teams, one of whom usually meets daily to discuss problems and how to avoid them and the other that usually punishes employees who make mistakes. The team that discusses and learns from mistakes performs better, which, for an ICU team, means fewer deaths and more recovered patients.

This type of environment that learns from mistakes is known as a psychologically safe environment, that is, in which people on the team can do their job without fear of negative consequences. As the product head, it is your role to create such an environment for your team and the entire company.

Don’t compare work situations with war, nobody wants to kill anyone

I often see the use of war analogies in the daily lives of companies. We will defeat this competitor. Let’s create this war room to address this issue. This is a war, we have to beat our enemies. There is a book called The Art of War, attributed to a Chinese general named Sun Tzu who lived between the years 550 and 500 BC, which is considered one of the 10 most influential business books of all time. This book has phrases like “In the face of a long battlefront, look for the weakest point and, there, attack with your greatest strength” and “The supreme art of war is to defeat the enemy without fighting”.

Although I understand the image that we want to create by making this comparison of war with business, to generate greater motivation in the team of a common enemy to be defeated, I am deeply disturbed by this analogy. War is a very ugly and sad thing. Try writing war on Google and click on the “Images” option. You will see many pictures of pain and suffering. In a war, for someone to win, someone must lose.

In my view, business is the opposite of that. The most prosperous businesses are those that positively impact everyone around you, employees, customers, suppliers, society, and even competitors. A good competitor is one that motivates you to improve. Competitors take companies out of their comfort zone. If it weren’t for them, companies would evolve much more slowly. In addition, competitors can and should join associations to pursue common goals.

Profit and revenue are a consequence, should not be the main focus

Yes, the goal of every company is to grow and make a profit, but that should not be the focus. A company’s primary purpose should be to help its customers in some way, and revenue and profit should be used as metrics that indicate whether the purpose is being fulfilled. But they shouldn’t be the only metrics, since there is always a risk of getting bad revenue, which can happen when we keep the main focus on having more revenue.

Imagine a situation where you subscribe to a service with a monthly payment and, for some reason, you need to cancel your subscription. When you try to do this, you discover that the cancellation process is super complicated. This will certainly leave you dissatisfied. The same thing happens when you take water from the fridge in a hotel room and discover that the water bottle costs 3 times more than in a supermarket. These are situations that even generate revenue for the company, but it is bad revenue, which leaves customers dissatisfied and that will probably make these customers not return and even speak ill of your company when they have the opportunity.

For this reason I like to make an analogy between recipe and profit with food:

Revenue is like food, it is necessary, it is vital for the health and success of a company, but it is not the purpose of life. You don’t wake up in the morning and the first thing you think is “how can I get more food?”

However, both a company and a person must always be attentive to the quality of the food they are eating, to be sure that it will not cause any harm to their health.

Summing up

  • Culture is the way a group of people responds to everyday situations. It is the role of the product head to assist in the design and promotion of the company’s culture to ensure an environment conducive to the development of successful products.
  • It has five values ​​that I believe are essential to help create a culture that enables the development of successful products. In this chapter I spoke of 3 of those values: don’t waste time looking for the culprits, focus on learning. Don’t compare work situations with war, nobody wants to kill anyone. Profit and revenue are a consequence, it should not be the main focus.

In the next chapter, we’ll talk about the importance of transparency in creating high-performance teams.

Missing something?

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

Digital Product Management Books

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