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 uma resposta

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:

Microsserviços podem se transformar, rapidamente, em um pesadelo para a área de operações. Diferente do que ocorre com um monolítico,...
Conheci o poema maravilhoso da Viviane Mosé, transcrito abaixo, na interpretação de uma grande amiga. Quem tem olhos pra ver...
Limpar strings é uma tarefa comum em nossas aplicações. Entretanto, .NET torna fácil cometer erros de implementação que levam a...
Gosto bastante da abordagem de Caitie McCaffrey para explicar sagas. Neste post, me inspiro na linha de raciocínio dela para...
Decidi aprender a programar com R. Aqui está algo que escrevi. ## defining a function makeCacheMatrix <- function(x = matrix())...
No último sábado, comprei um “toca-discos”. A experiência de ouvir um LP é algo bem diferente de quase tudo que...