O livro “A Meta“, de Eliyahu Goldratt, é um clássico romance sobre a Teoria das Restrições, em que o gerente de uma fábrica, Alex Rogo, se vê numa situação em que sua fábrica corre o risco de ser fechada pela administração da empresa por não estar conseguindo atender às demandas do mercado. Com pedidos atrasados em meses e ritmo de trabalho nada sustentável para ele e seus funcionários, Rogo, com ajuda de um consultor Jonah, identifica melhorias que poderia implementar na fábrica para que o lead time (tempo entre o pedido feito por um cliente e a entrega do produto) caísse de alguns meses para poucas semanas, salvando a fábrica da falência e recebendo uma promoção que lhe permitiria aplicar seu método em todas as fábricas da divisão.

Rogo percebe que, apesar de a fábrica não estar gerando dinheiro (devido a pedidos atrasados, clientes insatisfeitos, excesso de horas extras e diversos outros problemas), havia equipes na empresa que celebravam o sucesso por terem atingido suas metas locais (por exemplo, alta produtividade numa etapa do processo de fabricação do produto final). Rogo percebe que a alta produtividade de uma equipe (não gargalo) que gerava insumo para uma segunda equipe (gargalo) não era benéfica para a fábrica, pois gerava um inventário desnecessário (e caro), uma vez que o processo desta segunda equipe era mais lento e não dava conta de processar este insumo. Assim, a fábrica comprava matéria prima num ritmo alto para manter a produtividade da primeira equipe, e, no entanto, não conseguia entregar o produto final devido ao ritmo da segunda equipe. Assim, definem-se dois tipos de recursos: recurso-gargalo (aquele recurso cuja capacidade é igual ou menor do que a demanda colocada nele) e recurso-não-gargalo (qualquer outro recurso cuja capacidade é maior que a demanda colocada nele).

A primeira mudança na gestão de Alex se dá ao perceber que todos na empresa devem estar focados no objetivo da empresa, que é gerar dinheiro, e que a otimização local de uma etapa do processo era prejudicial para a meta global da empresa. Assim, sua primeira missão foi identificar a meta da empresa (geração de dinheiro) e fazer com que todos os times trabalhassem para o mesmo objetivo, e não para otimizações locais.

Através de três conceitos apresentados por Jonah, Alex e sua equipe conseguem identificar como gerenciar melhor seu processo de produção e identificar a meta de qualquer empresa: reduzir a despesa operacional e o inventário aumentando simultaneamente o ganho, onde Ganho é índice pelo qual o sistema gera dinheiro através das vendas -, Inventário é todo o dinheiro que o sistema investiu na compra de coisas que ele pretende vender -, Despesa Operacional é todo o dinheiro que o sistema gasta a fim de transformar o inventário em ganho”.

Rogo e sua equipe identificaram os gargalos da empresa (duas etapas do processo de produção), e fizeram com que toda a fábrica trabalhasse no ritmo do gargalo, assim, só haveria realização de trabalho caso fosse possível entregar o produto final para o cliente, caso contrário, todo trabalho realizado teria sido desperdício. Assim, através da otimização dos processos-gargalo da fábrica, Rogo percebeu que os únicos processos que precisavam ser otimizados eram os processos-gargalo, uma vez que estes eram os responsáveis pela baixa produtividade da fábrica.

Não adiantava hora-extra, pressão ou equipamentos melhores em processos que não eram gargalo, uma vez que isso geraria custos e inventário, e não teria impacto algum sobre a redução do lead time da empresa, que é o que geraria o resultado no final. Rogo percebeu que mesmo a compra de robôs para automatizar determinados processos da fábrica não havia sido benéfica, pois otimizava processos que não eram o gargalos, e portanto geravam inventário que não era processado pelas etapas seguintes.

Após todas as melhorias iniciais implementadas, o gargalo da produção passa a ser o mercado (vendas),  o que permitiu que a produção da fábrica fosse puxada pela demanda, e não empurrada para o mercado. A principal diferença é que quando a demanda é empurrada para o mercado, há geração de inventário (custo); quando a demanda é puxada pelo mercado, a fábrica produz (custa) somente o que precisa para gerar a receita (vendas), ou seja, o processo é muito mais otimizado e não há desperdício.

Através de um processo de melhoria contínua, Alex e sua equipe conseguem reduzir o lead time, reduzir custos e provar seu método para a alta direção da empresa, que reconhece o sucesso da fábrica com a produção dos principais envolvidos. O processo de melhoria contínua baseia-se em

1. IDENTIFICAR a restrição do sistema
2. EXPLORAR a restrição do sistema
3. SUBORDINAR tudo o mais a decisão acima
4. ELEVAR a restrição do sistema
5. SE num passo anterior a restrição for quebrada, volte ao passo 1. MAS não deixar que a INÉRCIA se torne  a restrição do sistema.

E o que isso tudo tem a ver com o desenvolvimento de produtos?

A analogia da fábrica descrita no livro pode ser feita com qualquer tipo de organização, inclusive com o desenvolvimento de software. Alguns exemplos:

- não adianta cobrar velocidade de entrega de features da equipe de desenvolvimento se a equipe de Marketing não consegue manter os clientes e prospects informados de que essas features existem no produto. As features são feitas para que mais clientes comprem o produto, e se não for publicado que a feature existe foi lançada, eles não comprarão, e assim ter feito a feature representa inventário

- não adianta a equipe de experiência do usuário (UX) ou design definir o layout de 20 telas do produto em uma semana, se a equipe de desenvolvimento consegue entregar apenas 1 tela por semana. Muito provavelmente boa parte das telas irá mudar por demandas do produto e dos desenvolvedores, então seria muito melhor a equipe de UX/Design estar no mesmo ritmo dos desenvolvedores do que tão adiantada.

- não adianta o Gerente de Produtos definir as histórias e funcionalidades num ritmo muito maior que a implementação, pois o inventário gerado certamente precisará de feedback, e quando o gerente de produtos receber este feedback, provavelmente terá que alterar boa parte do que havia planejado. Assim, terá trabalhado à toa se seu planejamento se distanciar muito do ritmo de entregas da equipe de desenvolvimento.

Em resumo, é importante que os lotes de trabalho sejam pequenos, para que os ciclos de entrega possam ser curtos e feitos conforme a demanda do mercado, para que não haja desperdício e possa haver feedback no processo. Lotes grandes implicam em ciclos de entrega grandes, que geram inventário e tornam as mudanças de prioridade mais difíceis e caras de serem gerenciadas.

A leitura deste livro é extremamente esclarecedora e importante para qualquer um que gerencia uma empresa, de qualquer tipo!

Na última semana tive duas experiências bem desagradáveis com Centrais de Atendimento. Nem sempre o Gerente de Produtos tem autonomia sobre como será feito o atendimento para seu produto, especialmente em empresas maiores em que há uma área de atendimento bem definida, ou separada do dia a dia do desenvolvimento de produtos. Mas é importante que ele levante as questões para que não passem batidas.

Vou citar os dois exemplos que passei:

- Migrei no começo do ano o plano individual da NET para o plano coletivo. Durante anos paguei o plano individual, e obviamente nunca foi interesse da NET me contar que meu prédio tinha a opção de plano coletivo, já que o plano coletivo é mais barato. Mas ainda assim, eu descobri! Conseguir a migração foi um processo que levou uns 2 meses, e várias horas no telefone. Cada um que me atendia falava coisas diferentes, preenchia o sistema errado e me dava informações conflitantes. Mesmo depois de ameaçar cancelar em vez de migrar, o atendimento deles se confundiu. Enfim, o saldo é que migrei de plano depois de uns 2 meses, só que logo no mês seguinte começaram a me cobrar por um ponto adicional, que não era cobrado antes, e nunca haviam dito que ao migrar para o plano coletivo o ponto adicional era cobrado por fora. De novo, liguei reclamando. A atendente disse que era para ser cobrado mesmo, que iria investigar, ouvir as conversas gravadas (acreditar em mim, pra que?), e que se alguém tivesse me prometido isso, veria se poderia cumprir a promessa e me dar a isenção. Fiquei bravo com a resposta. Twittei reclamando. Poucos minutos depois me ligaram, pediram desculpas e me deram a isenção que eu queria.

- Eu tinha um financiamento imobiliário no Unibanco, que agora virou Itaú. Mandei minha documentação para a Central para usar o FGTS para reduzir o valor da dívida, e, quando recebi o aviso de entrega dos Correios, liguei na Central para saber se estava tudo certo com a documentação. Quando ligo lá, disco meu número de conta e senha, e a pessoa que me atende diz que meu contrato não foi encontrado e que eu deveria ir na revenda (detalhe: nem sei o que é revenda!). Eu insisto que tenho um financiamento com eles, que já fiz esta mesma operação há 2 anos atrás, mas de nada adianta. A moça responde brava que eu deveria ir na agência ou na ‘revenda’ (detalhe: com a mudança para Itaú, minha agência já nem é mais a mesma). Não tive dúvidas: twittei. Logo entraram em contato comigo, acharam meu contrato na hora, me pediram 5 dias úteis para ter a resposta porque a documentação havia acabado de chegar e que iriam acompanhar o caso para conferir que a Central me avisaria quando tivesse uma resposta. Tudo perfeito.

O que eu aprendi destes dois casos? Que as Centrais de Atendimento destas duas empresas atendem mal e não estão nem aí para o cliente. Mas que as área de Marketing / Redes Sociais destas empresas não querem que os clientes falem mal delas em público, então, para compensar o mal atendimento, eles têm autonomia para fazer mais que a Central de Atendimento. Ou seja, para ser bem atendido, fale mal da empresa – em público. Provavelmente, quanto mais followers você tiver no Twitter e no Facebook, melhor será atendido. Aprendi. Da próxima vez nem ligo na Central, já saio falando mal que sei que terei um atendimento muito melhor e meu problema será resolvido na hora!

Será que as áreas responsáveis por Produtos, Atendimento, Marketing, Estratégia destas empresas se falam???? Fica a dica: as áreas tem que se falar!!!

Quando você desenvolve um produto web, as primeiras versões que você coloca em produção, seja para um beta test, seja no lançamento de fato, a única certeza é que as coisas vão mudar.

Ao lançar um produto, você certamente não terá todas as features de que gostaria, e já sabe o que pretende mudar logo depois do lançamento; os primeiros feedbacks de clientes lhe darão novas idéias; ou ainda você irá descobrir que o modelo de negócios que havia pensado inicialmente não traz os resultados que você esperava e precisa ser revisto.

Lembre-se, os primeiros clientes, muito provavelmente, sabem que são os primeiros clientes, e, ao usarem seu produto, estão fazendo uma aposta que seu produto será bom e irá atender suas necessidades. Possivelmente eles mudarão algo em seu processo de trabalho para se adaptar a seu produto, e portanto merecem todo o respeito por isso.

Se você for alterar a forma de funcionamento de algo, mesmo de algo que estava quebrado antes, não se esqueça de que muito provavelmente você já tem clientes que encontraram maneiras de usar a feature, mesmo que ela não esteja funcionando como você gostaria. Ao “melhorar” algo, preocupe-se com o impacto que isto isto irá gerar naqueles que estão usando a feature. Mesmo coisas pequenas têm impacto e se adaptar a elas pode gerar frustração em seu usuário, que ficará mais propenso a procurar outras alternativas no mercado.

Já ouvi casos de melhorias visuais em sites, como reorganização de botões ou mudanças no fluxo de navegação, que realmente eram melhorias significativas na ferramenta. E alguns minutos depois da publicação das melhorias já havia clientes reclamando que tinham acabado de treinar seus usuários e que aquela alteração implicaria em ter que preparar um novo treinamento e aplicá-lo para diversos usuários, gerando custos inesperados e retrabalho. E isso que a mudança foi para melhor!

Imagine se alguma mudança que você quer fazer não tenha o resultado esperado, você simplesmente transformou seus clientes em cobaias de um experimento mal sucedido. O risco de perdê-los fica altíssimo, e isso certamente não é o seu objetivo!

Pessoal,

Dou apenas um sinal de vida para avisar que não desisti deste blog!

Ando numa fase bem corrida no trabalho e em casa, e acabo ficando sem tempo.

Ainda vou consolidar as anotações da Business of Software (conferência que mencionei em posts anteriores), e também estou lendo livros interessantes que foram distribuidos na conferência, para comentar aqui.

Por enquanto, ando mais ágil pelo Twitter, então podem me seguir por lá: twitter.com/dovb

Abs
Dov

Recentemente li um material escrito por Ben Horowitz, atualmente venture capitalist no Valley do Silicio (Foursquare, entre outros investimentos). Em 1996, ele era Diretor de Gestão de Produtos na Netscape, e mandou o texto abaixo para sua equipe de Gerentes de Produto. Embora ele ache que talvez o documento não seja relevante para os Gerentes de Produto de hoje em dia, quinze anos depois, não tenho certeza de que todos os Gerentes de Produto do mercado tenham ‘ultrapassado esta fase’.

A tradução é do @henriquemacedo, que é responsável por levar os produtos da Locaweb para o mercado internacional. Obrigado, Macedo!

==================
Bons gerentes de produtos conhecem o mercado, o produto, a linha de produtos, e a concorrência extremamente bem e operam a partir de uma sólida base de conhecimento e confiança. Um bom gerente de produto é o CEO do produto. Bons gerentes de produtos aceitam total responsabilidade e medem-se em termos do êxito do produto. Eles são responsáveis pelo produto certo/hora certa e tudo que advém disto. Um bom gerente de produtos conhece o contexto desde o início (a empresa, o financiamento da receita, a concorrência, etc.) e assume a responsabilidade por criar e executar um plano vencedor (sem desculpas).

Gerentes de produtos ruins têm muitas desculpas. Falta financiamento, o gerente de engenharia é um idiota, a Microsoft tem 10 vezes mais engenheiros trabalhando na sua versão do produto, eu estou sobrecarregado, eu não tenho direção suficiente. [O CEO da Netscape] Barksdale não usa este tipo de desculpa e nenhum CEO de determinado produto deveria fazê-lo.

Bons gerentes de produtos não deixam todo o seu tempo ser absorvido pelas diversas organizações que têm que trabalhar juntas para entregar o produto certo na hora certa. Eles não usam todo o tempo da equipe de produtos e não atuam como gerentes de projetos das diversas funções; eles não são o “gopher”* da engenharia. Eles não são parte da equipe de produtos; eles gerenciam a equipe de produtos. Equipes de engenharia não consideram Bons Gerentes de Produtos como “recursos de marketing”. Bons gerentes de produtos são a contrapartida de marketing do gerente de engenharia. Bons gerentes de produtos definem claramente o “que” (ao contrário de definir o “como”) e gerenciam a entrega do “que”. Gerentes de produtos ruins se sentem melhor se descobrirem “como”. Bons gerentes de produtos se comunicam claramente com a engenharia, tanto por escrito quanto verbalmente. Bons gerentes de produtos não dirigem informalmente. Bons gerentes de produtos coletam informações informalmente.

Bons gerentes de produtos criam materiais de apoio, FAQs, apresentações e “white papers” que podem ser alavancados. Gerentes de produtos ruins reclamam de passar o tempo todo respondendo a perguntas da força de vendas e de estarem atolados. Bons gerentes de produtos antecipam as falhas graves do produto e constroem soluções reais. Gerentes de produtos ruins apagam incêndios o tempo todo. Bons gerentes de produtos tomam posições por escrito em questões importantes (balas de prata competitivas, escolhas difíceis de arquitetura, decisões duras de produtos, mercados a atacar ou a deixar). Gerentes de produtos ruins vociferam suas opiniões e lamentam que as “forças superiores” não deixam as coisas acontecerem. Quando falham, os gerentes de produtos ruins apontam que já haviam previsto que falhariam.

Bons gerentes de produtos focam equipe em receita e clientes. Gerentes de produtos ruins focam a equipe em quantos “features” a Microsoft está criando. Bons gerentes de produtos definem bons produtos que podem ser executados com um bom esforço. Gerentes de produtos ruins definem bons produtos que não podem ser executados ou deixam a engenharia criar o que quiser (ou seja, resolver o problema mais difícil).

Bons gerentes de produtos pensam em termos de entregar valor superior ao mercado durante o planejamento “para dentro”, e em termos de adquirir participação de mercado e de metas de receita durante o planejamento “para fora”. Gerentes de produtos ruins ficam muito confusos com as diferenças entre entregar valor, equiparar “features” competitivas, precificação e alcance. Bons gerentes de produtos decompõem problemas. Gerentes de produtos ruins juntam todos os problemas em um só.

Bons gerentes de produtos pensam na história que querem que a imprensa escreva. Gerentes de produtos ruins pensam em cobrir todas as “features” e em serem tecnicamente precisos com a imprensa. Bons gerentes de produtos fazem perguntas à imprensa. Gerentes de produtos ruins respondem a todas as perguntas da imprensa. Bons gerentes de produtos assumem que gente da imprensa e analistas são inteligentes. Gerentes de produtos ruins acham que a imprensa e os analistas são burros porque não entendem a diferença entre “push” e “simulated push”.

Bons gerentes de produtos pecam do lado da clareza ou invés de ficar explicando o óbvio. Gerentes de produtos ruins nunca explicam o óbvio. Bons gerentes de produtos definem seu trabalho e seu êxito. Gerentes de produtos ruins querem que alguém lhes diga o que fazer.

Bons gerentes de produtos enviam seus relatórios de andamento dentro do prazo toda semana, porque têm disciplina. Gerentes de produtos ruins esquecem de mandar seus relatórios de andamento no prazo, porque não dão valor à disciplina.

Ben Horowitz
Diretor da Gestão de Produtos
Verão de 1996

N. do T.: Gopher é um protocolo de redes de computadores que foi desenhado para distribuir, procurar e acessar documentos na Internet de forma hierárquica, semelhante a uma estrutura de pastas, criado na Universidade de Minesota.
==================

Material original em inglês: Good Product Manager, Bad Product Manager