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 a profound understanding of each problem it will address, the people affected by it, the context in which the problem occurs, and the motivation of people to have the problem solved, the solution implementation team focuses on implementing what is asked of them, regardless of whether what is being implemented serves a purpose.

The measurement of result delivery for these two types of teams is usually quite different. Through the way a team reports its results, we can clearly identify what type it is—something like “tell me about your results, and I’ll tell you what type of team you are!” While the solution implementation team usually measures its result delivery based on the quantity of features delivered, the problem solving team measures its result delivery based on how well the problems were solved.

Solution implementation teams are the famous “feature factories,” whose main metric is the quantity and speed of feature delivery. Since this is their main metric, this team is measured by its deliveries. The team said it would deliver a certain feature on a certain day, so that’s what the organization expects, and that’s what the organization will demand from the team. Another commonly attributed name to this work model is the “bakery” model, in which the technology team works based on the orders placed.

This situation is not as uncommon as one might think. At Locaweb, before implementing OKRs, the product development team was primarily judged by the accuracy of the planning. If the team said it would deliver X on day Y, that’s what was expected from the team, with no concern about whether X was the right thing to do and whether it would actually bring results to the company or customers. By implementing OKRs, we were able to make the team increasingly focused on understanding and solving problems.

When I joined Lopes, I found something quite similar. A portal team, a CRM team, and an app team, all with predefined deliveries up to 6 months ahead because that’s what was agreed upon with the company’s management. In fact, Lopes had hired two consulting firms that, when presenting their results reports, showed the quantity of delivered features as their main outcome because that’s what was demanded of them: feature delivery.

It’s important to note that a situation like this doesn’t happen exclusively due to the product development team’s responsibility. It’s also the responsibility of the people making the demands. While the product development team should always ask what problem it’s trying to solve with that demand, the people making the demands should always contextualize these demands by bringing up the problem that motivated them.

After my first 30 days at Lopes, I started working with the team to define the OKRs for the next quarter, which also motivated HR to plan based on OKRs. Later, these OKRs were presented to the entire company’s leadership. It was the way I found to provoke a cultural and mindset change both in the product development team and throughout the company.

Most of the OKRs we defined should be focused on business results. Increased sales, improvement in the service rate, and so on. That’s what matters to the business. Features are a means, not an end in themselves—even in 100% digital companies like Conta Azul and Locaweb, digital products are a means to an end.

Let’s remove the product from the center?

I’ve been working with digital products for over 30 years. I graduated in computer engineering from ITA in the early 1990s, and since then, I’ve been employed by companies whose core business is technology.

I started with Dialdata, my internet services startup from a time when new technology companies weren’t yet called startups. Later, I worked with technology products at .comDominio, a data center that became Alog and was later acquired by Equinix. After that, I went through Locaweb, Conta Azul, and more recently, Gympass— all technology companies that use technology to deliver value to their customers.

At Gympass, I began to understand the dynamics of a company where technology and digital products are not the core business. Gympass’s product is a corporate benefit that companies subscribe to, providing their employees with access to a network of gyms and studios. In late 2019, there was a digitization—and diversification— effort of Gympass’s product portfolio with the launch of Gympass Wellness. Nevertheless, the main product continued to be the offering of wellness services as a corporate benefit for companies to provide to their employees. Gympass’s digital products serve as vehicles for delivering these wellness services.

Even technology companies have a mission to do “something” through technology. Look at Locaweb’s mission:

• “Making businesses grow and prosper through technology.”

And the one from Conta Azul:

• “Boost the success of small entrepreneurs providing small businesses with more organization, control and time through technology.”

On the other hand, there are well-known tech companies that don’t even mention technology in their missions:

• “Our mission is to empower every person and every organization in planet to achieve more.” (Microsoft)
• “Organize the world’s information and make it universally accessible and useful.” (Google)
• “Give people the power to share and make the world more open and connected.” (Facebook)

The technology and digital products are not the mission of technology companies; they are the vehicles these companies use to fulfill their mission.

When I joined Lopes, a company founded in 1935, long before the existence of computers and the internet, I began to understand something that I had already noticed during my time at Gympass. The digital product should not be at the center of the company. The company does not revolve around the product; rather, it is the other way around: the digital product is there to serve the company and its customers, to enhance its results, and to help fulfill its mission— which, in the case of Lopes, is:

• “Helping people achieve their place.”

One of the products that was being developed when I started working at Lopes was the “MVP” of the brokers’ app, as described in the previous chapter. I put the term MVP in quotation marks because this app had been in development for 7 months, and it still had 2 or 3 months to be delivered, in addition to the 5 months of discovery.

When the product is at the center, people start to focus on the product and its features. This leads to demands for the delivery of functionalities. In defining the minimum scope of an MVP, the discussion often revolves around “minimum” features. Even when using the term MVP, the focus is on the minimum product.

The way Lopes Labs teams were organized in mid-2020 was putting the product at the center. There was a portal team, responsible for the portal where people search for real estate, a CRM team for franchises and brokers, and a broker’s app team. Teams were organized and oriented around products. The only way these teams had to solve problems was by adding new features to their products. Moreover, having more features in the backlog means more work to do and, consequently, job security. It’s not surprising that the only way to solve the problem of “getting leads into the hands of brokers” was through the push notification feature in the app. Additionally, the “MVP” of the broker’s app was defined with 58 requirements and features, and beyond those 58, there were already 90 more requirements and features with defined scope to be developed after the “MVP” launch. Job security for a long time.

It is clear that by putting the product at the center, we end up amplifying some pitfalls that can hinder our delivery of results. So what should we put at the center? The expected result. In the example of the Lopes MVP, the expected result was to get leads into the hands of brokers as quickly as possible so that they could contact the potential customer as soon as possible and engage them in a conversation with the potential to generate a real estate sale.

If we analyze the description of the expected result, there is no mention of an app, push notification, customer registration, or property search. The expected result is to get the lead into the hands of brokers as quickly as possible because, by doing so, the chances of turning the lead into a sale increase, bringing results to Lopes, the broker, and the customer. If we focus more on the problem, we will see that there are other possible solutions besides the brokers’ app. We can send notifications via SMS or WhatsApp, something much simpler and quicker to develop than an app—and probably with a broader reach since all phones accept SMS, and most people in Brazil have WhatsApp, while an app needs to be downloaded by the user.

Product is a means, not an end

I have often repeated that a product, app, website, technology, data, and algorithms are not the end goal; they are vehicles to achieve the goal of delivering value and should be treated as such. Getting the lead into the hands of brokers faster can be done through push notifications in a broker’s app, but it can also be achieved through SMS or WhatsApp notifications. The vehicle matters less than the delivered result.

In the example of the team that had been working for over a year on an “MVP” of an app for brokers, there was a team with people from engineering, design, and product management focused on developing a product: the app for brokers. Because it was organized to develop a product, the only way this team knew to solve problems was through that product.

In addition to this broker’s app team, Lopes had two more teams focused on products. One was the portal team, responsible for the website where people search for real estate, and a third CRM team that developed the CRM used by Lopes’ brokers and franchises.

Digital products for Lopes are a means of delivering value. Lopes does not market the broker’s app, portal, or CRM as products. For this reason, we made a change in Lopes’ team structure. We shifted from an organization of teams by product to teams by actors in our business. We created three teams:

• End Customer: Those looking for a property to buy or rent.
• Developer and Owner: Those wanting to sell or rent a property.
• Brokers and Franchises: Those facilitating the intermediation.

Each of them focuses on delivering value to their target audience, regardless of the delivery vehicle. It can be through a web system, an app, SMS notifications, a chatbot, etc. What matters is delivering value—and results—to brokers and franchises as quickly as possible.

As we’ve seen, even technology companies like Google, Microsoft, Facebook, Locaweb, and Conta Azul do not place the product at the center of their missions and purposes. Products, apps, websites, technology, data, and algorithms are not the end goal; they are vehicles to achieve the company’s result objectives while solving problems for their customers.

Digital transformation and product culture

This article is another excerpt from my newest book “Digital transformation and product culture: How to put technology at the center of your company’s strategy“, which I will also make available here on the blog. So far, I have already published here:

• About the book
• Part 1: Concepts
  • Chapter 1: The so-called digital transformation – Project and Product
  • Chapter 2: Uncertainty and digital transformation
  • Chapter 3: Types of company
  • Chapter 4: Type of company vs digital maturity
  • Chapter 5: Business models
  • Chapter 6: Agile, digital and product culture
• Part 2: Principles
  • Chapter 7: Deliver early and often – Measuring and managing the productivity – Case study: Dasa Group – Case study: Itaú Unibanco
  • Chapter 8: Focus on the problem – O Famoso Discovery de Produto – Why the “business demands => IT implements” model does not work – Case study: Magazine Luiza
  • Capítulo 9: Result delivery

Workshops, coaching, and advisory services

I’ve been helping companies and their leaders (CPOs, heads of product, CTOs, CEOs, tech founders, and heads of digital transformation) bridge the gap between business and technology through workshops, coaching, and advisory services on product management and digital transformation.

Digital Product Management Books

Do you work with digital products? Do you want to know more about managing 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 books, where I share what I learned during my 30+ years of experience in creating and managing digital products:

• Digital transformation and product culture: How to put technology at the center of your company’s strategy
• Leading Product Development: The art and science of managing product teams
• Product Management: How to increase the chances of success of your digital product
• Startup Guide: How startups and established companies can create profitable digital products