MVP & Prova de Conceito

Guia da quest

MVP: a definição exata, e as duas negações

O MVP permite ao empreendedor iniciar o processo de aprendizagem o mais rápido possível. Não é necessariamente o menor produto imaginável, mas simplesmente o método mais rápido de percorrer o ciclo construir-medir-aprender com o menor esforço possível.

— Eric Ries, A startup enxuta

Duas negações explícitas, e as duas derrubam projeto de aluno:

1. MVP não é desenvolvimento tradicional em versão reduzida. O objetivo do MVP é começar o processo de aprendizado, não encerrá-lo.

2. MVP não é protótipo nem teste de conceito. Diferente deles, o MVP não responde apenas a perguntas de design ou técnicas: ele testa hipóteses de negócio fundamentais.

Critério de corte para a quest: se o artefato só responde “dá pra construir?” ou “a tela está boa?”, é protótipo. Se responde “alguém quer isso a ponto de agir?”, é MVP.

Sobre qualidade

O MVP colide com a noção tradicional de qualidade, e o argumento é este: todas as filosofias de qualidade pressupõem que já se sabe o que o cliente valoriza — pressuposto arriscado aqui.

Se não sabemos quem é o cliente, também não sabemos o que é qualidade. — Eric Ries

Mas há um contrapeso explícito, e ele importa para não virar desculpa: isso não significa trabalhar de forma desleixada ou indisciplinada. Certos problemas de qualidade desaceleram o ciclo de aprendizado — bug dificulta evoluir o produto e limita a própria capacidade de aprender. Tolerar defeito em qualquer processo produtivo é jogo perigoso.

A regra que fecha: elimine toda funcionalidade, processo ou esforço que não contribua diretamente para o aprendizado desejado.

Prova de conceito — e por que ela vem antes

Processo que testa e valida a ideia em ambiente controlado e limitado, para determinar viabilidade técnica e comercial antes de investir recursos significativos.

A pergunta que ela responde: o usuário vê valor nisso? Usaria? Pagaria?

A PoC pode ser bem simples, sem uma linha de código.

Exemplo da disciplina: você quer controlar a TV por voz. Testa o conceito; 90% dizem que sim. Só então implementa o MVP. O que ele exige? Microfone, tela, interface, uma caixa, feedback sonoro ou visual — e o usuário pode estar sentado, sem controle na mão. A equipe atenta a isso sugere alterações, que serão testadas na Q8.

Os cinco tipos de MVP

Escolha pela pergunta que você precisa responder, não pela que é mais divertida de construir.

Distinção crucial sobre o concierge: não é virar uma pequena empresa artesanal. O serviço manual é temporário, existe só enquanto se testa o modelo. E o resultado médio de um concierge é revelar que o modelo de crescimento planejado não funciona — o que é exatamente o valor dele.

Nota honesta sobre uma frase famosa: a formulação célebre “construa metade de um produto, não um produto pela metade” é atribuída a este autor mas não foi verificável no texto disponível. O que existe, e é citável, é o caso do IMVU: a equipe não conseguia fazer os avatares andarem, trocou caminhada por teletransporte, sentiu-se ridícula entregando essa meia-solução — e os clientes elegeram o teletransporte entre as três coisas que mais gostavam. Use o caso, não a frase.

Por que o modo de IA se divide aqui

coprodução Construir é coprodução. É a quest em que a IA mais acelera. Trate como coprodução de verdade: defina o critério de aceitação antes de gerar, e verifique depois. A régua da disciplina subiu justamente aqui — espera-se sistema que funciona.

sem assistência Validar é sem assistência. E não é só porque a IA não pode ir a campo: a IA vai aprovar o seu MVP. Ela é complacente por construção. Se você perguntar “isso está bom?”, vai ouvir que sim.

Um MVP validado por IA é um MVP não validado.

As perguntas da entrega

1. Do que se trata a solução? Aplicativo? Produto físico? Website? Serviço?
2. Qual é a sua estratégia? Em forma de curva de valor: o que vão eliminar, diminuir, aumentar e criar.
3. O que é minimamente necessário para entregar os valores propostos?
4. Como a solução altera a jornada do usuário e/ou cliente? Como a persona resolve o problema usando o que vocês propõem?
5. Seus usuários/clientes aprovaram a ideia? Há evidência de que faz sentido, de que pagariam? Quantas pessoas você ouviu? Nesta quest não precisa prototipar. Piso: 5 pessoas na prova de conceito — abaixo disso não há sinal, e o milestone fica com teto de nível 3. Ver metodo/carga.md.

A pergunta 2 repete a curva da Q5 de propósito: agora ela é sobre o seu produto. É o que impede o escopo de explodir — cada item na coluna “criar” é semana de trabalho.

A pergunta 4 é a mais reveladora: se você não consegue descrever a jornada nova passo a passo, o MVP ainda está vago.

A entrevista de solução

Distinta da entrevista de problema da Q2. Teste a solução com uma demo antes de construir o produto de verdade — porque a maioria dos clientes é ótima em articular problemas, e ruim em visualizar soluções.

O que muda em relação à Q2: saem o ranqueamento de problemas e a exploração da visão de mundo; entram a demo e o teste de preço. Na entrevista de problema você ouve; nesta você mostra e mede a reação.

Portão explícito: se não houver forte ressonância com o problema no bloco da história, não continue — volte ao roteiro de problema.

Critério de saída: você terminou quando consegue identificar a demografia do usuário afoito, tem um problema must-have, sabe definir as funcionalidades mínimas, tem um preço que o cliente aceita, e consegue montar um negócio em cima disso numa conta de padeiro.

As cinco diretrizes da demo

1. Realizável. Demo em tecnologia que você não vai usar vende bem e cria elementos impossíveis de recriar — descolando o prometido do entregue.
2. Parecer real. Wireframe cru exige salto de fé do cliente. Quanto mais real a demo parece, mais precisamente você testa.
3. Rápida de iterar. Você vai receber feedback e precisa incorporá-lo na entrevista seguinte.
4. Minimizar desperdício. Comece em papel, e converta para a tecnologia final em algum ponto.
5. Dados realistas. Nada de lorem ipsum — dados verossímeis sustentam a narrativa. Design sem conteúdo não é design, é decoração.

Duas orientações de preço que contrariam o instinto

• Não pergunte quanto pagariam — diga o preço e meça a reação. Não há justificativa econômica para o cliente oferecer outra coisa que não um valor baixo.
• Não reduza a fricção de cadastro — aumente. Facilitar o “sim” atrasa a validação, e compromisso fraco prejudica o aprendizado.

Reduzir para o Release 1.0

O perigo depois das entrevistas é iterar mockups e acabar com mais do que o MVP precisa. A receita, em ordem:

1. Zere a lista. Nenhuma funcionalidade entra automaticamente.
2. Comece pelo problema nº 1. O trabalho da PUV é fazer uma promessa convincente; o trabalho do MVP é cumpri-la.
3. Rotule cada elemento como must-have, nice-to-have ou don't-need. Elimine os don't-need; mande os nice-to-have para o backlog.
4. Repita para os problemas 2 e 3.
5. Cobre desde o dia 1, mas colete no dia 30.
6. Foque em aprendizado, não em otimização.

Seu MVP deve ser como um bom molho reduzido: concentrado, intenso e saboroso.

Prototipagem paralela

Explorar várias alternativas ao mesmo tempo produz resultado melhor, mais divergência e maior autoeficácia — é o achado de um estudo publicado no ACM ToCHI (Dow et al., 2010), e o título do artigo já é a conclusão.

O mecanismo: iterar sozinho sobre uma ideia sobe o morro mais próximo; explorar em paralelo permite descobrir que havia uma montanha ao lado.

O ponto mais contraintuitivo: a avaliação dos protótipos não serve para escolher o melhor. Serve para o time refletir sobre como as pessoas reagem a elementos individuais — e depois fundir as melhores qualidades de todos num design superior.

E o corolário: protótipos iniciais devem ser rápidos, toscos e baratos. Quanto maior o investimento numa ideia, mais comprometido você fica com ela — e uma ideia medíocre pode ir longe demais.

Os dez tipos de pivô

Para a equipe cujo projeto não está funcionando. Pivô não é mudança qualquer: é um tipo específico de mudança cujo objetivo é testar uma hipótese fundamental sobre produto, modelo de negócio ou motor de crescimento.

O aviso que fecha o catálogo: trate o pivô como nova hipótese estratégica, que precisa ser testada com um novo MVP. Os casos famosos só mostram a estratégia final bem-sucedida — a narrativa heroica do fundador esconde as tentativas.

Referências desta quest

Antes de registrar pessoas

Técnicas desta quest

Fichas curtas de consulta rápida. Abra quando o procedimento acima mencionar a técnica.

Perguntas frequentes

“Como sabemos se o projeto está simples ou grande demais?” Não faça penduricalhos — ajustes cosméticos que não entregam valor. E não existe trabalho simples demais: o que se entrega é um MVP, um artefato funcionando plenamente que contém apenas o relevante para quem usa.

“Não sei nada de marketing/gestão. Vai ter aula?” Durante as aulas há explicações de 10 a 15 minutos de cada conceito, com referências para aprofundar. A disciplina estimula autonomia porque, num cenário real, não haverá apoio.

Bibliografia desta quest

Entrevista de solução

A entrevista de solução — Quest #6

Abra este arquivo na véspera de entrevistar. Ele traz o roteiro cronometrado, as falas a adaptar, o teste de preço, os critérios para parar e o que fazer com o resultado.

Modo de IA: sem assistência durante a entrevista e na leitura dos resultados. com apoio para preparar o roteiro e para criticar o seu formulário antes de ir a campo. A IA pode apontar que uma pergunta sua é indutora; ela não pode dizer se o cliente gostou.

1. O que esta entrevista testa — e por que ela não é a da Q2

Na entrevista de problema (Q2) você ouve. Aqui você mostra e mede a reação, porque a maioria dos clientes é ótima em articular problemas e ruim em visualizar soluções.

Os três riscos sob teste, na formulação de Maurya:

O que sai em relação à Q2: o ranqueamento de problemas e a exploração da visão de mundo do cliente. O que entra: a demo e o teste de preço.

Com quem falar

Blank descreve uma escala de dor do cliente com cinco pontos, e afirma que o cliente visionário — o que compra cedo e evangeliza — só existe nos pontos 4 e 5:

1. o cliente tem um problema;
2. o cliente sabe que tem um problema;
3. o cliente procura ativamente uma solução e tem prazo para achá-la;
4. o problema dói o bastante para que ele já tenha montado uma solução provisória própria — a gambiarra;
5. ele tem, ou consegue rápido, orçamento para resolver.

Se você levantou gambiarras na Q1, elas são a sua lista de convidados. Quem está no ponto 1 ou 2 vai ser educado com a sua demo e não vai comprar nada.

2. O roteiro, com tempos

Total previsto: 26 minutos com a pessoa, mais 5 de documentação.

Boas-vindas (2 min)

As falas abaixo são a tradução das falas do roteiro de Maurya, adaptadas ao português — a tradução é minha, e o exemplo (compartilhar fotos e vídeos entre pais) é o do livro. Substitua pelo seu domínio, mantendo a estrutura.

Muito obrigado por reservar este tempo para conversar com a gente.

Estamos trabalhando num serviço de compartilhamento de fotos e vídeos pensado para pais. A ideia surgiu depois que eu virei pai e senti na pele algumas frustrações com o que existe hoje.

A conversa vai funcionar assim: eu começo descrevendo os principais problemas que estamos atacando e pergunto se algum deles faz sentido para você. Depois queria te mostrar uma demonstração inicial da aplicação.

Queria deixar claro que não temos um produto pronto, e que nosso objetivo é aprender com você, não vender nem apresentar nada.

Tudo bem assim?

A frase “não temos um produto pronto e não estamos vendendo” não é gentileza: ela é o que autoriza a pessoa a discordar de você nos próximos vinte minutos.

Coletar demografia (2 min)

Perguntas curtas, sobre os atributos que você acredita que separam o usuário afoito do resto. No exemplo do livro: quantos filhos, que idades, você compartilha fotos on-line, e vídeos, com que frequência, com quem.

Se você já entrevistou essa pessoa na Q2, pule este bloco — a menos que tenham surgido atributos novos desde então.

Contar uma história (2 min)

Ilustre os três principais problemas com uma história, não com uma lista. O modelo do livro, traduzido:

Depois que os filhos nasceram, começamos a tirar muito mais fotos que antes, e principalmente mais vídeos. E passamos a receber pedidos regulares — semanais — de atualização, dos avós e de outros parentes. Só que era difícil compartilhar tudo isso com frequência, porque o processo tomava tempo e às vezes era doloroso: organizar os arquivos, redimensionar, ficar de babá do upload. Vídeo era pior ainda, porque muitas vezes tínhamos que converter antes para um formato que a web aceitasse.

Como a maioria dos pais, estamos com sono atrasado e temos menos tempo livre do que antes. Ter filhos nos deu uma noção nova do valor do tempo livre, e a gente preferia usar esse tempo em outra coisa.

Alguma coisa disso faz sentido para você?

O portão de ressonância

Se você não sentir uma ressonância forte com o problema, não continue a entrevista de solução. Use o roteiro de problema da Q2 para aprender como essa pessoa resolve isso hoje, e encerre.

Este é o erro mais caro do bloco: seguir para a demo por educação, com alguém que não tem o problema. O que você vai colher são elogios — e elogio de quem não tem o problema é ruído que vai contaminar a decisão de escopo da Q8.

Demo (15 min)

É o coração da entrevista. Percorra um problema de cada vez, mostrando como você o resolve com o apoio da demo. Pause depois de cada um e pergunte se há dúvidas. Depois de passar por todos:

Então é assim que a aplicação está hoje. Estamos tentando priorizar o que terminar e lançar primeiro, e queria te fazer mais algumas perguntas:

• Que parte da demonstração fez mais sentido para você?
• De qual delas você conseguiria viver sem?
• Está faltando alguma coisa que você acha importante?

A segunda pergunta é a mais produtiva das três e a mais fácil de esquecer. Ela é o que produz a etiqueta don't-need na seção 6.

As cinco diretrizes da demo

No Projetão, a diretriz que mais se descumpre é a quinta, e ela é a mais barata de cumprir. Trocar “Usuário 1, Usuário 2” por três nomes plausíveis com três históricos plausíveis muda a qualidade do feedback.

3. O teste de preço (3 min)

Duas orientações que contrariam o instinto, e o motivo de cada uma.

Diga o preço; não pergunte

Você consegue imaginar Steve Jobs perguntando quanto você teria pagado por um iPad antes do lançamento? (Maurya, tradução minha)

O argumento é econômico, não retórico: não há justificativa razoável para um cliente oferecer outra coisa que não um valor baixo. Além disso, o cliente muitas vezes honestamente não sabe quanto pagaria, e a pergunta só o deixa desconfortável.

A formulação do roteiro:

Vamos falar de preço. Vamos lançar o serviço num modelo de assinatura. Você pagaria R$ X por ano por compartilhamento ilimitado de fotos e vídeos?

E o registro que importa: se ele aceitar, anote se hesitou ou se aceitou de imediato. Aceitar rápido demais é sinal de que o preço está baixo.

Em geral, o preço certo é o que o cliente aceita, mas com um pouco de resistência.

Não reduza a fricção de cadastro — aumente

O instinto é facilitar o “sim”, esperando que o valor entregue ao longo do tempo justifique a relação. Isso atrasa a validação, porque é fácil demais dizer sim, e compromisso fraco prejudica o aprendizado.

Maurya relata um diálogo real de entrevista, aqui resumido e traduzido: o cliente sugeriu de 15 a 20 dólares por mês; o entrevistador respondeu que o plano era começar em 100 dólares por mês, explicou que estavam procurando 10 clientes que claramente tivessem aquele problema, prometeu trabalhar de perto com eles por 30 a 60 dias ou devolver o dinheiro, e ancorou: “você mencionou que gasta várias horas de desenvolvedor por mês num sistema caseiro e ainda não está satisfeito; 100 dólares por mês é menos de duas horas de desenvolvedor”. O cliente aceitou pagar cinco vezes o valor que ele mesmo tinha proposto.

Quatro princípios operavam ali:

A sequência: primeiro o que ele diz, depois o que ele faz

O bloco de preço mede compromisso verbal. Ele é o começo, não o fim. O fechamento (a seguir) é a tentativa de converter esse verbal em algo que custe alguma coisa: pré-reserva, sinal, lista de espera com dado real. A escada de compromisso é: verbal → escrito → pré-pagamento, e você deve pedir o degrau mais alto que faça sentido para o seu produto.

4. Fechamento — o pedido (2 min)

Duas perguntas, e as duas são pedidos:

Muito obrigado pelo tempo de hoje, você ajudou bastante.

Como falei no começo, isso ainda não é um produto pronto, mas estamos perto de lançar alguma coisa. Você teria interesse em experimentar o produto quando tivermos algo?

E estamos procurando entrevistar mais gente como você. Você conhece outros pais de crianças pequenas que a gente poderia entrevistar?

A segunda pergunta é o seu motor de recrutamento para as entrevistas seguintes. Uma equipe que não pede indicação passa a semana seguinte procurando participantes em vez de aprendendo.

5. Documentar (5 min) e o formulário

Use os cinco minutos imediatamente após a entrevista, com a conversa fresca. Cada entrevistador preenche o formulário de forma independente primeiro; só depois vem a reunião de comparação de notas e o registro final.

Formulário, adaptado do modelo do livro:

Data: ____/____/____

Contato
  Nome: ____________________   E-mail: ____________________

Demografia
  [atributo 1]: ______   [atributo 2]: ______   [atributo 3]: ______

Solução 1 — [nome da funcionalidade]
  Ordem de prioridade: ____   Nível de dor: ____
  Comentários: _______________________________________________

Solução 2 — [nome da funcionalidade]
  Ordem de prioridade: ____   Nível de dor: ____
  Comentários: _______________________________________________

Solução 3 — [nome da funcionalidade]
  Ordem de prioridade: ____   Nível de dor: ____
  Comentários: _______________________________________________

Preço
  Disposto a pagar (R$ __ / mês ou ano): ______
  Hesitou?  ( ) sim  ( ) não
  Notas: _____________________________________________________

Indicações: __________________________________________________

Duas colunas fazem a diferença na hora de decidir escopo: ordem de prioridade e nível de dor. Uma funcionalidade que todo mundo prioriza alto mas ninguém pontua dor alta é candidata a nice-to-have.

6. Quando parar, e o que fazer com o resultado

Revisão

Revise os resultados semanalmente, e só mude o roteiro depois de uma semana inteira de entrevistas — não depois de cada conversa. Nessa revisão:

• Adicione ou mate funcionalidades. Se vieram pedidos específicos, discuta se há razão convincente para incorporar. Remova o desnecessário.
• Confirme as hipóteses anteriores. Se a Q2 terminou com sinais positivos fortes, aqui não deve haver surpresa. Se houver, volte às hipóteses antigas.
• Refine o preço. Se não houve nenhuma resistência ao preço, teste um preço mais alto. Leve em conta as alternativas existentes: se a solução atual da pessoa é gratuita, como você entrega valor suficiente para justificar o pagamento?
• Procure padrão. Quem é o usuário afoito prototípico, e que preço ele suporta? Dá para montar um negócio viável nesse preço?

Critérios de saída

Você terminou quando tem confiança de que:

1. consegue identificar a demografia de um usuário afoito;
2. tem um problema must-have;
3. consegue definir as funcionalidades mínimas para resolver esse problema;
4. tem um preço que o cliente aceita pagar;
5. consegue montar um negócio em cima disso, numa conta de padeiro.

Cinco critérios, e nenhum deles é “entrevistamos dez pessoas”. Quantidade é meio.

Reduzir para o Release 1.0

O perigo depois das entrevistas é iterar mockups e terminar com mais do que o MVP precisa. A ordem, segundo Maurya:

1. Zere a lista. Nenhuma funcionalidade entra por padrão; cada uma precisa justificar a entrada.
2. Comece pelo problema nº 1. O trabalho da PUV é fazer uma promessa convincente; o trabalho do MVP é cumpri-la. A essência do MVP está no mockup do problema nº 1.
3. Rotule cada elemento como must-have, nice-to-have ou don't-need. Elimine os don't-need imediatamente; mande os nice-to-have para o backlog — a menos que sejam pré-requisito de um must-have.
4. Repita para os problemas 2 e 3.
5. Considere os pedidos de funcionalidade dos clientes (integrações, por exemplo) e decida entrar ou adiar pelo nível de “preciso ter”.
6. Cobre desde o dia 1, mas colete no dia 30. Período de teste é padrão hoje, e adiar a coleta de cartão reduz fricção de cadastro; os dois fatos trabalham a seu favor para reduzir escopo — você não precisa de conta de recebimento nem de múltiplos planos para lançar.
7. Foque em aprendizado, não em otimização. Não gaste esforço otimizando servidor, código ou banco. A chance de você ter problema de escala no lançamento é baixa; e se tiver, é um bom problema.

Seu MVP deve ser como um bom molho reduzido: concentrado, intenso e saboroso.

Fontes

• Maurya, Ash, Running Lean, cap. 8 (The Solution Interview) e cap. 9 (Get to Release 1.0) — os três riscos; o roteiro cronometrado e as falas; o portão de ressonância; as cinco diretrizes da demo; dizer o preço em vez de perguntar; aumentar a fricção; os quatro princípios do diálogo de preço; o enquadramento AIDA; o formulário; os critérios de saída; os sete passos de redução para o Release 1.0
• Blank, Steve, The Four Steps to the Epiphany — a escala de dor do cliente em cinco pontos e a tese de que o cliente visionário está nos pontos 4 e 5
• Zeldman, Jeffrey (A List Apart), citado por Maurya — design sem conteúdo é decoração
• Klaff, Oren, Pitch Anything, citado por Maurya — a técnica de enquadramento por posição de prêmio

Pivotar

Abra este arquivo quando os resultados do MVP não confirmarem o que vocês esperavam, quando as melhorias no produto pararem de mudar os números, ou quando alguém da equipe disser “acho que a gente errou o alvo”. Ele traz o catálogo dos dez pivôs, como conduzir a decisão e o que um pivô obriga você a fazer depois.

Modo de IA: com apoio. A IA é útil para mapear o seu caso contra o catálogo e para fazer as perguntas incômodas da reunião. Ela não decide, porque decidir aqui depende de dados de campo que só a equipe tem, e porque a IA tende a validar a alternativa que você já preferia.

1. O que é um pivô — e o que não é

Um pivô é um tipo específico de mudança, projetado para testar uma nova hipótese fundamental a respeito do produto, do modelo de negócios e do motor de crescimento.

Três negações que vêm da definição:

Pivô não é sinônimo de mudança. Trocar a paleta de cores, mudar o nome, reescrever a tela inicial: nada disso é pivô. A palavra é usada incorretamente como sinônimo de mudança com frequência.

Pivô não é desistir. Empreendedores de sucesso “não desistem ao primeiro sinal de dificuldade, nem perseveram até o desastre final; possuem uma combinação única de perseverança e flexibilidade”.

Pivô não é exortação. Boa parte da literatura de gestão pede que empresas se reinventem, sem dizer como. O pivô é uma categoria fechada de movimentos, cada um com uma hipótese associada.

2. Os dez pivôs, com o sinal de que é o seu caso

A coluna “sinal” traduz cada pivô em algo observável nos dados e nas entrevistas de vocês. A descrição vem de Ries; a leitura do sinal no contexto do Projetão é interpretação minha, marcada aqui como tal.

Sobre o pivô de captura de valor, vale registrar a advertência do próprio autor: chamar isso de “modelo de monetização” é limitado demais, porque sugere que a monetização é uma característica independente do produto, que pode ser adicionada ou removida à vontade. A captura de valor é parte intrínseca da hipótese de produto — mudá-la costuma ter consequências de longo alcance sobre produto e marketing.

Sobre o pivô de tecnologia: ele é muito mais comum em empresas estabelecidas, porque é uma inovação de sustentação — nada de relevante muda além da tecnologia. Num projeto de Projetão, “vamos trocar de framework” quase nunca é um pivô; é uma decisão de implementação.

Dois exemplos documentados, para citar:

• Zoom-in: a Votizen abandonou uma rede social completa e se aproximou de um produto simples de contato com o eleitor.
• Necessidade do cliente: a Potbelly Sandwich Shop começou em 1977 como um antiquário; os donos passaram a vender sanduíches para aumentar o movimento da loja, e em pouco tempo tinham pivotado para uma linha de negócio inteiramente diferente. Hoje a rede tem mais de duzentas lojas.

3. Como decidir: a reunião de pivotar ou perseverar

A decisão é difícil em termos emocionais e por isso precisa ser estruturada e agendada com antecedência — não tomada no calor de uma frustração.

Adaptação para o Projetão (interpretação minha): cadência quinzenal, alinhada com o ritmo das quests; “liderança comercial” é quem foi a campo; “conselheiro externo” é o professor, o monitor ou uma equipe vizinha — alguém que não esteja apaixonado pelo seu produto. A reunião precisa de ata, porque o argumento que sustentou a decisão é material de apresentação na banca.

Os sintomas que disparam a reunião extraordinária

Dois sinais reveladores, na formulação de Ries: a eficácia decrescente dos experimentos com o produto e a sensação generalizada de que o desenvolvimento do produto deveria ser mais produtivo. Quando os dois aparecem juntos, considere pivotar.

4. Por que quase todo mundo pivota tarde demais

Converse com quem pivotou e ouvirá que gostariam de ter decidido antes. Três razões:

1. Métricas de vaidade. Elas permitem chegar a conclusões falsas e viver uma realidade alternativa. O dano específico é que furtam da equipe a crença de que é necessário mudar. Quando as pessoas são forçadas a mudar contra o próprio julgamento, o processo demora mais e produz resultado menos decisivo.

2. Hipótese confusa. Com hipótese vaga, é quase impossível vivenciar um fracasso completo — e sem fracasso não há ímpeto para a mudança radical que o pivô exige. A crítica é direta: quem “lança e vê o que acontece” sempre terá êxito... em ver o que acontece. Os resultados iniciais serão ambíguos e você não saberá se pivota ou persevera.

3. Medo. O maior medo do empreendedor não é que a visão se mostre errada; é que ela seja considerada errada sem ter tido uma chance real de ser provada. Esse medo produz resistência ao MVP e ao teste comparativo, e ironicamente eleva o risco: o teste só acontece quando a visão está inteira representada — e, a essa altura, costuma ser tarde para pivotar, porque o recurso acabou.

O caso da Path é o contraexemplo útil: fundadores conhecidos lançaram um MVP que atraiu atenção da imprensa de tecnologia, o produto não era voltado a esse público e a reação inicial dos blogueiros foi bastante negativa. A equipe optou por ignorar o medo e olhar para o que os clientes diziam — que era diferente do que a mídia dizia. Nas palavras de Dave Morin: “Testamos humildemente as teorias e a abordagem para ver o que o mercado achava. Escutamos o feedback honestamente”.

5. Fracasso em pivotar — o caso que o próprio autor conta contra si

Anos após a fundação, a IMVU estava bem: receita acima de 1 milhão de dólares por mês, mais de 20 milhões de avatares criados, capital de risco levantado. E, por isso mesmo, deixou de perceber que precisava de um pivô de segmento de cliente.

O que aconteceu, na descrição de Ries:

• a empresa passou a confiar em métricas de vaidade — recordes de cadastro, de clientes pagantes, de usuários ativos — e parou de usar os milestones de aprendizagem;
• passaram meses tentando melhorar a taxa de ativação, com dezenas de experimentos medidos por teste A/B: melhorias de usabilidade, técnicas de persuasão, programas de incentivo, jogos. Individualmente, muitos foram bem-sucedidos;
• em conjunto, ao longo de muitos meses, os indicadores gerais do motor de crescimento mudaram de forma insignificante. A taxa de ativação subiu apenas alguns pontos percentuais;
• o mercado de usuários afoitos estava se esgotando; a equipe de marketing passou a alcançar clientes convencionais, menos tolerantes com um produto inicial; ativação e monetização caíram e o custo de aquisição subiu.

A lição operacional: retornos decrescentes num programa de otimização bem executado são o sinal clássico da necessidade de pivotar. Não é o experimento que falha; é o conjunto deles que para de mover o indicador macro.

6. A pista de decolagem se mede em pivôs, não em meses

A conta usual de sobrevivência é dinheiro em caixa dividido pela queima mensal. A reformulação:

A verdadeira medida da pista de decolagem é quantos pivôs uma startup ainda tem: a quantidade de oportunidades que possui para realizar uma mudança fundamental em sua estratégia empresarial.

A consequência prática é que existem duas formas de esticar a pista: cortar gastos, ou chegar a cada pivô mais rápido. E há uma armadilha na primeira: cortar de forma indiscriminada pode cortar justamente o que permite atravessar o ciclo construir-medir-aprender — e então tudo o que se conseguiu foi falir mais devagar.

Tradução para o semestre (interpretação minha): a sua pista é medida em quantas semanas restam até a Q13, e a sua taxa de queima é a agenda da equipe. Um pivô na Q6 é barato; o mesmo pivô na Q10 custa o produto inteiro. A decisão de pivotar cedo é a decisão de gastar pouco.

7. Um pivô é uma hipótese estratégica — e exige um MVP novo

Esta é a parte que mais se perde nas apresentações:

Um pivô é mais bem entendido como uma nova hipótese estratégica, que exigirá um novo produto mínimo viável para testar.

Ou seja: pivotar não é o fim do trabalho da Q6, é o reinício dele. Depois de escolher o pivô, a equipe volta a escrever a hipótese, escolhe o formato de MVP (ver tipos-de-mvp.md) e vai medir de novo. Uma equipe que pivota e segue direto para a implementação apenas trocou uma aposta não testada por outra.

E o cuidado com analogias: os pivôs que empresas conhecidas executaram costumam ser menos conhecidos que a estratégia final. “As empresas possuem um forte estímulo para alinhar suas histórias de relações públicas em torno do fundador heroico, e aparentar que seu sucesso foi o resultado inevitável de uma boa ideia.” Quando você diz “vamos fazer como a empresa X”, pergunte: estamos reproduzindo as características essenciais ou só as superficiais? O que funcionou naquele setor funciona no nosso? O que funcionou no passado funciona hoje?

8. Como um pivô aparece na entrega da Q6

Um pivô bem conduzido não enfraquece a apresentação — ele é evidência de que a equipe está medindo. O que precisa estar na entrega:

O que não deve aparecer: pivô justificado por preferência da equipe, por dificuldade técnica ou por cansaço. Esses são motivos reais para mudar de escopo, mas não são pivôs, e a banca vai perguntar qual foi o dado.

Fontes

• Ries, Eric, A startup enxuta (ed. brasileira), cap. 8 — a definição de pivô; o catálogo dos dez tipos com os exemplos Votizen e Potbelly; os três motivos para pivotar tarde; o caso Path; a reunião de pivotar ou perseverar (cadência, participantes e o que cada lado leva); o fracasso em pivotar na IMVU; a pista de decolagem medida em pivôs; o pivô como nova hipótese estratégica e a crítica à narrativa do fundador heroico
• Ries, Eric, A startup enxuta, cap. 6 — o compromisso antecipado com a iteração: qualquer que seja o resultado do MVP, não se abandona o projeto no primeiro teste

Tipos de MVP

Os cinco tipos de MVP — Quest #6

Abra este arquivo no momento em que a equipe já sabe qual hipótese precisa testar e está decidindo em que formato testar. Se você ainda não sabe qual é a hipótese, o arquivo errado está aberto: volte ao SKILL.md da quest.

1. A escolha é da pergunta, não do formato

Os MVPs “variam em complexidade, desde testes muito simples (pouco mais do que um anúncio) até protótipos iniciais reais, incluindo problemas e recursos ausentes” (Ries, tradução da edição brasileira). Não há fórmula para decidir a complexidade — é julgamento. E há um viés conhecido: “a maioria dos empreendedores e do pessoal de desenvolvimento de produtos superestima muito quantas funcionalidades são necessárias em um MVP. Em caso de dúvida, simplifique.”

Comece pela pergunta:

Uma equipe que escolhe pelo que é mais divertido de construir tende a escolher o Mágico de Oz — e a descobrir tarde demais que a pergunta dela era de canal, e que uma landing page teria respondido em um dia.

2. Smoke test — o anúncio que já transaciona

A pergunta: as pessoas demonstram intenção de agir — clicar, cadastrar, pagar — diante da promessa, antes de haver produto?

⚠️ Correção de termo. O termo smoke test não aparece em nenhuma das obras do acervo da disciplina. O que existe em Ries é a descrição da faixa inferior de complexidade: testes “pouco mais do que um anúncio”. Use o termo se ele circula na sua turma, mas não o atribua a Ries num trabalho acadêmico. Cite a descrição, não o rótulo.

O caso documentado mais próximo é o Groupon. A empresa nasceu como The Point, uma “plataforma de ativismo coletivo” para reunir pessoas em torno de causas e boicotes. Os primeiros resultados foram decepcionantes e, no fim de 2008, os fundadores decidiram tentar outra coisa mantendo o novo produto simples. Andrew Mason descreve o que construíram:

• um blog em WordPress, com um post novo por dia;
• a primeira oferta foram camisetas, com a descrição: “Essa camiseta será entregue na cor vermelha, no tamanho grande. Se você quiser uma cor ou tamanho diferente, mande um e-mail para nós” — não havia sequer formulário para escolher;
• os cupons eram gerados em FileMaker e enviados em PDF por e-mail;
• quando venderam quinhentos cupons de sushi num dia, dispararam quinhentos PDFs pelo Apple Mail.

A primeira oferta que funcionou foi um grupo de vinte pessoas comprando duas pizzas pelo preço de uma, numa pizzaria no primeiro andar do prédio do escritório.

Quando NÃO usar: quando a promessa é difícil de entender só por texto (aí é vídeo), ou quando a dúvida é sobre uso continuado e não sobre intenção inicial. Um smoke test mede o “sim” de quem ainda não usou nada.

Custo/esforço típico: horas a poucos dias. É o formato mais barato dos cinco e o que menos exige da equipe técnica.

3. Vídeo — quando o produto não pode ser prototipado

A pergunta: a proposta é entendida e desejada, num caso em que demonstrar o software funcionando é impossível?

O caso é o Dropbox. A equipe fundadora era de engenheiros; o produto exigia integração em nível profundo com Windows, Macintosh, iPhone e Android, além de um serviço on-line de alta confiabilidade. Em reuniões sucessivas, investidores diziam que o espaço estava abarrotado e que o problema não era importante — e não conseguiam imaginar o mundo que Drew Houston descrevia. Houston respondia com duas perguntas: “Você experimentou pessoalmente os outros produtos?” e, diante do sim, “Funcionaram com perfeição?”. A resposta quase sempre era não.

O que ele fez, em vez de esperar anos de desenvolvimento: um vídeo de três minutos, narrado por ele mesmo, mostrando a tela do próprio computador enquanto descrevia os arquivos que gostaria de sincronizar. Os arquivos que aparecem na tela estão cheios de piadas internas da comunidade de usuários afoitos (early adopters) de tecnologia — o vídeo foi feito para um público específico, não para o público geral. Resultado nas palavras de Houston: “Nossa lista de espera beta passou de 5 mil para 75 mil pessoas literalmente da noite para o dia”.

Maurya acrescenta dois dados sobre o mesmo caso: o vídeo, publicado no Hacker News junto de uma página de captura, ajudou Houston a atrair dezenas de milhares de usuários afoitos, a encontrar um sócio e a entrar na Y Combinator. Na época, Houston estimava lançar em menos de três meses; o lançamento público levou 18 meses.

A leitura correta do caso: o vídeo era o produto mínimo viável. Ele validou a suposição do tipo salto de fé não porque as pessoas disseram que gostaram num grupo de foco, mas porque se registraram.

Quando NÃO usar: quando o produto é fácil de simular com telas. Vídeo custa mais que uma demo em papel e responde menos sobre usabilidade.

Custo/esforço típico: dias. Num semestre de Projetão, um vídeo bem roteirizado de dois a três minutos é viável e cabe na Q6 sem comprometer a Q8.

4. Concierge — entregar à mão, um cliente por vez

A pergunta: o que o produto precisa ter de fato, descoberto entregando o valor manualmente?

O caso é a Food on the Table. Hoje o serviço monta planos de refeições e listas de compras a partir do que a família gosta e do que está em promoção nos supermercados locais — o que exige base de dados de quase todos os supermercados do país, receitas criadas por chefs e um algoritmo de compatibilização.

A empresa começou com um único cliente. Os fundadores não escolheram a loja que suportariam até terem o primeiro cliente; não tinham nenhuma receita até esse cliente estar pronto para planejar as refeições. Atenderam o primeiro cliente sem software, sem parceria comercial e sem contratar chef.

Manuel Rosso e Steve Sanderson visitavam supermercados e grupos de mães em Austin. Entrevistavam como um bom pesquisador de mercado entrevistaria — mas, ao fim de cada entrevista, tentavam vender: descreviam os benefícios, mencionavam uma taxa de assinatura semanal e convidavam a pessoa a se registrar. Em geral foram rejeitados. Alguém contratou.

Esse cliente recebia a visita pessoal do CEO toda semana. Os dois analisavam o que estava em promoção no supermercado preferido dele, escolhiam receitas conforme suas preferências, entregavam em mãos um pacote com lista de compras e receitas, pediam feedback e ajustavam. E recebiam um cheque de 9,95 dólares por semana.

Só quando os fundadores ficaram ocupados demais para conseguir novos clientes é que começaram a automatizar — e por partes: primeiro o envio por e-mail no lugar da visita, depois a análise das promoções por software, por fim o pagamento on-line no lugar do cheque escrito à mão.

A advertência que o caso carrega, e que derruba projeto de aluno:

Num MVP com concierge, esse serviço personalizado não é o produto, mas uma atividade de aprendizagem elaborada para testar as suposições do tipo salto de fé no modelo de crescimento.

É explicitamente diferente da pequena empresa em que o dono atende cada cliente pessoalmente. E há um resultado esperado que quase ninguém antecipa: “um resultado comum de um MVP com concierge é invalidar o modelo de crescimento proposto da empresa” — o que pode acontecer mesmo que o concierge seja lucrativo. Sem modelo de crescimento formal, a equipe fica satisfeita com um negócio pequeno e lucrativo quando um pivô levaria mais longe.

Quando NÃO usar: quando o valor do produto depende de escala desde o início (uma plataforma cujo lado A só tem valor se o lado B for grande). Aí o concierge testa a entrega, mas não testa o efeito de rede.

Custo/esforço típico: semanas de trabalho humano intenso, com pouquíssimo código. É o formato mais caro em horas de pessoa e o mais barato em horas de programação — o que costuma ser exatamente o inverso do que uma equipe do CIn prefere fazer.

5. Mágico de Oz — pessoas atrás da cortina

A pergunta: se resolvermos o problema técnico difícil, as pessoas usam? O uso leva a um produto com valor real?

O caso é o Aardvark, de Max Ventilla e Damon Horowitz: um serviço de busca para perguntas subjetivas (“qual é um bom lugar para beber um drinque depois do jogo na minha cidade?”), que roteia a pergunta pela rede social do usuário até alguém capaz de responder.

Com o repertório técnico dos dois, seria razoável esperar que começassem a programar. Levaram seis meses decidindo o que construir — e não em quadro branco. Nas palavras de Ventilla: “lançamos protótipos muito baratos para teste. O que se tornou o Aardvark foi o sexto protótipo. Cada protótipo representou um esforço de duas a quatro semanas. Utilizamos pessoas para replicar o back-end o máximo possível. Convidávamos de cem a duzentos amigos para testar os protótipos e medíamos quantos deles voltavam. Os resultados foram inequivocamente negativos até o Aardvark”.

Depois de escolhido o conceito, mantiveram o processamento humano por nove meses, com oito pessoas contratadas para gerenciar perguntas e classificar conversas. Toda vez que apareceu um problema técnico difícil — como decidir quem, na rede, é a melhor pessoa para responder —, eles se recusaram a resolvê-lo naquele estágio e simularam com o teste Mágico de Oz. O Aardvark foi adquirido pelo Google por divulgados 50 milhões de dólares.

A origem do método, útil para citar num trabalho: o “Paradigma OZ” foi cunhado por John F. “Jeff” Kelly, do IBM Thomas J. Watson Research Center, em 1980, na sua tese em Johns Hopkins; publicado como “An Iterative Design Methodology for User-Friendly Natural Language Office Information Applications”, ACM ToOIS 2(1), 1984, pp. 26–41. O nome atual remete ao filme de 1939, em que um homem comum se esconde atrás de uma cortina.

A montagem, segundo Hanington & Martin: o participante fica num local e o pesquisador-mago em outro; o mago precisa observar a atividade do participante (por vídeo ou compartilhamento de tela) para produzir uma resposta oportuna. Ele pode assumir três papéis: controlador (simula a inteligência do sistema), supervisor (corrige rumo e sobrepõe decisões do sistema ou do participante) e moderador (simula dados sensoriais e completa a experiência).

Quando NÃO usar: quando o gargalo do seu projeto não é técnico. Se você já sabe que dá para construir e a dúvida é se alguém quer, o Mágico de Oz é caro demais para a resposta que entrega.

Custo/esforço típico: semanas, com pessoas de plantão durante cada sessão. Exige combinar escala de quem “é o mago” — num semestre, isso significa alguém da equipe indisponível durante as janelas de teste.

6. Landing page — a página que mede o problema e o canal

A pergunta: o problema vale a pena ser resolvido? Quantas pessoas se inscrevem? O canal funciona?

O caso é o próprio livro de Maurya. Depois que uma dúzia de leitores do blog pediu que ele transformasse os posts num livro, ele ligou para esses leitores para entender qual seria a proposta única de valor do livro em relação às alternativas existentes. Com isso, gastou um dia construindo uma página com sumário, título e uma imagem de capa de banco de imagens.

O raciocínio de escopo é o ponto: ele sabia que a parte mais arriscada era acertar o sumário — não o título, não a capa, não o preço (livros de negócios têm preço estabelecido). A página testava o item mais arriscado.

Ele ligou de novo para os mesmos leitores perguntando: “se eu escrevesse este livro, você compraria?”. O feedback refinou o sumário. Como escrever para uma dúzia de leitores não indicava um problema que valesse a pena, ele deixou a página no ar e anunciou o livro no blog, em março de 2010, com previsão “neste verão”; os leitores espalharam a mensagem — isso foi o teste de canal. Em junho, tinha 1.000 e-mails coletados, o que, por uma conta de padeiro, cobria os custos. Só então começou a escrever.

Quando NÃO usar: quando você não tem como levar tráfego qualificado à página. Landing page sem canal mede zero, e o resultado nulo será interpretado erradamente como “ninguém quer”.

Custo/esforço típico: um dia de trabalho, mais o tempo de campanha. É o formato com melhor relação entre aprendizado e esforço para uma equipe do Projetão — e o mais fácil de fraudar sem perceber, se o único tráfego vier do grupo de WhatsApp da turma.

7. Comparação, para decidir em cinco minutos

Nenhum dos cinco responde à pergunta “dá para construir?”. Essa é pergunta de protótipo técnico, e é legítima — só não confunda uma com a outra na apresentação.

8. As duas regras que valem para qualquer formato

Elimine todo recurso, processo ou esforço que não contribui diretamente com a aprendizagem que você procura. Essa é a regra de corte do MVP, e ela é operacional: para cada item da sua lista, escreva qual hipótese ele testa. Se não houver hipótese, o item sai.

Um protótipo bem-sucedido não é o que funciona sem falhas; é o que ensina alguma coisa — a formulação é de Tim Brown, e vale como critério de avaliação da sua própria Q6. Junto dela, o corolário: protótipos iniciais devem ser rápidos, toscos e baratos, porque quanto maior o investimento numa ideia, mais comprometido você fica com ela, e uma ideia medíocre pode ir longe demais.

Modo de IA neste arquivo: coprodução para construir o artefato (telas, vídeo, página, automação parcial); sem assistência para rodar o teste e interpretar o resultado. A IA não deve opinar se o seu MVP “está bom” — ela vai dizer que sim.

Fontes

• Ries, Eric, A startup enxuta (ed. brasileira) — a definição de MVP e as duas negações; o caso Groupon/The Point; o MVP em vídeo (Dropbox); o MVP com concierge (Food on the Table) e a distinção em relação à pequena empresa; o teste Mágico de Oz (Aardvark); a regra de corte; “em caso de dúvida, simplifique”
• Maurya, Ash, Running Lean — “faça a menor coisa possível para aprender” (Dropbox, food trailers de Austin, Food on the Table); o caso da página de captura do próprio livro, com o sumário como parte mais arriscada e os 1.000 e-mails
• Hanington, Bruce & Martin, Bella, Universal Methods of Design — método 99, Wizard of Oz: origem em Kelly (1980/1984), montagem da sessão e os três papéis do mago
• Brown, Tim, Change by Design — protótipos rápidos, toscos e baratos; o protótipo bem-sucedido é o que ensina algo

Autodiagnóstico

Faça este exercício antes de entregar. É o mesmo que o mentor vai fazer depois.

Os milestones que abrem aqui

A Q6 alimenta dois dos 13 milestones: Solução (o que vocês propõem e por que ela entrega a proposta única de valor) e MVP/Implementação (o que existe de fato, funcionando). A aprovação exige nível 4 em todos.

O salto que trava a maioria é o 3 → 4, e na Q6 ele tem um nome preciso: sair de “mostramos para umas pessoas e elas gostaram” para “pedimos um compromisso a doze pessoas, cinco deram, e o preço que sustenta a conta é este”.

Rubrica — milestone Solução

1. Natureza da solução

2. Estratégia em curva de valor

3. Mínimo necessário

4. Jornada alterada

Rubrica — milestone MVP/Implementação

5. Escolha do formato de MVP

6. Evidência com usuário

7. Preço

8. O que funciona

Checklist rápido

• Consigo dizer, numa frase, qual hipótese o meu MVP testa?
• O artefato responde “alguém quer isso a ponto de agir?” — ou só “dá para construir?”
• Para cada funcionalidade que ficou, sei qual aprendizado ela sustenta?
• Pedi um compromisso ao final das entrevistas, ou só agradeci?
• Disse o preço em vez de perguntar?
• Anotei quem hesitou?
• Existe alguma coisa na demo que a equipe não consegue construir na tecnologia final?
• Alguma entrevista me fez cortar uma funcionalidade — ou todas confirmaram a lista original?
• Se a resposta ao MVP tivesse sido negativa, o que exatamente eu teria feito?

Sinal de alerta: se nenhuma entrevista de solução cortou nada da lista, ou a demo estava vendendo em vez de testando, ou vocês só mostraram para quem já torcia pelo projeto.

Segundo sinal: se a equipe descreve o MVP pelo que ele terá, e não pelo que ele já mede, o artefato ainda é um plano de produto.

Registro de trajetória (modo de IA)

Meia página, entregue junto. Ver metodo/modo-ia.md para o racional.

1. Modo em que a quest foi feita, e onde você saiu dele. Na Q6, construir é coprodução e validar é sem assistência. Se a IA participou da leitura dos resultados de campo, diga.

2. O que a IA gerou e você descartou — e por quê. Típico da Q6: a IA propõe um conjunto de funcionalidades “essenciais” a partir da descrição do produto. Essa lista é hipótese, não escopo. Se vocês a cortaram depois das entrevistas, esse é o registro mais valioso da quest.

3. O que você verificou, e como. Típico da Q6: o critério de aceitação do código gerado, e o teste que confirmou que o caminho principal funciona com dado real.

4. O que ainda não sabe. Exemplos honestos: “não testamos com ninguém fora de Recife”; “o trecho X é operado à mão e não sabemos o custo dele em escala”.

Um MVP validado por IA é um MVP não validado.

Como o mentor vai ler

Quatro perguntas frequentes na apresentação da Q6. Se você responde às quatro, está em 4.

1. “Quantas pessoas viram isso, e o que elas fizeram depois?” Resposta fraca: “todo mundo achou legal”. Resposta forte: número de demos, número de pedidos de compromisso, número de aceites.

2. “O que é minimamente necessário aqui — e o que vocês tiraram?” A segunda metade da pergunta é a que vale. Sem itens removidos, não houve redução.

3. “Quanto vocês disseram que ia custar, e o que aconteceu?” Se a equipe perguntou em vez de dizer, o dado é fraco e é preciso admitir isso.

4. “O que nesta demo não existe de verdade?” Responder com naturalidade é sinal de maturidade; ser pego é o pior desfecho possível da Q6.

Divergência entre a sua auto-avaliação e a leitura do mentor é informação útil, não constrangimento.