Definindo “produto pronto” para apaziguar as áreas de DEV, MKT e Vendas

Se há algo que nunca vi foi consenso para o significado de “produto pronto” nas as áreas de desenvolvimento, marketing e vendas.

Trabalho há mais de 20 anos desenvolvendo produtos de software e ainda sinto calafrios quando ouço perguntas tipo: “Produto X estará pronto para a feira?”. Isso porque, geralmente, não tenho a menor ideia do que o meu interlocutor está querendo dizer. Normalmente, o que ele entende por “pronto” é bem diferente daquilo que eu entendo.

Há algum tempo, tentando minimizar o sofrimento geral, venho propondo uma definição simples mas abrangente para “produto pronto”. Aliás, quatro definições complementares. Defendo que há quatro “estágios de pronto”. São eles:

  1. Pronto para Testar
  2. Pronto para Divulgar
  3. Pronto para Vender
  4. Pronto para Exportar

Pronto para Testar

Penso que um produto está pronto para testar quando:

  • Tem uma proposição de valor claramente definida
  • Possui features que atendem claramente a proposição de valor

Se você não sabe que problema seu produto ajuda a resolver, então as chances de criar um bom produto são claramente reduzidas.

Seguindo Paretto, assumo que 20% das features de um produto de software geralmente entregam 80% do valor (da proposição do valor). Se essas features não estiverem implementadas, não há o que testar.

Quando alguém pergunta para a área de desenvolvimento “Quando produto X estará pronto?”, só poderá ter como resposta quando haverá algo pronto para ser testado.

Produto não fica “Pronto para a feira” na área de desenvolvimento.

Pronto para Divulgar

Considero uma série falha estratégica divulgar um produto antes que ele esteja pronto… para divulgar.

Um produto pronto para divulgar precisa:

  • Ter clientes que atestam que as features implementadas conseguem entregar a proposição de valor
  • O produto já possui um nome (e marca)
  • Ter suporte qualificado
  • Uma ideia de preço (captura do valor proporcionado)

Se estas quatro premissas não são atendidas, então, as chances de ficar “sem resposta” para questões dos clientes é grande.

Em vendas, dizem, timing é tudo!

Pronto para Vender

Há quem defenda que divulgar um produto sem poder vender é um erro. Há quem defenda que não.

Para um produto estar pronto para vender, é necessário:

  • Ter canais de venda e distribuição acertados e capacitados;
  • Ter estrutura de custos e geração de receitas bem definidas (o tal business model)
  • Ter mecanismos para faturamento e cumprimento de obrigações fiscais implantados

Pronto para Exportar (vender fora)

Para poder exportar, é necessário:

  • Ajustar cultura (considerando cores, medidas, etc)
  • Traduzir adequadamente
  • Certificar-se, em cada mercado, que todos os outros “prontos” já ocorreram

Concluindo

Produto pronto é um conceito complexo. O “pronto” do desenvolvimento não é suficiente para divulgar. O “pronto para a feira” está longe de ser o pronto para vender. Ter um produto que vende bem não significa que “basta traduzir para exportar”.

Infelizmente, o que mais vejo é pessoas antecipando o “pronto”. Por vias das dúvidas, a culpa é sempre do desenvolvimento que não consegue cumprir prazos e “atrasa o lançamento”, não é mesmo?

Comentários?

Capa : Pineapple Supply Co.

Compartilhe este insight:

2 respostas

  1. Excelente post Elemar!
    De fato, essa é a questão mais esquisita dentro da área de desenvolvimento, justamente por ser onde todas as outras áreas fazem uma convergência.

    Além dos problemas na especificação e priorização do backlog, acredito que a falta de acompanhamento é causa desse problema.

    Gosto de pensar que nenhum projeto atrasa 1, 2 ou 3 meses, ele atrasa, 30, 60 ou 90 dias, sendo um dia de cada vez.

    Acho que essa é uma das motivações da Daily meeting, que acaba na maioria das vezes sendo entendida como uma reunião sem sentido.

  2. Excelente questão! Acho que não a toa, no Scrum, é um requisito forte definir a noção de pronto, com critérios de aceitação, e ser globalmente informando.

    O que é uma noção magnífica, até nos sub processos: qual é o pronto de design e ux? O pronto de negócios e requisitos?

    Acho que no fundo, é tudo uma questão de “gestão do óbvio” das necessidades do próximo nível, afinal, todo mundo tem uma ideia rápida (egoísta e tendenciosa ao escopo da área em que trabalha) de “o que é pronto”. O negócio é ter essa consciência de fazer o alinhamento de expectativas sobre esse pronto.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Elemar Júnior

Sou fundador e CEO da EximiaCo e atuo como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Elemar Júnior

Sou fundador e CEO da EximiaCo e atuo como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Mais insights para o seu negócio

Veja mais alguns estudos e reflexões que podem gerar alguns insights para o seu negócio:

RavenDB utiliza Lucene como motor de indexação. Isso significa suporte natural a full-text search que pode ser facilmente habilitado a partir da...
No meu cotidiano, reconheço que, por mais estranho que pareça, comprometo muito do meu tempo ouvindo música ruim até que,...
Ontem, dia 25/07/2018, a convite do Canal.NET, compartilhei alguns insights sobre modelagem de microsserviços a partir de processos de negócio....
“Microservices” is a trending topic. Big companies are trying to associate their technologies with this concept – but, it is...
No último post, solicitei uma explicação para o resultado da execução do código que segue: using System; using System.Threading.Tasks; using...
Nessa última semana, Fernando Neiva apresentou um compilado de nossas lições aprendidas implementando Kanban na Guiando. Aqui, compartilhamos o registro...
× Precisa de ajuda?