Qual a diferença entre produto e projeto?

Já escrevi sobre a diferença entre gerenciamento de produtos e gerenciamento de projetos, mas acredito que há espaço para aprofundar um pouco mais as diferenças entre produto e projeto. Então, uma rápida lembrança das definições de produto e projeto:

Projeto

Um projeto em negócios e ciência geralmente é definido como um empreendimento colaborativo, muitas vezes envolvendo pesquisa ou design, que é cuidadosamente projetado para atingir um objetivo específico.

Fonte: Wikipédia

Produto

O termo produto é definido como “algo produzido por trabalho ou esforço” ou como “o resultado de um ato ou processo” e tem sua origem no verbo latino produzir(re), ‘fazer existir’.

Fonte: Wikipédia

Ou seja, enquanto o projeto é um processo com início e fim; o produto é o resultado de um processo.

Diferenças de produto e projeto

As definições acima podem ser expandidas para ajudar a entender um pouco mais as diferenças:

  • Enquanto em um projeto focamos na entrega com um caminho bem definido, em um produto focamos no resultado com objetivos bem definidos.
  • Enquanto em um projeto temos um escopo claramente definido durante o planejamento, em um produto usamos testes e validação de ideias para definir os próximos passos.
  • Enquanto uma abordagem de projeto pode funcionar em situações previsíveis, uma abordagem de produto é útil em contextos mais voláteis.
  • Enquanto um projeto tem um fim claro e bem definido, um produto não é desenhado para ter um fim em um futuro previsível.

Para nos ajudar a entender melhor essas diferenças, darei um exemplo do mundo da tecnologia e duas analogias do nosso dia a dia.

  • Na Locaweb, desde o início até por volta de 2007, utilizávamos serviços de Data Center de terceiros para hospedar todos os nossos serviços. À medida que crescemos, fez mais sentido construir nosso próprio data center e mover nossos servidores para esse novo data center, onde tínhamos melhor controle e custos reduzidos. Construir o próprio data center da Locaweb e mover todos os servidores para este data center pode ser facilmente identificado como projetos. Por outro lado, todos os serviços da Locaweb (Hospedagem, E-mail, eCommerce, etc.) podem e devem ser gerenciados como produtos. Até o data center, depois de pronto, foi (e é) gerenciado como um produto.

E agora as duas analogias do nosso dia a dia para ajudar a ilustrar a diferença entre projeto e produto::

  • A construção de um novo prédio de apartamentos é tipicamente um projeto, incluindo todo o planejamento necessário não apenas para construir o prédio, mas também para vender todas as suas unidades de apartamentos. Por outro lado, assim que o prédio está pronto para uso e as famílias se mudam para seus novos apartamentos, chega uma fase em que podemos fazer a analogia do prédio como um produto: manutenção do apartamento, administração do condomínio, aluguel, aquisição.
  • Quando duas pessoas se casam, também é fácil ver um projeto e um produto. A cerimônia de casamento, festa, lua de mel, morar juntos, todos esses eventos devem ser gerenciados como projetos. Por outro lado, o seu dia-a-dia com seu parceiro de casamento, morar junto, formar uma família, ter filhos, netos podem ser vistos como um produto.

Jogos finitos e infinitos

Simon Sinek, autor de “Start with Why” e “Leaders Eat Last”, lançou em 2019 um livro muito interessante chamado “The Infinite Game” onde construiu em cima do argumento do clássico livro “Finite and Infinite Games”, de James P. Carse, um acadêmico americano que foi professor emérito de história e literatura da religião na Universidade de Nova York. Em seu livro, Carse explica que enquanto um jogo finito tem um fim e um vencedor claro, como esportes, política e guerra, jogos infinitos, como nossa vida, cidades, países, carreira, são aquelas atividades que não têm um fim claro e definido. e não necessariamente um vencedor. De acordo com Carse:

Um jogo finito é jogado com o propósito de ganhar, um jogo infinito com o propósito de continuar o jogo.

Sinek “começou a ver que muitas das lutas que as organizações enfrentam existem simplesmente porque seus líderes estavam jogando com uma mentalidade finita em um jogo que não tem fim. organizações mais inspiradoras.”

É fácil ver que projetos são jogos finitos enquanto produtos são jogos infinitos.

Quando me perguntam sobre a diferença entre um projeto e um produto, tenho usado as duas analogias acima, prédio de apartamentos e casamento para ajudar a ilustrar esses conceitos, com bom feedback. Espero que agora que consegui escrever esses conceitos e analogias, eles possam ajudar mais pessoas.

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:

Mentoria e aconselhamento em desenvolvimento de produtos digitais

Tenha ajudado várias empresas a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

Crescimento: ouvindo feedback do seu cliente

Você descobriu um problema de um conjunto de pessoas, e entendeu a fundo esse problema e o seu contexto. Descobriu o que motiva as pessoas a terem-no resolvido, e analisou a oportunidade em mais detalhes para avaliar se vale a pena desenvolver seu produto de software. Por fim, você desenvolveu sua primeira versão de seu produto de software e o lançou no mercado, seguindo as recomendações dos vários ótimos livros que existem falando sobre startup, inovação e desenvolvimento de software.

Sucesso! Só que não…

Na verdade, esse foi o seu primeiro passo de uma jornada bem longa, que vamos conhecer nos próximos capítulos.

Passada a fase de inovação, quando você desenvolve e lança a primeira versão de seu produto de software, chega o momento em que você tem de investir mais energia para entender se seu produto de fato resolve o problema dos clientes e atende aos objetivos de seu dono. Esse é o momento em que você, ou entra na fase de crescimento, ou então pode não cruzar o abismo.

Ciclo de vida de um produto de software

Aliás, esse é um dos momentos mais importantes do ciclo de vida de seu produto de software, o “momento da verdade”, o momento no qual seu produto encontra o mundo real. Você certamente deixou alguma maneira fácil de seus usuários entrarem em contato, e agora está começando a receber seus feedbacks. São esses feedbacks que vão dizer se você está ou não na direção certa para resolver o problema deles.

Lidando com o feedback de usuários

Responda rápido

É importante responder rapidamente aos feedbacks. Isso criará uma percepção de que quem está por trás do produto de software se importa com os comentários e com os usuários de seu sistema. Isso ajuda a criar uma imagem positiva de seu produto.

Não invente

Não diga que você vai implementar alguma determinada funcionalidade em algum momento do futuro se você não tem planos de fazer isso, ou se isso é só uma possibilidade remota. Se esse for caso, apenas agradeça a sugestão.

Seja educado

Essas pessoas que estão dando feedback estão fornecendo uma informação muito valiosa. Mesmo que elas não sejam muito educadas com você, o que elas estão lhe dizendo serve para você entender como elas estão percebendo seu produto.

Você deve sempre ser educado com seus usuários, mesmo com aqueles que não forem muito educados com você. Sua forma educada de tratá-los pode eventualmente ajudar a reverter a má impressão que ele tinha de seu produto.

Não implemente todas as sugestões que receber

Principalmente no começo, você receberá muitas sugestões de funcionalidade: versão para celular, funcionamento mais preditivo, conhecendo o usuário e já preenchendo os dados automaticamente, e assim vai.

Nesse começo, o recomendado é não implementar nada: você ainda está conhecendo seus usuários e entendendo se seu produto resolve um problema real deles. Se você implementar todas as sugestões que receber, poderá estragar a solução que criou e, pior, começará a deixar seu produto complicado, com muitas funcionalidades desnecessárias. Para lidar com todas as sugestões, não é necessário criar um sistema para anotá-las. Depois de algum tempo recebendo sugestões, você vai se lembrar de quais são as mais populares.

Se você quiser implementar um sistema de sugestões, existe o UserVoice (http://uservoice.com), que tem versão gratuita.

Feedback não é só o que o usuário lhe manda

Apesar de seus usuários que lhe mandam feedback já lhe dizerem muita coisa, você não deve considerá-los como sua única fonte de feedback. Você deve usar as estatísticas de uso do produto de software como ferramenta para entender como ele está sendo utilizado. A quantidade de vezes que as pessoas acessam, a quantidade de dados que elas entram no sistema, depois de quanto tempo elas voltam, tudo isso você deve ser capaz de extrair de sua base de dados e do relatório de estatísticas de acesso.

Para relatório de estatísticas de acesso ao site, uma boa solução é o Google Analytics. Com um pequeno pedaço de código JavaScript em seu site e em sua aplicação web, o Google Analytics colhe várias informações das pessoas que navegam por eles, como: por qual página entraram; de que página saíram; quanto tempo ficaram em cada página; de que localidade são (cidade, estado, país); se estão acessando via computador, tablet ou celular; além de informar quantidade de visitas, e várias outras informações muito úteis, principalmente nesse começo.

Uma outra ferramenta muito útil para ver como as pessoas estão usando seu produto é o ClickTale, que também com um pequeno JavaScript colocado em sua página, é capaz de dar informações sobre, não só os cliques, como também da movimentação do mouse das pessoas enquanto elas usam seu produto. Ver isso pode lhe dar várias informações úteis sobre sua aplicação.

Interaja com seus usuários por diferentes meios

Existem outras formas além de você obter feedback de seus usuários. Seu site tem um blog para você contar novidades de seu produto, não tem? Nos comentários dos posts, você certamente receberá muita informação bacana.

Você também pode criar uma página no Facebook, que pode ser o lugar onde os usuários de seu produto se encontram e trocam experiências. Se você tiver a oportunidade, também converse ao vivo com as pessoas que estão usando seu sistema. Conversas ao vivo são muito ricas por permitirem maior interação e troca de informações.

Exemplo de pressa em agir devido ao feedback

Logo após o lançamento do ContaCal, produto digital que comentei no capítulo Inovação: muitas oportunidades, muitos usuários comentaram que seria bacana ter a possibilidade de controlar não só a quantidade de calorias ingeridas como também a quantidade de calorias gastas. De tanto ouvir pessoas pedindo por essa funcionalidade, ela acabou ficando na minha cabeça como uma funcionalidade importante para ser implementada. Talvez eu pudesse até estar perdendo inscrições de novos usuários por não a ter, ou usuários estivessem desistindo de utilizar o sistema pela falta dela.

Eu estava me organizando para decidir como implementar cobrança no sistema mas, em função desse feedback, decidi colocar a funcionalidade de registro de atividades físicas no ContaCal, dois meses e meio após seu lançamento. Fiz isso por ser simples de implementar e por achar que poderia ajudar a aumentar o número de pessoas que continuariam utilizando o produto após o primeiro uso.

Anunciei para a base de usuários existentes, passei a destacar isso como uma das funcionalidades que o sistema tem na comunicação do produto, e passei a ensinar novos usuários mais sobre essa funcionalidade. Várias pessoas acharam bacana, mas a curva de novos usuários que se cadastraram para testar o sistema, bem como de usuários que decidiram continuar usando-o após o primeiro contato, não mudou em nada!

Para confirmar essa percepção de esforço com pouca utilidade, bastou olhar na base de dados para ver que apenas 2,4% dos registros feitos são de atividades. Acabei postergando em um mês a implementação de cobrança para colocar essa funcionalidade. Hoje vejo que não precisava ter a implementado antes da funcionalidade de cobrança. Acho até que não precisava ter implementado essa funcionalidade e poderia ter deixado o ContaCal como sistema apenas para registro de calorias ingeridas, sem me preocupar com o gasto de calorias em atividades físicas.
Recentemente, recebi um e-mail de uma usuária reclamando de que o gráfico que apresento como relatório não mostra as atividades físicas, sendo que o objetivo deste é somente mostrar a evolução das calorias ingeridas. Coloquei mais uma complexidade no sistema com a qual tenho de lidar até hoje e com praticamente nenhum ganho, nem para os usuários, nem para mim, que sou o dono do software.

Muito cuidado quando for implementar uma nova funcionalidade. Sua criação cria complexidade de código, de regra de negócio e de interface. Se não estiver muito claro o que seus usuários e o dono do software vão tirar de positivo dela, talvez seja melhor esperar um pouco antes de investir.

Cruzando o abismo

Cruzar o abismo que separa os primeiros clientes, aqueles entusiastas que adoram testar todo e qualquer produto novo, do restante do mercado não é uma tarefa simples. Tanto que existe um livro inteiro falando sobre o assunto, que já mencionei algumas vezes, o Crossing the Chasm, de Geoffrey A. Moore.

Apesar de eu já ter falado várias informações a respeito desse livro, neste momento em que estamos considerando o crescimento do produto e a importância de recolher feedback, vale a pena nos determos em algumas observações sobre ele.

A primeira parte do livro é muito boa; uma leitura recomendada para qualquer pessoa que trabalha com tecnologia. Nela, Moore mostra a curva de adoção de tecnologia em detalhes, a existência do abismo nessa curva e explica o motivo de este abismo acontecer.

Na segunda e última parte do livro, Moore sugere como cruzar o abismo. O problema é que ele usa analogias de guerra para isso; o que, volto a ressaltar, não é a maneira mais apropriada para endereçar questões de negócios. O primeiro capítulo da segunda parte está intitulado como “A analogia do dia D”, e vem seguido de capítulos com o mesmo tipo de títulos (“Mire o ponto de ataque”, “Monte sua força de invasão”, “Defina a batalha” e “Lance a invasão”).

Apesar da péssima analogia, as ideias são boas. Em resumo, ele recomenda um profundo entendimento do usuário para garantir que seu produto esteja, de fato, resolvendo um problema dele. Ele recomenda foco nesse único empecilho para um grupo de usuários. Melhor ser algo muito bom para um grupo de pessoas do que tentar ser tudo para todos.
A partir do momento em que seu produto for uma ótima solução de um problema de um pequeno grupo, você poderá procurar mais pessoas que possam estar com um problema igual ou parecido para você adaptar seu produto, e assim ganhar mais mercado.

Claro que é muito mais fácil falar do que fazer, mas não se esqueça: o bom entendimento de seu usuário, de seu problema, do contexto onde este acontece e a motivação que ele tem para querer tê-lo resolvido são as suas melhores ferramentas para cruzar o abismo, e evitar a morte prematura de seu produto de software.

Gestão de produtos digitais

Este artigo é mais um capítulo 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:

Mentoria e aconselhamento em desenvolvimento de produtos digitais

Tenha ajudado várias empresas a extrair mais valor e resultados de seus produtos digitais. Veja aqui como posso ajudar você e a sua empresa.

Inovação: Como Obter Retorno com seu Produto Digital?

Uma das perguntas mais importantes do questionário de análise de oportunidade que vimos no capítulo anterior é a pergunta: “Como vamos medir o sucesso e ganhar dinheiro com esse produto?”. Ela trata de dois assuntos: métricas e receita. Veremos sobre métricas no capítulo Crescimento: seja um “data geek”. Agora vamos falar sobre receita.

Quais são os Custos de Desenvolver, Distribuir e Operar um Software?

Todo desenvolvimento de software tem custo. Quando esse software é um produto de software – ou seja, é um software que tem usuários –, o produto tem, além do custo de desenvolvimento, o custo de operação, que é o custo de fazer esse software chegar até os usuários e, a depender do tipo de produto, de armazenar dados desses usuários.

Antes da internet, os produtos de software eram vendidos em caixas com manual e disquetes, ou CDs de instalação. A receita vinha da venda dessas caixas com o software. Algumas empresas chegam a cobrar uma taxa anual de manutenção, que dá aos clientes o acesso a versões mais novas à medida que ficam disponíveis. Esse produto de software roda nos computadores do cliente, isto é, todo custo de operação é de sua responsabilidade. O fabricante recomenda uma configuração mínima de equipamento para rodar esse software e o cliente é que se preocupa em ter, configurar e manter esse equipamento.

Além disso, administrar esse produto de software também é de sua responsabilidade, como também garantir que ele esteja rodando em equipamento com espaço em disco e memória suficientes, e que os dados gerados estejam seguros e tenham backups. A receita proveniente da venda desse produto de software serve para pagar seus custos de desenvolvimento e de distribuição.

Com a internet, veio a possibilidade de oferecer softwares para serem usados de forma remota. Passou a ser possível usar um software que não está mais rodando no equipamento do cliente e que não precisa ser administrado por ele. É o que estamos chamando aqui de produto de software. Nesse novo modelo de comercialização, não há somente a venda do software, mas também do serviço de sua operação. Mesmo as apps dos smartphones, que rodam nos telefones dos usuários, têm em sua maioria algum componente online, isto é, buscam e armazenam dados em servidores remotos, que também trarão custos de operação.

Todo produto de software tem custos para desenvolver o software mais custos de operá-lo. Para cobrir esses custos, é necessário ter algum tipo de retorno com seu produto de software que os compense.

Tipos de Receita de Produto Web

Basicamente, existem 3 formas de se ter receita com um produto web:

Receita paga pelo usuário

É o modelo usado na maioria dos produtos web para empresas, tais como os produtos oferecidos pela Locaweb, Google AdWords, MailChimp, entre outros. Nesse caso, a receita vem do pagamento periódico (mensal, anual etc.) pelo uso do software via web. Outra opção bastante comum é o pagamento por uso (mais adiante falarei um pouco mais sobre essas formas de pagamento).

A receita paga pelo usuário é também uma forma usada por alguns produtos de software para consumidor final, mas é mais difícil cobrar desse tipo de usuário, sendo alguns exemplos o Netflix, o LinkedIn e o Dropbox. Para entender como é difícil cobrar de um consumidor final, imagine-se pagando para usar a busca do Google. Mesmo o consumidor final percebendo muito valor em um produto web, é difícil justificar para esse tipo de usuário que ele deve pagar para usar.

Receita paga por alguém interessado no seu usuário

Nesse modelo, normalmente não se cobra do usuário do produto, mas sim de alguém que está interessado nele. Esse modelo é bastante usado em produtos para consumidor final. Normalmente, o modelo de negócio é a venda de anúncio. Um exemplo é o Google, que permite que qualquer pessoa use a busca, e cobra de empresas a possibilidade de colocar anúncios junto com os resultados da pesquisa.

Outro exemplo similar é o Facebook, que também oferece acesso gratuito aos usuários, e cobra por anúncios de empresas interessadas em fazer propaganda para seus usuários. Outra forma de receita é a venda de relatórios baseados nos dados de uso. Além de anúncios e da venda de relatórios, outra opção de receita e permitir que outras empresas vendam serviços para sua base de clientes e compartilhem a receita. Um exemplo é o Guia Bolso, aplicativo gratuito que permite controle financeiro e que oferece opções de crédito para seus clientes, crédito oferecido por instituições financeiras que dividem com o Guia Bolso parte da receita gerada com os empréstimos.

Um ponto importante a ser ressaltado é que, para conseguir ser interessante para alguém ao ponto de ele querer pagar para ter acesso ao seu usuário, você precisa ter uma quantidade muito grande de usuários. Pense em centenas de milhares, que retornem com frequência para usar seu produto web.

Para atrair centenas de milhares de usuários de forma paga, você provavelmente vai investir bastante dinheiro, então terá de buscar formas gratuitas de divulgar seu produto. Além disso, este deve promover o retorno frequente de usuários, pois assim você terá uma audiência que será de interesse para quem quiser pagar para falar com eles.

Para tornar sua base de usuários ainda mais atraente para possíveis anunciantes, você deve buscar conhecer bastante sobre seus usuários, como dados demográficos, comportamento e preferências. Assim, você pode oferecer maior assertividade e eficiência para os anunciantes.

Receita indireta

É a receita que você obtém como resultado do uso do software, mas que não é paga pelo seu uso. Existem basicamente dois tipos de receita indireta:

  • Receita de venda ou aluguel de itens físicos ou virtuais: é o caso das lojas virtuais que usam os softwares e serviços de loja online como produto de software para vender ou alugar itens físicos. Amazon e Submarino são bons exemplos. Há também as lojas que vendem ou alugam itens virtuais, como o serviço de streaming da Netflix ou a venda de livros Kindle da Amazon. No caso dos livros, a venda é por item. Já no serviço da Netflix, eles cobram uma mensalidade para ter acesso ao conteúdo de streaming. Vale notar que os sites de comércio que fazem a intermediação da venda de itens físicos, como o eBay, Mercado Livre e Elo7, não são desse tipo. Eles são do tipo em que a receita é paga pelo usuário do produto de software, ou seja, por quem coloca o item físico para vender, pagando uma comissão pela venda. Esses sites de intermediação de vendas estão na categoria de plataformas.
  • Redução de custos: é o caso do internet banking, intranet de colégio ou faculdade, sistema de acesso a resultado de exames laboratoriais, entre outros produtos de software que não comercializam nada e nem cobram pelo acesso. Nesse tipo de produto, não existe receita, mas sim redução de custo. O internet banking diminui os custos de atendimento presencial de clientes nas agências; a intranet permite um fluxo de comunicação mais ágil entre escola e aluno ou pais de aluno, economizando em visitas e reuniões no colégio ou faculdade; e o acesso a resultado via internet reduz custos de outras formas de entrega de exames, como impressão e envio pelo correio.

Tipos de Pagamento Pelo uso do Produto de Software

Quando há pagamento pelo uso de um produto, este pode ser feito de duas formas:

  • Pagamento periódico: é o pagamento de um valor fixo para poder usar o produto, como uma assinatura de uma TV a cabo ou uma mensalidade de uma academia. Se o usuário deixa de pagar, ele deixa de poder usar o produto e de ter acesso a todas as informações que podem estar armazenadas nele. As periodicidades mais comuns são a mensal e a anual.

Pagamento por uso: nesse caso, paga-se pelo uso do produto que deve ter uma forma muito fácil de ser medida e acompanhada. Por exemplo, em um produto de e-mail marketing, que permite o disparo de mensagens de e-mail para uma lista de endereços, pode ser cobrado pela quantidade de mensagens enviadas. Outro bom exemplo é o pagamento de anúncios, que podem ser pagos por exibição, por cliques ou ainda pela conversão do anúncio. A comissão cobrada pelos sites de intermediação de venda de itens físicos como eBay, MercadoLivre e Elo7 é outro exemplo, como também a cobrança feita pelo Skype para fazer ligações para telefones fixos e celulares.

É possível ainda ter um modelo misto, com pagamento periódico mais pagamento por uso. Um bom exemplo é um produto para telefonia via internet, em que você pode cobrar uma mensalidade para ter acesso ao produto, mais uma cobrança por ligações feitas, sendo o caso do PABX Virtual da Locaweb. Outro exemplo é um produto que oferece a possibilidade de seu usuário ter uma loja virtual. Nesse caso, pode-se cobrar uma mensalidade mais uma taxa de uso baseada na quantidade de vendas que seu cliente faz usando essa loja.

Obtendo Retorno de uma Plataforma

Nos capítulos O que é um produto de software? e O que é gestão de produtos de software?, falei sobre um tipo diferente de produto de software, as plataformas, sistemas que são mais valorizados quanto mais pessoas usam. Expliquei o que as diferenciam de um produto, e quais as diferenças entre gerenciar um produto e uma plataforma.

Agora que vimos como obter retorno com um produto de software, perguntas que ficam são: como funciona a precificação da plataforma, onde tenho interesse que muitas pessoas usem para que ela seja mais valorizada? E, em alguns casos de plataforma, tenho pessoas de grupos diferentes (compradores e vendedores, desenvolvedores de apps e usuários de smartphones). O ideal em uma plataforma seria não cobrar nada de ninguém, para garantir o maior número de usuários; entretanto, se eu não cobrar nada, como cobrirei os custos do seu desenvolvimento e de sua operação? São quatro pontos que devemos levar em conta sobre precificação de plataforma: quem, o quê, quanto e quando devemos cobrar.

Quem devemos cobrar?

A primeira resposta a essa pergunta é simples: quem for menos sensível ao preço. Se você tem uma plataforma de dois lados, identifique qual dos dois é menos sensível a um preço; este será o lado com maior disposição para pagar por uma plataforma. O lado mais sensível é o que queremos subsidiar.

Por exemplo, se você estiver gerenciando uma plataforma que conecta advogados com possíveis clientes, é bem provável que o lado menos sensível ao preço sejam os advogados, por terem margens altas. Por outro lado, suponha que você esteja gerenciando uma plataforma que conecta fornecedores de equipamentos e materiais químicos – que têm pouca margem em seus preços – com possíveis compradores; talvez faça mais sentido cobrar dos compradores, devido à baixa margem dos fornecedores.

Contudo, como disse anteriormente, essa é só a primeira resposta. Há outros fatores a serem considerados:

  • Sensibilidade à escala: se um dos lados perceber que sua plataforma é mais valiosa a partir da quantidade de usuários do outro lado, este será o sensível à escala e com maior disposição para pagar pela plataforma. Por exemplo, no Google, quanto mais pessoas buscando, mais interessante a plataforma fica para os anunciantes.
  • Sensibilidade à competição: se um dos lados perceber que a plataforma é mais valiosa quanto menor for o seu lado e, consequentemente, menor for a competição existente, este será o lado sensível à competição e com mais disposição para pagar. Um exemplo fora da internet são os bares que cobram entrada, que decidem ou cobrar uma entrada mais barata das mulheres ou não cobrar, mas cobram entrada cheia dos homens, que estarão dispostos a pagar por entender que haverá menos competição. Para atrair mais clientes do sexo feminino, os bares costumam ter uma política de “entrada gratuita para mulheres”, às vezes uma noite das mulheres. Em alguns casos, essas políticas foram contestadas em processos judiciais como discriminatórias, e são ilegais em algumas jurisdições nos Estados Unidos, mas é um bom exemplo de sensibilidade à competição, se enquadrarmos como uma plataforma bilateral onde homens e mulheres vão para se conhecer.

Há vários fatores para se levar em consideração. Em alguns casos, os dois lados podem estar dispostos a pagar; em outros, somente um. Casos como Google e Facebook são mais simples de analisar:

  1. São sempre dois lados: quem anuncia e quem consome a plataforma.
  2. Para quem anuncia, quanto mais pessoas consumindo a plataforma, melhor.
  3. Para quem consome a plataforma, os anúncios ou o próprio conteúdo podem ser uma intrusão se o Facebook e o Google não conseguirem fazê-los ser relevantes.
  4. Para quem anuncia, cada negócio iniciado ou fechado através da plataforma representa um ganho.
  5. Para quem consome a plataforma, cada negócio iniciado ou fechado através da plataforma representa um investimento com um possível desembolso de dinheiro.
  6. Por essas razões, principalmente pelas duas últimas, faz sentido que sejam os anunciantes a pagar.

Por outro lado, casos como sites de leilão, de emprego, de busca de táxi, e de imóveis para compra ou aluguel já são mais complexos:

  1. Também são sempre dois lados: quem anuncia e quem tem interesse no que está sendo anunciado.
  2. Para quem anuncia, quanto mais pessoas consumindo a plataforma, melhor.
  3. Para quem tem interesse no que está sendo anunciado, quanto mais ofertas disponíveis, melhor, pois há mais chances de encontrar o que se procura.
  4. Para quem anuncia, cada negócio iniciado ou fechado através da plataforma representa um ganho.
  5. Para quem tem interesse no que está sendo anunciado, cada negócio iniciado ou fechado através da plataforma representa a possibilidade de conseguir o que estava procurando.
  6. Por essas razões, principalmente pelas duas últimas, pode fazer sentido que os dois lados paguem para usar a plataforma. Por outro, considerando os itens 2 e 3, também faz sentido que os dois lados possam usar a plataforma sem nenhum custo. Nesse caso, pode fazer sentido analisar quem é menos sensível ao preço e quais são as práticas do mercado.

O que devemos cobrar?

Normalmente, as pessoas estão dispostas a pagar por algo quando enxergam o valor e o benefício que esse algo traz para elas.
Existem 3 benefícios que podem ser cobrados em uma plataforma:

  • Acesso: pode-se cobrar para as pessoas terem acesso à plataforma. Algo como uma taxa mensal, por exemplo. Essa é a forma de cobrar menos comum, uma vez que um dos seus principais benefícios é a quantidade de pessoas nos diferentes lados. Pode-se encontrar esse modelo em plataformas que trabalham a exclusividade, em que a qualidade dos membros é sua principal proposta de valor, e a quantidade não é relevante. Algumas plataformas, após atingirem um certo volume crítico, podem decidir cobrar pelo acesso para garantir qualidade e exclusividade. É possível também implementar dois níveis de acesso, um grátis e um pago, com diferentes funcionalidades e níveis de serviço como, por exemplo, quem é grátis tem suporte somente via site de perguntas e respostas, e quem paga tem direito a um suporte personalizado por telefone.
  • Uso: pode-se cobrar por cada vez que as pessoas utilizam a plataforma. Por exemplo, em um site para anúncio de vagas de trabalho, pode-se cobrar por cada vaga anunciada. Outro exemplo é o Google AdWords, em que a cobrança é feita a cada vez que alguém clica em seu anúncio, isto é,
  • Taxa/percentual: nesse modelo, o valor a ser cobrado é um percentual ou uma taxa variável do benefício que um dos lados da plataforma tem com cada negócio realizado nela. Normalmente, sites de leilão e de intermediação de pagamento (PayPal, PagSeguro etc.) costumam usar esse modelo de cobrança.

É possível fazer combinações dessas formas de cobrança. Por exemplo, cobrar uma taxa mensal de acesso mais uma taxa de uso, ou um percentual.

Quanto devemos cobrar?

Para responder a essa pergunta, precisamos pensar no lock-in, que significa que um usuário de sua plataforma tem chances menores de parar de usá-la quanto mais ele usar e enxergar benefícios no seu uso. O custo de troca é o que explica o lock-in; quanto maior o custo de troca, maior será o lock-in. Outro ponto importante para levar em consideração quando estamos definindo quanto cobrar pela plataforma é o efeito de rede, ou seja, quanto valor geramos para o usuário ao termos mais pessoas usando a plataforma. Normalmente, o valor a ser cobrado por uma plataforma, quer seja acesso, uso e/ou taxa, reflete no lock-in e no efeito de rede.

Geralmente, esses valores mudam ao longo do ciclo de vida de uma plataforma. No começo, quando há poucos usuários, e o lock-in e o efeito de rede ainda são pequenos, é muito provável que se tenha que subsidiar o seu uso.

O Dropbox pode ser visto como uma plataforma de um lado só (single-sided platform), onde o benefício do efeito de rede aparece quanto mais usuários o usarem para troca de arquivos. O custo de troca aumenta à medida que você coloca mais arquivos no Dropbox e tem mais conhecidos com quem trocar esses arquivos por lá. Esse é o motivo por ele cobrar por GB e incentivar a convidar amigos para também o usar. Esse incentivo, dando GBs de graça para você e para os amigos que convidar, é a forma de subsídio que o Dropbox usa para poder aumentar o lock-in e o efeito de rede de sua plataforma.

Outro exemplo interessante é o de um serviço de monitoração de avalanches, que lançou uma plataforma na qual resorts de esqui compartilhariam dados sobre condições meteorológicas para poder prever avalanches com maior acurácia. Para poder participar desse sistema, o resort teria de instalar um monitor, e esse processo de instalação tinha um custo considerável.

A plataforma pretendia cobrar também uma mensalidade para os resorts poderem usá-la. O problema é que eles não se sentiam confortáveis em pagar a mensalidade tendo já pago o custo da instalação do equipamento de monitoração. Além disso, não queriam pagar mensalidade no verão, quando há poucas avalanches e os resorts têm baixa ocupação. A solução encontrada foi subsidiar a instalação dos monitores nos resorts e fazer a cobrança anual em vez de mensal, com preço variando por profundidade da análise feita.

Quando devemos cobrar?

Para cobrança por acesso à plataforma, pode-se cobrar uma única vez ou periodicamente. Por periodicidade, pode-se variar do mensal até a cobrança por múltiplos anos. Não é incomum ver casos em que há múltiplas opções de período (por exemplo, mensal e anual), em que se oferecem descontos nos preços com período maior. Em alguns casos, períodos maiores podem ser a única forma de mostrar o benefício do longo prazo de sua plataforma, ou de afastar preocupações com a sua utilidade sazonal, como no caso do serviço de monitoração de avalanches.

Para cobrança por uso, o mais comum é fazer essa cobrança de forma periódica, ou seja, a cada período é avaliado quanto foi usado e é feita a cobrança. O período mais comum é o mensal.

Um cuidado deve ser tomado em relação a modelos de cobrança mistos, com cobrança por acesso mais cobrança por uso. Se você fizer cobrança por acesso anual, avalie se você poderá fazer também a cobrança por uso anual, ou se é melhor cobrar pelo uso mensal ou trimestralmente.

Já na cobrança de taxa ou percentual, o mais indicado é que ela ocorra no evento da transação. Caso haja uma frequência alta de eventos de transação em um mês, uma outra opção é cobrar essa taxa mensalmente.

Concluindo

Todo produto de software tem custos de desenvolvimento e de operação, e é preciso cobri-los de alguma forma. Vimos diferentes formas de se obter retorno com o produto e entendemos as diferenças entre produto e plataforma no que se refere à obtenção de receita.

Gestão de produtos digitais

Este artigo é o 12º capítulo 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:

Inovação: Muitas Oportunidades

É provável que, após se focar no problema e entender o trabalho a ser feito, como descrito no capítulo anterior, você descubra não só uma, como algumas oportunidades de desenvolvimento de novo produto, ou de funcionalidades novas para seu produto de software.

Nunca vi em nenhuma organização uma situação em que abundavam os recursos e havia escassez de oportunidades. Via de regra, sempre há muitas oportunidades pela frente, e não sabemos qual ou quais perseguir, pois não conseguimos perseguir todas já que não temos os recursos necessários (tempo, dinheiro ou pessoas) disponíveis.

Nessas situações, gosto de usar o modelo de análise de oportunidade, proposto por Marty Cagan, em seu livro Inspired: how to create products customers love. Cagan é ex-vice-presidente de gestão de produtos no eBay e, atualmente, consultor sobre gestão de produtos.

Respondendo a um conjunto de 10 perguntas, podemos ter mais informação para decidir se vale perseguir uma determinada oportunidade agora ou se é melhor deixar para reavaliá-la no futuro. As perguntas são bem simples:

  1. Qual problema vai resolver?–proposição de valor;
  2. Para quem esse problema será resolvido?–mercado alvo;
  3. Qual o tamanho dessa oportunidade? – tamanho do mercado;
  4. Que alternativas existem?–cenário competitivo;
  5. Por que somos os melhores qualificados para perseguir essa oportunidade? – nossa diferenciação;
  6. Porque agora?–janela de oportunidade;
  7. Como levaremos essa oportunidade ao mercado? – estratégia de lançamento;
  8. Como vamos medir o sucesso e ganhar dinheiro com esse produto? – métricas e receita;
  9. Que fatores são críticos para o sucesso? – requisitos essenciais;
  10. Dado o acima, qual a recomendação?–go ou no-go.

As perguntas de 1 a 4 servem para entender melhor a oportunidade. Já as 5 e 6 são bem interessantes, pois não basta só entender a oportunidade e ela ser muito boa. É preciso ter certeza de que esse é o momento certo e que nós somos os mais qualificados para persegui-la.

De 7 a 9 são perguntas do tipo “e se…”, ou seja, supondo que se decida por perseguir essa oportunidade, como ela vai ser levada ao mercado, como será medido o sucesso e quais fatores são críticos para o sucesso.

Responder a esse questionário é bom não só para decidir se vale a pena desenvolver um determinado produto, ele também pode ajudar com oportunidades de parceria, oportunidades de desenvolver novas funcionalidades, e oportunidade de atender um cliente especial que requer mudanças no seu produto. Enfim, todas as oportunidades que vão requerer esforço seu e do seu time podem e devem ser analisadas para ver se o retorno compensa o investimento de esforço requerido.

Quantas Oportunidades Perseguir ao Mesmo Tempo?

Outra dica importante é não perseguir muitas oportunidades ao mesmo tempo; caso contrário, você e seu time perderão o foco e acabarão não obtendo retorno de nenhuma das oportunidades perseguidas.

No mundo ideal, o indicado é perseguir uma oportunidade por vez. Porém, como sabemos que isso é utópico, acabaremos perseguindo mais de uma oportunidade simultaneamente. Procure limitar essa quantidade a poucas unidades (2, 3 ou 4, no máximo), lembrando de que, em qualquer momento, você e seu time só conseguem dar atenção a uma coisa por vez.

Se você estiver trabalhando em mais de uma oportunidade ao mesmo tempo, toda vez que quiser trabalhar em uma delas, deixará de trabalhar momentaneamente nas outras. Por isso, restrinja a poucas oportunidades para perseguir, preferencialmente, uma por vez.

Novas Oportunidades vs. Melhorias no Produto Existente

Essa é uma dúvida bastante frequente. Devo perseguir novas oportunidades? E o que faço com as dores dos clientes atuais? Devo desenvolver um novo produto ou uma nova funcionalidade? Ou devo resolver dores dos clientes atuais desenvolvendo melhorias em meu produto? Como fazer para balancear entre perseguir novas oportunidades e implementar melhorias no produto existente?

Aqui a solução é simples, pelo menos em teoria. Produto atual é produto atual, novas oportunidades são novas oportunidades. Cada um tem de ser tratado de um jeito. O ideal é que sejam tratados até mesmo por times diferentes. Só que nem sempre isso é possível. Nesses casos, se quisermos perseguir novas oportunidades, esse time precisa saber separar claramente o trabalho no produto existente versus o trabalho nas novas oportunidades. Por exemplo, 2 semanas para o produto existente e uma para a nova oportunidade, até que se justifique a criação de um novo time para a nova oportunidade.

Atenção: não é time de bugs

Esse é um ponto importante. A ideia não é separar os times para ter um time fazendo coisas novas e outro corrigindo bugs do produto existente. Isso não funciona, pois vai criar uma separação muito grande entre os dois times.

Quem faz coisas novas vai eventualmente acreditar que pode fazer qualquer coisa sem se preocupar tanto com qualidade, já que existe um time focado em correção de bugs. Do outro lado, o “time de bugs” vai achar que está fazendo trabalho de faxineiro, limpando as bagunças que outras pessoas fazem.

Oportunidades vs. melhorias

Antes de investir em uma nova oportunidade, é muito importante entender por que está investindo nela. Uma ótima ferramenta para isso é a análise de oportunidades, descrita anteriormente. Sem um claro entendimento e correto engajamento de todos os envolvidos, pode-se colocar a oportunidade a perder sem nem mesmo começar a explorá-la.

Um ponto importante que todos os envolvidos devem entender é que uma nova oportunidade é uma nova oportunidade, isto é, ela deverá gerar resultados que se somam aos atuais. Esses resultados deveriam ser suficientes para justificar a criação de um novo time para perseguir essa nova oportunidade. No mínimo, dois engenheiros de software.

Idealmente, além dos dois engenheiros, seria bom ter um gestor de produtos, um designer de UX e uma pessoa de marketing de produto dedicados a essa nova oportunidade. Ela será um novo produto ou uma nova funcionalidade. Quando esse novo produto ou nova funcionalidade estiver pronto e lançado, quem trabalhou no seu desenvolvimento vai cuidar de seus bugs e melhorias.

Enquanto isso, o outro time cuida do produto atual, isto é, de melhorar o produto atual para que ele continue atingindo seus objetivos. Melhorar o produto atual significa sim corrigir bug, mas significa também fazer coisas novas no produto existente. Melhorias para tornar o produto melhor, mais útil e mais usável.

Caso não seja possível criar um novo time, pode-se fazer compartilhamento do tempo do mesmo time. Algo como uma ou duas semanas para bugs e melhorias do produto atual, e uma semana para a nova oportunidade, até que se justifique a criação de um novo time para a nova oportunidade.

Como saber se é uma melhoria ou uma nova oportunidade?

É responsabilidade do gestor de produtos, junto com o time, entender se esse algo novo que surgiu para ser feito é uma oportunidade ou uma melhoria. Mas como discernir entre melhoria e oportunidade? Especialmente quando o algo novo a fazer for uma nova funcionalidade do produto existente, devemos encarar como nova oportunidade ou melhoria do produto existente?

Depende do esforço e do retorno envolvidos. Uma nova oportunidade deve ter um retorno alto para fazer sentido persegui- la. Lembre-se de que uma nova oportunidade vai eventualmente ter um time só para cuidar dela, então é preciso que o retorno seja suficiente para justificar esse novo time. Se o retorno for incerto, é melhor não tirar energia do produto existente para persegui-la.

Por outro lado, se houver a perspectiva de um bom retorno, qual o esforço de criar algo para explorar essa oportunidade? E qual será o esforço para o manter? Essas duas perguntas devem orientar a forma de encarar. Se o esforço for baixo, esse algo novo pode ser tratado como uma melhoria e ser desenvolvido pelo time atual. Se o esforço é alto, é recomendável tratá-lo como nova oportunidade e considerar ter um time separado para fazer o desenvolvimento.

Testando Oportunidades

Depois de analisar as oportunidades, o próximo passo é testá- las, ou seja, ver se realmente existem pessoas interessadas nesse seu produto que resolverá o problema que você pesquisou. Existem algumas maneiras para fazer isso. A primeira é voltar para a rua e conversar com possíveis clientes. Essa será uma conversa exploratória na qual você expõe o problema para pessoas que provavelmente o tenham. Em seguida, você conta sobre a solução que será desenvolvida e avalia a reação. Simples assim. O problema de contar sobre uma solução é que, por melhor que seja a descrição, ela ainda não é um produto pronto, e força a pessoa a imaginar algo que pode ser diferente daquilo que você está concebendo.

Em 2011, resolvi fazer um teste um pouco mais realista. Nessa época, conduzi um experimento de startup, fiz minha pesquisa inicial e acabei com 3 ideias de produto para desenvolver. Com dificuldade para escolher em qual das 3 oportunidades investir meu dinheiro, minha energia e meu tempo, resolvi fazer um teste bastante simples. Escolhi um nome e um domínio para cada uma das ideias e os registrei. Em seguida, criei uma página para cada uma das ideias de produto web que tive. Como não sou designer, nem tenho qualquer habilidade para fazer páginas bonitas, usei um site chamado unbounce (http://unbounce.com), que permite criar páginas simples e até testes A/B de forma bem fácil. Com o unbounce, criei a seguinte página:

Tela do ContaCal no unbounce

Note que essa página tem só 3 pontos que descrevem o produto: um para falar do problema; outro para falar da solução; e um terceiro para falar do preço. O formulário de e-mail serviu para captar a quantidade de interessados. Rodei uma campanha no Google AdWords de R$10,00 por dia por produto que queria testar durante um mês. Veja um print de um resultado parcial:

Resultado parcial no unbounce

Esse print é de uma tela do unbounce. Depois dos 30 dias de testes, terminei com 216 e-mails interessados no ContaCal – que foi o produto que acabei lançando e está no ar até hoje – e 1.043 pageviews, o que dá 20,7% de taxa de conversão. As outras duas ideias também mantiveram a mesma tendência desse resultado parcial. Preferi deixá-las ilegíveis para não influenciar ninguém a apostar em alguma delas sem fazer testes.

Para quem não conhece, o ContaCal é um diário alimentar virtual no qual o usuário registra sua alimentação e o sistema informa a quantidade total de calorias, como de um chocolate twix. Além da quantidade total de calorias, ele também informa a qualidade das calorias por meio de um sistema de cores. As cores servem para indicar quão recomendável é ingerir o alimento. Se é um alimento de calorias vermelhas, é melhor evitá-lo ao máximo. Calorias amarelas podem ser ingeridas com moderação. Já as calorias verdes podem ser ingeridas sem restrição.

O custo total desse teste foi de R$990,00:

  • Campanha AdWords: R$900,00.
  • Domínios: R$90,00.
  • Site unbounce: grátis por 30 dias; se passasse, pagaria R$85,00 por mês para até 5 domínios diferentes que eu quisesse testar ao mesmo tempo.

Cada nova ideia custa R$30,00 por registro de domínio .br, e mais R$300,00 por mês de campanha no Google AdWords se fizermos um investimento de R$10,00 por dia.

Um ponto importante a observar é que não necessariamente o ContaCal era a melhor das três oportunidades, mas sim a que eu melhor consegui comunicar. Por isso, esse teste é interessante, ajuda não só a testar a ideia de um produto como também a sua capacidade de comunicar.

Gestão de produtos digitais

Este artigo é o 12º capítulo 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:

Inovação: o trabalho a ser feito

O Prof. Clayton Christensen, professor de Harvard e autor de vários livros – dentre eles The Innovator’s Dilemma: the revolutionary book that will change the way you do business, obrigatório para todas as pessoas que trabalham com tecnologia –, desenvolveu uma técnica para descobrir problemas a serem resolvidos, chamada “o trabalho a ser feito”.

A ideia por trás do “trabalho a ser feito” é que precisamos entender para qual trabalho nossos clientes contrataram nossos produtos, isto é, qual o trabalho que nossos clientes esperam que nossos produtos façam.

Clayton ilustra essa técnica com um exemplo muito interessante. Ele havia sido contratado para avaliar um produto específico de uma lanchonete, o milkshake. A empresa já tinha feito pesquisas com os clientes perguntando o que eles queriam: se eram milkshakes mais densos, com pedaços de biscoito, de fruta ou de chocolate, ou com mais calda. A resposta da pesquisa apontou para uma preferência, que foi implementada. Contudo, essa preferência em nada mudou as vendas, o que era o objetivo principal da empresa.

Clayton decidiu fazer, então, a pesquisa de forma diferente. Em vez de perguntar o que os clientes queriam, procurou entender qual era o trabalho para o qual as pessoas contratavam o milkshake. Após várias conversas com clientes, descobriu que os clientes passavam na lanchonete antes de ir para o trabalho de carro e que ficavam bastante tempo no trânsito. O milkshake, por ser grosso e ser tomado de canudo, demorava para acabar. Demorava o tempo todo da viagem, ou seja, entretinha o cliente durante toda a viagem até chegar ao trabalho. As pessoas contratavam o milkshake de manhã antes de ir para o trabalho de carro para ter com que se entreter no caminho.

Elas já haviam tentado com outros “concorrentes”, como bananas, mas acabava muito rápido. Tentaram também com bagels, mas o trabalho e a sujeira para passar manteiga não compensava. O milkshake era perfeito para esse trabalho a ser feito!

Entendendo o trabalho a ser feito, a lanchonete pôde melhorar o milkshake, deixando-o mais denso e colocando pequenos pedaços de fruta e/ou cereais para adicionar pequenas surpresas enquanto seus clientes os degustavam. Além disso, preparou um sistema de atendimento que minimizou as filas para garantir um tempo mínimo de espera, por entender que seus clientes estavam com pressa e não queriam ficar esperando na lanchonete. Esses ajustes, sim, trouxeram melhorias nas vendas.

O alcance da técnica do “trabalho a ser feito”

O próprio Clayton comenta que, no marketing mais tradicional, é comum associar um determinado produto a um determinado conjunto demográfico. Por exemplo, no caso anterior, se fôssemos responsáveis pela gestão de produtos da lanchonete, poderíamos associar milkshakes com pessoas de certa idade que trabalham e que, consequentemente, sempre procuram milkshake densos que demorem para acabar. Acontece que, usando a técnica do “trabalho a ser feito”, temos uma visão mais ampla do contexto onde o produto está inserido.

Clayton estendeu sua pesquisa para outros períodos do dia e pegou as mesmas pessoas voltando à lanchonete no fim da tarde, só que agora com seus filhos, para um lanche rápido. Com certa frequência, os filhos pediam aos pais por um milkshake. A lanchonete servia o mesmo milkshake: denso, grande, e que demorava para acabar. Só que os pais não queriam esperar muito tempo para que os filhos terminassem seus milkshakes; era para ser um lanche rápido.

Aqui, apesar de o cliente ser o mesmo, o trabalho a ser feito era outro: agradar o filho do cliente de forma rápida. Sendo assim, o milkshake poderia ser menor, talvez metade do tamanho, e menos denso, para acabar mais rápido.

O mesmo cliente quer que o mesmo produto faça trabalhos diferentes, a depender da situação. Daí a importância de entender o trabalho a ser feito.

Compreendendo os problemas e seu contexto

Neste capítulo e no anterior, aprendemos como entender mais sobre um problema de um grupo de pessoas; entender a fundo seus problemas e o contexto em que eles acontecem; e entender a motivação que as pessoas têm para querer que ele seja resolvido.

Eventualmente, ao usarmos a técnica do trabalho a ser feito, fica a dúvida: será que temos uma boa oportunidade em mãos? Ou ainda, pode acontecer de encontrarmos mais de um problema. Como escolher, dentre esses problemas, qual é a melhor oportunidade a ser explorada? É o tema do próximo capítulo.

Gestão de produtos digitais

Este artigo é o 12º capítulo 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:

Inovação: foco no problema

O primeiro passo para se criar um novo produto de software é entender o problema. É bastante tentador, à medida que se vai entendendo o problema, já ir buscando soluções. É da natureza humana solucionar problemas.

Todo desenvolvedor de software tem alguma história para contar sobre demandas mais ou menos assim: “Então, eu preciso de um sistema que faça isso e aquilo, preciso ter um campo para eu digitar essas informações e ele deve ter um relatório que mostre isso aqui”. Aí, quando esse sistema é entregue, a pessoa fala: “Bem, já ajuda, mas agora eu preciso também de um campo para inserir esse outro dado, e preciso que o sistema exporte um arquivo .txt separado por vírgulas”. Em outras palavras, as demandas já vêm em forma de soluções e sequer mencionam qual o problema a ser resolvido.

Existem algumas técnicas para focar no problema:

Entrevista

É uma ótima forma de entender mais sobre o cliente, o problema que ele tem, o contexto onde esse problema acontece, e o que o motiva a ter esse problema resolvido. Contudo, é preciso ter cuidado, pois o entrevistado vai tentar dar a solução que ele já pensou para o problema. Você deve ser cuidadoso para não menosprezar a sua sugestão, mas deve sempre manter a conversa focada no problema.

A entrevista, na qual você conversa diretamente com seu cliente, é considerada um método qualitativo, ou seja, você faz algumas poucas perguntas, mas tem a oportunidade de se aprofundar nas respostas.

A seguir, está um conjunto de perguntas para ajudar a manter a conversa focada no problema:

  • Conte-me sobre seu problema.
  • Qual é a maior dificuldade que você tem em relação a esse problema?
  • O que o motiva a querer ter esse problema resolvido?
  • Onde esse problema costuma acontecer?
  • Quando aconteceu pela última vez? O que aconteceu?
  • Por que foi difícil / complicado / ruim?
  • Você conseguiu achar uma solução? Qual(is)?
  • O que você não gostou das soluções que achou?

Por exemplo, voltando à questão do carro e da carroça do Henry Ford, imagine um diálogo imaginário entre Henry Ford e um hipotético Sr. Smith, um possível comprador de seu futuro produto:

– Sr. Smith, o que mais o aflige?

– Sr. Ford, o que mais me aflige é que passo pouco tempo com minha família.

– E por quê?

– Porque passo tempo demais na carroça indo de um lado para o outro. Se eu pudesse colocar mais um cavalo puxando minha carroça, ela andaria mais rápido e eu passaria mais tempo com minha família.

– Ah, entendi seu problema, e tenho uma solução ainda melhor para você, chama-se automóvel.

Será mesmo que Henry Ford entendeu o problema? Ou ele entendeu a solução que o Sr. Smith apresentou para ele, e desenvolveu uma solução baseada na solução dada pelo Sr. Smith? Será que o problema real do Sr. Smith não era que ele passava pouco tempo com a família?

Vamos experimentar usar as perguntas mostradas anteriormente para ver se conseguimos entender melhor o problema:

– Sr. Smith, o que mais o aflige?
– Sr. Ford, o que mais me aflige é que passo pouco tempo com minha família.
– E qual é a maior dificuldade que o Sr. tem em relação a esse problema?
– Passo muitas horas no trabalho, indo de um lugar para outro, sem falar com as pessoas.
– O que o motiva a querer ter esse problema resolvido?
– Tenho crianças pequenas e, por causa do trabalho, passo muito tempo fora de casa. Quando chego em casa, meus filhos já estão dormindo.
– Onde esse problema costuma acontecer?
– No trabalho.
– Quando aconteceu pela última vez? O que aconteceu?
– Praticamente todos os dias. Aconteceu ontem. Acho que eu consigo chegar em casa a tempo de ver meus filhos acordados uma vez por semana…
– Por que foi difícil / complicado / ruim?
– Porque me deixou longe das crianças.
– Você conseguiu achar uma solução? Qual(is)?
– Saí mais cedo do trabalho.
– O que você não gostou das soluções que achou?
– O trabalho acumulou nos outros dias.

Note que essa conversa pode gerar como solução a invenção do carro para ajudar o Sr. Smith a chegar mais rápido em casa. Entretanto, poderia também ter sido a motivação para a criação de um processo mais eficiente de trabalho, ou de uma máquina que fizesse o trabalho pelo Sr. Smith.

Você pode ter uma solução em mente. Mas considere fazer uma entrevista real, concentrando-se nas perguntas para realmente entender o problema do cliente.

Pesquisa

Outra forma de se obter informações dos clientes é pela pesquisa. Esse método é considerado quantitativo, pois procura-se pesquisar uma quantidade considerável de pessoas para poder obter o que é conhecido como relevância estatística. Ou seja, para se poder confiar que o resultado obtido não tenha acontecido por acaso.

Por exemplo, caso você pergunte em uma pesquisa se uma pessoa tem iPhone ou Android, e só consiga duas pessoas para respondê-la, isto é, só duas respostas – quer sejam as duas iPhone, as duas Android, ou uma iPhone e a outra Android –, é muito difícil concluir qualquer coisa. Já se você tiver mais respostas, maiores as chances de o resultado de sua pesquisa refletir a realidade.

Existem ótimas ferramentas para se fazer pesquisa online, como o Google Form e o Survey Monkey. Existe também uma ferramenta brasileira chamada OpinionBox que, além de ajudar a construir seu questionário e coletar respostas, permite também que você selecione pessoas para respondê-lo baseando-se em critérios de definição de perfil que você especifica.

Pesquisas não precisam necessariamente ser feitas online. Pode-se também fazer uma por telefone ou ao vivo. Existem empresas que podem ajudá-lo a coletar as respostas.

Decidir fazer uma pesquisa é fácil, já fazer o questionário é difícil. O primeiro passo é ter bem claro qual é o seu objetivo com a pesquisa. Em seguida, crie suas perguntas tendo em mente duas regras principais:

  1. Seja breve. Quanto menor o seu questionário, maiores são as chances de obter um bom número de respostas e garantir maior relevância estatística.
  2. Seja claro. Principalmente em questionários online, quando você não interage com o respondente do questionário, são grandes as chances de a pessoa interpretar sua pergunta de forma diferente da qual você havia originalmente pensado. Uma boa forma de você testar seu questionário antes de disponibilizá-lo para obter um grande número de respostas é testá-lo com algumas pessoas ao vivo. Verifique o que as pessoas entenderam de cada pergunta, ou se tiveram dificuldade em compreender alguma parte dele.

Veja alguns exemplos de perguntas ruins que podem gerar interpretações equivocadas ou atrapalhar a qualidade das respostas obtidas, e sugestões de como essas perguntas podem ser melhoradas:

Pergunta original: Quão baixo era Napoleão?

Versão melhorada: Qual era a altura de Napoleão?

Pergunta original: Pais preocupados devem usar cadeirinhas infantis no carro?

Versão melhorada: Você acha que o uso de cadeiras especiais para crianças no carro deve ser obrigatório?

Pergunta original: Onde você gosta de beber cerveja?

Versão melhorada: Quebrar em duas perguntas: Você gosta de beber cerveja? Se sim, onde você gosta de beber cerveja?

Pergunta original: No seu trabalho atual, qual é seu nível de satisfação ou insatisfação com o salário e benefícios?

Versão melhorada: Quebrar em duas perguntas: Qual é seu nível de satisfação com seu salário em seu trabalho atual? Qual é seu nível de satisfação com seus benefícios em seu trabalho atual?

Pergunta original: Você sempre toma café da manhã? Respostas possíveis: Sim / Não.

Versão melhorada: Em quantos dias por semana você costuma tomar café da manhã? Respostas possíveis: Todos os dias / 5-6 dias / 3-4 dias / 1-2 dias / Não tomo café da manhã.

Observação

Uma outra técnica bem útil para entender o problema é a observação. Ver o cliente enfrentando o problema ou tendo uma necessidade, no contexto em que isso ocorre, pode ser inspirador!

A observação é uma forma qualitativa de se entender um problema. Para fazer uma boa observação, se prepare; tenha em mão um conjunto de hipóteses. A cada rodada de observação, reavalie as suas hipóteses e ajuste-as, se necessário. Normalmente, após umas 6 ou 8 observações, você já começará a encontrar um padrão.

A observação pode ou não ter a interferência do observador. Por exemplo, se você estiver observando hábitos de consumo em uma farmácia, você pode fazer isso sem que as pessoas notem que você as está observando. Já em um teste de usabilidade, no qual você convida pessoas a testarem seu software, as pessoas saberão que você as está observando. As observações podem ser complementadas com entrevistas, o que pode ajudar a melhorar a qualidade dos achados.

Uma técnica muito útil para descobrir problemas no uso do software é observar o que o seu usuário faz 10 minutos antes e depois de usá-lo. Por exemplo, se ele pegar informações em algum outro sistema para inserir no seu software. Talvez haja aí uma oportunidade para você já trazer essas informações do outro sistema de forma automática. E se, após usá-lo, ele copia informações para uma planilha para gerar algum gráfico, eventualmente seu software poderia poupar esse trabalho e já gerar esse gráfico para ele.

A observação geralmente é descrita como um método qualitativo. Mas você pode e deve tratá-la como uma observação quantitativa. Para isso, observe o usuário e algumas métricas importantes, como estatísticas de acesso e de uso, engajamento, NPS, receita, novos clientes, churn etc. Em outras palavras, é uma forma de observar o comportamento do seu usuário enquanto ele se relaciona com seu software.

Foco no problema vs foco na solução

Quando nos apressamos em lançar um MVP, estamos criando uma solução para um problema. No entanto, um passo muito importante para criar uma boa solução é o entendimento do problema.

É da natureza humana entrar no modo de solução quando aprendemos sobre um problema. Quando ouvimos sobre um problema, imediatamente começamos a pensar em soluções. No entanto, quanto mais tempo gastamos aprendendo sobre o problema, mais fácil será encontrar uma solução e há boas chances de que essa solução seja mais simples e rápida de implementar do que a primeira solução em que pensamos.

Aqui está uma ótima citação de Albert Einstein:

“Se eu tivesse uma hora para resolver um problema, passaria 55 minutos pensando no problema e cinco minutos pensando em soluções.”

Einstein acreditava que a qualidade da solução gerada é diretamente proporcional à sua capacidade de identificar e entender o problema que você espera resolver.

Deixe-me contar uma pequena história para ilustrar isso.

Durante a corrida espacial, os cientistas se depararam com a questão de escrever no espaço, onde não há gravidade para fazer a tinta cair em uma caneta esferográfica. Os americanos iniciaram seus esforços de P&D e, após algum tempo e alguns milhões de dólares, construíram uma caneta com um pequeno motor que bombeia tinta para o papel, mesmo sem gravidade. Enquanto isso, os russos decidiram usar lápis, que podem fazer o trabalho de escrever em ambientes sem gravidade.

Fisher Space Pen, caneta que escreve sem gravidade

Esse foco nas soluções, sem uma boa compreensão do problema e a motivação para resolvê-lo, pode ser bastante prejudicial. Isso pode nos fazer gastar tempo e dinheiro desnecessários para chegar a soluções abaixo do ideal. Essa é uma questão cultural, ou seja, um comportamento que podemos e devemos mudar. O primeiro passo para mudar um comportamento é reconhecê-lo quando isso acontecer. Quando você, como gerente de produto ou membro da equipe de desenvolvimento de produto, recebe uma solicitação para implementar algo, pergunta à pessoa que a solicitou qual é o problema que esse “algo” deve resolver e por que é necessário resolvê-lo.

Aqui estão alguns exemplos das empresas em que trabalhei.

Na Locaweb, um provedor de hospedagem de sites, os serviços de hospedagem e email podem parar de funcionar devido a fatores externos, como o domínio associado à hospedagem e ao email, não serem renovados.

Primeira solução: o Registro.br, o registrador brasileiro de domínios .br, lançou uma API para permitir à Locaweb cobrar o domínio do cliente em nome do Registro.br. No início, a ideia parecia boa, já que a Locaweb faturava o domínio como a maneira mais fácil de garantir que o cliente soubesse que precisava pagar pelo registro do domínio para manter os serviços de hospedagem e email funcionando corretamente. No entanto, quando analisamos mais profundamente, vimos que essa solução poderia gerar alguns problemas. O cliente seria cobrado duas vezes pelo mesmo registro de domínio porque o Registro.br continuaria cobrando o domínio. O que aconteceria se o cliente pagasse as duas contas? E se ela pagasse apenas o Registro.br? E se ela pagasse apenas Locaweb? Além disso, implementar um novo tipo de cobrança em que se cobra por um serviço de terceiros era algo novo para a equipe da Locaweb. Novos processos teriam que ser cuidadosamente projetados.

Solução implementada: começamos a pensar se haveria maneiras mais simples de resolver o problema de ajudar nosso cliente a não esquecer de que precisa pagar pelo registro de domínio no Registro.br. Como seria possível cobrar pelos serviços do Registro.br, foi possível acessar as informações sobre o domínio prestes a expirar. Decidimos criar uma solução mais simples: implementar uma sequência de comunicação com esse cliente, aconselhando- o sobre a importância de pagar o Registro.br para garantir que os serviços de email e hospedagem continuem funcionando normalmente. Essa é uma solução muito mais simples do que implementar um processo de cobrança dupla. Se o Registro.br nos fornecer o URL de cobrança, podemos enviar essas informações para o cliente e as chances de resolver o problema aumentarão ainda mais. E uma sequência de comunicação é muito mais simples e rápida de implementar do que um processo de cobrança duplicado.

Na Conta Azul, um ERP SaaS para MPEs (micro e pequenas empresas), usamos contadores como um de nossos canais de distribuição e queríamos aumentar as vendas por meio de contadores.

Primeira solução: compras em lote, onde os contadores adquiriam um número fixo de licenças da Conta Azul para revender aos seus clientes. Um sistema para gerenciar compras em lote levaria cerca de três meses para ser implementado, pois deveria permitir que os contadores comprassem licenças da Conta Azul em massa, mas só deveria começar a cobrar do cliente do contador quando ela realmente ativou a licença.

Solução implementada: os contadores não se importaram com as compras em lotes. O que eles queriam era oferecer um desconto a seus clientes para que eles pudessem assinar a Conta Azul com esse desconto exclusivo fornecido por suas contas. O custo para implementar isso foi zero, pois o sistema já tinha um recurso de gerenciamento de descontos.

Na Gympass, uma academia que estava ingressando em nossa rede de parceiros solicitou que apresentássemos seu termo de renúncia a todos os usuários que fizessem check-in em suas instalações.

Primeira solução: alterar nosso aplicativo para solicitar aos usuários finais que acessam este parceiro de fitness que leiam sua renúncia em nosso aplicativo e marque uma caixa informando que leem e estão de acordo.

Solução implementada: nenhuma alteração em nosso aplicativo. Use um campo de texto personalizável no ginásio configurado em nosso sistema que normalmente é apresentado aos usuários que fazem check-in nesse ginásio para apresentar o seguinte texto: “Ao fazer o check-in, você concorda com a renúncia localizada em http://fitnesspartner.com/termoderenuncia”.

Não me interprete mal, é muito bom que todos tragam soluções para a mesa sempre que quisermos discutir algo a ser feito pela equipe de desenvolvimento de produtos. Quanto mais ideias de soluções tivermos, melhor. No entanto, precisamos nos educar para termos uma compreensão mais profunda do problema por trás dessa solução, para que possamos encontrar soluções mais simples e rápidas para implementar. E, em última análise, é tarefa do gerente de produto e de todos os membros da equipe de desenvolvimento de produtos perguntar qual é o problema e por que precisamos resolvê-lo.

Concluindo

Para concluir este capítulo, vou fazer algumas considerações finais sobre essa fase de entendimento do problema, crucial para o sucesso do seu produto de software.

Deixei de lado, propositadamente, uma técnica chamada de focus group (ou grupo focal), em que reunimos um conjunto de pessoas (entre 6 a 15) para discutir sobre um determinado problema. É uma técnica tida como qualitativa, pois permite nos aprofundarmos nas questões que estão sendo discutidas.

Minha razão para deixar de lado é que, nesses grupos de discussão, existe um elemento forte de influência social, no qual pessoas mais assertivas e extrovertidas acabam dominando a discussão e polarizando a opinião do grupo. Na minha opinião, entrevistas individuais são de forma geral muito mais relevantes, a não ser em situações nas quais o que se queira pesquisar é exatamente a influência e a interação social do grupo.

Outro ponto importante a considerar durante sua descoberta do problema é quem são as pessoas que têm esse problema, e que características elas têm em comum. Além de entender muito bem sobre o problema, é muito importante conhecer para quem pretendemos resolvê-lo, e quais são suas motivações e seus anseios. Vamos falar sobre isso mais à frente; entretanto, é importante manter isso em mente durante o processo de descoberta do problema.

Uma pergunta que você pode estar se fazendo é “Por que é tão importante investir tanto tempo e esforço em entender bem o problema?”. A resposta é simples: desenvolver um produto de software é caro. Investir em ter uma boa compreensão do problema, das pessoas que o têm, do contexto onde ele ocorre e das motivações que as pessoas têm para vê-lo resolvido é essencial para não gastar tempo e dinheiro construindo a solução errada.

Por fim, como mencionei antes, os métodos não são excludentes, podem e devem ser usados em conjunto pois se complementam. Uma observação é bem complementada com uma entrevista. Os achados da observação e da entrevista podem ser confirmados (ou confrontados) com resultados de pesquisa e análise de métricas de uso.

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:

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: