Por que o Marketing deveria escrever os manuais de usuário?

Por que tantas empresas tratam os potenciais usuários tão melhor que os já existentes? Pense nisso. O folheto é um exemplo de beleza; o manual de usuário é uma chatice. O folheto recebe uma boa parte do investimento, enquanto manual é uma grande despesa. E se parássemos de fazer o material que distribuímos de graça tão melhores do que aqueles pelos quais os usuários pagaram? E se ao invés de seduzir os potenciais usuários para que comprem, seduzíssemos os usuários existentes para que aprendam?

Peguemos todo o orçamento de anúncios e marketing e vamos migrá-lo para os manuais de produto e suporte. Vamos colocar nosso dinheiro no lugar em que nossos usuários estão. Se estamos operando há pouco tempo, então, é claro – faz sentido fazer de tudo para conseguir um novo cliente e fazer o mínimo possível a partir de então. Mas se estamos no jogo para o longo prazo – pela retenção de clientes e por usuários fiéis – então não deveríamos aproveitar todo aquele design gráfico e aquele talento para escrever para as pessoas com quem mais nos preocupamos? Nossos usuários?

A maior parte de vocês conhece nossa filosofia:

• Usuários realmente apaixonados irão evangelizar o produto para outros;
  
• Quando melhor um usuário fica em algo, melhor será sua experiência de usuário;
  
• Quanto melhor a experiência de usuário, mais provável que os usuários tentarão usar mais e melhor o produto;
  
• Ninguém é apaixonado por algo que não sabe / não consegue usar;
  
• Ajudar os usuários a aprender e (em última instância) dominar é melhor maneira de deixá-los apaixonados;

Criar materiais de aprendizado fabulosos pode ser um destino muito melhor para o orçamento do que anúncios e folhetos. Se os anúncios tradicionais e o marketing estão se tornando cada vez menos efetivos, porque não migrar todo este talento (designers, artistas, escritores e outros ‘criativos’) do “pré-vendas” para o “pós-vendas”? Sempre nos perguntamos por que os usuários não lêem o manual, mas simplesmente veja os manuais! Folhetos são impressos coloridos, em papel brilhante; manuais são em branco e preto, em papel sulfite simples. Só esta simples mudança – deixar os manuais mais bonitos quanto o material de marketing – já seria um bom começo.

E se sua empresa insiste em ter folhetos bonitos, coloridos, etc... por que não pegar os manuais coloridos, bonitos, etc. e usá-los como material promocional? Como cliente potencial, acredito muito mais nas possibilidades do seu produto vendo o manual do que os folhetos mirabolantes e seus discursos de venda. Prefiro ver como você vai me ajudar a ter sucesso, e não suas propagandas bem feitas.

Se a melhor maneira de criar usuários apaixonados e ajudando-lhes a aprender e a dominar o produto, devemos dedicar nossos esforços para atiçar, motivar e inspirar alguém a comprar mais, e para atiçar, motivar e inspirar alguém a aprender mais. No final, estes usuários apaixonados irão evangelizar seu produto ou serviço com muito mais credibilidade e honestidade do que você.

Então, você é tão sexy depois da venda quanto é antes? Voce conhece alguém que seja? (eu conheço alguns, como o Electric Rain)

Migrando de uma organização de TI para um organização orientada a produtos.

Boa parte das empresas que existem hoje começou como algo diferente de uma empresa de produtos ou de software para Internet. Talvez sua empresa tenha começado como uma grande loja de varejo, ou uma companhia área, ou uma empresa de serviços financeiros.

Embora seja verdade que todas estas empresas criam montes de software para realizar seus negócios, tipicamente elas não são organizadas para produzir o tipo de software do qual elas dependem para seus negócios de hoje.

Por exemplo, varejistas desenvolvem (ou compram) software para coordenar e gerenciar estoque, distribuição e sistemas de ponto de vendas. Companhias áreas escrevem software para gerenciar a logística envolvida em vôos, tripulações, reservas, pagamentos e manutenção de aeronaves. Empresas de serviços financeiros escrevem software para gerenciar os ativos e investimentos de seus clientes.

Mas nos últimos 10 anos, virtualmente todas estas empresas, bem como as de dezenas de outras indústrias, perceberam que precisavam utilizar a Internet para se envolver diretamente com seus clientes online.

Hoje, a maior parte dos varejistas vende suas mercadorias diretamente para seus consumidores online. A maior parte dos usuários reserva e compra suas passagens aéreas online, diretamente pelo site da companhia aérea, ou do site de um revendedor. E quase todas as empresas de serviços financeiros deixam seus clientes gerenciar seus ativos e negociar diretamente através de sites financeiros em tempo real.

Não preciso dizer para ninguém que lê este artigo o quão fundamental mente a Internet transformou os negócios.

Entretanto, muitas destas empresas tentam tratar este novo software que interage com o cliente como se fosse um software que interage com colaboradores internos da empresa, e o resultado é que muitas destas empresas apresentam experiências terríveis para seus clientes no mundo online, e, pior, elas não têm a organização, as pessoas ou processos preparados para melhorar isto.

Observo isso freqüentemente, especialmente quando estou fora do Vale do Silício, e, quando estou na Europa, Ásia ou Austrália, já percebi que esta é a regra. Chego numa empresa e descubro que ela não tem Gerentes de Produto ou designers de experiência do usuário – geralmente elas têm gerentes de projeto, e talvez alguma espécie de ‘analista de negócios’, e, é claro, desenvolvedores de TI, e geralmente todos eles se reportam para o CIO. Algumas vezes encontrei até mesmo empresas que estavam terceirizando seu “site” para agências externas fazerem o design e manterem.

Para ser mais claro, quando digo “organização orientada a produtos”, estou me referindo a uma organização de software que cria produtos para clientes-finais (milhares ou milhões), e não apenas para funcionários ou parceiros.

Por que o software-produto é tão diferente do software de TI? Por várias razões: você paga seus funcionários para trabalharem na sua empresa e utilizarem o software que você mandar; por outro lado, no software-produto, cada um toma sua própria decisão de compra – se não quiserem, não usam. Além disso, para seus próprios funcionários você pode oferecer manuais, treinamentos, serviços profissionais; já para o software-produto, se os usuários não conseguem descobrir como usar seu software, eles estarão apenas a um click de seu concorrente. Para software de TI, você mede a escala e a quantidade de usuários simultâneos em centenas; em contraste, para software-produto, é em centenas de milhares, ou até milhões de usuários. Para software de TI, se há um problema com o software, eles são seus funcionários e são obrigados a lidar com isso; para um software como produto, deixar o software fora do ar prejudica a receita e imediatamente atrai a atenção do CEO e da imprensa.

A verdade é que a maior parte dos produtos de software têm necessidades muito maiores em relação a definições, design, implementação, testes, deployment e suporte do que para a maior parte dos softwares de TI. Também é verdade que os salários usualmente refletem isso. Encontrar pessoas com a experiência necessária para o desenvolvimento de produtos de software é muito mais difícil do que pessoas com experiência em TI.

Para ajudar estas organizações de TI, neste artigo quero enfatizar as mudanças típicas que são necessárias para evoluir uma organização de TI para uma organização efetiva em softwares-produtos.

1. Primeiro, trace uma linha clara entre software interno e software voltado para os clientes. As demandas são diferentes, as capacidades necessárias são diferentes, e você descobrirá que precisa de equipes, processos e recursos distintos. Não me entenda errado – ambos são importantes, mas são muito diferentes e a maior parte de seu foco deve ser em software-produto. Se você pode terceirizar ou comprar software de prateleira para seus sistemas internos, você deve fazê-lo, para poder alocar as melhores pessoas, seu tempo e seus esforços no software voltado para clientes.
2. Você precisará de Gerentes de Produto que representem as necessidades de seus usuários-alvo e que liderem os esforços de criação do produto. Você provavelmente já tem gerentes de projeto, mas, se não tiver, você precisará deles também. Só não cometa o erro de tentar contratar a mesma pessoa para fazer os dois papéis.
3. Você precisará de designers de experiência do usuário, porque fazer software que não precise de um guia passo-a-passo, ou de um treinamento, não é fácil.
4. Você precisará contratar engenheiros e desenvolvedores web que entendam as demandas de software de alta disponibilidade e larga escala, e como isto difere do “software corporativo”. Embora você seja uma “corporação”, este termo se refere à sua organização de TI, e não à sua organização de produtos, em que você está tentando criar algo muito diferente e muito mais difícil.
5. Você precisará de engenheiros de QA, porque precisará garantir que seu software rode bem nos mais diversos ambientes de usuário, sob carga, e os momentos fora do ar têm impacto direto em sua receita e são bem piores do que se você diminuir o ritmo de seus próprios funcionários.
6. Você precisará de uma equipe de operações que mantenha seu site no ar 24x7x365, pois é isso é difícil e requer conhecimentos e processos especiais.
7. Você provavelmente precisará revisar seus processos de desenvolvimento de software desde o planejamento até o lançamento, uma vez que as necessidades do software como produto são bem diferentes das do software corporativo.
8. Você precisará de uma estrutura de marketing online. Trazer as pessoas para o seu site não é fácil no mundo dos mecanismos de busca de hoje, e esta é uma competência cuja necessidade ainda não foi percebida por muitas organizações de TI.
9. Você precisará repriorizar seus esforços em torno do fato de que esta experiência focada nos clientes que permite com que os usuários se envolvam diretamente para comprar e usar os produtos ou serviços de sua empresa não é algo superficial – precisa ser uma competência primária de sua empresa. Não é algo a se passar a agências externas.
10. Determine suas principais métricas de negócio, instrumentalize seu site e estude religiosamente os relatórios diários e então dedique-se a melhorar estas métricas-chave.

Se você ainda não sabe o que são estes papéis e processos referenciados aqui, você pode achar mais lendo outros artigos em www.svpg.com/articles.

Uma nota de atenção: há uma indústria grande, bem estabelecida e lucrativa de organizações que auxiliam organizações de TI (especialmente empresas de serviços e consultorias). Infelizmente, a maior parte destas empresas também não entende as diferenças do software como produto, o que apenas perpetua este problema. Sejamos justos, a maior parte do software existente hoje ainda é customizado, de TI, e estas firmas podem ajudar muito na criação deste tipo de software. Mas software-produto é um bicho totalmente diferente, então, mantenha isso em mente ao falar com estas empresas.

Para muitas empresas, estabelecer uma competência de software como produto é a coisa mais importante a se fazer para garantir sua sobrevivência, ainda que, surpreendentemente, algumas ainda nem perceberam que tem um problema. Elas assumem que “software é software”, e que as mesmas pessoas que cuidaram de sua implementação de SAP não devem ter problemas em colocar algo funcional na web. Se você está numa destas empresas, esperamos que você consiga encorajar sua gerencia a considerar os dez passos acima e ver se você consegue fazer com que as coisas melhorem.

Quando o Luxo vem sem etiqueta

O cara desce na estação do metrô de NY vestindo jeans, camiseta e boné, encosta-se próximo à entrada, tira o violino da caixa e começa a tocar com entusiasmo para a multidão que passa por ali, bem na hora do rush matinal.

Durante os 45 minutos que tocou, foi praticamente ignorado pelos passantes, ninguém sabia, mas o músico era Joshua Bell, um dos maiores violinistas do mundo, executando peças musicais consagradas num instrumento raríssimo, um Stradivarius de 1713, estimado em mais de 3 milhões de dólares.

Alguns dias antes Bell havia tocado no Symphony Hall de Boston, onde os melhores lugares custam a bagatela de 1000 dólares.

A experiência, gravada em vídeo, mostra homens e mulheres de andar ligeiro, copo de café na mão, celular no ouvido, crachá balançando no pescoço, indiferentes ao som do violino. A iniciativa realizada pelo jornal The Washington Post era a de lançar um debate sobre valor, contexto e arte.

A conclusão: estamos acostumados a dar valor às coisas quando estão num contexto.

Bell era uma obra de arte sem moldura. Um artefato de luxo sem etiqueta de grife.

Quando deve ser estimado o Backlog de Produtos

Recentemente me enviaram uma pergunta sobre a reunião de planejamento do Sprint deve começar com tempo alocado para colocar estimativas em pontos (story points) nas histórias de usuários que ainda não tenham sido estimadas.

Não, não acho que isto seja uma boa idéia. Tenha em mente que colocamos estimativas em itens do backlog de produtos (que recomendo que sejam histórias de usuário) para que:

- o backlog de produtos possa ser priorizado. É impossível priorizar completamente uma lista de itens sem saber, no mínimo, seu custo relativo;
- possamos fazer previsões de alto nível e quanto terá sido feito até lá;
- possamos tomar decisões de trade-offs entre escopo e prazos;

Podemos alcançar estes objetivos com estimativas relativas aproximadas, tal como é dados pelos pontos. Por exemplo, se decido comprar um carro neste final de semana, é suficiente saber que posso comprar um Honda ou Toyota por $ 30.000 e uma Ferrari por cerca de $ 800.000. Não preciso saber o custo preciso do Honda ($ 31.850) antes de saber que deve estar na minha lista de carros candidatos que a Ferrari não fará parte desta lista.

As reuniões de planejamento de Sprint tipicamente entram num nível detalhe mais profundo do que o necessário para as estimativas do Backlog de produtos (sejam em pontos ou dias ideais). Como nos acostumamos, durante o planejamento de Sprint, a quebrar as histórias de usuário em tarefas e considerar estas tarefas em detalhes, há uma chance de que isso se transformará numa estimativa em pontos feita na mesma reunião.

Então, quando deve ser feita a estimativa em pontos? Descreverei o caso ideal, que você pode facilmente adaptar para o caso real do seu projeto. Os projetos tipicamente se iniciam de uma destas duas formas:

1. Um Backlog de produtos completo é escrito antes do primeiro Sprint, e todos os itens são estimados antes da reunião de planejamento do primeiro Sprint. (Se você fizer isso, cuidado para não escrever todas as histórias de usuário com detalhes demais. Cada item do Backlog de produtos representa um investimento. As histórias de usuário devem então ser elaboradas ‘just-in-time’ e com detalhes apenas suficientes para que possam se transformar em funcionalidade em um Sprint).

2. Sabemos que temos que começar o projeto, então mergulhamos de cabeça. Durante os primeiros Sprints, todas as histórias de usuário são escritas como descrito acima.

Continuamente, uma vez por Sprint, recomendo que o ScrumMaster diga para o time algo como “Tivemos cinco novas histórias de usuário neste Sprint, e precisamos estimá-las. Preparem-se para pensar nisso um pouquinho após a reunião diária de Scrum de amanhã, e faremos o Poker do Planejamento para estimar estes novos itens”. Fazer logo após da reunião diária de Scrum ajuda a diminuir as interrupções ao longo do dia. Normalmente procuro fazer esta reunião dois dias antes do final do Sprint. Desta forma, o Product Owner tem as estimativas e pode priorizá-las antes do início do próximo Sprint.

Delegue as responsabilidades táticas

Se você quer ser um mau Gerente de Produtos, faça tudo você mesmo. Você é o Gerente de Produtos, afinal, então deve ser a autoridade final em tudo que diz respeito ao produto. Você deve ser aquele que responde as perguntas do pessoal comercial, rascunha as press releases para o marketing, define todos os processos para os fornecedores e discute cada detalhe com engenharia. É claro isso consome bastante do seu tempo, mas é nessas coisas que o Gerente de Produtos deve gastar seu tempo. O que pode ser mais importante?

Se você quer ser um bom Gerente de Produtos, delegue as atividades táticas para permitir que você gaste seu tempo nos aspectos estratégicos de seu trabalho. Gerentes de Produto efetivos transferem o conhecimento do produto e a responsabilidade pela tomada de decisões táticas para os outros do time de desenvolvimento o tanto quanto for possível. Ao fortalecer o resto do time, o Gerente de Produtos pode focar na parte estratégia do trabalho do Gerente de Produtos.

É difícil para muitos Gerentes de Produto – especialmente os mais novos – efetivamente balancear entre as prioridades táticas e as estratégias da gerência de produtos. Com tantas prioridades concorrentes, não somente os Gerentes de Produto focam nas árvores em vez de nas florestas – mas também eles acabam se focando às vezes em pequenos detalhes.

Embora seja fácil dizer que Gerentes de Produto devam ser mais estratégicos e menos táticos (Spend your time in the right places), na verdade cumprir isso é um desafio significativo. O e-book gratuito do Pragmatic Marketing, The Strategic Role of Product Management, de Steve Johnson, que descreve porque a gerência de produtos é um trabalho estratégico e porque Gerentes de Produto devem pensar e agir estrategicamente. Escondida na seção de pensamentos finais do livro, há uma bela pérola da sabedoria (indicado pelo negrito):

Apesar de a gerência de produtos ser uma função estratégica, em sendo especialistas no produto e no mercado, os Gerentes de Produto são frequentemente empurrados para atividades táticas. Os desenvolvedores querem que os Gerentes de Produto priorizem os requisitos; o pessoal de marketing quer que os Gerentes de Produto escreveram material; a área comercial quer os Gerentes de Produto para fazerem várias demonstrações. Gerentes de Produto ficam tão ocupados dando suporte a outros departamentos, que não têm tempo para fazer a gerência de produtos. Mas, somente porque o Gerente de Produtos é especialista no produto, isso não significa que ninguém mais precisa ser.

Gerentes de Produto devem refletir sobre esta última frase. Pense em todas as atividades táticas em que você se envolve – documentação, respostas a perguntas, descrição de funcionalidades, dar respostas a feedbacks, acompanhar respostas, e assim por diante. Quanto de seu tempo é tomado por estas atividades? Por que você está envolvido nelas? É porque:

1. Você é a única pessoa da empresa que sabe fazer?
2. Todo mundo está ocupado é você é o único que tem tempo livre?
3. São coisas tão importantes que devem ser feitas apenas por você?

A resposta para estas perguntas provavelmente é NÃO na maior parte dos casos. O motivo real pelo qual Gerentes de Produto se envolvem com estas atividades é porque eles as fizeram no passado, então os demais assumem que eles as farão no futuro. Todas vez que um Gerente de Produtos escreve um documento para o marketing, faz uma demonstração para a área comercial ou investiga alguma questão técnica pelo time de desenvolvimento, o Gerente de Produtos cria a expectativa de que ele fará isso outras vezes no futuro. Obviamente há ocasiões em que isso possa ser apropriado, no entanto, na grande maioria do tempo, o Gerente de Produtos pode e deve dar o direcionamento e o contexto necessários, guiando os outros para que cumpram estas tarefas eles próprios.

A maior parte dos Gerentes de Produto não tem equipe que se reporta a eles, então, não é tão simples quanto delegar para um subordinado direto. Em vez disso, Gerentes de Produto devem orientar os outros e ensiná-los a ser auto-suficientes. Isso não quer dizer que os Gerentes de Produto devam ignorar solicitações, ou rapidamente repassar suas responsabilidades. Ao contrário, Gerentes de Produto devem cuidar para tornar aqueles que o cercam mais eficientes, provendo-lhes ferramentas, informação ou os recursos de que eles precisam.

Toda vez que você, como Gerente de Produtos, se depara com uma tarefa, deve se perguntar as seguintes questões:

• Ajuda a evoluir a estratégia do produto?
• Dá suporte a alguma das metas de alto nível do meu produto?
• Há outra pessoa na empresa, exceto eu, que pode realizar esta tarefa (responder a esta pergunta, investigar este problema, etc.)?
• Isso já surgiu antes, ou pode surgir novamente no futuro?
• É um uso do meu tempo que agrega valor?

É sempre difícil dizer “não”, embora possa facilitar se enxergar desta forma – toda vez que um Gerente de Produtos diz “sim” a algo tático e de rotina, está dizendo “não” a algo estratégico e voltado para o futuro. Para qual das duas coisas você se sentiria mais a vontade de contar ao seu chefe – o CEO – que você disse “não”?

Então o que você faz com as atividades táticas – os pedidos para elaborar textos, ter reuniões operacionais, respostas a clientes e discussões detalhadas sobre o produto? Pergunte-se, e também aos outros, se é realmente necessário que você seja incluído. Volte para as três perguntas feitas anteriormente, e descubra o porquê de você estar envolvido em atividades táticas:

1. Se você é o único que sabe alguma informação vital, encontre alguma forma de corrigir esta situação. Documente, comunique, ensine aos demais, pegue alguém para quem transferir o conhecimento – encontre alguma forma de garantir que outra pessoa também tenha a informação. Além de permitir o melhor uso de seu tempo, isso pode ser vital para a continuidade dos negócios e para um plano de sucessão.
   
2. Se todos os demais alegam estar ocupados e sobrecarregados de responsabilidades, o mesmo é duplamente verdadeiro para o Gerente de Produtos. Ajude a criar maneiras de as pessoas responderem às questões ou tarefas operacionais sozinhas, ao invés de transferir trabalho adicional para você.
   
3. Se realmente há atividades que pareçam ser suficientemente vitais e que precisem ser executadas exclusivamente por você, analise estas atividades. Algumas podem parecer críticas na primeira olhada, embora ao serem revistas podem não ser tão importantes quanto você tinha pensado originalmente. Outras pessoas podem estar se voltando para você por acharem que você quer ser envolvido, ou porque acham que você ficaria ofendido se não fosse consultado. Só porque alguém acha que uma tarefa é suficientemente importante, e que só pode ser feita por você, isso não significa que você quem que concordar com esta pessoa.

Finalmente, caso você esteja envolvido com estas atividades apenas por que sempre esteve – bem, é hora de você adotar a resolução de não fazer mais! Quanto mais os Gerentes de Produto vêem seu papel como sendo estratégico e focado no mercado, mais eles podem agregar valor à empresa e a seus clientes. Gerentes de Produto efetivos ajudam a criar mais expertise do produto dentro da empresa. Isto dá ao Gerente de Produto mais tempo para que se dedique àquilo que fez com que a empresa criasse este cargo – agregar valor ao criar e melhorar produtos focados no mercado.

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

Estratégia de Produto num Mundo Ágil

Recentemente conversei com uma equipe muito frustrada de engenheiros praticantes de Scrum. Eles estavam frustrados, pois sentiam que tudo que haviam feito no último ano era implementar funcionalidades e que o Gerente de Produtos não tinha nenhuma idéia do rumo que o produto deveria tomar ou o que eles estavam tentando atingir. Quando falei com o Gerente de Produtos (Product Owner, na linguagem do Scrum), ele explicou que ele acreditava que toda a sacada das de metodologias ágeis como o Scrum era poder se manter flexível e ágil, e que ele não achava que deveria se preocupar, ou se fixar, num rumo de longo prazo.

Esta não é a primeira vez que vi esta confusão, e temo que a estratégia de produto pode ter se tornado uma vítima não intencional da mudança para metodologias ágeis.

Pensei então que seria útil discutir o que é uma estratégia de produto, por que é tão importante fazê-la e como ela é, de fato, completamente compatível com uma filosofia ágil.

Primeiro, uma estratégia de produto deve descrever a visão daquilo que você está tentando alcançar. Usualmente, o intervalo de tempo entre dois e cinco anos. É um trabalho visionário e que deve ser persuasivo. Definitivamente não é nenhum tipo de especificação.

Algumas vezes a estratégia de produto é articulada na forma de uma página web no Wiki, algumas vezes é um documento, algumas vezes é um conjunto de slides no PowerPoint, e outras na forma de um vídeo seu evangelizando a visão. Em parte, o meio depende de quantas pessoas precisam ser comunicadas de sua estratégia de produto, e se você pode apresentar pessoalmente ou se deve ser enviada “empacotada”. De qualquer modo, ela deve ser clara, comprometedora e inspiradora. Como as coisas irão melhorar quando este produto ou serviço atingir seu potencial? Não é sobre as funcionalidades específicas que podem ou não ser construídas, mas sobre os benefícios de possuir este produto. Que problemas serão resolvidos com este produto? Porque os usuários adorarão o produto? Como o mundo será melhor uma vez que esta visão se torne realidade?

Em segundo lugar, a estratégia de produto é a ponte entre a estratégia do negócio e o roadmap do produto. A estratégia do produto deve suportar a estratégia de negócios, e o roadmap do produto é o que descreve seu plano atual de como irá de onde está agora, para a visão descrita em sua estratégia de produto.

Assegure-se de não confundir a estratégia do negócio com a estratégia do produto. A estratégia do negócio pode ser algo como “expandir nossa oferta de comércio eletrônico para permitir clientes na Europa e Ásia”. A estratégia do produto pode então descrever a eventual oferta de comércio eletrônico que tenha o suporte a línguas estrangeiras, a conversões de moeda, métodos de pagamento, entrega, controle de impostos, etc. que você precisará para suportar a estratégia de negócios.

Em terceiro, ter uma boa estratégia de produto é uma das coisas mais importantes que um Gerente de Produtos (ou, muito freqüentemente, o Diretor de Produtos) faz. Não é fácil, mas sem isso você pode ter pouca esperança de terminar com um produto que valha a pena. É como o antigo ditado que diz que se você não sabe para onde está indo, qualquer caminho serve.

Temos uma estratégia de produto ao obter um profundo conhecimento de nosso público-alvo, do mercado e das tecnologias envolvidas. Haverá brainstormings e montes de debates. Você deve ativamente envolver seus líderes de design e líderes de engenharia nesta discussão, bem como os principais stakeholders. A estratégia de produto é algo que você irá discutir e rever ativamente com sua gerência. Seu time executivo deve se preocupar profundamente com esta estratégia de produto.

Muitos Gerentes de Produto cometem o erro de acreditar que a estratégia de produto deve vir de cima para baixo, e em alguns casos isso acontece, especialmente caso você esteja numa startup com o fundador fazendo o papel de visionário do produto. Mas caso contrário, você precisa propor a estratégia de produto e oferecê-la para sua gerência para sua aprovação. É uma grande oportunidade para você subir na carreira.

Mas definir e construir funcionalidades sem uma estratégia de produtos bem pensada é, muito provavelmente, perda de tempo e dinheiro.

Em quarto lugar, é essencial compreender que a estratégia de produto não lhe prende a nenhuma funcionalidade (ou seqüência de funcionalidades) em particular. A seqüência e as funcionalidades são representadas no roadmap de produtos (o backlog no linguajar do Scrum). Você pode (e certamente deve) ajustar o roadmap constantemente com base no que você aprende de seus usuários, do mercado, suas análises e as novas tecnologias sobre as quais o produto é construído.

Finalmente, descobri que criar um conjunto de princípios de produto que acompanham sua estratégia de produto ajudará você e o time de produtos a tomarem as muitas decisões e trade-offs que surgem quando você realmente define as funcionalidades e a experiência do usuário. Os princípios de produto vão junto com e suportam a estratégia de produto. Você pode ler mais sobre princípios de produto em http://www.svpg.com/blog/files/product_manifesto.html.

Se tudo correu bem você já pode ter a noção de que ter uma visão daquilo que você está tentando atingir não é de forma alguma inconsistente com os princípios das metodologias ágeis. Defendo que as metodologias ágeis aplicadas corretamente lhe ajudarão e tornar sua estratégia de produto uma realidade mais rapidamente que com as metodologias tradicionais.

Se você não tem uma estratégia de produtos para seu produto, recomendo fortemente que você pare, de um passo para trás, e se pergunte o que está tentando realizar. Em uns três anos, o que você quer que este produto seja? Como você irá medir e reconhecer isto? Compartilhe esta visão com sua gerência e seu time de produtos, especialmente seus engenheiros. Eles também querem saber para onde o produto está se direcionando. Ajudará a mantê-los motivados, eles terão alguma fé de que você, como Gerente de Produtos, não está apenas atirando no escuro, e a estratégia é importante também porque ajuda os engenheiros a anteciparem as necessidades futuras que podem impactar suas escolhas em tecnologia e arquitetura.

Webinar gratuito: Ten Traits of Good Product Managers

Muitos dos textos deste blog são traduzidos do blog How To Be a Good Product Manager, de Jeff Lash. No próximo dia 9 de Julho, as 12h00 (ET - horário de Nova Iorque) ele fará uma apresentação sobre o trabalho e as características de bons Gerentes de Produto.

Participe: http://community.featureplan.com/community/2008/07/webinar_july_9_1200pm_edt_ten.php

Meça o Impacto das Mudanças no Produto

Se você quer ser um mau Gerente de Produtos, não se preocupe em medir os resultados do do desenvolvimento de produtos. Apenas inclua novas funcionalidades, e não veja se elas fazem diferença. Se um cliente pediu, deve valer a pena fazer. Se as pessoas não gostam, ou se está atrapalhando o produto, você certamente irá ouvir rapidamente. Além disso, o mercado e a competição estão mudando tão rapidamente, que você não tem tempo de medir o impacto de novas funcionalidades depois que são implementadas. Uma vez que o trabalho está feito, você já precisa focar sua atenção no próximo conjunto de funcionalidades a incluir.

Se você quer ser um bom Gerente de Produtos, meça o impacto das mudanças implementadas no produto. Gerentes de Produto devem constantemente avaliar as mudanças feitas ao produto e medir se foram bem sucedidas.

Freqüentemente, Gerentes de Produtos implementam novas funcionalidades, ou fazem outras mudanças ao produto sem um verdadeiro conhecimento do porquê estas mudanças serem feitas. O Gerente de Produtos pode pensar que tem uma razão lógica para pedir a mudança – um cliente específico pediu, um engenheiro sugeriu, a gerência executiva pediu – embora isto seja apenas parte do todo.

Mesmo que haja uma razão legítima para que as mudanças sejam feitas (e bons Gerentes de Produto devem saber que nenhuma das razões acima são verdadeiramente legítimas por si só), o Gerente de Produtos tem a responsabilidade de ir vários passos à frente e quantificar o impacto das mudanças. Embora isso possa parecer que está apenas criando mais trabalho para o Gerente de Produtos, na verdade isso torna seu trabalho muito mais fácil. Gerentes de Produto precisam ser capazes de quantificar o ‘sucesso’ de qualquer mudança, e descartar mudanças que tenhan menor probabilidade de serem bem sucedidas, e medir todo trabalho que é implementado. Isto permite com que o Gerente de Produtos garanta uma maior probabilidade de sucesso, e também mostre o impacto das mudanças, para conquistar o apoio ao solicitá-las.

Além de ter uma idéia e implementá-la, há vários passos que Gerentes de Produto devem seguir antes de se envolver no desenvolvimento do produto:

1. Definir o impacto esperado das mudanças: Diferentes produtos e diferentes mudanças terão diferentes impactos, embora algumas medições populares sejam:
a. Aumento no uso;
b. Aumento na receita dos clientes existentes;
c. Aquisição de novos clientes;
d. Melhora na taxa de retenção de clientes;
e. Melhora na satisfação do cliente;
f. Aumento no market share;
g. Servir de referência em blogs, cobertura de mídia ou relatórios de analistas especializados;

2. Estabelecer objetivos para as mudanças. Uma vez que você tenha definido as métricas específicas, o próximo passo é explicitamente esclarecer o que você espera que esta mudança consiga realizar. Bons objetivos são objetivos SMART (ou objetivos MT, se você preferir), deixando claro se o objetivo foi alcançado ou não.

3. Determinar como o impacto será medido. Embora você possa saber o impacto que você espera ou deseja ver, e tenha um objetivo quantitativo especifico em mente, você deve ser capaz de medí-lo para avaliar seu sucesso. Por exemplo, se você considera incluir uma nova funcionalidade em seu site, e seu objetivo é que 10% de seus clientes utilizem esta funcionalidade do site em até 30 dias após seu lançamento, você precisa der ferramentas de estatísticas para web preparadas para medir se este objetivo foi atingido ou não. Embora pareça óbvio, muito freqüentemente o trabalho de se medir o impacto da mudança não é considerado até que seja muito tarde no processo de desenvolvimento para que as medições sejam postas em prática, ou, até pior, depois que a mudança já foi implementada.

4. Meça o impacto e avalie objetivamente. Depois que a mudança é implementada, compare seus resultados reais com os esperados. Os resultados foram alcançados? Por que, ou por que não? O que poderia ter causado estes resultados? Há necessidade de mudanças adicionais? O que foi bem feito e pode ser replicado em outras mudanças de produto? O que você aprendeu que poderia aumentar seu sucesso no futuro?

Muitos resistem a este processo por diversas razões. Há muitas objeções e respostas comuns:

• Objeção: “Dá muito trabalho percorrer todos estes passos para cada funcionalidade! Não podemos definir o impacto, estabelecer objetivos, criar as métricas, e então medir tudo o que fazemos! Se fizéssemos, lançaríamos apenas uma pequena parte das mudanças que fazemos atualmente.” Boa! O trabalho do Gerente de Produtos não é fazer mudanças ao produto somente para dizer que está fazendo mudanças. Os produtos devem ter metas, e o Gerente de Produtos deve focar em atingir e ultrapassar estas metas. Adicionar novas funcionalidades não é um objetivo; aumentar a receita é um objetivo. Se este processo diminui um pouco o ritmo do processo, pode ser algo bom. Em vez de gastar dinheiro em 10 novas funcionalidades medíocres, o dinheiro pode ser gasto em uma única que tenha um impacto muito maior do que estas 10 combinadas.

• Objeção: “Não queremos definir metas se não temos certeza de que podemos cumprí-las.” Se a meta de uma nova funcionalidade é incrementar o faturamento em 10%, e sua nova funcionalidade incrementa a receita em 5%, você não atingiu sua meta, embora tenha causado um aumento de 5% na receita! É claro, ficou abaixo do objetivo, embora você esteja bem melhor do que estava antes. Em vez de criticar a incapacidade de atingir a meta, avalie se a meta era realista, o que poderia ter sido feito diferente para atingí-la e que mudanças podem ser feitas agora para alcançar e meta, e o que pode ser feito diferente no futuro.

• Objeção: “Não temos uma forma de mensurar o impacto das nossas mudanças.” Algumas mudanças são mais difíceis de serem medidas do que outras, e pode não ser prático ou válido medir cada pequena mudança minúscula no produto. Entretanto, sem métricas e medidas, Gerentes de Produto estão “voando às cegas”. Mudanças de produto precisam que organização invista tempo, dinheiro e outros recursos, e há um retorno esperado neste investimento que, cedo ou tarde, você terá que demonstrar. Estabelecer e acompanhar métricas permitirá que você crie um produto melhor e identifique problemas mais cedo. É de interesse do seu produto, de sua organização, de seus clientes e de você, como Gerente de Produtos, determiner como estas pedidas podem ser postas em prática.

• Objeção: “Não conseguimos concordar em quais deveriam ser os impactos e metas.” Se este é de fato o acaso, então evitar estes passos não resolverá o problema. O processo pode ser difícil de começar, embora a equipe só vá melhorar com o tempo. Pode não ser possível obter concordância total sobre todos os detalhes, embora passar pelo processo irá identificar em quais metas não há alinhamento. Por exemplo, o gerente de marketing pode querer implementar mudanças que gerarão mais clientes para uma aplicação web, enquanto um engenheiro pode querer implementar mudanças que irão deixar a aplicação mais rápida. Neste caso, chegar num acordo geral nas áreas em que deve-se focar seria bastante benéfico.

Ainda sob a luz destas objeções, há valor em passar pelos primeiros dois passos apresentados acima mesmo que não haja forma efetiva de passar pelos passos 3 e 4 ainda. Discutir o impacto esperado e definir as metas com os stakeholders relevantes é um exercício incrivelmente proveitoso. Mais do que apenas discutir sobre os detalhes de como uma mudança será feita, como geralmente acontece, você focará a conversa no porquê de a mudança ser feita. Ter o hábito de passar por esse processo é benéfico, mesmo que não seja possível de acompanhar completamente ou passar por todas as medições, isto pode criar uma mentalidade sobre como abordar a evolução do desenvolvimento do produto.

Implementar métricas e medições pode ser um passo intimidador e uma sobrecarga para o Gerente de Produtos. No entanto, se feito adequadamente, pode levar potencialmente a enormes melhorias no produto. Tornará o desenvolvimento do produto menos contencioso e mais baseado em evidências, levando a um processo mais eficiente e efetivo de gerenciamento. Além disso, pode tornar a você, como Gerente de Produtos, mais efetivo, uma vez que seu tempo e seus esforços estarão focados em áreas que trarão valor, e você poderá mostrar o valor que você criou – uma verdadeira medida de um bom 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/)

Desenvolvimento de Software Ágil no Desenvolvimento de Produtos

No desenvolvimento de produtos de software, especialmente de produtos web, metodologias ágeis facilitam e 'agilizam' o desenvolvimento.

Algumas das vantagens imediatas do desenvolvimento Ágil são:

- participação ativa e colaborativa do cliente (ou, no caso, do Gerente de Produtos);
- entregas rápidas e constantes;
- mudanças de regras de negócios podem ser incorporadas rapidamente;
- falhas podem ser corrigidas rapidamente;
- os desenvolvedores ficam mais envolvidos com os projetos;
- o conhecimento dos desenvolvedores é compartilhado com toda a equipe;

Enfim, sempre de acordo com o manifesto Ágil.

Não necessariamente é papel do Gerente de Produtos definir ou participar da decisão de metodologia de desenvolvimento da equipe, especialmente em casos de softwares desenvolvidos por terceiros (software houses, fábricas de software, consultorias, etc), mas não perca a oportunidade de sugerir e mostrar as vantagens destas metodologias para a equipe desenvolvimento.

Aqui vai um vídeo que explica porque o Desenvolvimento Ágil de Software se justifica: