You are currently browsing the Guia do Gerente de Produtos 2.0 blog archives for July, 2007


Melhore sua Performance no Gerenciamento de Produtos

Se você quer ser um mau Gerente de Produtos, não avalie sua performance nem tente melhorar. Assuma que você está fazendo um bom trabalho e continua assim. Você foi contratado para o emprego e você continua nele, portanto não deve estar indo tão mal, certo? Você leu alguns artigos e parte de um livro há alguns anos atrás, portanto conhece o básico e como está de fato gerenciando produtos, esta é a melhor forma de aprender.

Se você quer ser um bom Gerente de Produtos, meça sua efetividade e trabalhe para melhorar. Parece tão obvio, mas é algo tão fácil de não se fazer. Para uma pequena porcentagem das pessoas, serem bons Gerentes de Produtos é algo natural. A maior parte das pessoas precisa aprender a ser bons Gerentes de Produtos, a avaliar continuamente seus esforços e a trabalhar sempre para melhorar.

Em seu artigo Are You Decent? The Naked Truth About Product Management Performance, Alyssa Dver apresenta várias sugestões para avaliar sua efetividade como Gerente de Produtos e para melhorar. Antes de qualquer coisa, obtenha feedback dos stakeholders relevantes:

Converse com as pessoas chave nas áreas com as quais você interage: Engenharia, Finanças, Marketing, Suporte e mais importante, vendas. Fale com seu gerente e com outros gerentes. Peça por feedback sincero e deixe-os saber que você está interessado em garantir que está contribuindo bem com um trabalho prioritário e valioso como Gerente de Produtos… Ouça e aprenda com o que as outras pessoas pensam. De novo, você não precisa concordar, mas, assim como ao reunir requerimentos para um produto, anote o feedback. Decide depois aquilo que você deve aceitar e mudar. Não pergunte apenas o que acham de sua performance, pergunte o porquê.

Ela também sugere que você se auto-avalie, com perguntas como:

  • Você prioriza uma reunião com clientes ante uma reunião interna ou outro entretenimento? Você esta em contato com tantos clientes quanto for possível para obter input e melhorar seu trabalho como Gerente de Produtos?
  • Você consegue listar três coisas em que poderia melhorar como Gerente de Produtos? Você tem planos para medir e melhorar estas coisas?
  • Seu chefe o contrataria novamente caso fosse para outra empresa? Seus colegas teriam boas referências para dar sobre você para um futuro emprego?

Uma que você tenha uma melhor imagem de seu status atual como Gerente de Produtos, você pode identificar o que fazer para melhorar. A boa noticia é que se você está lendo este texto, você já esta no caminho correto! Blogs como este são úteis para aprender a ser um bom Gerente de Produtos! Há centenas de blogs que podem lhe ajudar a ser um excelente Gerente de Produtos, basta pesquisar! Certificações, conferências, treinamentos, educação continuada e cursos acadêmicos, livros, rede de contatos ou até mesmo conversar sobre o tema com outros Gerentes de Produto são ótimas maneiras de ampliar seu conhecimento de gerenciamento de produtos.

E, por último, para ser um bom Gerente de Produtos, você deve continua e ativamente tentar ser um bom Gerente de Produtos, aprender mais e tentar melhorar suas habilidades como tal. Enquanto você se lembrar disso, estará no bom caminho!

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/)

As 10 Heurísticas da Usabilidade

1) Feedback

  • O sistema deve informar continuamente ao usuário sobre o que ele está fazendo.
  • 10 segundos é o limite para manter a atenção do usuário focalizada no diálogo.

2) Falar a linguagem do usuário

  • A terminologia deve ser baseada na linguagem do usuário e não orientada ao sistema. As informações devem ser organizadas conforme o modelo mental do usuário.

3) Saídas claramente demarcadas

  • O usuário controla o sistema, ele pode, a qualquer momento, abortar uma tarefa, ou desfazer uma operação e retornar ao estado anterior.

4) Consistência

  • Um mesmo comando ou ação deve ter sempre o mesmo efeito.
  • A mesma operação deve ser apresentada na mesma localização e deve ser formatada/apresentada da mesma maneira para facilitar o reconhecimento.

5) Prevenir erros

  • Evitar situações de erro.
  • Conhecer as situações que mais provocam erros e modificar a interface para que estes erros não ocorram.

6) Minimizar a sobrecarga de memória do usuário

  • O sistema deve mostrar os elementos de diálogo e permitir que o usuário faça suas escolhas, sem a necessidade de lembrar um comando específico.

7) Atalhos

  • Para usuários experientes executarem as operações mais rapidamente.
  • Abreviações, teclas de função, duplo clique no mouse, função de volta em sistemas hipertexto.
  • Atalhos também servem para recuperar informações que estão numa profundidade na árvore navegacional a partir da interface principal.

8) Diálogos simples e naturais

  • Deve-se apresentar exatamente a informação que o usuário precisa no momento, nem mais nem menos.
  • A seqüência da interação e o acesso aos objetos e operações devem ser compatíveis com o modo pelo qual o usuário realiza suas tarefas.

9) Boas mensagens de erro

  • Linguagem clara e sem códigos.
  • Devem ajudar o usuário a entender e resolver o problema.
  • Não devem culpar ou intimidar o usuário.

10) Ajuda e documentação

  • O ideal é que um software seja tão fácil de usar (intuitivo) que não necessite de ajuda ou documentação.
  • Se for necessária a ajuda deve estar facilmente acessível on-line.

Os 10 Princípios do Desenvolvimento Ágil

Desenvolvimento Ágil é uma das palavras do momento na indústria de desenvolvimento de software. Mas o que exatamente é isso? Desenvolvimento Ágil é uma maneira diferente de gerenciar projetos de desenvolvimento de software. Os princípios chave, e como esta metodologia se difere do modelo tradicional de Waterfall são os seguintes:

1. Envolvimento ativo do usuário é mandatório
2. A equipe deve ser autonoma para tomar decisões
3. Requisitos evoluem, mas a escala de tempo é fixa
4. Definição de requisitos em alto nível, leve e visual

5. Desenvolvimento de versões pequenas, incrementais e iterativas
6. Foco na entrega frequente de produtos
7. Complete cada funcionalidade antes de ir para a próxima
8. Aplique a regra de 80/20
9. O teste é integrado ao longo da vida do projeto – teste cedo e com frequência
10. Uma abordagem colaborativa entre todos os envolvidos no projeto é fundamental

As principais metodologias ágeis são: XP, DSDM e SCRUM

Como Gerente de Produtos de projetos de Software vale a pena estar a par daquilo que os desenvolvedores da área de tecnologia estão pensando, e acompanhar sua forma “ágil” de trabalhar!

Admita que você não sabe a resposta

Se você quer ser um mau Gerente de Produtos, responda as perguntas mesmo quando não tiver certeza da resposta. Você não quer que os outros achem que você não sabe algo sobre seu produto. Se um representante de vendas perguntar se seu produto inclui uma determinada funcionalidade, e você acha que sim, mas não tem certeza, apenas diga que sim; se você estiver errado, sempre poderá incluir a funcionalidade depois. Faça suposições sobre os aspectos do produto sobre os quais você não tem certeza. Se você tiver que verificar com outras pessoas na empresa a cada vez que uma pergunta pipocar e você tiver dúvidas, nunca conseguirá atender àquilo que esperam de você.

Se você quer ser um bom Gerente de Produtos, não tenha medo de dizer “Eu não sei.” Gerentes de Produto devem estar informados, conhecer e ter um bom entendimento sobre seu produto. Entretanto, sempre haverá perguntas feitas – por representantes de venda, pela direção da empresa ou por clientes – para as quais você não tem a resposta. Nestes casos, melhor que dar uma resposta meio-certa, certifique-se de ir atrás da resposta imediatamente.

A maior parte dos Gerentes de Produto que cometem o erro de responder a perguntas quando não estão certos da resposta não estão mentindo intencionalmente. Eles podem querer proteger sua reputação perante os stakeholders empresa. Eles não querem dificultar uma funcionalidade que seja crucial para uma grande venda. Eles podem não estar suficientemente próximos dos detalhes do produto para estarem de fato informados para responder corretamente.

Assim, por estas e outras razões, quando Gerentes de Produto deveriam responder com “Eu não sei”, eles respondem com confiança, e a resposta geralmente está errada. Fazer suposições ou reivindicações inevitavelmente terá efeitos colaterais. Há um alivio inicial – de que você respondeu a uma pergunta com a resposta que as pessoas queriam ouvir – mas logo os fatos virão à tona. A diretoria o verá ou como perigosamente mal informado, ou como se estivesse intencionalmente enganando-os. O cliente achará que você de fato não suporte o caso de uso especifico que ele está pedindo. Outra pessoa que sabe mais sobre o produto mostrará que você respondeu incorretamente porque não tinha toda a informação.

Por que Gerentes de Produto tem medo de responder com “Eu não sei”? Provavelmente é conseqüência do ambiente de negócios, em que muitas pessoas, em muitas funções, sentem como se precisassem saber tudo dentro de sua área. O fato é que ninguém sabe tudo. Sempre haverá lacunas no conhecimento, mesmo do mais experiente e informado Gerente de Produtos.

A diferença entre maus e bons Gerentes de Produtos é que os maus supõem saber as respostas e jamais investigarão para saber se estavam corretos, enquanto os bons não respondem a não ser que estejam suficientemente informados, e, se não estiverem, certamente se informarão para que saibam esta (e outras) respostas.

Responder simplesmente com “Eu não sei” é tão ruim quanto dar uma resposta correta; por outro lado, Gerentes de Produto devem responder com “Eu não sei, mas encontrarei a resposta e a trarei para você.”. Acompanhamento é um fator chave e bons Gerentes de Produto podem usar isso como oportunidade para construir suas bases de conhecimento para que não precisem responder com “Eu não sei” da próxima vez – é isso que faz um ótimo Gerente 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/)

Ajude em Áreas fora do Gerenciamento de Produtos

Se você quer ser um mau Gerente de Produtos, nunca gaste tempo trabalhando com tarefas que não sejam função do gerenciamento de Produtos. Você é parte da equipe de desenvolvimento de produtos e cada membro da equipe é responsável por sua própria área. Você lida com as tarefas de gerenciamento do produto, a pessoa de marketing cuida das tarefas de marketing, os designers e desenvolvedores cuidam das suas áreas, os testadores são responsáveis por suas atribuições e assim por diante. Trabalhar com estes outros grupos apenas os encorajará a relaxar e a contar com você caso não consigam terminar seu trabalho. Foque nos deliverables do gerenciamento de produtos, e force os outros a se assegurar de que estão contribuindo da maneira correta.

Se você quer ser um bom Gerente de Produtos, ajude outras áreas quando for necessário. Gerentes de Produtos devem ser mais estratégicos e táticos e devem evitar o micro-gerenciar os membros da equipe de desenvolvimento de produtos, mas em todos os projetos sempre chega o momento em que os membros da equipe precisam ajudar em outras áreas. Há uma diferença entre mergulhar nos detalhes para preencher as lacunas ainda não concluídas e mergulhar nos detalhes para mudar o trabalho que alguma outra pessoa do time tenha feito.

O Silicon Valley Product Group discutiu isto em seu artigo Thriving in Large Companies, embora a idéia realmente se aplique da mesma forma para empresas de qualquer tamanho!

Esteja pronto para fazer o que precisar. …. Sei de muitos casos em que o Gerente de Produtos precisou ajudar com os deliverables para o suporte a clientes, treinamento comercial, documentação técnica, QA, engenharia e marketing. Você simplesmente pode ter que fazer.

Este é um conceito importante para todos na equipe, mas especialmente para o Gerente de Produtos. Auxiliar com os deliverables de outras áreas ajuda por algumas razões:

  • Ajuda no progresso do projeto. A principal razão para simplesmente fazer é ajudar na conclusão do projeto e a melhorar o produto. Se a única coisa segurando o lançamento de seu produto é a documentação de Ajuda, ajude os documentadores o máximo que você puder. Se o Marketing normalmente faz o treinamento com a equipe de atendimento ao cliente, mas eles estão ocupados com outros projetos, faça o treinamento você mesmo.
  • Dá um bom exemplo para o restante do time. Quando você começa a ajudar outras áreas, as pessoas começam a ver que não somente isto é bom, mas merece ser encorajado. Os designers ajudarão os desenvolvedores. Analistas ajudarão os engenheiros. As pessoas focarão no produto como um todo e o objetivo global, e não somente em suas áreas de atuação.
  • Torna você um funcionário mais valioso. Seu ponto forte pode ser o gerenciamento de produtos, mas se você puder mostrar como tem boa aptidão para treinamento, escrita ou design, mostrará que você é um colaborador e um líder melhor. Quanto mais áreas você puder ajudar, mais você poderá contribuir e mais provável será que seus produtos sejam bem sucedidos no final.

Gerentes de Produtos devem se assegurar de que não estejam tão apegados a detalhes todo o tempo, mas devem sim estar disponíveis e dispostos a ajudar os outros quando necessário. No final, o Gerente de Produtos é julgado por sua habilidade de liderar um time na entrega de um produto bem sucedido Algumas vezes, isto pode ser feito pela liderança e direcionamento à distância, mas mais freqüentemente do que isto, geralmente requer que o Gerente de Produtos participe de alguns pontos críticos para garantir o sucesso.

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/)

Ouça o “Vocabulário do Usuário”

Quantas vezes você leu folhetos de marketing, datasheets, etc e balançou a cabeça, perguntando para que de fato serve o produto que está sendo descrito? O vocabulário do marketeiro está cheio de “flexível, escalável, confiável, robusto, próxima geração, poderoso, estado da arte, …” – você entendeu! Sempre me perguntei se as pessoas que escrevem estes folhetos entendem estas coisas, quanto mais seus clientes.

Um dos fatores chave ao ouvir seus clientes é anotar as palavras e frases que eles usam – o vocabulário que eles usam para descrever as coisas. Se você não entender os termos, peça-lhes que expliquem. Uma vez que você percebe que há uma tendência de palavras comumente utilizadas, incorpore-as na interface visual de seu produto, sua documentação, suas apresentações, seu material de marketing, etc. Comunicar-se com seus clientes utilizando termos com os quais eles estão familiarizados lhe ajudará a conectar-se diretamente com eles. Empresas que fazem isso conseguem se diferenciar (é claro que isso não compensa o fato de um produto ser inferior!). É surpreendente como a maior parte das empresas não faz isso. Comunicar os benefícios de seus produtos para sua audiência será tão mais simples se você prestar atenção ao vocabulário do usuário. Para mim, seria o senso comum… mas, quem disse que o senso comum é tão comum???

Começar do Zero ou Consertar o que Já Existe?

Frequentemente me perguntam qual o balanceamento certo entre o desenvolvimento de novos produtos e o investimento em melhorar produtos já existentes. Suponho que seja natural para as empresas quererem ter um tipo de porcentagem padrão, mas eu tento fazer com que as empresas pensem nestes investimentos de uma forma diferente. Para mim, todos estes projetos são investimentos em produtos, e, mais do que se preocupar em investir o suficiente numa nova linha de projeto ou nas linhas de produtos existentes, prefiro ter o time se preocupando se eles estão investindo nas melhores oportunidades.

Expandir seu portfólio de produtos para oferecer produtos adicionais a novo clientes, ou alcançar novos clientes podem ser coisas ótimas. Melhorar seus produtos existentes para que eles gerem mais receita de seus cliente atuais, e tornar mais fácil o processo a aquisição de novos clientes, também pode ser excelente.

Mas o principal é que cada um destes projetos é uma oportunidade de produtos, e, como tal, é responsabilidade da equipe de produtos avaliar os custos e benefícios. É responsabilidade da equipe de gerência (idealmente o Comitê de Produtos, caso você já tenha adotado esta idéia) garantir que a empresa está indo atrás das melhores oportunidades. Isto pode significar que tudo (ou a maioria) seja referente a produtos novos, caso a empresa esteja iniciando-se no mercado, ou pode ser que a maior parte seja referente a oportunidades de melhoria nos produtos. Não é ruim ser oportunista ao escolher seus investimentos em produtos.

Dito isto, direi que muitas vezes as melhores oportunidades de produtos estão bem de baixo do nariz da empresa. Por exemplo, geralmente, o melhor impacto na receita vem da melhoria de produtos existentes que não estão desempenhando tão bem como deveriam, normalmente por questões de usabilidade. Por exemplo, você pode descobrir que para cada 100 pessoas que explicitamente começam o processo de contratação de seu produto, apenas 9 concluem-no com sucesso. Você sabe que pode melhorar este número para 18, e assim, essencialmente, você dobrou a receita deste produto. É uma excelente oportunidade se você puder encontrar uma boa solução. E o irônico deste tipo de oportunidade é que geralmente é tem uma resolução bastante trivial. Um pouco de prototipação e testes com usuários e você poderá rapidamente identificar os problemas e perceber soluções melhores que normalmente não são difíceis de serem implementadas.

Ou, você pode descobrir que está mantendo centenas de pessoas em sua área de suporte para ajudar seus usuários à medida que eles sofrem para configurar e usar seu produto. Um design melhor geralmente pode eliminar a necessidade de boa parte desta equipe. E isso diz respeito apenas à economia com a redução de custo. O ganho ainda maior será a melhora da satisfação do cliente e a correspondente melhora na pontuação NPS (Net Promoter Score).

Geralmente vou a uma empresa e sou visto como um herói quando aponto estas “oportunidades”e elas geram grande retorno. Mas o que realmente está em jogo é uma tendência nas empresas de software de assumir que o produto já é o melhor possível, e que o investimento contínuo não fará muita diferença. As empresas tendem a acreditar que seus produtos são inerentemente complexos, ou pensam que uma taxa de conversão de 9% não é ruim; ou que apenas precisam gastar mais com marketing para aquisição de clientes ou divulgação; ou ainda que investir em suporte ao cliente é um custo necessário do negócio.

Mas o que de fato ocorre é que o produto está fraco, e a empresa está apenas tentando tirar o máximo proveito do que já tem.

Até certo ponto isto é apenas outro sintoma de empresas investindo pouco em design e experiência do usuário. Mas, geralmente, a verdade é que muitos produtos por aí são de fato mal feitos, e, mais do que melhorar um produto para que ele possa gerar mais receita e sucesso para você, muitas organizações acham mais fácil criar novos produtos. Mas, a menos que mudem a forma de produzir este novo produto, provavelmente vão terminar o processo com mais um produto que necessitará de melhorias.

Fonte: Silicon Valley Product Group
Autor: Marty Cagan