No capítulo anterior, vimos a diferença entre um time que soluciona problemas e um time que implementa soluções. Enquanto um time que resolve problemas precisa ter um profundo entendimento de cada problema que vai resolver, das pessoas que são afetadas por ele, do contexto em que o problema acontece e da motivação das pessoas para terem esse problema resolvido, o time implementador de soluções foca na implementação daquilo que lhe é pedido, sem se importar se o que está sendo implementado serve para algo.

A medição de entrega de resultado desses dois tipos de times costuma ser bem diferente. Por meio da forma como um time reporta seus resultados, conseguimos claramente identificar de que tipo ele é — algo como “conte-me sobre seus resultados, que lhe direi que tipo de time é!”. Enquanto o time implementador de soluções costuma medir sua entrega de resultado com base na quantidade de funcionalidades entregues, o time solucionador de problemas mede sua entrega de resultado com base em quão bem os problemas foram resolvidos.

Os times implementadores de soluções são as famosas “fábricas de funcionalidades”, cuja principal métrica é a quantidade e a velocidade de entrega de funcionalidades. Como essa é sua principal métrica, esse time passa a ser medido pelas suas entregas. O time disse que ia entregar tal funcionalidade nesse dia, então é isso que a organização espera e será isso que a organização vai cobrar do time. Um outro nome comumente atribuído a esse modelo de trabalho é o modelo “pastelaria”, no qual o time de tecnologia trabalha com base nos pedidos que lhe são feitos.

Essa situação não é tão incomum quanto se imagina. Na Locaweb, antes de implementarmos OKRs, o time de desenvolvimento de produto era primariamente cobrado por assertividade do planejamento. Se o time disse que ia entregar X no dia Y, era isso que era esperado do time, com nenhuma preocupação se X era a coisa certa a ser feita e se ia de fato trazer resultado para a empresa ou para os clientes. Ao implementarmos OKRs, conseguimos tornar o time cada vez mais focado em entender e resolver problemas.

Ao me juntar à Lopes, encontrei algo bastante similar. Um time de portal, outro de CRM e outro de app, todos eles com entregas predefinidas até 6 meses à frente, porque foi isso o que foi acordado com a direção da empresa. Inclusive a Lopes tinha contratado duas empresas de consultoria que, ao apresentarem seus relatórios de resultados, mostravam a quantidade de funcionalidades entregues como seu principal resultado, porque foi isso que foi demandado delas: entrega de funcionalidades.

É importante notar que uma situação como essa não acontece exclusivamente por responsabilidade do time de desenvolvimento de produto. É também responsabilidade das pessoas que estão fazendo as demandas. Enquanto o time de desenvolvimento de produto deve sempre perguntar qual é o problema que está tentando resolver com aquela demanda, as pessoas que fazem as demandas devem sempre contextualizar essas demandas trazendo o problema que as motivou.

Após meus primeiros 30 dias na Lopes, já comecei a trabalhar com o time na definição dos OKRs para o próximo trimestre, o que motivou inclusive o RH a também fazer seu planejamento baseado em OKRs. Depois, esses OKRs foram apresentados para toda a liderança da empresa. Foi a forma que encontrei de provocar a mudança de cultura e de mentalidade tanto no time de desenvolvimento de produto quanto em toda a empresa.

A maioria dos OKRs que definimos devem ser focados em resultados de negócio. Aumento de vendas, melhoria da taxa de atendimento e assim por diante. É isso o que importa para o negócio. As funcionalidades são um meio, não um fim em si mesmo — até mesmo em empresas 100% digitais, como a Conta Azul e a Locaweb, os produtos digitais são um meio para o fim.

Vamos Tirar o Produto do Centro?

Trabalho com produtos digitais há mais de 30 anos. Eu me formei em engenharia de computação no ITA no início da década de 1990 e desde então trabalho em empresas cujo core business é tecnologia.

Começando com a Dialdata, minha startup de serviços de internet da época em que novas empresas de tecnologia ainda não se chamavam startups. Depois trabalhei com produtos de tecnologia na .comDominio, data center que virou Alog e depois foi comprada pela Equinix. Em seguida, passei pela Locaweb, Conta Azul e, mais recentemente, Gympass: todas empresas de tecnologia, que usam tecnologia para entregar valor para seus clientes.

No Gympass, comecei a entender a mecânica de uma empresa em que a tecnologia e o produto digital não são o core business. O produto do Gympass é um benefício corporativo que empresas contratam para dar aos seus funcionários acesso a uma rede de academias e estúdios. No final de 2019, houve um trabalho de digitalização – e diversificação – do portfólio de produtos do Gympass com o lançamento do Gympass Wellness, mas, mesmo assim, o produto principal continuou sendo a oferta de serviços de bem-estar como benefício corporativo para empresas oferecerem a seus funcionários. Os produtos digitais do Gympass são veículos para a entrega desses serviços de bem-estar.

Mesmo empresas de tecnologia têm por missão fazer “alguma coisa” por meio de tecnologia. Veja a missão da Locaweb:

• Fazer negócios nascerem e prosperarem por meio da tecnologia.

E a da Conta Azul:

• Impulsionar o sucesso dos pequenos empreendedores levando às pequenas empresas mais organização, controle e tempo por meio da tecnologia.

Por outro lado, há empresas tech bem conhecidas que sequer mencionam a tecnologia em suas missões:

• Nossa missão é capacitar cada pessoa e cada organização no planeta para alcançar mais. (Microsoft)
• Organizar as informações do mundo e torná-las universalmente acessíveis e úteis. (Google)
• Dar às pessoas o poder de compartilhar e tornar o mundo mais aberto e conectado. (Facebook)

A tecnologia e os produtos digitais não são a missão das empresas de tecnologia, são os veículos utilizados por essas empresas para cumprirem sua missão.

Quando me juntei à Lopes, empresa fundada em 1935, bem antes da existência dos computadores e da internet, comecei a entender melhor algo que eu já estava percebendo durante meu tempo no Gympass. O produto digital não deve estar no centro da empresa. A empresa não gira em torno do produto, mas sim o contrário: o produto digital está ali para servir a empresa e seus clientes, para potencializar os seus resultados e para ajudar a cumprir com sua missão — que, no caso da Lopes, é:

• Ajudar as pessoas a conquistarem o seu lugar.

Um dos produtos que estavam sendo desenvolvidos quando comecei a trabalhar na Lopes era o “MVP” do app dos corretores que descrevi no capítulo anterior. Coloquei aspas no termo MVP porque esse app estava em desenvolvimento há 7 meses e ainda faltavam 2 ou 3 meses para ele ser entregue, além dos 5 meses de discovery.

Quando o produto está no centro, as pessoas passam a se preocupar com o produto e com suas funcionalidades. E é daí que vem a cobrança por entrega de funcionalidades. No desenho do escopo mínimo de um MVP, a discussão acaba girando em torno das funcionalidades “mínimas”. Até mesmo quando usamos o termo MVP, o foco é no produto mínimo.

A forma como os times do Lopes Labs estavam organizados em meados de 2020 estava colocando o produto no centro. Um time de portal, que cuidava do portal onde as pessoas fazem buscas por imóveis, um time de CRM, para franquias e corretores, e um time de app do corretor. Times organizados e orientados por produtos. A única forma que esses times têm de resolver problemas é fazendo novas funcionalidades em seus produtos. Além disso, ter mais funcionalidades no backlog significa mais trabalho para fazer e, consequentemente, garantia de emprego. Não é de se espantar que a única forma de resolver o problema “fazer leads chegarem na mão do corretor” fosse através da funcionalidade de push notification no app. Além disso o “MVP” do app do corretor foi definido com 58 requisitos e funcionalidades e, além dessas 58, já havia mais 90 requisitos e funcionalidades com escopo definido para serem desenvolvidos após o lançamento do “MVP”. Garantia de trabalho e de emprego por um bom tempo.

Está claro que, ao colocar o produto no centro, acabamos potencializando algumas armadilhas que podem atrapalhar a nossa entrega de resultado. Então o que devemos colocar no centro? O resultado esperado. No exemplo do MVP da Lopes, o resultado esperado era fazer os leads chegarem o mais rápido possível nas mãos das corretoras para que elas pudessem entrar em contato com o possível cliente o quanto antes e engajá-lo em uma conversa com potencial de gerar uma venda de imóvel.

Se analisarmos a descrição do resultado esperado, não há menção a app, push notification, cadastro de cliente nem busca de imóveis. O resultado esperado é fazer o lead chegar o mais rápido possível nas mãos das corretoras, pois, ao fazer isso, aumentam as chances de o lead virar uma venda e, consequentemente, trazer resultado para a Lopes, para a corretora e para a cliente. Se nos focarmos mais no problema, veremos que há outras possíveis soluções além do app para corretores. Podemos enviar notificações via SMS ou WhatsApp, algo bem mais simples e rápido de desenvolver do que um app — e provavelmente com alcance maior, pois todos os celulares aceitam SMS e a maioria das pessoas no Brasil têm WhatsApp, enquanto um app precisa ser baixado pelo usuário.

Produto é meio, não é fim

Tenho repetido com frequência que produto, app, site, tecnologia, dados, algoritmos, não são o fim, não são o objetivo; são veículos para se atingir o objetivo de entrega de valor e devem ser tratados como tal. Fazer o lead chegar mais rápido na mão das corretoras pode ser feito por push notification em um app para corretores, mas também pode ser feito por notificação SMS ou WhatsApp. O veículo importa menos do que o resultado entregue.

No exemplo do time que estava trabalhando há mais de um ano em um “MVP” de um app para corretores, tínhamos um time com pessoas de engenharia, design e gestão de produtos focado em desenvolver um produto: o app para corretores. Por estar organizado para desenvolver um produto, a única forma que esse time sabia para resolver problemas era por meio desse produto.

Além desse time do app para corretores, tínhamos na Lopes mais dois times focados em produtos. Um deles era o time de portal, que cuidava do site onde as pessoas fazem buscas por imóveis, e um terceiro time de CRM, que desenvolvia o CRM usado pelos corretores e pelas franquias da Lopes.

Os produtos digitais para a Lopes são um veículo de entrega de valor. A Lopes não comercializa o app para corretores, o portal ou o CRM como produtos. Por esse motivo, fizemos uma mudança na estrutura de times da Lopes. Saímos de uma organização de times por produto para times por atores do nosso negócio. Criamos três times:

• Cliente final, que é quem busca um imóvel para compra ou aluguel;
• Incorporador e proprietário, que é quem quer vender ou alugar um imóvel;
• Corretores e franquias, que fazem a intermediação acontecer.

Cada um deles tem foco em entregar valor para o seu públicoalvo, não importando o veículo de entrega desse valor. Pode ser por um sistema web, um app, notificação via SMS, chatbot etc. O que importa é entregar valor — e resultado — para corretores e franquias o mais rápido possível.

Como vimos, mesmo as empresas de tecnologia como Google, Microsoft, Facebook, Locaweb e Conta Azul não colocam o produto no centro de suas missões e propósitos. Produto, app, site, tecnologia, dados e algoritmos não são o fim, não são o objetivo: são veículos para atingirmos os objetivos de resultado da empresa enquanto resolvemos problemas de nossos clientes.

Transformação digital e cultura de produto

Esse artigo é mais um trecho do meu mais novo livro “Transformação digital e cultura de produto: Como colocar a tecnologia no centro da estratégia da sua empresa“, que vou também disponibilizar aqui no blog. Até o momento, já publiquei aqui:

• Sobre o livro
• Parte 1: Conceitos
  • Capítulo 1: A tal da transformação digital – Projeto e Produto
  • Capítulo 2: Incerteza e transformação digital
  • Capítulo 3: Tipo de empresa
  • Capítulo 4: Tipo de empresa x maturidade digital
  • Capítulo 5: Modelos de negócio
  • Capítulo 6: Cultura ágil, digital e de produto
• Parte 2: Princípios
  • Capítulo 7: Entregas rápidas e frequentes – Medindo e gerenciando a produtividade – Estudo de caso: Grupo Dasa – Estudo de caso: Itaú Unibanco
  • Capítulo 8: Foco no problema – O Famoso Discovery de Produto – Por que o modelo “negócios demanda → tecnologia implementa” não funciona? – Estudo de Caso: Magazine Luiza
  • Capítulo 9: Entrega de resultado