Sua empresa oferece diversos produtos, e alguns deles não são estratégicos, ou, tem uma receita muito baixa em relação aos demais, ou ainda tem um custo de manutenção tão alto, que a receita simplesmente não é suficiente para pagar as contas.

Se for um produto estratégico, que você acredite que tenha potencial para deslanchar, e, ainda, todas as variáveis que permitirão o sucesso do produto estão sob seu controle, invista no desenvolvimento e faça acontecer;

Se for um produto estratégico, que você acredite que tenha potencial para deslanchar, mas nem todas as variáveis que permitirão o sucesso do produto estão sob seu controle, embora você acredite que em algum tempo razoável estas variáveis caminharão a seu favor, invista o suficiente para manter o serviço ativo, sem grandes inovações, aguardando a maré boa.

Se, por outro lado, o produto não for estratégico, não tiver previsão de pagar as contas sem grandes investimentos ou ainda você não tem controle nenhum sobre as variáveis que o afetam, seja corajoso e “mate” o produto!

Mas lembre-se, um produto que não seja estratégico para você, e que tenha na sua empresa somente 1 ou 2 clientes, pode ser altamente estratégico para seus clientes. Se você simplesmente descontinuar, estará “salvando” sua empresa, mas destruindo (em alguns casos, literalmente!) a empresa de um cliente seu.

Se você optar por descontinuar um produto, respeite muito seus clientes, independente de quantos forem:

- Comunique com muita antecedência: seu cliente pode estar no meio de um projeto em que seu produto seja fundamental; se você descontinuar, ele pagará multas, perderá clientes, perderá dinheiro.

- Repita a comunicação: como você já informou o cliente com antecedência, repita o comunicado periodicamente informando da proximidade da data de encerramento da prestação do produto.

- Explique os motivos: se seu cliente for sensato, ele também não irá querer que sua empresa quebre somente para atendê-lo.

- Sugira alternativas: ainda que as únicas alternativas sejam seus concorrentes

- Conte seu “segredo” para esses clientes, a infra-estrutura e os fornecedores que você usava, para que os clientes possam ir atrás e tentar montar sua estrutura própria.

- Respeite seus contratos: em alguns casos, desativar um produto pode implicar no pagamento de multas rescisórias. Se é melhor você pagar essas multas a manter o serviço, faça-o.

- Envolva outras áreas: o suporte técnico, o marketing, o comercial, etc. devem estar todos alinhados com seu discurso e serem capazes de explicá-lo para os clientes. Clientes que tenham atendimento comercial personalizado, devem ser comunicados de forma personalizada por seus respectivos gerentes comerciais. Assim como um cliente deve ser bem tratado ao entrar, deve ser bem tratado ao sair (ainda mais quando é por necessidade sua!)

Embora você não precise assumir a migração do serviço para a nova solução, você deve orientar e auxiliar o máximo possível. Para “salvar” sua empresa você não precisa quebrar nenhuma outra empresa, nem deixar estes clientes, que continuam sendo clientes de outros serviços seus (no mínimo em potencial), com raiva de sua empresa.

A transparência e a honestidade podem fazer com que você receba elogios destes clientes ainda que esteja causando algo extremamente incomodo para eles

Excelente apresentação!

Já tinha escrito sobre o NPS antes e lido alguns posts muito interessantes sobre o tema, como este.

Esta semana li o livro e recomendo!

1. Meça tudo! Quando a história foi criada; quando entrou no sprint; quando o desenvolvimento começou e acabou; quando foi para QA; quando foi publicada em produção. Sem medir, você nunca saberá se está melhorando ou piorando!

2. Melhore a qualidade: quanto melhor a qualidade do desenvolvimento, menos tempo em QA, menos bugs e menos retrabalho – eduque os desenvolvedores, coloque pessoas de QA na equipe, determine uma política de zero bugs, automatize os testes unitários, de regressão, testes funcionais e de integração.

3. Reduza o retrabalho: bugs identificados por clientes levam tempo para ser resolvidos – o cliente avisa do bug, passa pela equipe de QA, é reproduzido, é cadastrado no sistema de bug tracking, vai para um desenvolvedor, é reproduzido novamente, validado com o Gerente de Produtos se realmente é bug, é analisado, corrigido, testado por QA novamente, encerrado no bug tracking, empacotado para publicação e deployado. Faça certo da primeira vez, com qualidade, e evite o retrabalho.

4. Releases frequentes: colocar novos recursos em produção a cada 2 semanas permitirá que você aproveite a receita gerada por eles logo. Se seu deployment ocorre a cada 6 meses, uma nova funcionalidade criada hoje só trará resultado daqui a 6 meses. Além disso, com releases frequentes todo o processo de desenvolvimento flui melhor, e os problemas são detectados mais cedo no processo.

5. Para de trabalhar em paralelo: se cada desenvolvedor leva cinco meses para fazer sua funcionalidade, e cinco puderem levar um mês para fazer uma funcionalidade, a cada mês você resolverá o problema de um cliente em vez de ficar cinco meses com cinco clientes insatisfeitos. É claro que nem tudo pode ser paralelizado (9 mulheres grávidas por 1 mês não geram um filho… mas muita coisa pode sim!)

6. Histórias mais curtas: a regra 80/20 vale para o software, com 20% do desenvolvimento você satisfará 80% das necessidades de seu cliente, e, estudos mostram que mais de 60% dos recursos de um software nunca são usados. Entenda seu cliente, e foque naquilo que é mais relevante.

7. Gerencie o fluxo do desenvolvimento: post-its numa lousa, status das histórias e acompanhamento transparente explicitam os gargalos do processo, e, somente depois de conhecidos eles poderão ser melhorados.

8. Cancele reuniões: desenvolvedores entregam valor quando estão desenvolvendo; reuniões desviam seu foco e geram insatisfação para todos (inclusive para eles!). Metodologias ágeis como Scrum tem reuniões pré-definidas, com duração pré-estabelecida, minimizando as reuniões desnecessárias.

9. Deploy contínuo: quanto mais automatizado for o processo de testes e deployment, mais frequentes poderão ser os deployments. Quanto mais frequentes, mais rapidamente uma feature desenvolvida e testada irá para produção, diminuindo os buffers desnecessários.

10. Tenha uma gestão de produtos ágil: para de falar, e faça! Reduza o tempo em que uma feature fica sendo elaborada, e não desenvolva features diferentes ao mesmo tempo. Utilizando metodologias ágeis, melhorias podem ser aplicadas ao longo do processo, iterativamente.

11. Não tenha pontos únicos de falha (SPOF – single points of failure) – com SPOFs, você está sempre sujeito a problemas imprevisíveis que podem desviar seu foco. SPOFs podem ser de hardware ou software, mas também podem ser de pessoal (apenas 1 designer, apenas 1 especialista em alguma tecnologia, um único desenvolvedor de determinada parte do sistema)

12. Nivele seu trabalho: evite períodos de picos e vales no desenvolvimento – ociosidade e sobrecarga são dois extremos que prejudicam o ritmo do desenvolvimento e tornam o lead time variável.

Fonte: e-book “12 Things to Shorten Your Lead Time” – http://codemonkeyism.com/

O processo de introdução de um produto no mercado é uma empreitada séria, mas muitas empresas é meramente o processo de seguir um checklist ao término do desenvolvimento do produto. O lançamento é parte fundamental do processo é pode comprometer toda a expectativa de vendas se for mal planejado.

1. Não há metas para o lançamento: quais são seus objetivos ao lançar o produto?

2. Qual a estratégia de lançamento e os deliverables que ela implica? Todos os times estão alinhados (vendas, marketing, suporte, etc)?

3. O plano contém prazos e expectativas inatingíveis? É bom ser otimista, mas o otimismo não pode cegar para a realidade. A organização tem capacidade de execução para atingir as espectativas?

4. A força de vendas foi treinada com base nas features do produto, e não em como o produto resolve o problema dos clientes. Bons vendedores vendem soluções para os clientes, não listas de funcionalidades, e portanto devem ser treinados para isso. Entenda como e por que seus compradores compram.

5. Esforço significativo é gasto na criação de material de apoio e ferramentas de venda que nunca serõa utilizadas: 90% do material de vendas nunca é lido pela equipe comercial, mas ainda assim as equipes de marketing gastam tempo com isso.

6. Não há uam pessoa responsável por direcionar os resultados do lançamento do produto. Deve haver um “launch owner” com responsabilidade sobre o lançamento.

7. O plano de lançamento é baseado em suposições, não em evidências do mercado.

8. Seu plano é cópia do plano de um concorrente: nem tudo que vale para um player vale para os outros. Além disso, copiar o concorrente significa que você acha ele mais inteligente que você. Se você acha isso, que dirá o mercardo?

9. Clientes existentes não são considerados: lembre-se da migração dos clientes atuais para o novo plano, não frustre os clientes atuais – é mais caro conquistar novos clientes do que manter e aumentar as vendas para os clientes antigos.

10. O time de lançamento de produtos não é um time: o time responsável deve ser matricial, envolvendo as diversas equipes vinculadas ao produto.

Baseado em material do webinar Ten Ways to Identify an Impending Product Launch Disaster

As pessoas da área comercial são motivadas de forma diferente do resto de nós. Eles querem mais dinheiro. Eles devem estar sempre “famintos”, com baixos salários, e comissões gordas para produzirem bem e conseguirem mais clientes. Isto é verdade?

Vendedores comissionados se preocupam mais com seu próprio bolso do que com a empresa. Se num determinado mês eles têm uma excelente oportunidade de venda, mas já atingiram sua meta, eles adiarão a venda para o mês seguinte. Você até pode fazer variações na estrutura de comissionamento, mas isso tende a deixar tudo mais complexo, e provavelmente menos eficiente.

Se sua empresa vende produtos, geralmente a customização é feita através de configurações, pelo próprio usuário, ou por alguma consultoria. Projetos maiores exigem customizações maiores, mas não necessariamente no seu produto. As vezes é necessário envolver uma consultoria, um desenvolvedor ou alguém que faça a adaptação de seu produto para as necessidades deste cliente. A equipe comercial geralmente não quer fazer este meio de campo de envolver terceiros que façam o projeto dar certo, e jogam o problema para a área de desenvolvimento, já que não podem “perder tempo” com um cliente, pois se o fizerem, estarão colocando em risco sua comissão do próximo mês.

Quanto mais ambiciosas forem as metas, maior será a pressão sobre os vendedores, mais atendimento personalizado e customizações que sua equipe de desenvolvimento terá que gerenciar. Quanto mais vendas, mais custos. Recentemente ouvi de uma empresa que mais de 80% dos chamados abertos no suporte técnico eram dos clientes grandes, que provavelmente geraram as maiores comissões para os vendedores. Mas também foram os clientes que geraram maior custo na área de desenvolvimento, no suporte técnico, no jurídico e no financeiro. E, como seu foco é o desenvolvimento de produtos, e não de projetos customizados, as demandas destes clientes não são sua prioridade, e assim eles serão os clientes mais insatisfeitos. Provavelmente, quando estes “projetos” foram vendidos, os vendedores esqueceram que vendiam “produtos”, viram felizes da vida os valores de suas comissões, e prometeram coisas que sua empresa não podia cumprir (não podia, ou até mesmo não queria, por não ser o foco de sua estratégia de negócios).

Com foco exclusivo em vender, vender e vender, seus vendedores viram especialistas em vendas, mas não sabem mais o que estão vendendo. Tanto faz se estão vendendo software, passagens ou bicicletas. E, quando os clientes têm dúvidas legítimas sobre o produto em si, eles não sabem mais responder: precisam de apoio da área de produtos ou de desenvolvimento, gerando custos (antes mesmo de fecharem a venda). Custos que não entram na conta de quem vende, pois em sua conta entram apenas comissões.

Em alguns casos, este perfil de clientes fora do padrão traz lucro para o vendedor, na forma de comissões, e prejuízo para toda a empresa, pois atender a estas demandas desvia o foco de várias equipes que trabalham para atender a todos os demais clientes, que são menos rentáveis individualmente, mas, no total, muito mais rentáveis e lucrativos para a empresa.

Sua empresa não vende qualquer coisa, ela vende determinados produtos.

Enfim, seu modelo de comissionamento faz com que seus vendedores vendam para clientes que não são bons clientes para sua empresa! (Sim, nem todo cliente é um cliente bom!). É um círculo vicioso, mantido pela pressão sobre os vendedores, que gera insatisfação nos clientes que são “enganados”, e nas áreas de desenvolvimento, que não tem foco em atender estes clientes.

Como resolver esta questão?

Uma possibilidade é simplesmente melhorar o salário fixo e tirar as comissões. As vendas não deveriam gerar comissões para pessoas específicas, pelos seguintes motivos, entre outros:

• Não ter comissionamento dará a cada vendedor a possibilidade de compartilhar informações e clientes com outros vendedores, melhorando seu nível e a qualidade de seu trabalho. Se um vendedor estiver doente um dia, não se incomodará em passar o cliente para outra pessoa da equipe. Se um vendedor conhece melhor um produto, não se incomodará de explicar e ajudar outro vendedor a apresentar este produto a um cliente. Os clientes de sua empresa serão melhor atendidos.
• Não ter comissionamento dará a cada vendedor a possibilidade de entender melhor seu produto, e seus clientes, fazendo com que vendam o produto certo, para o cliente certo, e não o produto mais caro, para qualque cliente.
• Não ter comissionamento fará com que seus vendedores tenham as mesmas metas do resto da empresa, ligadas ao resultado da empresa, e não a resultados individuais. Por que um vendedor deve receber comissão por vender, e um desenvolvedor não deve receber comissão por linha de código que escrever? Ou até mesmo por cliente que contratar o serviço? O vendedor só vende porque alguém desenvolveu, não é melhor, nem pior.
• A equipe de desenvolvimento atenderá as demandas do comercial com mais satisfação, pois estarão juntos trabalhando pelo resultado da empresa, e não por um resultado que terá lucro para uma pessoa e prejuízo para as demais.

E se um vendedor for um mal vendedor, como será punido, se não há mais um modelo de comissionamento? Fácil: da mesma forma que um desenvolvedor, que alguém do RH, do financeiro, etc. Ele é um profissional como qualquer outro, sem a empresa ter que se preocupar com modelos diferenciados, formas de pagamento, etc., que geram overhead nas áreas administrativas, e, portanto, mais custos para a empresa.

Em resumo, se você trabalha com produtos, envolva a equipe comercial com os produtos. Não tenha um modelo de motivação distorcido para os vendedores.

Eles não são pessoas diferentes, piores ou melhores. Eles também têm suas famílias para sustentar e contas para pagar. Pressioná-los com comissões será ruim para todos na empresa, inclusive para eles.

Afinal, as pessoas do comercial não são tão diferentes assim, eles são como nós!

Baseado em no post “Are sales people different from you and me?” no Blog do Business of Software.

Com o crescimento das redes sociais e de ferramentas como os Blogs e o Twitter, cada vez mais as pessoas expressam suas opiniões (boas ou ruins) sobre produtos e empresas.

Monitore e interaja com as pessoas que falam sobre seu produto e sua empresa. Com isso, você poderá reverter más impressões, e estimular que as boas impressões sejam retransmitidas e gerem indicações para seu produto!

Há diversas ferramentas que monitoram blogs, redes sociais e o Twitter… conheça algumas neste artigo.