Planeje para o presente e para o futuro provável

Se você quer ser um mau Gerente de Produtos, planeje com muita antecedência para o futuro. Seu produto certamente será um sucesso, logo você precisa ter cada possível detalhe definido agora para garantir que continuará sendo um sucesso nos anos vindouros. É tão importante planejar-se para um problema que provavelmente ocorrerá amanhã quanto planejar-se para um problema que possivelmente acontecerá daqui a alguns anos. Se as coisas forem realmente bem – ou realmente mal – você quer estar preparado “just in case,” não importa quão improvável isso seja.

Se você quer ser um bom Gerente de Produtos, planeja para agora e para o futuro provável. Entender as implicações de suas decisões no longo prazo é importante, embora as possibilidades num futuro distante não devam se sobrepor às decisões de curto prazo.

Muito freqüentemente, boas idéias são rejeitadas porque não serão verdadeiras ‘se’ algumas coisas acontecerem. Por exemplo, um bom design para uma base de dados que possui 10.000 registros pode ser inadequado por não escalar para 1 milhão de registros – embora apenas um em um milhão de clientes potenciais jamais terá esta quantidade de registros. Ou, alguns insistirão em investir esforço substancial em automatizar um processo manual simples que leva 2 minutos para ser executado e é feito apenas em determinada ocasião, usando o argumento de que se o processo alguma vez ocorrer com maior freqüência (o que seria em alguns anos, na melhor hipótese), a versão automatizada será mais eficiente.

Planejar para um futuro longínquo geralmente ocorre porque as pessoas estão em busca da solução perfeita. (Surpresa! Não existe uma...). Uma solução “suficientemente boa” pode atender muito bem por vários meses ou anos; infelizmente, aqueles procurando pela resposta “perfeita” irão rejeitar o que é “suficientemente bom” e insistir numa solução geralmente mais complicada, mais complexa e mais cara.

Outro perigo de planejar com tamanha antecedência é que quanto mais no futuro você observar, mais provável que suas suposições estarão erradas. Qualquer coisa além do que é conhecido neste exato momento, é especulação. É claro, algumas áreas são mais previsíveis do que outras, embora em muitos aspectos da gestão de produtos as previsões são pouco mais do que educados ‘chutes’ com uma boa dose de otimismo.

Falando em otimismo, a razão para o planejamento de longo prazo é que geralmente os times de desenvolvimento assumem um estrondoso sucesso e querem se planejar para isso. É claro, seria ótimo se você tivesse um milhão de usuários para seu sistema de rede social na primeira semana e você estivesse planejado de acordo. Certamente você espera que sua campanha de marketing brilhante gere demanda para seu estoque de doze meses em apenas três. Mas, e se as coisas não derem certo?

Infelizmente, a maior parte do pensamento no futuro é influenciada por um extremo otimismo (ou, em alguns casos, pessimismo). Gerentes de Produto precisam ser razoáveis e racionais em suas suposições e expectativas. É necessário balancear esperança e pensamento positivo com a realidade, e, muito freqüentemente, Gerentes de Produto e times de desenvolvimento de produtos terminam numa extremidade do espectro ou na outra.

Como a 37signals descreve em Otimize para agora!:

Uma das maneiras mais fáceis de destruir boas idéias, políticas interessantes ou experimentos valiosos é usar a premissa de que qualquer coisa que você esteja fazendo precise durar para sempre... A melhor maneira de chegar ao ponto de precisar de mais, é otimizar para o agora. Utilize as forças de seu momento atual em vez de ficar tão ansioso por adotar as soluções para o amanha.

Mais que planejar para o future distante, os Gerentes de Produto precisam planejar para o que é conhecido e para o que é razoável de se esperar do futuro. Quando idéias são rejeitadas porque não ‘escalam’ para níveis razoáveis ou porque irão durar ‘apenas’ por certo período de tempo, o Gerente de Produtos deve lembrar ao time de desenvolvimento de produtos para manter os problemas em perspectiva.

Esclareça os requisitos e objetivos, entenda os trade-offs, priorize adequadamente e faça decisões sábias com base no que é lógico hoje e no que for mais provável no futuro.

Esta é uma tradução do conteúdo escrito por Jeff Lash (http://www.jefflash.com/) no How To Be A Good Product Manager (http://www.goodproductmanager.com/)

Garçon, vendedor ou Gerente de Produtos?

Normalmente, quando resolvo comer fora, peço uma recomendação ao garçon. E, normalmente, a resposta é sempre a mesma: o garçon responde me dizendo o que ele prefere. Francamente, não estou interessado no que ele gosta. Na verdade, quando imagino meu garço comendo, chego a perder o apetite.

Estou na verdade perguntando (i) qual a especialidade do restaurante, (ii) qual o prato de maior sucesso ou mais interessante para outro clientes, e (iii) qual prato seria o mais adequado para os meus "objetivos" nesta refeição.

O garçon está em perfeitas condições de ajudar. Ele tem contato com mais clientes do que qualquer um no restaurante. Se prestar atenção, ele pode perceber quais são os pratos que são deixados pela metade ou mais bem avaliados. Ele poderia responder com "que tipo de prato você gostaria hoje?", ou "você está realmente com fome ou quer algo light?". Com esta informação em mente, ele poderia recomendar algo que combinasse com o que estou buscando e que seja mais popular entre seus outros clientes.

Relevante para a gestão de produtos? Acho que sim:

- seu pessoal de vendas está perguntando quais os objetivos do cliente antes de enviar uma proposta ou iniciar uma demonstração?

- seu pessoal de vendas conhece os objetivos típicos de seus prospects? Eles podem associar os objetivos dos prospects com as capacidades individuais de seu produto?

- quando você fala com as pessoas de desenvolvimento, marketing, vendas, operações, financeiro, etc., eles lhe vêem como a pessoa que fala pelo cliente, ou apenas mais uma pessoa com uma opinião?

Como Gerente de Produtos, você precisa ser a pessoa que fala com a maior parte dos clientes e prospects em conversas abertas, e você deve ter os dados mais amplos com base nas perguntas fechadas.

Por favor não seja como meu garçon. Reuna os dados e compartilhe com marketing, desenvolvimento e vendas. Esta é a melhor maneira de ganhar respeito e cultivar sua posição como verdadeiro líder de sua linha de produtos.

Problema de Estimativa

Se você é Gerente de Produtos numa startup, você geralmente será a pessoa que dá a palavra final e responderá às dúvidas sobre qualquer tema, incluindo desde a coordenação dos requisitos até a primeira entrega a um cliente. Mesmo que o Gerente de Produtos não é/não deva ser o Gerente de Projetos, você geralmente será aquele que responderá pelos prazos. Muitos de nós ainda erramos a data de entrega, mas isso não torna o atraso algo permitido. É péssimo perder uma data.
Perder datas atrapalha todo o resto: anúncios publicados com antecedência devem ser adiados ou ajustados, expectativas de clientes devem ser remanejadas, e, mais importante, a entrada da receita esperada devido aos novos produtos ou funcionalidades será adiada. Estou nessa área por quase uma década, e comecei a perceber alguns padrões dos quais, espero, todos poderemos nos beneficiar. Vamos usar este espaço para facilitar a discussão sobre o porquê de deslizes de prazos acontecerem, e como prevenir e mitigar alterações de datas num projeto.
Quando comecei minha carreira como programador, sempre pensei que a maior parte das datas não atingidas ocorrida devido ao “problema”. Sendo que o problema que o time de desenvolvimento tinha para resolver era tão difícil e sem precedentes que seria muito difícil de ser resolvido. Eu estava errado – quase todos os problemas que vi um time de desenvolvimento experienciar foram problemas de estimativa, e não de entrega. Estimativa e entrega são explicitamente relacionados – dê a um time todo o tempo do mundo e ele poderá resolver qualquer problema... mas o resto da empresa não pode esperar todo este tempo. A gerência de produtos escreve os requisitos para definir o escopo e o tamanho do problema para que o time de desenvolvimento ajude com as estimativas. Assim, assumindo que você ajudou seu time de desenvolvimento provendo o escopo do problema, a próxima área de atuação é em precisar as estimativas, e em seguida o que chamo de “estar pronto para o lançamento”.

Quando um líder de desenvolvimento ou arquiteto vê um problema novo, ele pergunta “será que este problema se parece com algum trabalho que já foi feito antes?” e “será que nossa experiência anterior pode nos ajudar a resolver este problema?”. Se a resposta for sim, então ele pode estimar com maior precisão. Se a resposta for não, há uma grande incerteza que gera risco haver uma estimativa incorreta. O líder de desenvolvimento pode tentar mitigar este risco com uma variedade de táticas tais como colocar uma margem de segurança ou pedir para sua equipe preparar estimativas mais detalhadas (a abordagem do Joel on Software é minha favorita, pois força o desenvolvedor a, de fato , pensar nas implicações do design de uma arquitetura antes de estimar). O time de desenvolvimento pode até querer fazer uma transição para metodologias mais rádicais como as ágeis, em que os prazos são fixos e o escopo é flexível (pode ser adequado para software, mas não para hardware). Há também táticas que o Gerente de Produtos pode adotar para proteger o negócio de expectativas mal colocadas, que descreverei em breve.

Estar pronto para o lançamento é um conceitos com o qual um de meus gerentes me iluminou numa reunião de equipe há muito tempo atrás. Nunca esquecerei o cenário: os Executivos estavam na sala perguntando por que um produto/serviço não poderia ser lançado em 90 dias em contrapartida ao prazo maior que a gerência de produtos queria. Ele colocou um slide intitulado “Itens necessários para o lançamento”. O primeiro item, em letra discreta, tamanho 12, no topo superior esquerdo, dizia “Desenvolvimento Completo” e então ele continuou a apresentar o resto do slide, que incluía três colunas adicionais com trabalhos necessários para o lançamento, tais como “Completar Documentação”, “Treinar o Suporte”, “Treinar Vendas”, “Publicar Demos” e assim por diante. O ponto é que você precisa levar em conta os outros itens que você precisa para lançar o produto, para não acontecer o que chamo de “tropeçar no objetivo” e ter um lançamento pouco efetivo por que só levou em conta que o time de desenvolvimento acabou de escrever seu código.

Táticas para Vencer

Algumas destas táticas eu já usei com sucesso, outras ainda estou fazendo o ajuste fino:

• Separe o Roadmap do Plano de Releases – isto permite que você foque naqueles produtos para os quais você já tem recursos comprometidos e o lançamento é iminente, e ainda assim olhando para o future através de lentes diferentes.
• Use um “Modelo de Planejamento” para estimar – trabalhe com seu par no Desenvolvimento para criar um planejamento modelo ou uma linha mestra para um produto teórico. Sobreponha este planejamento sobre novos projetos à medida que eles estão começando, e você rapidamente poderá dizer se está totalmente fora das expectativas.
• Utilize uma zona de segurança – Para produtos no Plano de Releases, não os anuncie até que você atinja a fase de piloto (hardware e software completos). Conte que as demais tarefas de lançamento tomarão X dias (costumamos usar 90), você sempre poderá lançar antes se terminar antes. Se você fizer isso corretamente, saberá no início de cada trimestre que produtos você pode lançar: se eles atingiram a fase piloto, serão lançados; se não, não.

Este último é o mais difícil – especialmente numa startup. O negócio quer se mover tão rápidamente que a idéia de diminuir o ritmo do processo é difícil de ser aceita. Observe seu processo hoje, você está “tropeçando no objetivo final?” Você chega à data de lançamento e o time de engenharia ainda encontra bugs? Você adia sua data de lançamento em duas semanas a cada duas semanas? Se alguma destas afirmações for verdadeira, você já está se movendo mais lentamente do que gostaria, é só o seu processo que não foi atualizado.

Pergunte a um bom Gerente de Produtos

Se você quer ser um mau Gerente de Produtos, não procure por conselhos de outros Gerentes de Produto. Os problemas que você enfrenta em seu trabalho são tão únicos que certamente ninguém mais os enfrentou antes. Seu produto é especial e diferente, e não há como alguém oferecer bons conselhos. Mesmo que houvesse alguém que pudesse ajudar, você certamente não poderia compartilhar nenhum detalhe, devido à confidencialidade, segurança e questões de propriedade intelectual. Além do mais, resolver problemas é bom para o seu caráter. Você nunca irá aprender se você sempre precisar pedir ajuda aos outros, certo?

Se você quer ser um bom Gerente de Produtos, peça conselhos a um bom Gerente de Produtos quando precisar de ajuda. Muito freqüentemente Gerentes de Produto ficam muito focados nas tarefas específicas do dia-a-dia. Eles não dão um passo para trás para olhar os problemas de fora, e ficam se questionando se estão abordando os problemas da melhor forma.

Pense em algum desafio de gestão de produtos que você tenha tido na semana passada. Você soube imediatamente a melhor abordagem? Você lidou com a situação de forma perfeita? Houve recursos que você poderia ter utilizado, mas não usou porque estava excessivamente focado em resolver o problema e seguir em frente?

Gerentes de Produto – e a maior parte dos profissionais – geralmente não utilizam recursos que podem tornar seu trabalho mais fácil e podem melhorar sua efetividade. Por que não?
Gerentes de Produto acham que seus problemas são únicos. Eles não são. Todo mundo pensa que seu produto é especial ou que sua situação é diferente. Há um monte de Gerentes de Produto que já enfrentaram problemas similares e tem experiência que pode ser compartilhada.

Gerentes de Produtos tem medo de compartilhar sua situação por razões de privacidade. Esta é uma preocupação compreensível, embora na maior parte dos casos o risco percebido é várias vezes maior que o risco real. É possível descrever o problema que você enfrenta em um nível de detalhes suficientemente adequado para receber conselhos e que ainda assim não comprometa a privacidade, confidencialidade ou ética. Você provavelmente descobrirá que outros já enfrentaram problemas similares também, e que eles estão disponíveis para compartilhar suas experiências e preocupações com você.

Gerentes de Produto sentem que eles devem resolver seus próprios problemas. Colocado de maneira simples, a maior parte das pessoas bem sucedidas chegaram onde estão porque receberam ajuda de outros. Seja você um gerente ou um atleta, político ou escritor, professor ou medico, você pode ser mais bem sucedido com a ajuda dos outros.

Gerentes de Produto não sabem a onde recorrer por ajuda. Muitos Gerentes de Produto se voltam para outros Gerentes de Produto de sua organização, embora isso não traga uma gama ampla de experiências. Outros Gerentes de Produto podem não ter colegas internamente a quem recorrer atrás de conselhos, ou podem ter uma rede limitada de outros Gerentes de Produto a quem consultar em caso de ajuda.

Este último ponto é certamente um desafio para muitos Gerentes de Produto. Quanto mais difícil for pedir conselhos a outros Gerentes de Produto, mais fácil será que ele tente resolver seu problema por sua própria conta.

Há recursos como o Product Strategy Network, PDMA, e AIPMM que podem ajudar a encontrar alguém que responda sua dúvida; o Pragmatic Marketing oferece a possibilidade de pergunta a um especialista (Ask An Expert); e há, é claro, diversos blogs sobre gerência de produtos que oferecem dicas e técnicas.

No entanto, nenhum destes recursos torna fácil para um Gerente de Produto fazer uma pergunta, obter uma – ou várias – respostas de outros Gerentes de Produto, e que então esta discussão possa ser capturada por outros Gerentes de Produto que tenham a mesma dúvida. A seção de respostas sobre gerência de produtos do LinkedIn chega perto, embora a alta quantidade de sujeira torne difícil de se encontrar boas perguntas e respostas úteis entre a infinidade de perguntas inúteis para a maior parte dos leitores.

Ask A Good Product Manager é um novo site da família do Good Product Manager. Muitos leitores deste blog enviam e-mails pedindo por conselhos para suas questões de gestão de produtos e desafios. Ask A Good Product Manager foi criado como forma de responder mais destas perguntas e compartilhar as respostas com outros Gerentes de Produto que tenham as mesmas perguntas. Bons Gerentes de Produto são chamados regularmente para dar suas opiniões e conselhos e todos os leitores são convidados a também participarem das discussões.Aqueles pedindo por conselhos certamente se beneficiarão, assim como aqueles respondendo às perguntas, já que é fato que ensinando e aconselhando os outros é uma ótima maneira de melhorar seus próprios skills. Caso você tenha uma pergunta que você já respondeu ou tenha algum conselho para compartilhar, contribua com o Ask A Good Product Manager e ajude a construir mais uma fonte valiosa de recursos para a comunidade de Gerentes de Produtos.

Esta é uma tradução do conteúdo escrito por Jeff Lash (http://www.jefflash.com/) no How To Be A Good Product Manager (http://www.goodproductmanager.com/)

Não tenha medo de remover funcionalidades

Se você quer ser um mau Gerente de Produtos, nunca remova funcionalidades. Por que você tiraria algo de seu produto? Mais funcionalidades apenas tornam o produto melhor, assim, a retirada de funcionalidades obviamente tornará o produto pior. É claro, nem todo mundo usa todas as funcionalidades, e é por isso que você mantém a todas elas. E se você removesse algo que pelo menos uma pequena parcela de seus clientes usa e você os prejudicar? Clientes sempre pedem por mais funcionalidades - não por menos – então, no final, aquele produto com mais funcionalidades ganha.

Se você quer ser um bom Gerente de Produtos, seja esperto na remoção de funcionalidades. Ter muitas funcionalidades não tornará seu produto ótimo. Ótimos produtos são aqueles que têm as funcionalidades certas para resolver os problemas dos clientes, e ainda tê-las apresentadas da maneira correta.

A remoção de funcionalidades pode e deve ser feita para muitos produtos. Bons Gerentes de Produto se defrontam com este difícil aspecto do trabalho, embora isso possa ser desafiador e desagradável. Similarmente, bons Gerentes de Produto não tomam esta responsabilidade de forma impensada, e apenas removem funcionalidades uma vez que entendem as implicações de quaisquer mudanças para o produto e seus clientes.

O primeiro passo para remover funcionalidades, em primeiro lugar, é não incluir funcionalidades desnecessárias. Muito freqüentemente, funcionalidades irrelevantes são incluídas por diversos motivos – resposta rápida a uma reclamação de um cliente, idéia de algum engenheiro, falta de entendimento da necessidade do cliente. Então, quando as funcionalidades precisam ser removidas por algum motivo – desafio técnico, custo de suporte, instabilidade – e dificuldade e quantidade de reclamações que o Gerente de Produtos terá que transpor serão bem maiores do que o valor que a funcionalidade jamais teve.

Como escreve Marty Cagan, do Silicon Valley Product group, em seu artigo Great Products by Design:
O trabalho do Gerente de Produtos é identificar o produto mínimo possível que atenderá aos objetivos e proverá a experiência de usuário desejada – minimizando o time to market, a complexidade de implementação e a complexidade para o usuário.

No ‘produto mínimo possível’, não há funcionalidades desnecessárias. Cada aspecto do produto é absolutamente essencial para atender aos objetivos relevantes.

Infelizmente, Gerentes de Produto geralmente herdam produtos que eles não planejaram desta maneira, e quase sempre há funcionalidades que não são necessárias para atender ao negócio e aos objetivos do usuário.

Há dois passos na remoção de funcionalidades – identificar quais funcionalidades remover, e explicar aos seus clientes porque você está removendo tais funcionalidades.

1. Identificar quais funcionalidades remover não deve ser um processo difícil. As funcionalidades a serem removidas são aquelas que:

- São caras de se manter
- Colocam em risco a confiança no produto
- Distrai de outras funcionalidades que agregam valor
- Não se adéquam à estratégia do produto
- Não são usadas pelos clientes

Uma vez que você identificou uma funcionalidade que cai numa destas categorias, identifique porque a funcionalidade havia sido inclusa originalmente. Ela foi planejada para atrair a um determinado tipo de cliente? Era relevante quando foi lançada, mas inapropriada agora, dado o progresso tecnológico desde então? Independente da validade do racional por trás de uma funcionalidade, primeiro tente entendê-lo.

Então, verifique se este racional ainda é válido. Pode ter feito sentido dada a estratégia original do produto, embora agora contradiga a estratégia atual. Talvez a funcionalidade fosse única e diferenciadora naquele tempo, e a agora é lugar comum e irrelevante. Talvez o objetivo de adicionar determinada funcionalidade tenha sido capturar algum tipo de cliente, e esta estratégia nunca foi bem sucedida.

Em última análise, Gerentes de Produtos devem procurar identificar qualquer funcionalidade cuja remoção não tenha impacto na receita. Sim, os clientes podem reclamar um pouco, embora isso seja provável de acontecer caso a funcionalidade exista ou não. Se as funcionalidades podem ser removidas sem qualquer perda mensurável na satisfação do cliente ou em sue uso - ambos, em última instância, geradores de receita - qual é o benefício de mantê-las? De forma similar, se incluir uma nova funcionalidade não tem nenhum aumento mensurável na satisfação do cliente, uso ou receita, qual o benefício de incluí-la? Se mais Gerentes de Produto tivessem isso em mente ao considerarem melhorias em produtos, eles não se colocariam na situação de terem que remover funcionalidades depois.

2. Explicando para seus clientes porque você removeu estas funcionalidades é relativamente simples uma vez que você tenha feito a análise explicada acima. Isto não implica que você deva enganar seu mercado e colocar uma visão positiva nesta mudança. Você deve ser honesto e direto com seus clientes ao descrever a razão da mudança. Isto deve ser apresentado sob o ângulo dos benefícios para o cliente. Por exemplo, remover alguns ícones da barra de menu tornará mais fácil para os novos usuários aprenderem e mais rápido para os usuários experientes utilizarem; ou, recursos serão direcionados para novas funcionalidades que seus clientes estão pedindo, ao invés de serem despendidos em dar suporte a funcionalidades com alto custo de manutenção e que raramente são utilizadas.

Faça a transição o mais suave possível para os clientes. Manda vários avisos antecipadamente e assegure-se de comunicar de diversas maneiras – por exemplo, através de sua força de vendas, por e-mail, correio, webinars, etc.

Para clientes que contavam com a funcionalidade que está sendo removida, você pode sugerir alternativas quando for possível, mesmo que estas alternativas sejam produtos concorrentes. Se a funcionalidade realmente tão pouco importante para seus usuários, você não terá tantos clientes abandonando o produto devido a esta pequena mudança. Clientes apreciarão sua honestidade e ajuda para minimizar os impactos desta mudança.

Sempre que possível, implemente melhorias em seu produto ao mesmo tempo em que remove funcionalidades. Isso nao apenas oferecerá um produto melhor para seus clients, mas também será mais fácil de comunicar para o cliente. Em vez de defender a remoção que foi feita, você enfocará nas melhorias e em explicar como a remoção era parte necessária para implementação das melhorias.

A 37signals descreve isso como “toda vez que você inclui algo, também está removendo algo,” e os comentários e discussões em cima deste post mostram o desafio e a confusão sobre este tema.
Bons Gerentes de Produto precisam ter uma estratégia de produtos clara para assegurar que seu produto permaneça focado. Isto pode ser feito em sendo bem regimentado no desenvolvimento do produto e apenas adicionando novas funcionalidades que fortalecem o valor do produto. Entretanto, quando há funcionalidades presentes cujos custos ultrapassam seu valor, um Gerente de Produtos deve tomar a difícil decisão de removê-las para garantir o foco na visão do produto.

Esta é uma tradução do conteúdo escrito por Jeff Lash (http://www.jefflash.com/) no How To Be A Good Product Manager (http://www.goodproductmanager.com/)