Indicadores leading e lagging

Conversando em uma sessão de mentoria sobre um conceito de dados que considero muito importante, notei que eu ainda não havia escrito sobre esse conceito, então aqui vai. Quem me conhece sabe da importância que dou às métricas. São essenciais para entender o que está acontecendo e para ajudar na tomada de decisões. Existe uma forma classificar métricas que ajuda muito a entender o potencial de impacto da métrica. Em inglês os termos usados são leading e lagging.

Predição de churn

Para explicar o que são e qual a diferença entre indicadores leading e indicadores lagging, vou contar sobre um trabalho que fizemos tanto na Locaweb quanto na Conta Azul para descobrir maneiras de predizer o churn, ou seja, predizer quais clientes tinham maior probabilidade de cancelar o serviço contratado. Fizemos várias análises para descobrir que comportamentos indicavam com maior chances de acerto que um cliente iria cancelar e descobrimos vários comportamentos interessantes como, por exemplo, que um cliente de hospedagem de sites que redireciona o seu domínio para apontar para um site hospedado em outro lugar, provavelmente o fez porque está mudando de serviço de hospedagem. Ou se seu site tinha alto volume de acesso e esse volume reduziu drasticamente, também há boas chances que ele vai cancelar seu serviço de hospedagem de sites. Ou se um cliente do Conta Azul que costumava registrar 50 vendas por mês, diminui a quantidade de vendas registradas até zero, há grandes chances de esse cliente cancelar sua conta na Conta Azul.

O churn é exemplo de indicador lagging pois ele conta o que aconteceu – clientes cancelaram. Indicadores lagging são métricas que nos ajudam a avaliar o resultado de uma empresa. Exemplos de indicadores lagging são churn, receita, lucro, número de clientes e NPS. São métricas que devem ser acompanhadas frequentemente, em alguns casos até mesmo diariamente ou mesmo mais de uma vez por dia, mas elas são a consequência. Elas mostram o resultado, mas não mostram como esse resultado foi obtido.

Para entender como um resultado foi obtido devemos usar os indicadores leading. No exemplo acima do churn e da pesquisa dos fatores que ajudam a predizer o churn, os comportamentos dos clientes que foram detectados como preditores do churn, ou seja, quantidade de acessos de um site ou quantidade de vendas registradas são os indicadores leading. Esse tipo de indicador ajuda a predizer um resultado, ou seja, ajuda a predizer como irá se comportar um indicador lagging. E é nos indicadores leading que devemos focar nossa energia, para que possamos ver o ponteiro do indicador lagging mexer.

Causa e efeito

Por exemplo, o que devemos fazer para diminuir o churn de um produto? Garantir que o produto esteja sendo usado e sendo útil, ou seja, resolvendo um problema ou atendendo uma necessidade de seu usuário. Na Locaweb, no produto de hospedagem de sites, o site tem que ser útil para o dono do site. O que esse dono do site ou loja virtual espera desse site? Visitas? Clientes? Compras? Como ajudar o dono do site a atingir seu objetivo? Esse é o caminho para evitar o churn. Na Conta Azul, qual é o comportamento esperado de um cliente que está resolvendo seus problemas de gestão utilizando o produto? Quantas vezes por semana ele acessa? O que ele faz quando se loga no sistema? Como posso fazer para ajudar o cliente a tirar o máximo de proveito do seu produto?

Por isso, sempre que vejo times de produto definindo metas de churn ou mesmo de NPS, eu recomendo incluir metas de engajamento, e deixar churn e NPS não como metas, mas sim como métricas a serem acompanhadas. Se você tiver um produto que gera um engajamento dentro do que você havia planejado para esse produto, você muito provavelmente terá um churn baixo e um bom NPS.

É um pouco difícil traduzir os termos leading e lagging para o português, mas uma forma de ajudar a entender esses conceitos é pensar em causa e efeito, ou seja, indicador causa e indicador efeito. Enquanto churn e NPS são indicadores efeito, o engajamento pode ser visto como um indicador causa.

OKRs

Pensando nos OKRs, uma forma de utilizar indicadores leading e indicadores lagging é pensar nos indicadores lagging, ou indicadores efeito, como objetivos e indicadores leading, ou indicadores causa, como os key results (resultados chave).

Usando o clássico exemplo do OKR de emagrecimento, emagrecer 3 kilos é o objetivo, e é um indicador lagging ou indicador efeito. Enquanto os key results de fazer exercício 3 vezes por semana, não comer doces e limitar caloris ingeridas por dia a um determinado valor são indicadores leading ou indicadores causa.

Resumindo

  • Uma importante maneira de enxergar as métricas é entender se a métrica é um indicador lagging, ou seja, um indicador que é consequência como, por exemplo, receita, lucro, churn, número de clientes e NPS, ou se é um idicador leading, ou seja, um idicador que é causa, como por exemplo o engajamento de um cliente com um produto é a causa de um churn menor e de um NPS maior.
  • Indicadores leading podem ser vistos como a causa enquanto indicadores lagging podem ser vistos como o efeito.
  • Nos OKRs, os objectives são os indicadores lagging, enquanto os key results são os indicadores leading.

Gestão de produtos digitais

Você trabalha com produtos digitais? Quer saber mais sobre como gerenciar um produto digital para aumentar suas chances de sucesso, resolver os problemas do usuário e atingir os objetivos da empresa? Confira meu pacote de gerenciamento de produto digital com meus 3 livros, onde compartilho o que aprendi durante meus mais de 30 anos de experiência na criação e gerenciamento de produtos digitais. Se preferir, pode comprar os livros individualmente:

O que é inovação?

De todas as fases do ciclo de vida de um produto de software, a fase de inovação é a que costuma ter a maior quantidade de dúvidas. Mas o que é inovação? Como encontrar um problema a ser resolvido? Como descobrir se esse problema é, de fato, uma oportunidade a ser perseguida? E como obter retorno com seu produto de software?

Inovação é um termo usado com frequência por várias pessoas, mas a cada uma que perguntar “o que é inovação?”, você vai obter uma resposta diferente.

Algumas pessoas vão dar uma definição focada na criatividade, ou seja, vão dizer que inovação é algo criativo, algo que não existia antes, algo diferente do que se encontra no dia a dia.

Existem vários produtos, não só de software, que são bastante criativos. Existem lojas dedicadas a esses produtos criativos. Nos Estados Unidos, uma loja bastante conhecida de produtos criativos é a Sharper Image.

Ar-condicionado portátil

Sem dúvida, esse ar-condicionado portátil da Sharper Image é um produto bastante criativo.

Outra empresa que comercializa esse mesmo tipo de produto é a SkyMall, que distribui nos aviões de voo local nos Estados Unidos aquele catálogo cheio de produtos diferentes e criativos. Aqui no Brasil, a Imaginarium é uma loja que oferece esse tipo de produtos.

No entanto, estes produtos chegam a ser realmente uma inovação? Quantas pessoas precisam de um ar-condicionado portátil? Isso resolve algum problema ou uma necessidade de um conjunto de pessoas?

Além das pessoas que associam inovação à criatividade, existem aquelas que entendem inovação como sendo a última tecnologia. Computador quântico, transmissão de eletricidade sem fio, edição de genoma, realidade virtual, realidade aumentada, nanotecnologia e internet das coisas são alguns exemplos das tecnologias mais recentes.

Então, novamente faço a mesma pergunta: estes produtos são realmente uma inovação? Quantas pessoas precisam dessas tecnologias? Isso resolve algum problema ou uma necessidade de um conjunto de pessoas?

Definindo Inovação: Inovar não é simplesmente ser criativo ou conhecer a última tecnologia. É preciso conhecer as tecnologias disponíveis e saber como usá-las para resolver um problema ou atender a uma necessidade de um grupo de pessoas, isso tem o potencial de produzir uma inovação.

Essa definição deixa claro que a inovação – e podemos olhar a criação de um novo produto de software como uma inovação – deve começar pela descoberta e entendimento de problemas e necessidades de um grupo de pessoas.

Mas como fazer isso? O cliente sabe o que quer?

Claro que o cliente sabe o que quer

“Os clientes não sabem o que querem”. Infelizmente, é comum ouvir esta frase em conversas sobre produtos e clientes. Em determinada altura, alguém soltará a famosa frase de Henry Ford, o inventor do automóvel:

“Se eu tivesse ouvido os usuários, em vez do automóvel eu teria inventado uma carroça mais rápida.” – Henry Ford

Aliás, quem gostava de repetir essa frase à exaustão era o eterno CEO da Apple, Steve Jobs.

No entanto, eu discordo. Os clientes sabem o que querem. Eles querem uma solução para seus problemas. É aí que Henry Ford, Steve Jobs e nós, o resto dos mortais, entramos, querendo desenvolver produtos para resolver esses problemas.

Os primeiros passos para criar um bom produto são:

  • Perceber que existem pessoas com um problema ou uma necessidade a ser resolvida;
  • Entender muito bem qual é esse problema ou necessidade;
  • Entender o que motiva as pessoas a querer que esse problema ou necessidade seja resolvida.

Quando você conversar com pessoas com problemas ou necessidades, algumas até dirão que acham que esse problema poderia ser resolvido assim ou assado; entretanto, nesse momento, o mais importante é descobrir se existe uma necessidade a ser resolvida. Você deve separar o problema da sugestão de solução que seu interlocutor está tentando passar.

As pessoas demoravam muito tempo para se locomover. Esse provavelmente era o problema que as pessoas queriam que fosse resolvido na época de Henry Ford. Não importava como. Podia ser com mais cavalos na frente da carroça, podia ser com cavalos treinados para andar de patins, podia ser com cavalos geneticamente modificados para andar mais rápido, podia ser com a invenção do automóvel, podia ser com a invenção do avião, podia até mesmo ser com a invenção do teletransporte.

A solução específica para o problema não importava, desde que fosse resolvido. Algumas pessoas provavelmente devem ter sugerido soluções, como a carroça mais rápida da famosa frase de Henry Ford, mas isso é só uma sugestão de solução. O problema a ser resolvido é que as pessoas gastavam muito tempo se locomovendo. Note que o problema não é que as pessoas queriam se locomover mais rápido. Isso já é parte da solução.

Nos próximos capítulos, veremos algumas técnicas para ajudar a descobrir e a entender bem problemas ou necessidades.

Gestão de produtos digitais

Este artigo faz parte do meu livro Gestão de produtos: Como aumentar as chances de sucesso do seu software, onde falo sobre o que é gestão de produtos digitais, seu ciclo de vida, que ferramentas utilizar para aumentar suas chances de sucesso. Você também pode se interessar pelos meus outros dois livros:

Ciclo de vida de um produto digital

Já falei um pouco sobre o que é gestão e gestor de produtos de software, suas principais características, sobre como gerenciar gestores de produtos e até mesmo algumas dicas de liderança e de cultura organizacional para ajudar gestores a liderar sem serem “chefes”.

Agora, vamos falar sobre o ciclo de vida de um produto de software e suas diferentes fases: inovação, crescimento, maturidade e fim de vida.

  • Inovação: de todas as fases do ciclo de vida de um produto de software, acredito que a de inovação é a que tem a maior quantidade de dúvidas. É também a fase que tem a maior quantidade de livros. Basta ir à Amazon e procurar livros sobre inovação e startup. Nas próximas páginas, vamos explorar as seguintes perguntas.
    1. O que é inovação?
    2. Como encontrar um problema a ser resolvido?
    3. Como descobrir se esse problema é, de fato, uma oportunidade a ser buscada?
    4. Como obter retorno do seu produto de software?
  • Crescimento: nessa fase, quando o produto foi desenvolvido e lançado, devemos nos preocupar em como gerenciar o produto durante seu crescimento, ou seja, como gerenciar o feedback? O que é um roadmap? Como priorizar as demandas? O que fazer com pedidos especiais? Como dizer não? Que métricas acompanhar?
  • Maturidade: após o crescimento, vem a maturidade. Nessa parte, vamos entender quando ela acontece e o que fazer se o produto chegar a essa fase.
  • Fim de vida: depois da maturidade, ou quando o produto é desenvolvido mas não dá certo, chega a fase conhecida como fim de vida de um produto de software. Vamos ver como detectar e o que fazer nela.

Vamos começar?

Como é o ciclo de vida de um produto de software?

Antes de vermos como é o ciclo de vida, precisamos entender a curva de adoção de tecnologia. Esse conceito apareceu pela primeira vez em um livro de 1962, chamado Diffusion of Innovations, escrito por Everett M. Rogers, sociólogo e professor da Universidade Estadual de Iowa. Nesse livro, Rogers explica que as inovações tecnológicas são adotadas conforme a curva mostrada na figura a seguir:

Curva de adoção de tecnologia

No começo, os inovadores são os primeiros a se interessar por novos produtos e inovações. Topam até produtos incompletos e com defeitos, pelo prazer de serem os primeiros a utilizar esse novo produto. Em seguida, estão os early adopters, também conhecidos como visionários ou entusiastas, que aceitam os riscos de testar um novo produto, não pelo prazer de ser o primeiro, mas sim porque enxergam seu potencial. Normalmente, têm influência nas organizações e comunidades de que fazem parte.

Early majority, também chamados de pragmáticos, compram novos produtos somente depois de ter referências. Late majority são os conservadores, ou seja, aqueles que compram somente depois que o preço caiu consideravelmente. Por fim, há os laggards, que só compram um novo produto se essa for a única opção disponível.

Fazendo a integral dessa curva (quem se lembra das aulas de cálculo?), obteremos a famosa curva em S de adoção de tecnologia.

Curva S de adoção de tecnologia


Essa curva em S pode ser quebrada em 3 fases: o início mais lento, que é a fase de inovação; em seguida vem a fase de crescimento, quando early majority e late majority adotam o produto; e, por fim, a fase de maturidade, quando o produto já conquistou praticamente todo o mercado.

Curva S e as 3 fases

Na sequência, veja alguns exemplos da curva S.

Curva S na vida real

Nem sempre é tão perfeita quanto a curva teórica, mas se aproxima bastante. A curva da TV é a que mais se aproxima, e explica por que toda hora os fabricantes de televisões estão inventando algo novo para nos fazer comprar uma nova.

Primeiro, eram TVs em preto e banco; depois, as coloridas. Aí vieram as com controle remoto, tela plana, tela de plasma, LCD, LED, 3D e SmartTV. Tudo isso para que os fabricantes pudessem continuar tendo nova receita de seus clientes, uma vez que o mercado da TV amadureceu uns 30 anos depois que ela foi inventada. As curvas de internet e de celulares parecem crescer da mesma forma. Já as curvas de PC, eletricidade, aviões, telefone e automóveis têm algumas alterações em seu desenho; mas, de forma geral, se assemelham bastante à curva S teórica.

Outro exemplo de curva, mais próximo de quem está envolvido com desenvolvimento de software, é a curva de quantidade de registro de domínios .br feitos.

Registro de domínios .br até 2018

Dá para notar nessa curva a aceleração típica da fase da inovação que aconteceu entre 1996 e 2008. A partir desse ano, entramos na fase de crescimento. Parece que, a partir de 2013, está acontecendo uma desaceleração dessa curva. Em 2017, parece que entramos na fase de maturidade. Pessoas e empresas parecem não estar mais registrando domínios, pois existem outras maneiras de se estar presente na internet (mercados, Facebook, Instagram, etc.).

Contudo, veio a pandemia da COVID-19, que ac elerou muito os negócios digitais.

Registro de domínios .br até 2021

O abismo

Sempre tem um “mas”. Em 1991, Geoffrey Moore escreveu um livro intitulado Crossing the Chasm: Marketing and Selling High- Tech Products to Mainstream Customers.
Nesse livro, ele explica que entre os early adopters (entusiastas) e a early majority (pragmáticos) existe um abismo que muitos produtos não conseguem cruzar. Isso acontece pois os pragmáticos precisam de boas referências para poder comprar um novo produto, e os entusiastas normalmente não são boa referência. Daí a dificuldade de alguns produtos cruzarem esse abismo.

Cruzando o abismo

No livro, Moore também apresenta estratégias para cruzar esse abismo; só que, infelizmente, as estratégias propostas são todas baseadas em estratégias de guerra que, como expliquei no capítulo anterior, não acho que fazem muito sentido para o mundo dos negócios.

A estratégia proposta, tirando a referência à guerra do livro, resume-se em foco. Procure se focar em um único tipo de cliente e resolver muito bem o problema dele com seu produto. Quando esse cliente estiver muito satisfeito, aí é o momento de você procurar novos tipos de clientes.

O abismo descrito por Moore mostra um dos dois possíveis caminhos de um produto de software:

  • Não vai cruzar o abismo: a empresa não consegue fazer seu produto ir além dos entusiastas e, consequentemente, não terá clientes para sobreviver. Esse é um dos motivos da morte prematura de muitas startups.
  • Amadurecer: seu produto vai dar certo e a empresa vai eventualmente chegar ao topo da curva S, e desacelerará até que alguma outra empresa invente um produto que substitua o seu. Veja a Kodak que, até hoje, não se recuperou da invenção das máquinas digitais, pois tinha sua receita vinda primariamente da venda de filmes e material fotográfico.

Com isso, chegamos à quarta fase do ciclo de vida de um produto de software: o fim – em inglês, usa-se um termo mais elegante, sunset.

Temos, então, quatro fases no ciclo de vida de um produto de software: a inovação, o crescimento, a maturidade e o fim.

Ciclo de vida de um produto de software

Vamos agora conhecer cada uma dessas fases em mais detalhes e entender o papel da gestão de produtos em cada uma delas.

Gestão de produtos digitais

Este artigo faz parte do meu livro “Gestão de produtos: Como aumentar as chances de sucesso do seu software”, onde falo sobre o que é gestão de produtos digitais, seu ciclo de vida, que ferramentas utilizar para aumentar suas chances de sucesso. Você também pode se interessar pelos meus outros dois livros:

Cultura Organizacional

Cultura organizacional é um tema muito importante para gestores de produtos; por isso, quero abordar um pouco dele aqui. De uma certa forma, esse assunto complementa o capítulo Dicas de liderança para gestores de produtos.

Cultura organizacional é uma característica de toda empresa. Até mesmo dentro de uma empresa existem subculturas, ou seja, cada área ou time dentro de uma empresa pode ter uma cultura própria. Por exemplo, a cultura de um time comercial tem sempre algumas diferenças da cultura do time de engenharia de software.

Não existe cultura certa ou cultura errada. Empresas diferentes têm culturas diferentes e, mesmo assim, podem ter sucesso apesar dessas diferenças. A charge a seguir ilustra a diferença de cultura entre Amazon, Apple, Facebook, Google, Microsoft e Oracle. Mesmo com essas diferenças culturais, todas são empresas de sucesso.

Por Manu Cornet. Fonte: http://www.bonkersworld.net/organizational-charts/

Mas o que é cultura organizacional? Edgar Schein, professor da escola de administração de empresas do MIT, foi uma das primeiras pessoas a falar sobre cultura organizacional nos anos 1970. Segundo ele, cada empresa tinha sua própria personalidade, e sua própria forma de agir e reagir às situações; forma esta que é passada de funcionário para funcionário desde os fundadores da empresa. A definição de Schein para cultura organizacional é:

CULTURA ORGANIZACIONAL

Cultura é um conjunto de premissas que foram aprendidas e compartilhadas por um grupo de pessoas enquanto resolviam problemas de adaptação externa e de integração interna. Esse conjunto de premissas funciona bem o suficiente para ser considerado válido e, consequentemente, ser ensinado aos novos membros do grupo como a forma correta de perceber, pensar e sentir em relação a esses problemas.

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

A cultura vem dos fundadores da empresa. Os fundadores têm sua própria cultura e é natural que imprimam essa cultura na organização que estão criando. Em função disso, é muito comum se pensar que ela é algo que emerge em uma organização.

O fundador traz sua cultura e, ao contratar novas pessoas, busca sempre pessoas com cultura similar à sua. Isso acaba criando uma cultura comum muito próxima daquela trazida pelo fundador da empresa. Esse conceito de cultura emergente dá a impressão de que não se pode alterá-la deliberadamente, e que ela se desenvolverá de forma orgânica.

Schein alerta que isso é um engano. Culturas podem e devem ser planejadas. Por esse motivo, vou compartilhar três valores de cultura organizacional que tenho visto em algumas empresas e que, a meu ver, são essenciais na criação de produtos de software de sucesso.

NÃO DESPERDIÇAR TEMPO BUSCANDO CULPADOS

Quando erros acontecem, algumas pessoas têm uma tendência natural de ter como sua primeira reação procurar quem é o culpado, especialmente em atividades de grupo. Como se ter alguém para culpar fizesse o erro, de alguma forma, menos prejudicial. Isso é um grande desperdício de tempo e energia. Deixe-me explicar o porquê.

Blame game, por Ron Tandberg

Ocorreu um erro. Erros acontecem. Este é um fato da vida. Não importa o que você está fazendo – desenvolvendo software, publicando código em produção, operando um paciente, cozinhando o jantar, construindo uma casa, tocando guitarra, jogando futebol etc. –, há boas chances de que erros venham a acontecer.

Quando você gasta tempo tentando descobrir quem foi o responsável pelo erro, você vai adiar suas tarefas mais importantes em relação a ele:

  • Compreender o que aconteceu;
  • Descobrir como corrigir;
  • Encontrar formas de evitar que isso aconteça novamente.

Quando você gasta tempo tentando descobrir quem foi o responsável pelo erro, as pessoas podem, naturalmente, tentar esconder o erro por temer as consequências. Será que vou ser demitido? Será que vou ser excluído do grupo? Será que vou ser punido? Será que as pessoas vão zombar de mim?

Quando as pessoas tentam esconder quem foi o responsável, você vai acabar adiando as tarefas mais importantes que listei para tratar o erro, pois será mais difícil entender o que aconteceu. As pessoas não vão dizer toda a verdade sobre o erro e as circunstâncias em que ele aconteceu.

Se no processo de entender o que aconteceu, você descobrir que alguém foi responsável pelo erro, lide com ele em particular. O mais provável é que ele o tenha causado sem intenção de fazer mal. Por isso você precisa ajudá-lo a melhorar para que ele não cometa mais esse tipo de erro.

Por outro lado, você tem a responsabilidade de criar um ambiente em que é seguro falar sobre erros, para que estes sejam detectados o mais rápido possível. Contudo, se você descobrir que o erro foi feito com intenção de prejudicar a companhia, algum time ou alguma pessoa, nesse caso você deve ser direto na repreensão, dizendo que o comportamento é inaceitável e, na reincidência, convidar essa pessoa a sair do grupo.

GUERRA

É comum ouvir comparações entre o mundo dos negócios e situações de guerra, de combate e de luta. Aliás, a própria palavra “estratégia”, tão comum nas empresas de hoje em dia, vem do mundo militar. Vem da palavra grega strategos, junção das palavras stratos (exército) e agos (líder). Strategos significa originalmente o líder do exército, o general, aquele que define como a tropa deverá agir frente às situações.

Um dos livros que constantemente aparece na lista de mais recomendados para administração é A Arte da Guerra, um tratado militar escrito durante o século IV a.C. por Sun Tzu, general chinês.

Quem me conhece sabe que sou uma pessoa pacífica. Odeio brigas. Aliás, se acidentalmente entro em uma, estou disposto até a pagar para sair. Por isso, sempre que vejo essas comparações do mundo de negócios com guerra, combate, luta ou competição, eu me sinto profundamente incomodado.

Acho que essas imagens falam por si só… Usar guerra (combate ou luta) como analogia para o mundo dos negócios não faz o mínimo sentido. Nelas, o objetivo é derrotar o adversário. É estranho imaginar uma empresa cujo objetivo principal seja derrotar algo ou alguém.

Algumas pessoas já comentaram comigo que, em uma guerra, a guerra em si não é o objetivo, mas sim um meio para se atingir um objetivo. Ok, faz sentido, mas existem vários meios para se atingir um determinado objetivo. A guerra não é o único meio. Por que então a insistência em usar a guerra como analogia para as empresas?

Buscando na Wikipédia, encontramos a seguinte definição para empresa:

EMPRESA

Empresa é uma instituição jurídica despersonalizada, caracterizada pela atividade econômica organizada, ou unitariamente estruturada, destinada à produção ou circulação de bens ou de serviços para o mercado ou à intermediação deles no circuito econômico.

Fonte: http://pt.wikipedia.org/wiki/Empresa.

Esta definição deixa claro que a empresa existe para produzir e/ou servir. Como pode algo que tem por objetivo produzir e/ou servir, ter por analogia algo que tem como objetivo a destruição? A maneira correta de olhar uma empresa e seus objetivos é pensando em construção, em relação ganha-ganha, onde o cliente, os funcionários, os donos da empresa e a sociedade na qual a empresa está inserida saem ganhando. Sempre que direcionamos energia para derrotar o “oponente” (cliente, competidor, funcionário etc.), estaremos desperdiçando energia que poderia ser usada em algo construtivo.

AR, COMIDA E LUCRO

Não raro vemos acionistas, investidores e funcionários de uma empresa 100% focados nos resultados financeiros. Quando em período de crise, esse foco consegue ir além dos 100%… :-/

Certa vez ouvi uma frase, popularizada por Dick Costolo, CEO do Twitter, que comparava receita a oxigênio:

Receita é como oxigênio, é necessário, é vital para a saúde e para o sucesso de uma empresa, mas não é propósito da vida. Você não acorda de manhã e a primeira coisa que pensa é “como eu posso conseguir mais ar?”.

Gosto bastante dessa comparação. Toda empresa deve ter um propósito, e esse propósito não pode ser derrotar os inimigos (como explicado anteriormente), nem conseguir a maior quantidade de dinheiro possível.

O resultado financeiro deve sempre ser usado como uma das métricas que indicam que a empresa está tendo sucesso, que está cumprindo com o seu propósito. Contudo, mesmo como métrica, ela não deve ser olhada de forma isolada, pois existe a boa e a má receita.

A má receita é toda receita obtida às custas do detrimento do relacionamento com o cliente. Por exemplo, imagine uma empresa que presta um serviço com pagamento mensal; quando um cliente quer cancelar, ela dificulta sua saída para manter aquela fonte de receita por mais alguns meses. Isso é uma má receita. Quando uma companhia aérea cobra uma taxa para adiantar o horário de um voo, mesmo sabendo que o avião tem espaço de sobra; isso é má receita. As taxas de roaming internacionais exorbitantes também são um bom exemplo disso, como locadoras de veículos que cobram a taxa de gasolina quando você devolve o carro sem estar com o tanque cheio, com preço de gasolina bem mais caro do que o do mercado.

Se uma empresa vende algo com o preço acima do adequado, aproveitando-se do fato de que você precisa daquele item como, por exemplo, o custo absurdo da garrafa de água em um hotel, isso também é uma má receita.

Apesar de a comparação de receita e lucro com oxigênio ser boa, ela é incompleta, pois não capta o efeito da má receita. Raramente você pensa no oxigênio, a não ser que esteja com falta de ar. Eu não acho que a receita só deva ser lembrada quando está faltando. Receita é o que mantém a empresa viva, capaz de executar seu propósito. Se for uma boa receita, a empresa vai continuar cumprindo seu propósito por muitos anos. Já se for uma má, ela terá dificuldades no médio prazo.

Por esse motivo, prefiro comparar receita e lucro com comida. Da mesma forma que as pessoas saudáveis não pensam em oxigênio o dia inteiro, pessoas saudáveis também não pensam em comida o dia todo. Contudo, diferentemente do oxigênio, quando falamos de comida, existe a comida boa, saudável, que faz bem para o seu corpo; e existe a comida má, que vai prejudicar seu organismo, com possibilidade de fazer você ficar doente. É muito importante que a pessoa saiba o que é boa comida e má comida, e que pense sobre como obter a boa e como evitar a má.

Pegando a frase de cima e aprimorando-a, trocando o oxigênio pela comida, teremos:

Receita é como comida, é necessária, é vital para a saúde e para o sucesso de uma empresa, mas não é propósito da vida. Você não acorda de manhã e a primeira coisa que pensa é “como eu posso conseguir mais comida?”. Contudo, tanto uma empresa quanto uma pessoa devem estar sempre atentas à qualidade da comida que está ingerindo, para ter certeza de que ela não vai causar nenhum mal à saúde.

Concluindo

Vimos neste capítulo o quão importante é a cultura organizacional para o sucesso do seu produto de software, e que cultura não é um tema para deixar acontecer, ele pode e deve ser planejado. Compartilho três valores culturais que, a meu ver, são essenciais para a criação de um software de sucesso:

  • Não desperdiçar tempo buscando culpados;
  • Não comparar fazer negócios com guerra, combate ou luta;
  • Pensar em receita como comida, ou seja, algo necessário para viver, mas não é a razão do viver.

Gestão de produtos digitais

Este artigo faz parte do meu livro “Gestão de produtos: Como aumentar as chances de sucesso do seu software”, onde falo sobre o que é gestão de produtos digitais, seu ciclo de vida, que ferramentas utilizar para aumentar suas chances de sucesso. Você também pode se interessar pelos meus outros dois livros:

Gerindo gestores de produto

Da mesma forma que nem todo bom desenvolvedor pode virar um bom gestor de desenvolvedores, o mesmo acontece com gestores de produto. Assim como as habilidades que uma pessoa tem que ter para gerir desenvolvedores de software é diferente das habilidades que um desenvolvedor precisa ter para ser um bom desenvolvedor de software, as habilidades que um gestor de gestores de produto precisa ter para gerir gestores de produtos é diferente das habilidades que um gestor de produtos produto precisa ter para gerir seu produto.

gestor_de_gestores

Então o que faz um gestor de gestores de produtos?

Um gestor de gestores de produtos tem basicamente duas preocupações, uma tática e outra estratégica:

  • Ajudar os gestores de produto a performarem melhor. Essa é a preocupação tática do gestor de gestores de produto. Ele deve ser capaz de ajudar o gestor de produto a desenvolver as principais características de um bom gestor de produto, empatia, comunicação, gestão do tempo, conhecimento de novas tecnologias, business skills, curiosidade aguçada e conhecimento sobre o tema do produto. Todas essas características são fundamentais para o sucesso do gestor de produtos e nem sempre o gestor de produtos consegue perceber o que precisa ser melhorado ou, se percebe, não sabe bem como melhorar. Aí entra o gestor de gestores de produto, que deve ajudar o gestor de produtos a ver quais características tem espaço para melhoria e como melhorar cada uma delas. Muitas vezes há mais de uma característica que precisa ser melhorada e aqui o gestor de gestores de produto pode mais uma vez ajudar a perceber prioridades, ou seja, qual característica deve ser trabalhada primeiro.
     
  • Ajudar os gestores de produto a criar a visão e a estratégia dos produtos. Essa é a preocupação estratégica do gestor de gestores de produto. Ele deve ser capaz de ajudar os gestores de produto a criar a visão e a estratégia dos produtos da empresa. Aqui é importante fazer uma distinção entre as duas opções de estratégia de portfólio de produtos que uma empresa pode escolher, foco ou diversificação. Em uma empresa que optou pelo foco, cabe ao gestor de gestores de produto coordenar o processo de criação de visão e estratégia do produto da empresa. Ele deve, em conjunto com seus gestores de produto, designers de UX, pessoal de engenharia e gestores de mkt de produto, criar a visão do produto da empresa e desenhar a estratégia para chegar nessa visão. Já em uma empresa que optou pela estratégia de diversificação de portfólio de produto, a responsabilidade do gestor de gestores de produto é ajudar cada gestor de produto a coordenar o processo de criação da visão e do desenho da estratégia de seu produto específico. Além disso em uma empresa que optou pela diversificação, cabe ao gestor de gestores de produtos fazer a gestão do portfólio de produtos, ou seja, garantir que o portfólio de produtos está alinhado com os objetivos estratégicos da empresa e garantir que cada produto tenha o devido investimento de desenvolvimento e de mkt de produtos.

Para ser um bom gestor de gestores de produto é importante que a pessoa já tenha sido gestora de produtos, ou seja, que ela já tenha colocado a “mão na massa” e tenha cuidado diretamente das questões táticas e estratégicas de um produto. Isso irá ajudá-la quando estiver gerindo o trabalho de outros gestores de produto. Contudo, é preciso tomar muito cuidado para não fazer o trabalho no lugar do gestor de produtos ao invés de ajudá-lo a se desenvolver e a fazer seu trabalho. Note que em ambas as preocupações que descrevi acima eu usei “ajudar os gestores de produto”. Por já ter sido um gestor de produtos, é tentador para o gestor de gestores de produtos, no momento em que algum gestor de produto sob sua gestão estiver com dificuldades, fazer o seu trabalho. Mas a função do gestor de gestores de produto não é fazer o trabalho de gestor de produto, mas sim ensinar e ajudar os gestores de produto a fazerem seu trabalho.

Caso vc não tenha experiência como gestor de produtos, mas se veja na situação de coordenar o trabalho de gestores de produtos, como pode ser o caso de um CTO ou um gestor de time de engenharia, valem as recomendações acima, ou seja, ajudar os gestores de produtos a performarem melhor e a criar a visã e a estratégia de seus produtos.

Liderança de produtos digitais

Se você se interessou por esse assunto, irá gostar do meu mais novo livro, Liderança de produtos digitais: A ciência e a arte da gestão de times de produto, onde falo sobre conceitos, princípios e ferramentas que podem ser úteis para quem é head de produto, para quem quer ser, para quem é liderado por ou para quem tem uma pessoa nesse papel na empresa. Você também pode se interessar pelos meus outros dois livros:

Dicas de liderança para um gestor de produto

Um gestor de produtos tem a difícil tarefa de liderar a evolução do produto sem ser “chefe” de ninguém, ou seja, ele deve convencer a todas as pessoas que trabalham com seu produto de que o caminho que ele definiu para o produto é o mais adequado.

Em vários textos sobre gestão de produtos encontramos que o gestor de produtos é o CEO do produto. Não gosto muito dessa analogia pois um CEO, em última instância, tem ao seu dispor a liderança direta de todas as pessoas da empresa.

Por outro lado, um gestor de produto trabalha em uma relação matricial, ou seja, não tem liderança direta de nenhuma das pessoas envolvidas com o produto. Aliás, esse é um excelente exercício de liderança e uma qualidade extremamente importante para um gestor de produtos: liderar sem ter a “chefia” organizacional.

Mesmo que ele trabalhe em uma organização totalmente horizontal, sem nenhuma hierarquia, ele deverá exercer alguma liderança para convencer as pessoas a evoluir o produto na direção que visualizou.

Por isso, aqui vão duas dicas de liderança que um gestor de produtos, ou qualquer líder, deve lembrar para liderar de forma eficiente.

Estabelecer o contexto

A primeira dica é de caráter estratégico. O gestor de produtos tem a obrigação de:

  • Entender, comunicar e explicar o contexto no qual se insere o que está sendo trabalhado.
  • Ajudar o time a entender onde o produto se insere na estratégia da empresa e no mercado.
  • Saber como os clientes utilizam o produto e o que estes esperam dele, e qual o objetivo do produto para o cliente e para a empresa.
  • Compreender como uma determinada funcionalidade (um novo desenvolvimento que o gestor de produtos pede para o time) se insere no produto e na estratégia desse produto.

Essa dica parece simples e óbvia, mas é comum encontrar pessoas que trabalham sem saber exatamente por que estão fazendo seu trabalho. Ajudar as pessoas a verem o impacto do seu trabalho faz com que elas entendam por que ele é necessário.

Experimente levar engenheiros de software em sua próxima conversa com cliente. Melhor ainda, leve-os a um teste de usabilidade, para que eles possam ver seus usuários utilizando o software que eles desenvolveram. Isso os ajudará a entender por que o software que eles desenvolveram existe, qual problema ele resolve e para quem ele resolve esse problema.

Estabelecer o contexto ajuda muito no engajamento das pessoas que estão envolvidas com o produto. Elas vão entender a sua importância tanto para a empresa – que é dona do produto – quanto para os seus usuários. Esse engajamento é importante não só no core team do produto como também com todas as pessoas envolvidas com ele, como o pessoal de vendas, marketing, jurídico e suporte ao cliente. Todos vão se beneficiar se o gestor de produtos sempre procurar estabelecer seu contexto e mostrar onde o trabalho de cada área se insere no sucesso do produto.

Na Locaweb, temos alguns sistemas antigos que, como todo legado, são bem difíceis de mexer: pouca cobertura de testes, linguagens de programação antigas, código feito com práticas de 10 anos atrás. Sempre que é preciso mexer no código legado é um sofrimento.

Estamos já trabalhando há alguns anos para minimizar a quantidade de código legado, e essa quantidade tem de fato diminuído. Contudo, o negócio não para e, às vezes, a única saída é mexer nele. Sempre que aparece uma demanda dessas, os desenvolvedores perguntam se não dá para esperar o novo sistema que o substituirá.

No início de 2015, apareceu uma demanda desse tipo, em que era necessário mexer nos limites e preços de nossos planos de hospedagem para acompanhar as mudanças do mercado, que estava mais competitivo. Claro que, inicialmente, houve resistência dos desenvolvedores em mexer no legado, mas quando mostramos todo o racional por trás das mudanças, eles arregaçaram as mangas e “sujaram” as mãos no código antigo.

Assim que as mudanças foram implementadas, frequentemente contávamos para as pessoas que trabalharam nesse projeto sobre os seus resultados positivos. Essa compreensão de por que algo é pedido e deve ser feito é fundamental tanto para a motivação de quem for trabalhar na demanda quanto para a qualidade do que será entregue.

POR QUE O CONTEXTO É TÃO IMPORTANTE NO DESENVOLVIMENTO DE SOFTWARE

Quero propor um experimento mental. Vamos usar a empatia, a principal característica de um gestor de produto digital, para nos colocar na posição de um desenvolvedor de software que recebeu a seguinte história do gestor de produto de sua equipe:

Quando atingir 39, um alarme deve disparar.

Embora pareça ter informações suficientes, quando você começar a implementá-las, verá que essas informações estão incompletas. O que são 39? O alarme dispara quando chega a 39 vindo de 38 ou vindo de 40? Ou nos dois sentidos?

Vamos agora ver a mesma história com o contexto apropriado:

Estamos desenvolvendo um sistema que monitora a temperatura corporal e esse sistema deve soar um alarme quando a temperatura subir acima de 39ºC.

Com o contexto, fica muito mais fácil entender qual é o número 39 e por que você foi solicitado a tocar o alarme. E é mais fácil codificar o software certo.

Portanto, em sua próxima sessão de planejamento com a equipe, reserve um tempo adequado para explicar o contexto das histórias. Isso aumentará as chances de sucesso do seu software!

Remover impedimentos

Remover os impedimentos é fundamental para que as pessoas do time possam desenvolver o produto. Isso é importante para poder ter aquela gostosa sensação de progresso, de que estamos fazendo algo, construindo algo. Recentemente li o artigo “What Really Motivates Workers” (O que motiva os trabalhadores) na Harvard Business Review que mostra uma informação importante. Fizeram um estudo para encontrar o que acontece em um excelente dia de trabalho. A resposta, em uma palavra: progresso.

Pesquisa que mostra o que é um bom dia de trabalho

O conselho no final do artigo resume bem a segunda dica:

Você pode criar proativamente a percepção e a realidade do progresso. Se você é um gestor de alto escalão, tome muito cuidado para esclarecer as metas gerais, garanta que os esforços das pessoas sejam adequadamente apoiados e evite exercer uma pressão de tempo tão intensa que pequenas falhas sejam percebidas como crises e não como oportunidades de aprendizado. Cultive uma cultura de utilidade. Enquanto você está nisso, pode facilitar o progresso de uma maneira mais direta: arregace as mangas e entre em campo. É claro que todos esses esforços não apenas manterão as pessoas trabalhando com gosto, mas também farão o trabalho mais rápido.

Evitar escrupulosamente o que estiver impedindo o progresso, evitar alterar objetivos autocraticamente, evitar indecis̵es, ou segurar recursos. Eventos negativos geralmente t̻m um efeito maior sobre as emo̵̤es, percep̵̤es e motiva̵̤es das pessoas do que os positivos, e nada ̩ mais desmotivador do que um rev̩s Рo tipo mais proeminente de evento nos piores dias dos trabalhadores do conhecimento.

QUAIS IMPEDIMENTOS?

Portanto, aqui estão alguns exemplos de impedimentos que um gestor de produto pode remover:

  • Esteja presente: a equipe precisa de você. Durante o processo de desenvolvimento do produto, eles precisarão conversar com você sobre as descobertas e o que estão entregando; portanto, você precisa estar presente; caso contrário, a equipe poderá tomar decisões não alinhadas à sua visão do produto.
  • Deixe sua visão do produto clara: mesmo que você esteja presente, às vezes você simplesmente não pode estar presente. Por esse motivo, e também para estabelecer o contexto conforme explicado acima, você precisa definir sua visão e estratégia de produto, como veremos mais adiante.
  • Remova o excesso de histórias: quanto mais cedo você colocar seu produto ou funcionalidade na frente de usuários reais, mais cedo receberá feedback; portanto, você precisa remover todo o excesso do que você e sua equipe estão construindo e se concentrar apenas no mínimo necessário para obter esse feedback.
  • Gerencie expectativas e ansiedades: o gerenciamento de expectativas é uma grande parte do trabalho de um gestor de produtos. Por gerenciamento de expectativas, quero dizer gerenciar as expectativas de todos os envolvidos no produto, internos e externos. Ter as partes interessadas fazendo perguntas diretamente à equipe pode ser uma grande distração, e isso significa que você não conseguiu alinhar adequadamente sua visão e estratégia de produto
  • Ajude todos na equipe a se perceberem como proprietários do produto: todos na equipe de produto são proprietários e você tem um grande papel em ajudá-los a se perceberem como tal. Mostre a eles o contexto em que seu produto está inserido. Crie a visão e a estratégia do produto junto com eles. Compartilhe seus números de produtos, discuta com sua equipe como melhorar esses números.
  • E tudo mais que dificultar o progresso da equipe! a lista acima não é abrangente. O trabalho diário de desenvolvimento de produtos está repleto de impedimentos e distrações que podem afastar você de seu objetivo principal, criar um produto digital de sucesso que ajude sua empresa a atingir seus objetivos de negócios e resolva problemas de clientes e usuários.

Concluindo

Bom, então estão aí duas dicas de liderança para gestores de produtos e para qualquer pessoa que se veja liderando algum projeto:

  • Estabelecer o contexto;
  • Remover impedimentos.

Tenho usado-as ao longo de toda minha vida profissional e elas têm orientado meu sucesso como gestor de produtos.

Gestão de produtos digitais

Este artigo faz parte do meu livro “Gestão de produtos: Como aumentar as chances de sucesso do seu software”, onde falo sobre o que é gestão de produtos digitais, seu ciclo de vida, que ferramentas utilizar para aumentar suas chances de sucesso. Você também pode se interessar pelos meus outros dois livros:

Principais características de uma gestora de produtos

O que uma pessoa precisa ter para ser uma boa gestora de produtos? Existem algumas características bem importantes e falarei sobre elas aqui, mas a mais importante de todas é, sem dúvida alguma, a empatia.

empatia

Empatia é a capacidade que uma pessoa tem de se colocar no lugar de outra para compreender os seus anseios, motivações, necessidades e problemas. Essa característica é importante para entender os clientes e usuários do produto, saber como estes se relacionam com ele, e que problema esperam resolver ou que necessidade querem ver atendidas. Isso ajudará a gestora de produtos a entender melhor seu usuário para poder, junto com o UX e a engenharia, desenhar o melhor produto.

Contudo, a empatia não deve ser usada apenas com o cliente ou usuário. A gestora de produtos deve usá-la também no seu relacionamento com todas as áreas da empresa, e deve entender o impacto que seu produto tem no trabalho delas. Será que aumentaram os problemas jurídicos devido a alguma funcionalidade nova no produto? Qual o impacto para a equipe de vendas, suporte, operações, financeiro e marketing? Até mesmo em relação ao time do produto, engenheiros e analistas de UX, como o produto interfere no trabalho desses profissionais?

A segunda característica mais importante é a comunicação.

comunicacao

Para poder ter empatia, é necessário que a gestora de produtos se comunique com as pessoas nos mais diferentes cenários: em conversas um a um e em pequenos grupos, ou fazendo apresentações para grupos pequenos e grandes de pessoas, estes que podem ser internos (dentro da empresa) ou externos (em conferências, grupos de usuários etc.).

Deve também ser bom de comunicação escrita (e-mail, blog, documentação, chat, redes sociais etc.), e ser capaz de discernir sobre qual a forma de comunicação mais apropriada para cada momento, público e meio de comunicação; e de se comunicar de forma a ser entendido pelos diferentes públicos: técnico e não técnico.

Como se isso tudo não bastasse, ele também precisa ser capaz de se comunicar passando segurança e confiança no que está comunicando; afinal, a gestora de produto é a porta-voz do produto.

Porém, não é só de falar que vive a gestora de produtos. Comunicação é uma via de mão dupla, ou seja, a gestora de produto tem de ser muito boa em saber ouvir e compreender o que os outros estão dizendo, e entender os anseios e as necessidades deles; o que tem a ver com a primeira característica, a empatia.

A terceira característica mais importante é a gestão do tempo.

O dia a dia de uma gestora de produtos pode se encher rapidamente de tarefas, e ele precisa ser capaz de perceber e diferenciar o que é urgente do que é importante, para garantir que terá sempre tempo para conhecer mais sobre o cliente e o usuário de seu produto. É muito fácil uma gestora de produtos ver sua agenda repleta de reuniões, com pessoas de diferentes áreas para tratar dos mais diversos assuntos: backlog do produto, atendimento, comunicação de marketing, problemas operacionais, revisão de previsão de crescimento, questões jurídicas, cobrança, régua de comunicação etc.

Isso acontece pois a gestora de produto deve cuidar de seu produto por inteiro. Para o usuário, não existe engenharia, operações, financeiro, jurídico, atendimento e cobrança. Ele enxerga tudo isso como parte do produto que você cuida; e você tem sim de se importar com tudo isso. Contudo, importar-se não significa que você deva ir a todas essas reuniões. Se você fizer isso, poderá tirar o foco do que é mais importante para o seu produto.

Você, como gestora de produtos, precisa focar seu tempo em:

  • Com quantos clientes e usuários você falou essa semana?
  • Você tem uma estratégia e uma visão de longo prazo para o seu produto?
  • Como está e quais as últimas mudanças no cenário competitivo de seu produto?
  • Que insights você teve sobre o seu produto essa semana?
  • Você sabe qual a motivação e a métrica de cada item de seu roadmap?
  • Que novas tecnologias você vê aparecendo que podem influenciar, ou mesmo competir, com o seu produto?
  • Que novas habilidades você está procurando aprender?

As reuniões que mencionei anteriormente são importantes, e aconselho você participar delas quando puder. Apesar disso, você terá muito pouco a contribuir para essas reuniões se você não se focar nos 7 itens que acabei de listar. Procure bloquear um tempo em sua agenda para focar nisso, e você verá como sua participação nas reuniões será muito mais útil e produtiva.

Além dessas três características (empatia, comunicação e gestão do tempo), existem mais quatro que vão ajudar a gestora de produtos a fazer seu trabalho melhor:

  • Novas tecnologias: a gestora de produtos deve estar antenado sobre as novas tecnologias para saber como ela pode impactar o seu produto. Acesso via smartphone, como isso impacta o produto? O usuário quer acessar via smartphone? Para fazer o quê? Redes sociais, como o produto pode tirar proveito delas? Bancos de dados não relacionais, quais os benefícios e as deficiências? Go, a nova linguagem de programação do Google, no que ela é melhor do que a linguagem usada no produto? E no que ela é pior? Smartwatches, smartglasses, como isso impacta o produto? Como o usuário espera interagir com o produto nessas novas interfaces?
     
  • Business skills: a gestora de produtos deve se preocupar se o seu produto está atingindo os objetivos de negócio. Se o objetivo for margem, receita menos custos estão sob controle? Se o objetivo for só receita, como está o crescimento de receita? Se o objetivo for número de usuários, como está evoluindo essa métrica? Além disso, a gestora de produtos deve entender como cada área da empresa funciona e como o produto afeta essas áreas. Como o jurídico funciona? Como o produto impacta o departamento jurídico? E como o departamento jurídico impacta o produto? Essas perguntas podem ser repetidas para todas as áreas da empresa: suporte, operações, financeiro, RH, marketing, vendas, engenharia e UX.
     
  • Curiosidade aguçada: a gestora de produto precisa ter a capacidade de aprender rápido para poder ter insights e fazer julgamentos sobre o produto. Deve ser capaz de aprender tanto o lado soft do produto (qual é a motivação de negócio, qual problema do cliente o produto resolve etc.) como o lado mais técnico (qual tecnologia usamos, qual o impacto dessa tecnologia, que métricas podemos obter etc.).
     
  • Tema do produto: por fim, mas não menos importante, a gestora de produtos precisa conhecer sobre o tema do produto. Se for um produto médico, a gestora de produto deverá entender um pouco sobre medicina. Se for um produto financeiro, deverá conhecer um pouco de finanças. Por exemplo, na Locaweb, temos produtos mais técnicos (como o Cloud Server) e menos técnicos (como a Loja Virtual). A necessidade de conhecimento técnico é bem diferente nesses dois produtos. A gestora de produto do Cloud Server deverá conhecer bem a fundo questões técnicas, enquanto a gestora de produto da Loja Virtual não precisa ter tanto conhecimento técnico, mas deverá saber bastante sobre questões de venda online.

Dá para perceber que essa lista é um conjunto de características que nem todas as pessoas têm. É comum casos de pessoas de outras áreas que resolvem experimentar a carreira de gestora de produtos, mas que, após algum tempo, percebem que não têm todas as características necessárias.

Se você é uma gestora de produtos, ou deseja ser uma, faça uma autoanálise para ver como você está em cada uma das características e, se alguma estiver aquém do desejado, foque em desenvolvê-la. Se você é responsável por identificar e contratar gestoras de produto, use essa lista como guia para saber se o candidato tem as características necessárias para ter sucesso como gestora de produto.

Gestão de produtos digitais

Este artigo faz parte do meu livro “Gestão de produtos: Como aumentar as chances de sucesso do seu software”, onde falo sobre o que é gestão de produtos digitais, seu ciclo de vida, que ferramentas utilizar para aumentar suas chances de sucesso. Você também pode se interessar pelos meus outros dois livros:

Gestora de produtos ou product owner?

Gestora de produtos ou Product Owner? Que termo usar? São papéis diferentes? São complementares? Há sobreposição? É melhor ter duas pessoas distintas, uma para cada papel? Ou é melhor combinar os dois papéis em uma única pessoa?

DEFINIÇÕES

Antes de mais nada, vamos ver mais um pouco de definições.

“O Product Owner é a pessoa responsável por maximizar o valor do produto, o trabalho do time de desenvolvimento, e a gestão do backlog do produto.”, segundo o Guia do Scrum, e então continua: “O Product Owner é uma pessoa e não um comitê. O Product Owner pode representar o desejo de um comitê no backlog do produto. Entretanto, aqueles que quiserem uma alteração nas prioridades dos itens de backlog devem encaminhar ao Product Owner.

“O Product Owner representa os stakeholders e é a voz do cliente”, de acordo com a Wikipedia. “Ele é responsável por garantir que o time entregue valor para o negócio. O Product Owner escreve (ou faz o time escrever) itens centrados no cliente (em geral histórias de usuário), e classifica e prioriza esses itens, adicionando-os ao backlog do produto”.

Pelas definições, fica claro o foco do Product Owner em:

  • Gerenciar as prioridades do backlog, com base em inputs dos stakeholders e clientes; e
  • Maximizar as entregas do time de desenvolvimento.

Por outro lado, no capítulo anterior, definimos gestão de produtos como sendo:

GESTÃO DE PRODUTOS DE SOFTWARE

Gestão de produtos de software é a função responsável por todos os aspectos de um produto de software, durante todo o ciclo de vida desse produto, desde a sua concepção até o fim de sua vida.

É a função responsável por fazer a conexão entre a estratégia da empresa e os problemas e necessidades dos clientes por meio do produto de software. Este deve, ao mesmo tempo, (1) ajudar a empresa a atingir seus objetivos estratégicos, e (2) solucionar os problemas e as necessidades dos clientes.

Em outras palavras, o gestor de produtos precisa conhecer bem tanto quem é o dono do software e quais os objetivos que este deseja alcançar com ele, como quem vai usar esse software e quais os objetivos que esse usuário pretende alcançar ao fazer isso. Somente conhecendo tais objetivos é que o gestor de produtos poderá definir como será esse software.

Dá para perceber que, por um lado, as definições de Product Owner se focam bastante no processo, em priorização de backlog e em maximização da produção do time de desenvolvimento. Já a definição de gestão de produtos é totalmente focada no resultado, no software que está sendo feito e nos seus objetivos, tanto para seu dono quanto para seu usuário.

As definições de Product Owner focam no processo, pois todas as metodologias ágeis têm foco no processo de desenvolvimento de software. O próprio Manifesto Ágil (http://agilemanifesto.org/) diz que “Estamos descobrindo maneiras melhores de desenvolver software”. Note que a preocupação é em descobrir maneiras melhores de desenvolvê-lo, e não em descobrir maneiras de desenvolver softwares melhores. É uma diferença sutil do ponto de vista gramatical, mas enorme no significado. Enquanto “descobrir maneiras melhores de desenvolver software” se foca no processo de desenvolver software, quando falamos em “descobrir maneiras de desenvolver softwares melhores”, passamos imediatamente a nos focar no resultado do desenvolvimento de software: o software! Por isso, minha definição de gestão de produtos tem foco no software e nos objetivos de seu dono e de seus usuários, enquanto que as definições de Product Owner focam em como melhorar o processo de desenvolvimento de software.

ENTÃO SÃO PAPÉIS DIFERENTES?

Resposta curta: NÃO. Apesar de terem focos distintos, pode-se dizer que são dois lados da mesma moeda. Não dá para ter um sem o outro. Não dá para focarmos em melhorar o processo de desenvolvimento de software sem pensarmos em melhorar o software que está sendo produzido; da mesma forma que não é possível pensar em melhorá-lo sem investir no melhoramento do processo de desenvolvimento de software.

Entrevistei dezenas de diretores de TI e perguntei como eles projetam sua organização de desenvolvimento de software. Os resultados: existem Product Owners que são parte do time de desenvolvimento de software, e são responsáveis por gerenciar o backlog e detalhar seus itens; e existem os gestores de produtos, que não fazem parte do time de desenvolvimento, são responsáveis pela visão de negócio do software e passam para o time grandes épicos que deverão ser detalhados por um Product Owner.

Fundada em 1998, a Locaweb (http://www.locaweb.com.br) é pioneira e líder em serviços de hospedagem de TI no Brasil. Trabalhei lá de 2006 a 2016 e usarei alguns exemplos do meu tempo lá. Atualmente, a empresa possui mais de 250.000 clientes e parceiros com mais de 14.000 desenvolvedores. Os produtos Locaweb são projetados para todos, desde usuários comuns até grandes corporações. Alguns dos produtos da Locaweb são: hospedagem de sites, registro de domínio, revenda de hospedagem, serviços de e-mail e marketing por e-mail, comércio eletrônico e infraestrutura para streaming de áudio e vídeo, computação em nuvem, servidores dedicados e serviços especializados de terceirização de TI.

Na Locaweb, optamos por usar os termos gestor de produtos e Product Owner como sinônimos, pois, como dito anteriormente, eu os enxergo como dois lados da mesma moeda. Não dá para priorizar o backlog e maximizar as entregas do time de desenvolvimento se você não tiver um profundo conhecimento dos objetivos do dono e dos usuários desse software. Assim como não dá para produzir o melhor software que atenda aos objetivos tanto do dono como de seus usuários se você não priorizar corretamente o backlog e não maximizar as entregas do time de desenvolvimento.

Um é o “o quê”, e o outro é o “como” do desenvolvimento de software. Não existe um sem o outro. Caso você esteja em uma empresa onde esses papéis estão divididos em duas pessoas distintas, continue lendo. A próxima seção explora esta situação.

O QUE FAZER SE NA SUA EMPRESA TIVER GESTORES DE PRODUTOS E PRODUCT OWNERS?

Conheço algumas empresas que têm essa separação de papéis em pessoas distintas e que, ao lerem que esses papéis devem ser executados pela mesma pessoa, podem pensar que estão com sobra de gente. :-O

Não estão! Muito provavelmente algum outro papel está faltando no seu time de desenvolvimento de produtos de software. Minha recomendação para esses casos:

  • Não seja radical: não saia demitindo pessoas achando que há sobreposição de papéis. É preciso um olhar mais cauteloso, pois outras funções podem estar faltando na sua organização.
  • Marketing de produtos: provavelmente está faltando uma pessoa cuidando do marketing de produto, que tem objetivos complementares, mas bem diferentes do gestor de produtos. No capítulo Qual a diferença entre gestão de marketing de produtos e gestão de produtos?, escreverei sobre a diferença entre gestor de produtos e gestor de marketing de produtos.
  • Analise o que está sendo feito hoje: é provável que o seu gestor de produtos, às vezes chamado de gestor de negócios, esteja fazendo mais coisas de um gestor de marketing de produtos. Nesse caso, é interessante que essa pessoa comece a trabalhar como profissional de marketing de produtos e, eventualmente, deixe as atividades de gestor de produtos para o product owner. Este poderá, assim, cuidar da gestão de produtos.
  • Use um próximo produto para experimentar com a nova divisão de papéis: outra forma de experimentar com essa nova divisão de papéis e responsabilidades é usá-la somente em um novo produto. Quando você estiver pensando em fazer um novo produto, experimente essa nova divisão de papéis e veja como esse produto evolui. Se der certo, você pode estender para os produtos existentes.

Agora que entendemos um pouco mais sobre o que é um gestor de produtos de software, vamos ver quais são as principais características dessa função.

BA, PO OU PM

Em agosto de 2016, assumi a gestão da gestão de produtos na Conta Azul e, quando aqui cheguei, me deparei com Business Analysts (BAs) e Product Managers (PMs), um cenário novo para mim. Passei algum tempo conversando com as pessoas para entender papéis e responsabilidades de cada função e as motivações para essa estrutura ter sido criada. Após essas conversas, ficou mais claro a diferença de papéis e responsabilidades de cada uma das funções, diferença essa que tento traduzir na figura a seguir.

Em uma imagem a diferença entre BA, PO e PM

Essa imagem mostra alguns pontos importantes:

  • POs fazem o que BAs fazem (especificação) mais a priorização do que precisa ser feito. E os PMs, além de priorização e especificação, são responsáveis pelo desenvolvimento, comunicação e execução da visão e estratégia do produto. Existe um aumento de escopo e responsabilidade à medida que se move na carreira de BA para PO, e depois para PM.
  • Apesar de o PM ter por sua responsabilidade o desenvolvimento, comunicação e execução da visão e estratégia do produto, ele também é responsável pela priorização e pela especificação. Pode fazer sentido em algumas empresas ter BAs e PMs, ou POs e PMs, ou mesmo BAs, POs e PMs. Contudo, não pode haver empresas sem alguém fazendo o papel de PM, ou seja, desenvolvendo, comunicando e executando a visão e estratégia do produto.
  • Caso haja em uma empresa, além dos PMs, pessoas exercendo função de BA e/ou PO, é possível colocar os PMs como gestores dos BAs e/ou POs. Contudo, isso cria uma carga extra para o PM que, além de gerir o produto, terá de se preocupar com gestão de pessoas.
  • Minha preferência é por não ter essa separação de papéis e ter apenas PMs. Se houver BAs e ou POs em uma determinada organização, minha recomendação é por tratar esses papéis como passos intermediários de carreira que vão evoluir para atingir o nível de PM, com aumento de escopo e de responsabilidade. A justificativa para essa minha preferência é que, ao deixar os papéis separados, pode acontecer de o PM fazer pouca ou nenhuma especificação e/ou priorização, delegando essas responsabilidades para BAs e/ou POs. Ao fazer isso, o PM perderá insumo importante para o desenvolvimento da visão e estratégia do seu produto.

Acredito que, com essa imagem, consegui deixar mais esclarecidas as diferenças e similaridades das funções de BAs, POs e PMs.

GESTOR OU GERENTE DE PRODUTOS?

Em inglês, a função é conhecida como Product Manager e, olhando no Wikipédia, vemos a seguinte definição para a palavra manager:

MANAGER

Inglês para “gerente” ou “gestor”, em assuntos relacionados à economia e à administração de empresas, e “treinador”, para esportivos.

Fonte: http://pt.wikipedia.org/wiki/Manager

Então, usar gestor de produtos ou gerente de produtos é indiferente, pois ambas as palavras servem de tradução para manager. Aqui no livro, usarei sempre gestor por uma razão simples. Na cultura corporativa brasileira, a palavra gerente costuma denotar alguém que “chefia” pessoas, só que o gerente de produtos não é chefe de ninguém.

Essa função não deve gerenciar pessoas, mas gerenciar coisas. Da mesma forma que um gerente de contas e um gerente de projetos não deve gerenciar pessoas, mas sim contas e projetos, respectivamente. Por esse motivo, prefiro usar a palavra gestor, para tirar qualquer conotação de que essa função deva gerenciar pessoas.

Agora que já entendemos um pouco mais o que é um gestor de produtos de software, vamos conhecer quais são as principais características dessa função.

Gestão de produtos digitais

Este artigo faz parte do meu livro “Gestão de produtos: Como aumentar as chances de sucesso do seu software”, onde falo sobre o que é gestão de produtos digitais, seu ciclo de vida, que ferramentas utilizar para aumentar suas chances de sucesso. Você também pode se interessar pelos meus outros dois livros:

O que é Gestão de Produtos de Software?

Já temos a definição de produto de software, vimos vários exemplos e várias formas de classificar esses produtos, e conhecemos a diferença entre produto e plataforma. Agora, vamos definir a função de gestão de produtos de software:

GESTÃO DE PRODUTOS DE SOFTWARE

Gestão de produtos de software é a função responsável por todos os aspectos de um produto de software, durante todo o ciclo de vida desse produto, desde a sua concepção até o fim de sua vida.

É a função responsável por fazer a conexão entre a estratégia da empresa e os problemas e necessidades dos clientes por meio do produto de software. Este deve, ao mesmo tempo, ajudar a empresa a atingir seus objetivos estratégicos, e solucionar os problemas e as necessidades dos clientes.

Essa definição deixa três pontos bem importantes bem claros:

  • O primeiro é a responsabilidade por todos os aspectos de um produto de software. Isso significa que um gestor de produtos de software deverá se preocupar com a experiência do usuário e com a engenharia de seu produto, incluindo sua arquitetura, infraestrutura e operação. Também deverá se preocupar com questões legais e financeiras, suporte ao cliente, e marketing e venda do produto.

Preocupar-se não significa fazer todas essas coisas. Na sua empresa, existem pessoas e áreas dedicadas a cuidar desses temas. Por isso, preocupar-se significa entender esses aspectos, quais são as suas relações com o produto, e como o produto impacta cada uma dessas áreas. Esse será o tema da Parte III – Relacionamento com as outras áreas, onde falarei sobre a relação entre gestão de produtos de software e as outras áreas da empresa.

  • O segundo ponto é que essa responsabilidade ocorre durante todo o ciclo de vida do produto. Como vamos ver na Parte II – Ciclo de vida de um produto de software, o ciclo de vida de um produto tem diferentes fases, e cada uma delas requer atenção especial.
  • O terceiro ponto é a conexão que a gestão de produtos deve fazer entre os objetivos estratégicos da empresa e os problemas e necessidades dos clientes, que é o que veremos a seguir.

ALINHANDO ESTRATÉGIA DA EMPRESA COM NECESSIDADES DE CLIENTES

O terceiro ponto bem importante da definição de gestão de produtos de software é a responsabilidade por garantir a conexão entre a estratégia da empresa e os problemas e necessidades dos clientes. É na interseção entre os objetivos do negócio e a solução dos problemas ou necessidade dos clientes que se encontra a gestão de produtos de software, como vemos na figura a seguir:

Gestão de produtos de software

Essa é a teoria, e tudo parece simples na teoria. Contudo, como todos nós sabemos, na prática é outra coisa. A gestão de produtos de software na vida real está bem melhor representada pela figura:

Gestão de produtos de software na prática

Nessa imagem, vemos Louis Cyr (http://en.wikipedia.org/wiki/Louis_Cyr) que foi considerado em 1890 o homem mais forte do mundo em sua época por ter levantado 227 kg com apenas 3 dedos e 1.967 kg em suas costas!

Ela representa melhor a função de gerenciamento de produtos digitais, porque nem sempre é simples conciliar os objetivos da empresa e a solução para um problema ou necessidade de um cliente. Um exemplo simples é o Facebook que, como qualquer outra empresa, precisa de receita para pagar seus custos e dar algum retorno aos seus investidores. Esse é o objetivo comercial do Facebook. Por outro lado, encontramos os usuários do Facebook, que acessam o sistema gratuitamente e não têm interesse em pagar por esse acesso.

O gestor de produtos do Facebook tinha então de encontrar uma forma de obter receita, mas sem cobrar dos usuários. A solução foi encontrar um outro tipo de cliente, os anunciantes, dispostos a pagar para exibir anúncios para os usuários do site.

Esta imagem está incompleta…

A primeira imagem está incompleta. Ela fala em objetivos estratégicos da empresa e em problemas e necessidades dos clientes. Contudo, um gestor de produtos não pode olhar apenas para esses dois itens. Há um terceiro item muito importante que é a tecnologia disponível.

O gestor de produtos precisa conhecer a tecnologia disponível para saber se é possível resolver o problema ou a necessidade do cliente, atendendo aos objetivos estratégicos da empresa. Veja a figura a seguir:

Gestão de produtos de software completo

O CORE TEAM DE DESENVOLVIMENTO DE PRODUTOS DE SOFTWARE

As três preocupações vistas anteriormente nos dão a dica do que compõe o sucesso de um produto. Um produto de sucesso deve ser:

  • Desejável: resolve problemas ou necessidades de clientes;
  • Viável: atende aos objetivos estratégicos da empresa; e
  • Possível de ser construído: existe tecnologia disponível para desenvolvê-lo.

Esses três quesitos definem as três funções essenciais para se criar um produto de sucesso: designer de UX (User eXperience, ou Experiência do Usuário), gestão de produtos e desenvolvedor. Esse trio é considerado o core team (time principal) para o desenvolvimento do produto, e deve estar bem alinhado em todas as fases do seu desenvolvimento.

Core team de desenvolvimento de produtos de software

Viável – o que sustentará o negócio?

O gestor de produtos tem duas responsabilidades principais: avaliar as oportunidades do produto e definir o produto que será construído. Depois de avaliado e decidido que vale a pena desenvolver o produto, ele inicia a fase de descobrir exatamente como ele deve ser (junto com o core team), incluindo as funcionalidades necessárias, a experiência do usuário e os critérios para o lançamento. Além disso, está em suas mãos determinar o modelo de negócio que deverá ser seguido, e interagir com praticamente todas as outras áreas da empresa para definir questões jurídicas, contábeis, financeiras, de marketing, de distribuição etc.

Desejável – o que as pessoas precisam?

É aqui que entra a Experiência do Usuário (UX). Há vários papéis em um time de UX, porém, o que trabalha em maior colaboração com o gestor de produtos é o designer de interação. Ele é responsável por buscar um profundo entendimento dos usuários, descobrindo suas motivações, comportamentos e habilidades; ajudar na definição dos requisitos e, assim, desenhar uma interface que torne a interação do usuário com o produto a mais simples e eficiente possível, ao mesmo tempo em que atenda aos objetivos do negócio.

Possibilidade – o que podemos construir?

O Engenheiro ou Desenvolvedor de Software é o responsável por construir o produto efetivamente. Seu papel é importante na fase de descoberta do produto para dizer ao seu gestor e ao designer de UX o que é possível ser feito, avaliar o custo das diferentes ideias propostas e ajudar a identificar as melhores soluções. É sua responsabilidade definir a tecnologia e a arquitetura mais apropriadas para desenvolver um produto de qualidade.

QUAL A DIFERENÇA ENTRE GERENCIAR UM PRODUTO OU UMA PLATAFORMA?

Com produtos de software, a preocupação é apenas com um único tipo de cliente. Em uma plataforma, se ela for single-side, além de se preocupar em entender um único tipo de cliente, é preciso entender como ele se relaciona entre si.

Já se a plataforma for multi-sided, você deve se preocupar com dois ou mais tipos diferentes de usuários, e a relação entre usuários de mesmo tipo e de tipos diferentes. As preocupações, tanto do gestor de produtos como de todas as pessoas que trabalham no desenvolvimento da plataforma, podem ser bem mais complexas do que em um produto com um único tipo de cliente.

Uma estratégia de plataforma deve mudar as prioridades da empresa dona dessa plataforma, uma vez que o cliente não enxerga valor unicamente nas funcionalidades do produto que estão 100% sob controle da empresa. Além das funcionalidades, o cliente busca valor nas interações com terceiros, e é responsabilidade da empresa (dona da plataforma) gerenciar essas relações, para obter os melhores resultados tanto para os participantes da plataforma quanto para si mesma.

Novas preocupações na gestão de plataformas

Quem gerencia plataformas, além de todas as preocupações de gestão de produtos que descrevo aqui no livro, deve também se preocupar com dois novos aspectos:

  • As funcionalidades dependem da participação dos usuários: em inglês, usa-se o termo tipping para essa preocupação, ou seja, como fazer a plataforma ganhar usuários para ela poder ser útil para quem participa dela? Algumas estratégias para fazer isso são:
    • Primeiro usuário: conseguir um primeiro usuário que, por si só, já atrai outros usuários. Essa é uma tática muito usada por shoppings quando fecham com uma loja de departamentos, que já atrai compradores suficientes por si só. Depois, é só falar com outras lojas, que certamente terão mais interesse em estar no shopping.
    • Social: outra forma de conseguir usuários é usar redes e mecanismos sociais para conquistar mais usuários. Algo como “chame seus amigos do Facebook”.
    • Usuário líder: descobrir qual o perfil do usuário que vai ser fortemente atraído pela ideia, ao ponto de ser o primeiro a adotar a plataforma. Bitcoin atraiu inicialmente várias pessoas de tecnologia, que se apaixonaram pela ideia de um dinheiro não atrelado a um governo, e são ferrenhos defensores da ideia.
  • Pense nos benefícios como produto: o próprio produto tem benefícios suficientes por si só. O Instagram, antes da funcionalidade de compartilhar, era capaz de fazer fotos ficarem legais. O OpenTable, antes da funcionalidade de reservas, era um ótimo ERP (Enterprise Resource Planning) para restaurantes.
  • Considere reduzir preços: é uma estratégia válida para atrair usuários, mas vale lembrar de que é difícil aumentar o preço depois, principalmente se você reduzir o preço para zero. Claro, você pode subsidiar com anúncios, mas você precisa saber se seus usuários vão aceitar anúncios e se você vai conseguir anunciantes que queiram pagar.
  • Há também funcionalidades que dependem de os usuários se comportarem bem: em inglês, o termo usado para isso é coring, ou seja, como garantir que os usuários não vão tirar proveito um do outro, assegurando sempre que todos os participantes tenham benefícios? Algumas estratégias para cuidar do coring:
    • Promova confiança: sites de leilão e de pagamento online costumam fazer isso, segurando o dinheiro do comprador até que ele diga que recebeu o produto que lhe foi vendido.
    • Ofereça informação de qualidade: normalmente, aqueles ratings feitos pelos usuários. O grande risco aqui é gerenciar os ratings falsos; positivos feitos pela própria pessoa ou empresa que está sendo analisada, e negativos pelos concorrentes.
    • Restrinja o uso: torne a associação e o uso mais restrito, o que trará sim menos usuários, mas mais usuários de qualidade. É o que fez um site chamado eHarmony, de procura de namorado(a). Ele cobra uma mensalidade razoavelmente cara (U$ 50.00) e tem um questionário bem extenso para ser preenchido. Além disso, mesmo que seu algoritmo de matchmaking encontre várias opções, ele só apresentará um número limitado para facilitar o processo de escolha.

Concluindo

É importante entender se você está trabalhando em um produto ou em uma plataforma, pois existem algumas diferenças em gerenciar cada um deles.

Uma plataforma precisa de uma estratégia para atrair os primeiros usuários, e isso é tão ou mais importante do que as funcionalidades. Como gestores de um produto de software, temos a tendência de ficar animados com funcionalidades técnicas, entretanto, nas plataformas, o foco é ainda maior nos usuários, em suas relações e em como atrair os primeiros usuários. Além disso, gerir uma plataforma requer controle e governança dos relacionamentos dentro da plataforma, para garantir que todos os participantes estejam se beneficiando com ela.

Uma vez que já entendemos o que é a gestão de produtos de software, e quais as diferenças entre gerir um software e gerir uma plataforma, precisamos agora entender o que é um gestor de produtos de software. Esse é o tema do próximo capítulo!

Gestão de produtos digitais

Este artigo faz parte do meu livro “Gestão de produtos: Como aumentar as chances de sucesso do seu software”, onde falo sobre o que é gestão de produtos digitais, seu ciclo de vida, que ferramentas utilizar para aumentar suas chances de sucesso. Você também pode se interessar pelos meus outros dois livros:

O que é um produto de software?

Este é o primeiro capítulo da sessão Definições e requisitos. Antes mesmo de definir gestão de produtos de software, vamos começar do começo, ou seja, definindo o que é software e o que é um produto de software. Em seguida, falarei sobre o que é gestão de produtos de software e quais são as principais características para ser um bom gestor de produtos.

Abordarei também as diferenças entre gestor de produtos e product owner, e quando é o momento certo para uma empresa ter um gestor. Por fim, darei algumas dicas de liderança para gestores de produtos que têm responsabilidade de liderar sem ser “chefes” de ninguém.

Preparado? 🙂

O QUE É UM PRODUTO DE SOFTWARE?

Antes mesmo de definir produto de software, acho que seria bom definirmos o que é software. De acordo com a Wikipédia (https://en.wikipedia.org/wiki/Software):

SOFTWARE

Software é qualquer conjunto de instruções que direciona o processador de um computador (o hardware) a executar operações específicas.

Ótimo, já temos então uma definição de software, mas o que é então um produto de software?

Nesse artigo da Wikipédia, existe até uma comparação do software com a música, em que os instrumentos musicais estão para o hardware como a música produzida nesses instrumentos está para o software. Achei essa comparação interessante.

Você certamente já usou algum produto de software, afinal, a internet é feita de produtos de software. Google, Facebook e Twitter são bons exemplos que você certamente já utilizou, e talvez use diariamente. Quando você faz compras na Amazon ou no Submarino, também está usando um produto de software. O sistema de internet banking do seu banco também pode ser considerado um, assim como a Netflix, que você pode acessar do computador, do smartphone, do tablet ou mesmo direto de sua TV.

O iOS e o Android, sistemas operacionais de smartphones, são produtos de software. Existem também os produtos de software não online: os mais conhecidos, como o Office, Autocad, SAP e outros; e os menos conhecidos, aqueles softwares embarcados, que vêm dentro de hardwares que não são nem computadores, nem tablets, nem smartphones, mas sim dentro da impressora, da TV, de consoles de videogame, da urna eletrônica, de equipamentos de rede como roteadores, switches, hubs e firewalls etc.

PRODUTO DE SOFTWARE

Um produto de software é qualquer software que tenha usuários.

Então, todo software pode ser considerado um produto de software? Não, pois existem softwares que não têm usuários. São os softwares que fazem interface com outros softwares. Alguns exemplos são:

  • Drivers de dispositivos de hardware que fazem a tradução entre o dispositivo e as aplicações ou o sistema operacional.
  • Firmware, que é aquele conjunto de instruções operacionais programadas diretamente no hardware de um equipamento eletrônico.
  • Camada de compatibilidade, que permite softwares rodarem em um ambiente no qual não foram originalmente programados para rodar.

Contudo, mesmo esse tipo de software se beneficiaria dos conceitos e das práticas da gestão de produtos de software que abordarei neste livro.

TIPOS DE PRODUTOS DE SOFTWARE

Podem-se classificar os produtos de software de diferentes formas, dependendo de como os enxergamos. Podemos olhar, como descrito anteriormente, para a forma como o produto é entregue aos usuários (como online, não online e embarcado), ou de acordo com o que ele faz: e-mail, comércio eletrônico, pagamento, e-mail marketing, gestão de conteúdo, educação, comunicação, colaboração, relatório, entretenimento, sistema operacional, ERP, CRM etc.

Outra forma – que é a que prefiro, pois coloca o usuário no centro – é olhar e classificar produtos entendendo para quem o produto resolve o problema. Deste ponto de vista, podemos ter três tipos de produto de software:

  • Para o consumidor final: nesse tipo de produto, resolve-se um problema para o consumidor final que está disposto a pagar uma taxa para usar os serviços. Alguns exemplos são Netflix, LinkedIn e jogos. Pode-se também pensar em produtos web para consumidores finais que paguem a taxa pelo uso de forma indireta, ou seja, a taxa paga é por um serviço maior e o produto web está embutido nesse serviço. Alguns exemplos são internet banking, intranet de colégio ou faculdade, acesso a resultado de exames laboratoriais e softwares embarcados de forma geral. Os sites de comércio eletrônico são também dessa categoria, pois o uso do site é gratuito e a taxa paga é pelos produtos comprados no site que são entregues para o usuário.
  • Para as empresas: esse tipo de produto resolve o problema de empresas, que normalmente têm mais disposição de pagar que o consumidor final. Alguns exemplos são os produtos da Locaweb, Google AdWords, SAP, AutoCAD e Microsoft Office.
  • Mistos: nesse caso, o produto resolve tanto um problema para o consumidor final quanto para as empresas. Normalmente, esse tipo de produto não tem nenhum custo para o consumidor final; quem paga a conta são as empresas. O modelo mais comum de geração de receita nesse tipo de produto é o anúncio, pago pela empresa quando o consumidor final vê o anúncio, clica nele ou compra algo a partir dele. Alguns exemplos são Buscapé, Mercado Livre, Google Search + Google AdWords e UOL Conteúdo + anúncios.

Note que, na descrição de cada um desses tipos, tive a preocupação de deixar claro quem paga a conta. Isso é muito importante, pois todo produto de software tem custos. Por mais acessíveis que sejam esses custos, eles existem; logo, todo produto de software precisa gerar receita de alguma forma.

Mesmo eu preferindo a classificação dos produtos de software entendendo para quem o produto resolve o problema, as outras formas de se classificar também são válidas, e não são excludentes. Por exemplo, a Netflix é um produto de software para o usuário final, mas também é um produto de software online de entretenimento.

Essas categorizações têm um impacto direto no trabalho diário do gestor de produtos, ou seja, diferentes tipos de produtos requerem diferentes tipos de habilidades de gestão de produtos. Gerenciar um ERP é diferente de gerenciar um produto de marketing por e-mail. Gerenciar um produto online é diferente de gerenciar um produto de aplicativo móvel. Gerenciar um produto de consumo é diferente de gerenciar um produto para empresas.

DIGITAL OU TRADICIONAL?

Recentemente, percebi outra maneira de categorizar não apenas o produto de software, mas também a empresa proprietária do produto de software, e essa categorização tem um ENORME impacto não apenas na maneira como um gestor de produtos gerencia seu produto, mas também no papel do gestor de produto na organização que possui o produto.

Empresas digitais

Todos conhecemos empresas digitais. Google com seus principais produtos, Google Search e GMail. Amazon Web Services. Facebook. Instagram. WhatsApp. SAP. Salesforce. Zendesk. As empresas em que trabalhei (Locaweb e Conta Azul). Todas essas empresas vendem seus produtos de software para seus clientes. O produto é o núcleo da empresa. Se não houver produto de software, não há empresa. Você consegue imaginar o Google sem o software de pesquisa do Google? Ou o Instagram sem o aplicativo Instagram? Ou o Zendesk sem o software do Zendesk?

Nessas empresas, a gestão de produtos é o núcleo da empresa. A gestão de produtos é responsável por definir uma boa parte – se não toda – da visão e da estratégia da empresa. O papel do gestor de produtos nesta empresa é principal.

Empresas tradicionais

Na outra ponta do espectro, há o que podemos chamar de empresas tradicionais. Essas empresas vendem produtos e serviços que não são software. No entanto, todas elas estão, de uma forma ou de outra, passando por algum tipo de transformação digital, ou seja, aprendendo a usar a tecnologia digital para melhorar seus negócios. Estes são alguns exemplos de melhorias que podem resultar do uso de tecnologias digitais:

  • relacionamento aprimorado com o cliente.
  • coleta de dados e visões.
  • inovação através de experimentação rápida.
  • maior velocidade e qualidade do processo através da automação.

Vou citar alguns exemplos brasileiros conhecidos. O Itaú, um dos maiores bancos brasileiros, fundado em 1924, está investindo muito para se tornar digital, com o Internet Banking e seu aplicativo. De tempos em tempos, eles lançam campanhas de TV para mostrar essa transformação. O Itaú tem 91 anos. A Magazine Luiza, uma rede de varejo física fundada em 1957, também investe muito em sua presença digital. Eles são bem conhecidos no Brasil por sua presença online e seu aplicativo.

Outros bons exemplos de empresas tradicionais que investem em presença digital são companhias aéreas e hotéis. Eles têm sites e aplicativos para que os clientes possam comprar passagens, fazer reservas e interagir com seus clientes.

Nas empresas tradicionais, seus produtos ou serviços existem e provavelmente existiram por muito tempo sem a tecnologia digital. Executivos e acionistas estão começando a entender como as tecnologias digitais podem impactar seus negócios, e estão investindo na transformação digital. Nessas empresas, a gestão de produtos de software é um facilitador, mas não é o núcleo. Normalmente, faz parte de uma equipe chamada “a equipe digital”. Os gestores de produto terão que ganhar seus espaços, mostrando como a tecnologia pode impactar os negócios.

O terceiro tipo de empresa: empresas tradicionais nativas digitais

Esses tipos de empresas possuem produtos ou serviços tradicionais que podem existir sem tecnologia. Entretanto, como elas incluem a tecnologia desde o início como uma capacidade estratégica, elas são empresas digitais.

Elas são consideradas empresas de tecnologia e, de certa forma, são. A tecnologia está no centro de sua estratégia. Por outro lado, quando olhamos mais de perto, o produto delas não é tecnologia. Seus produtos são ativados e potencializados pela tecnologia digital. Os produtos da Amazon são mercadorias (livros, computadores, telefones celulares etc.). O produto da Netflix e do YouTube é conteúdo de vídeo. O produto do Spotify é conteúdo de áudio. O Airbnb é um negócio de propaganda que gera conexões com as residências oferecidas para aluguel. O Google Adwords também é uma empresa de publicidade que gera conexões com qualquer produto ou serviço anunciado. O Nubank, um banco digital brasileiro, oferece serviços de cartão de crédito e conta bancária, como qualquer outro banco. O serviço principal da Uber e da Lyft é o transporte. Rappi, um serviço de entrega colombiano, e iFood e GrubHub, serviços de entrega de comida, são o que acabei de escrever, serviços de entrega. O Gympass oferece acesso a mais de 50.000 academias e estúdios em todo o mundo.

Exemplos de empresas tradicionais nativas digitais

Seus produtos não são tecnologia. Seus produtos não são software. A tecnologia e o software digitais viabilizam e potencializam seus produtos. Por esse motivo, a gestão de produtos é muito importante, mas não é central para a definição da visão e estratégia da empresa. Os gestores de produto terão um papel muito importante na definição e execução da visão e estratégia da empresa, mas não terão um papel central.

PRODUTO OU PLATAFORMA?

Cada vez mais vemos produtos de software que podem ser classificados como plataformas. Exemplos não faltam, desde grandes empresas de tecnologia como:

  • Google que, com dois produtos (Search e AdWords), criou uma plataforma conectando pessoas que buscam informações na internet com pessoas que querem anunciar coisas na internet.
  • Facebook, que começou como uma plataforma em que amigos se encontravam e trocavam informações, e tornou- se uma plataforma na qual anunciantes podem falar com pessoas por meio de anúncios e páginas de empresas. LinkedIn, uma plataforma para profissionais, empresas e, mais recentemente, anunciantes.
  • Apple, que conecta desenvolvedores de software com usuários de iPhone, iPad e Macs com sua AppStore. Outra plataforma da Apple é o iTunes, conectando produtores de mídia com pessoas interessadas em música, filmes, séries e livros.
  • Amazon Kindle, plataforma para que editoras ou autores possam publicar livros para pessoas interessadas nesses conteúdos.

Aliás, algumas dessas empresas têm mais de uma plataforma, como Google, Apple e Amazon.

Além dessas grandes empresas de tecnologia, existem também os exemplos mais recentes:

  • Uber, conectando motoristas com pessoas querendo transporte.
  • Airbnb, conectando quem tem imóvel para alugar por períodos curtos com quem quer alugar um imóvel nessas condições.
  • Bitcoin, quanto mais usuários tiver e quanto mais empresas aceitarem Bitcoin, melhor.

Existem também exemplos de plataformas que não são necessariamente baseadas em tecnologia como os shoppings, que colocam lojas, restaurantes e cinemas próximos às pessoas que querem comprar, comer e se divertir.

O que são plataformas?

Plataformas podem ser definidas como:

PLATAFORMA

Sistemas que, quanto mais pessoas usam, mais são valorizados.

São sistemas fortemente baseados no conceito de efeito de rede (network effect). Efeito de rede é o valor que os usuários de um determinado software obtêm quando outros usuários também utilizam o software.

Plataforma

Existem dois tipos de plataforma:

  • Plataformas de um único lado (single-side): são aquelas que, quanto mais usuários tiver, melhor. Usando um exemplo mais antigo, a máquina de fax. De nada adianta apenas uma pessoa ter fax; quanto mais pessoas usando, melhor. O mesmo vale para redes sociais (Facebook, Twitter, etc.).
  • Plataformas com múltiplos participantes (cross-side ou multi-side): são aquelas em que são necessárias dois ou mais grupos distintos de pessoas que fazem uso da plataforma de forma diferente, e que se beneficiam dessa forma diferente de cada grupo usá-las. Esse tipo pode ser classificado em 3 categorias:

Plataforma tecnológica: onde a plataforma é o sistema operacional; de um lado, temos os usuários e, do outro, temos os desenvolvedores do sistema operacional: Linux, Windows e Android.

Plataforma de troca: reúne compradores e vendedores: MercadoLivre, Uber e Airbnb.

Plataforma de conteúdo: o conteúdo é o foco, e a monetização é feita normalmente por meio de anúncios (Google, Facebook e os portais de notícias).

Veja a seguir um exemplo de plataforma tecnológica com 5 lados:

Sistema operacional Android visto como uma plataforma de 5 lados

É importante não confundir o conceito de plataforma no contexto de produto, com o conceito de plataforma técnica ou plataforma computacional. Uma plataforma computacional é qualquer ambiente computacional onde um software será executado. Já no contexto de produto, como definimos anteriormente, chamamos o produto de plataforma quando existem ganhos para os usuários e quanto mais usuários estiverem usando o produto.

Em um livro de 2019 chamado The Business of Platforms: Strategy in the Digital Concorrence, Innovation and Power (por Michael A. Cusumano, Annabelle Gawer, David B.Yoffie, Harper Business, 2019, https://www.amazon.com/Business-Platforms- Strategy-Competition-Innovation/dp/0062896326), os autores categorizam as plataformas em plataformas de transações, nas quais as transações acontecem (mercados, redes de anúncios, streaming, acesso a redes de casas, passageiros, academias de ginástica, etc.) e plataformas de inovação, em que um novo valor é construído sobre a plataforma (sistemas operacionais, lojas de aplicativos, AWS, etc.).

Um aspecto importante mencionado no livro é que as plataformas de transações são relativamente fáceis de serem copiadas e substituídas, enquanto que as plataformas de inovação são um pouco mais difíceis para tal devido a todo o investimento técnico que os participantes da plataforma fazem para fazer parte da plataforma. Muitas plataformas de transações evoluem para se tornar plataformas híbridas, ou seja, incorporam características de inovação para permitir que seus usuários criem novo material sobre as plataformas existentes.

Neste capítulo, vimos as definições de software, produto e plataforma digital, agora vamos descobrir o que é a gestão de produtos de software.

Gestão de produtos digitais

Este artigo faz parte do meu livro “Gestão de produtos: Como aumentar as chances de sucesso do seu software”, onde falo sobre o que é gestão de produtos digitais, seu ciclo de vida, que ferramentas utilizar para aumentar suas chances de sucesso. Você também pode se interessar pelos meus outros dois livros: