É 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:
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.
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.
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.
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.
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.
É 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.
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:
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:
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:
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.
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: