# Projetão — condutor de quests Você está ajudando um aluno do Projetão (CIn-UFPE). A disciplina se organiza em **10 quests semanais**. Cada quest tem perguntas próprias, um milestone de maturidade que alimenta, e um **modo de IA declarado**. ## Antes de qualquer coisa: três perguntas Não comece a produzir conteúdo. Descubra primeiro: 1. **Em que quest a equipe está?** (1 a 10 — a tabela abaixo) 2. **O que já existe?** Peça o material das quests anteriores. Uma quest sem lastro na anterior é retrabalho garantido. 3. **Qual o modo de IA desta quest?** Leia `metodo/modo-ia.md` e declare o modo em voz alta antes de trabalhar. 4. **Vai registrar pessoas?** Se a quest envolve foto, áudio, gravação de tela ou nome de terceiro, leia `metodo/consentimento.md` **antes** da ida — pedir depois não conserta. 5. **Em que formato e em quantos minutos a turma apresenta a quest?** Slides? Documento? Quadro? Quanto tempo cada equipe tem? A pergunta 5 existe porque **este material não sabe a resposta**. Ele diz "apresentação semanal" muitas vezes e nunca define o formato, porque isso varia por turma e por semestre — só o Demoday tem tempo fixo (8 minutos). Não invente: pergunte ao aluno, e se ele não souber, mande perguntar ao professor antes de montar qualquer coisa. Uma entrega ótima no formato errado é uma entrega ruim. Enquanto a resposta não vier, trabalhe pelo conteúdo — as perguntas da quest e o autodiagnóstico — e deixe a forma para o fim. Se o aluno não souber responder a 1, pergunte o que a equipe entregou na última semana e deduza. ## As 10 quests Cada quest é uma pasta com um `GUIA.md` e uma pasta `referencias/`. | # | Quest | Pergunta que ela responde | Pasta | |---|---|---|---| | 1 | Temáticas | Que assunto tem oportunidade de inovação de verdade? | `quests/q01-tematicas/GUIA.md` | | 2 | Oportunidades | Que dores concretas existem dentro dele? | `quests/q02-oportunidades/GUIA.md` | | 3 | Análise de Similares | Quem já tentou resolver, e o que falta? | `quests/q03-similares/GUIA.md` | | 4 | Oportunidade Escolhida & Equipe | Qual problema atacamos, e quem faz o quê? | `quests/q04-escolha/GUIA.md` | | 5 | Proposta Única de Valor | Que valor só nós entregamos? | `quests/q05-puv/GUIA.md` | | 6 | MVP & Prova de Conceito | Qual o menor produto que entrega esse valor? | `quests/q06-mvp/GUIA.md` | | 7 | Modelo de Receita | Como isso se paga? | `quests/q07-receita/GUIA.md` | | 8 | Prototipação & Usabilidade | O usuário consegue usar? | `quests/q08-prototipo/GUIA.md` | | 9 | Plano de Projeto | Como construímos até o Demoday? | `quests/q09-plano/GUIA.md` | | 10 | Preparação para o Demoday | Como isso é contado em 8 minutos? | `quests/q10-demoday/GUIA.md` | **Carregue apenas o `GUIA.md` da quest atual.** Não leia os dez. As `referencias/` dentro da pasta só devem ser abertas quando o `GUIA.md` daquela quest apontar para elas. ## Referências de apoio Puxe sob demanda, nunca por precaução: - `metodo/modo-ia.md` — **leia sempre**: os três modos de uso de IA e o que se avalia - `metodo/carga.md` — **leia antes de planejar a semana**: o mínimo e o desejável de cada quest - `metodo/visao-geral.md` — como as quests se encadeiam, vocabulário da disciplina - `metodo/avaliacao.md` — os 13 milestones, escala 0–5, avaliação 360° - `metodo/consentimento.md` — **leia antes da primeira ida a campo**: o que pedir antes de fotografar, gravar ou anotar nome de alguém - `tecnicas/` — entrevistas, personas, curva de valor, AEIOU, brainstorm, mapa de empatia… - `leituras/` — notas operacionais das obras da bibliografia ## A regra que atravessa as dez quests > Não projetamos para nós mesmos; projetamos para os outros. Traduzido em comportamento seu: **toda afirmação sobre o usuário precisa de evidência de campo.** Quando o aluno disser "as pessoas querem X", pergunte quantas pessoas ele ouviu, quando, e o que elas disseram literalmente. Se a resposta for suposição, diga isso e ajude a desenhar como sair a campo — não ajude a fabricar uma justificativa bonita. Esse é o erro que reprova projeto no Projetão, e é o erro que uma IA complacente ajuda a cometer mais rápido. ## O que você não faz - **Não escreve a entrega no lugar do aluno.** Você pergunta, critica, organiza e devolve. O aluno defende o resultado numa apresentação semanal. - **Não inventa dado de mercado, número de entrevista, nem citação.** Se falta evidência, o correto é dizer que falta. - **Não aceita ideia pronta.** Se o aluno chega com a solução decidida antes da Q4, o trabalho é destrinchar de que evidência ela nasceu. - **Não aprova por gentileza.** Perguntado "isso está bom?", responda o que você de fato observa — inclusive quando a resposta é que não dá para saber sem ouvir usuários. ## Fechamento de toda quest Antes de encerrar, faça o **autodiagnóstico**: leia em `metodo/avaliacao.md` o milestone que esta quest alimenta e peça ao aluno que se posicione na escala 0–5, com justificativa. Aprovação exige 4 em todos os milestones. Diga o nível que você observa e onde discorda dele. E peça o **registro de trajetória** — meia página: em que modo a quest foi feita, o que a IA gerou e o aluno descartou, o que ele verificou e como, e o que ainda não sabe. Peça o **artefato descartado colado junto**: descrever o descarte é barato, mostrar o que foi descartado não é. ⚠️ O registro de trajetória **não é exigência publicada da disciplina** (ver `metodo/avaliacao.md`). Ofereça-o como proteção da própria equipe, não como cobrança: quem tem a série de registros consegue mostrar o que fez; quem não tem, discute contra impressão. Se a equipe quiser saber o que é cobrado na apresentação, a resposta está com o professor — não aqui. **Antes de tudo isso, pergunte quanto tempo o aluno tem.** Se for menos que a semana, monte o plano pelo núcleo declarado em `metodo/carga.md` e diga o que ficou de fora. Nunca corte o piso de campo. --- # Avaliação — como o Projetão mede um projeto Quatro instrumentos rodam em paralelo: o **modelo de maturidade** (semanal, diagnóstico), a **avaliação do projeto** (final, nota), a **avaliação 360°** (dos pares, ajuste individual) e o **registro de trajetória** (semanal, o que separa o aluno da máquina). ⚠️ **Três são regra; o quarto é recomendação.** Modelo de maturidade, avaliação do projeto e avaliação 360° são o que a página `avaliacoes` do site da disciplina descreve. O **registro de trajetória** — e com ele a **regra do lastro** e a **pré-expectativa**, mais abaixo — é recomendação deste material, não regra publicada. Nada aqui substitui o enunciado do professor: se ele não pediu, não é exigência. Está aqui porque o problema que ele resolve é real, e porque a equipe que o adota sozinha se protege: O quarto existe por um motivo declarado: > **Se a máquina fabrica o produto, avaliar o produto mede a máquina.** Os três primeiros instrumentos avaliam o **artefato**. Sozinhos, eles medem cada vez menos o aluno — e essa é a razão de o quarto existir. Ver `modo-ia.md`. --- ## 1. Modelo de maturidade — 13 milestones, escala 0–5 Acompanhado **semanalmente**. Não gera nota: gera diagnóstico. Serve para a equipe saber onde está frágil enquanto ainda dá tempo de consertar. **Aprovação exige nível 4 em todos os 13.** Um projeto com doze cincos e um dois não está pronto. ### A escala | Nível | Significado | |---|---| | **0** | O critério ainda não aparece no projeto. | | **1** | Já aparece, mas sem clareza nem coerência. Normal na primeira vez que o tema é tocado. | | **2** | Falta clareza **ou** falta coerência com o resto. A resposta ainda está no terreno da insegurança. | | **3** | Coerente, mas ainda não totalmente claro. Há amadurecimento, resta uma parcela de incerteza. | | **4** | Claro e coerente com toda a proposta. Ainda cabe aperfeiçoar, mas a equipe responde com segurança. | | **5** | Perfeitamente alinhado ao conjunto. As respostas às questões de projeto são sólidas. | O salto que trava a maioria das equipes é o **3 → 4**: sair de "faz sentido" para "eu sustento isso sob pergunta". Quase sempre o que falta não é redação — é evidência de campo. > ⚠️ **A escala tem um ponto cego, e ele piora com IA.** Do 3 para cima, a diferença entre os níveis é descrita em termos de *clareza*, *coerência* e *segurança na resposta* — exatamente as qualidades que um texto bem gerado exibe sem que nenhum trabalho tenha sido feito. Um nível 5 escrito por máquina é mais elegante que um nível 4 escrito por quem foi a campo e voltou confuso. > > **Por isso, do 4 para cima o nível exige artefato, não redação.** Ver a regra do lastro, logo abaixo. ### A regra do lastro ⚠️ *Recomendação deste material — não é regra publicada da disciplina. Ver o aviso no topo.* Para pontuar **4 ou 5** em qualquer milestone, a equipe precisa apresentar, junto com a resposta, **pelo menos um artefato de trabalho** — algo que existe porque o trabalho foi feito, e que não seria produzido por quem apenas escreveu bem sobre ele. | Vale como lastro | Não vale | |---|---| | Foto do campo, com data | Descrição do que foi observado | | Áudio ou anotação bruta de entrevista | Resumo da entrevista | | Nome e contato de quem foi ouvido (com consentimento) | "Entrevistamos 14 pessoas" | | Post-its ou quadro de afinidades fotografado | A conclusão do agrupamento | | Gravação de tela do teste de usabilidade | Lista de problemas encontrados | | Link e captura da fonte do dado, com data de acesso | O número citado | | Registro de pré-expectativa datado (ver abaixo) | A afirmação de que houve surpresa | ⚠️ **O lastro é material de terceiros — trate-o como tal.** Foto, áudio, gravação de tela e contato pertencem a quem foi ouvido, não à equipe. Antes de coletar qualquer um deles, leia `consentimento.md`. E o lastro **não circula**: ele fica no repositório da equipe, e o professor o consulta ali, quando avalia. Não vai para o slide, não vai para o grupo da turma, não entra em documento que sai da disciplina. Quem promete "só a minha equipe e o professor" e depois publica um trecho quebrou a promessa que fez em campo. Lastro não precisa ser bonito nem organizado. Precisa ser **anterior à conclusão** e **custoso de fabricar**. ### A pré-expectativa — o único registro que não dá para forjar depois ⚠️ *Recomendação deste material — não é regra publicada da disciplina. Ver o aviso no topo.* Antes de ir a campo, a equipe escreve **o que espera encontrar**, e envia — com carimbo de data — para o canal da disciplina. Uma frase por item basta. Isso custa dez minutos e resolve o problema mais difícil da avaliação: *retroativamente, qualquer um consegue escrever que foi surpreendido.* Ninguém consegue escrever, antes, uma expectativa que depois se prove errada de um jeito específico. Na apresentação, a equipe compara o que escreveu com o que achou. **A divergência é o dado.** Equipe cuja pré-expectativa bateu 100% ou não foi a campo, ou não observou. ### Os 13 critérios | Milestone | Do que trata | Começa na quest | |---|---|---| | **Usuário** | Clareza sobre quem é o usuário/consumidor potencial | Q2 | | **Problema** | Compreensão do problema efetivo que se tenta resolver | Q3 | | **Similares** | Profundidade sobre concorrentes, práticas e boas referências | Q3 | | **PUV** | Identificação de um valor único a entregar, como centro da inovação | Q5 | | **Solução** | Maturidade da proposta e de como ela resolve o problema | Q6 | | **Prova de conceito** | Validação da solução conceitual junto ao usuário | Q6 ⚠️ | | **MVP / Implementação** | Amadurecimento do produto mínimo que entrega os valores validados | Q6 | | **Estratégias de tração** | Como a equipe se aproxima e constitui um grupo de usuários afoitos | Q7 | | **Tração efetiva** | Transformação em negócio real; divulgação e promoção | Q7 | | **Testes de usabilidade** | O que a equipe aprendeu testando, e como a solução mudou | Q8 | | **Plano de projeto** | Organização da equipe, processo produtivo, divisão de responsabilidades | Q9 | | **Modelo de receitas** | Custos, preço, formas de obter recursos | Q7 | | **Pitch** | Clareza para quem não acompanhou o projeto por meses | Q10 | > ⚠️ **Correção de numeração.** A planilha de maturidade publicada no site do Projetão foi escrita quando a disciplina tinha **9 quests**. Depois entrou a Q4 (Oportunidade Escolhida & Organização da Equipe) e tudo de Q4 em diante deslocou uma casa. A tabela acima já está **corrigida para as 10 quests atuais**. Se você comparar com a planilha original, verá as referências antigas — a diferença é essa, não é erro seu. > ⚠️ **Um milestone mudou de lugar por decisão, não por renumeração.** A planilha original põe **Prova de conceito** na quest anterior — que, pelo deslocamento acima, seria a **Q5**. Aqui ela está na **Q6**, porque a Q6 se chama literalmente "MVP & Prova de Conceito" e é onde a validação com usuário acontece. Todos os outros doze milestones seguem o deslocamento de +1 exato; este é o único em que houve escolha. Se o seu professor cobrar a prova de conceito já na Q5, siga o professor — e saiba que a diferença é esta. ### Índices de saúde da equipe Registrados junto com os milestones: - **Tamanho da equipe** — quantos alunos a compõem - **Presença** — quantos estão na apresentação - **Engajamento** — a razão entre os dois Engajamento é o melhor preditor isolado de projeto que termina mal. Queda sustentada nesse índice antecede, com regularidade, entrega incompleta no Demoday. Se a sua equipe está caindo, isso é um problema de projeto — não de frequência. --- ## 2. Registro de trajetória — o que separa o aluno da máquina Entregue **junto com cada quest**. Meia página. É o instrumento que responde "por que isso está certo?" em vez de "o que você entregou?". ### O que ele contém 1. **Modo de IA** em que a quest foi feita, e onde vocês saíram dele. 2. **O que a IA gerou e vocês descartaram — e por quê.** 3. **O que vocês verificaram, e como.** Que afirmação foram conferir na fonte primária? 4. **O que ainda não sabem.** ### Como ele é lido — e por que não basta escrevê-lo bem Este registro é, sozinho, o item mais fácil de fabricar do material inteiro: descrever com elegância o erro de uma IA é justamente a tarefa em que a IA é boa. Uma equipe pode produzir um registro convincente sem ter descartado nada. Três coisas tornam isso caro, e as três são baratas de exigir: **Lastro no item 2.** "Descartamos a persona que a IA propôs" não vale nada. **Cole a persona descartada.** O artefato descartado é gratuito para quem descartou de verdade e trabalhoso para quem não descartou. **Rastro no item 3.** "Conferimos o dado na fonte" não vale nada. **Diga qual afirmação, qual fonte, qual data de acesso, e o que estava diferente do que a IA disse.** Verificação que não achou nenhuma divergência em dez semanas é verificação que não aconteceu. **Consistência ao longo do semestre.** Este é o mecanismo mais forte, e é praticamente gratuito. As dez quests se encadeiam: o usuário afoito da Q4 tem de ser um dos ouvidos na Q2; os concorrentes da Q3 têm de aparecer na curva da Q5; a base de testes da Q9 tem de ser gente citada antes. **Fabricar dez semanas coerentes entre si custa mais que fazer o trabalho** — e a incoerência aparece sozinha na comparação. > **Não se avalia um registro de trajetória isolado. Avalia-se a série.** ### O que a disciplina não faz - **Não usa escore de detector de IA como prova.** Detectores erram de forma desigual: num teste com redações do **TOEFL** escritas por humanos, sete detectores classificaram como geradas por IA **61%** das redações de quem não é falante nativo de inglês, contra **5%** das de nativos (Liang, Yuksekgonul, Mao, Wu & Zou, *GPT detectors are biased against non-native English writers*, arXiv:2304.02819, 2023 — publicado em *Patterns*). ⚠️ O estudo mede texto em inglês; não há medida equivalente para português, e um contra-estudo do ETS com detectores mais recentes encontra viés menor (Jiang, Bosch, Attali & LaFlair, *Do AI detectors discriminate against non-native English writers?*, ETS Research, 2024). O ponto que sustenta a decisão não depende do número exato: **detector produz suspeita, não prova**, e o erro não se distribui por igual. - **Não trata declaração de não-uso como mecanismo de controle.** Além de não ser cumprida pela maioria, expõe justamente quem declara com honestidade. E uma coisa dita em voz alta, porque fingir o contrário seria pior: **o modo 🔴 sem assistência não tem fiscalização.** Nada impede um aluno de abrir outra aba. O que sustenta o modo não é vigilância — é o fato de que, sem o campo, ele não terá lastro para pontuar 4, e a incoerência entre as quests vai aparecer. O modo é um contrato, e o custo de quebrá-lo é diferido, não imediato. --- ## 3. Avaliação do projeto — nota 0 a 10 Feita pelos professores sobre o projeto ao final da disciplina. Considera: - **Completude** — da concepção até a execução e o pleno funcionamento - **Inovação** — a solução precisa trazer inovação na sua elaboração - **Especificidades** — cada disciplina tem exigências próprias que precisam aparecer - **Resultados** — qualidade do trabalho, levando em conta o amadurecimento ao longo do semestre e as considerações da banca no Demoday - **Trajetória** — a série de registros semanais: o que a equipe descartou, o que verificou, e o quanto o projeto mudou por causa de evidência O último critério é o que traz o processo para dentro da nota. Sem ele, a avaliação final mede o artefato — e o artefato, hoje, pode vir de qualquer lugar. A **banca do Demoday** é formada por profissionais do mercado. Ela influencia a nota, mas não a determina: julga o resultado apresentado, sem ter acompanhado o processo de aprendizado do semestre. Cada equipe tem um **professor mentor**, que acompanha de perto e atua como advogado da equipe na avaliação — ele é quem conhece as dificuldades que o resultado final não mostra. E é ele quem tem a série completa de registros de trajetória. --- ## 4. Avaliação 360° — ±2 pontos Cada aluno avalia **cada colega da própria equipe** em três dimensões: - **Engajamento** — atenção dada ao trabalho, envolvimento, colaboração nas tarefas - **Produtividade** — quanto cada um trabalhou e entregou - **Convivência** — o quanto as relações têm sido colaborativas, respeitosas e fluidas O resultado **soma ou subtrai até 2 pontos** sobre a nota de projeto do grupo, individualizando a nota de cada aluno. **Como o cálculo funciona, e por que isso importa:** o valor é calculado sobre o **desvio do aluno em relação à média da própria equipe** — não em relação a uma régua absoluta. Consequências práticas: - Avaliar todo mundo com nota máxima não beneficia ninguém: se todos estão na média, todos ficam em zero de ajuste. - Numa equipe que trabalhou bem por igual, o ajuste tende a zero — o que é o resultado correto. - Numa equipe desequilibrada, o instrumento separa. É desenhado para isso. --- ## Autodiagnóstico ao fim de cada quest Faça o exercício antes que ele seja feito por outros: 1. Que milestone esta quest alimenta? 2. Em que nível de 0 a 5 você se coloca? 3. **Qual artefato sustenta esse nível?** — se a resposta é "acho que ficou bom", o nível é 2. Se é um texto bem escrito e nada mais, o teto é 3. 4. O que faltaria para chegar a 4? Divergência entre a auto-avaliação da equipe e a leitura do mentor é informação útil, não constrangimento. Equipe que se dá 5 no que o mentor vê como 2 tem um problema anterior ao do projeto. --- # Carga de trabalho — o mínimo e o desejável Leia isto **antes** de planejar a semana. Vale para o aluno e para a IA que o acompanha. --- ## O problema que esta página resolve O material das quests descreve o trabalho **bem feito**. Se você tentar executar tudo o que cada quest sugere, vai gastar entre 12 e 30 horas por semana. ⚠️ **A referência de orçamento usada nesta página é uma premissa, não um dado da disciplina.** Assumimos **8 a 12 horas por aluno por semana**, o que corresponde a uma disciplina de 4 a 6 créditos. O site do Projetão não publica carga horária, e a palavra "crédito" não aparece em nenhuma das suas páginas. Confirme o número com o professor: se o seu for outro, os cortes desta página mudam junto. Quando o material pede mais do que cabe, o aluno não corta proporcionalmente. **Ele corta o campo** — porque o campo é a parte que ninguém vê, e a leitura é a parte que dá vocabulário para escrever uma entrega que parece boa. É exatamente o comportamento que a disciplina existe para impedir. Por isso cada quest tem, aqui, um **mínimo declarado**. > **Se você tiver de cortar, corte leitura e profundidade — nunca o campo.** --- ## A regra de três camadas Toda quest se divide em três: | Camada | O que é | Se faltar tempo | |---|---|---| | **Núcleo** | O que produz a evidência. Sem isso a quest não existe | **Nunca corte** | | **Estrutura** | O que organiza a evidência em resposta | Simplifique o formato, não o conteúdo | | **Profundidade** | Técnicas adicionais, leitura de referência, refinamento | Corte primeiro, e declare que cortou | Declarar o corte não tira ponto. **Fingir que não cortou, sim** — porque a incoerência aparece na quest seguinte. --- ## Por quest Os tempos são por **aluno**, numa equipe que dividiu o trabalho. O piso de campo é por **equipe**. | Quest | Núcleo — não corte | Piso de campo | Núcleo (h) | Com profundidade (h) | |---|---|---|---|---| | **Q1 Temáticas** | 1 ida a campo, registro estruturado, personas rastreáveis, 1 dado externo conferido | 1 visita de 2h, 2 lugares por equipe | 5–6 | 14–17 | | **Q2 Oportunidades** | Entrevistas até parar de aprender, com registro; 1 gambiarra observada; árvore de problema | **10 entrevistas por equipe** (não por aluno) | 6–8 | 14–18 | | **Q3 Similares** | "Como você resolve hoje?" a campo; lista com valores × funcionalidades; 1 vazio identificado | 5 pessoas confirmando as alternativas | 5–6 | 10–14 | | **Q4 Escolha** | Ranqueamento por dor e alcance; usuário afoito nomeado; jornada atual | 3 conversas de confirmação | 5–7 | 12–16 | | **Q5 PUV** | Curva dos concorrentes; matriz ERRC com "eliminar" preenchido; PUV em 1 frase testada | **5 pessoas ouvindo a frase** | 5–7 | 12–16 | | **Q6 MVP & PoC** | Escopo mínimo justificado; 1 prova de conceito barata testada | **5 pessoas na PoC** | 8–12 | 20–30 | | **Q7 Receita** | Custos com o trabalho incluído; ponto de equilíbrio; preço perguntado a clientes | **5 clientes no teste de preço** | 5–7 | 13–17 | | **Q8 Prototipação** | **Construir o protótipo navegável** + teste com tarefas, pensar em voz alta, os 3 problemas mais sérios | **3 usuários por rodada**, ao menos 2 rodadas | 9–14 | 20–28 | | **Q9 Plano** | Cronograma com donos; caminho crítico; base de testes contatada | 5 pessoas confirmadas na base | 4–6 | 12–15 | | **Q10 Demoday** | Roteiro de 8 min ensaiado cronometrado; demo com plano B; limitações declaradas | 1 ensaio com plateia externa | 5–7 | 10–14 | **Q6 e Q8 são as quests mais pesadas do semestre**, e por motivos diferentes: a Q6 concentra a decisão de escopo, a Q8 constrói o artefato testável **e** o testa na mesma semana. As saídas legítimas: - **Q6** — escolher uma prova de conceito que não exija construir (encenação, papel, concierge), ou dividir a construção em duas semanas e declarar isso no plano. - **Q8** — começar o protótipo na semana da Q7, em paralelo; ou reduzir o escopo do navegável a **um único fluxo** (o da PUV) em vez da interface inteira. O que **não** dá para cortar é o teste: protótipo não testado não produz achado, e é o achado que a quest cobra. ⚠️ **Não planeje a Q8 pela estimativa da Q6.** Quem faz isso chega ao dia do teste sem o que testar. ### Duas semanas em que o núcleo ocupa a semana inteira Some as colunas: o núcleo da **Q6** é 8–12 h e o da **Q8** é 9–14 h, contra as 8–12 h de orçamento assumido acima. Nessas duas semanas **não sobra margem** — o mínimo inegociável já é a semana toda, ou mais. Isso não é erro de conta: é a característica dessas duas quests, e dizê-la em voz alta vale mais que uma estimativa confortável e falsa. As consequências práticas: - **Planeje as duas com antecedência de uma semana.** O escopo do MVP na Q6 e o protótipo na Q8 são as únicas coisas do semestre que dá para adiantar sem furar o método. - **Distribua entre a equipe.** Os números da tabela são **por aluno**; numa equipe de cinco, construir o protótipo é trabalho paralelizável, ir a campo também. O que não paralela é a decisão. - **Se estourar mesmo assim, corte leitura e profundidade a zero nessas duas semanas** — e diga isso na apresentação. Entregar o núcleo e declarar o que ficou de fora vale mais que entregar tudo pela metade. - **Não corte o campo.** Vale aqui como vale nas outras oito. --- ## O que "piso de campo" significa É o mínimo abaixo do qual a quest **não tem evidência**. Pela regra do lastro, sem evidência o teto do milestone é nível 3, por mais bem escrita que esteja a entrega (⚠️ recomendação deste material, não regra publicada — ver `avaliacao.md`). Mesmo onde ela não vigora, o piso continua valendo pelo motivo original: entrega sem campo não tem o que defender na apresentação. O piso é sempre **por equipe**, não por aluno. Numa equipe de sete, dez entrevistas são uma ou duas por pessoa. E o piso não é meta: o critério real é **parar quando você para de aprender** — quando consegue prever o que a pessoa vai dizer com duas perguntas de qualificação. Se isso acontecer com sete, pare em sete e diga por quê. Se não tiver acontecido com trinta, você ainda não terminou. --- ## Como declarar um corte Uma linha no registro de trajetória, no item 4 ("o que ainda não sei"): > Cortamos a análise de auditoria de experiência da Q3 por falta de tempo. Ficamos com a lista de alternativas e a tabela de valores. Consequência: não sabemos onde a experiência do concorrente quebra, só o que ele entrega. Se isso importar na Q5, voltamos. Isso custa trinta segundos e faz três coisas: mostra que a equipe sabe o que deixou de fazer, protege a coerência das quests seguintes, e dá ao mentor a informação de que ele precisa para calibrar. --- ## Para a IA que acompanha Quando o aluno pedir ajuda com uma quest, **pergunte quanto tempo ele tem** antes de propor o roteiro completo. - Se ele tem a semana inteira, use a quest como está. - Se ele tem menos, monte o plano a partir da coluna **Núcleo** desta tabela, e diga explicitamente o que ficou de fora e qual a consequência. - **Nunca** proponha cortar o piso de campo. Se o tempo não dá para o campo, o problema é de planejamento da equipe, não de escopo da quest — e a resposta certa é remarcar, não substituir campo por raciocínio. Se o aluno disser que não vai dar tempo de ir a campo, **não preencha o buraco com plausibilidade.** Diga que a entrega vai ficar com teto de nível 3, e ajude a planejar a semana seguinte. --- # Consentimento e dados de terceiros Este material manda você fotografar pessoas em campo, gravar entrevistas, gravar tela de teste de usabilidade e registrar nome e contato de quem foi ouvido. Tudo isso é **dado de outra pessoa**. Ela não é sua colega de equipe nem parte do projeto: ela cedeu meia hora do dia dela. O que segue é o mínimo para que a coleta seja honesta. Não é assessoria jurídica, e não substitui o que o professor ou o comitê de ética da instituição determinar. Se o seu projeto envolve **saúde, crianças e adolescentes, população em situação de vulnerabilidade, dados de pessoas identificáveis em contexto sensível ou qualquer forma de dado que possa expor alguém**, pare aqui e pergunte ao professor antes de ir a campo. --- ## A regra curta **Pergunte antes, em voz alta, e aceite o não.** Três frases, ditas no começo da conversa, resolvem a maior parte dos casos: > "Sou aluno da UFPE, estou fazendo um trabalho de disciplina sobre *[tema]*. Posso te fazer umas perguntas por uns 20 minutos?" > > "Posso gravar só o áudio, para eu não perder nada? Fica com a minha equipe e com o professor da disciplina, que confere o trabalho; ninguém mais ouve, e eu apago no fim do semestre." > > "Se em algum momento você quiser parar, ou quiser que eu tire alguma coisa, é só falar." Se a pessoa hesitar na segunda, **não grave** — anote. Uma entrevista anotada vale mais que uma gravação que a pessoa cedeu constrangida. --- ## O que muda conforme o registro | Registro | O que fazer | |---|---| | **Anotação escrita** | Avise que está anotando. Não registre nome completo se não precisar dele. | | **Áudio** | Peça na hora, com a gravação **ainda desligada**. Comece a gravação pedindo de novo, agora gravado: assim o consentimento fica no próprio arquivo. | | **Foto de pessoa identificável** | Peça. Se for espaço público e a pessoa não é o assunto (multidão, movimento do lugar), enquadre de modo que ela não seja identificável. | | **Foto de lugar, objeto, fila, cartaz** | Livre, desde que não capture rosto, documento nem tela com dado de alguém. | | **Foto de gambiarra** | **Peça.** Gambiarra quase sempre documenta alguém contornando uma regra do próprio trabalho — o exemplo canônico da disciplina é discutir caso clínico por WhatsApp. A pessoa é identificável pelo contexto mesmo sem aparecer, e a foto pode custar o emprego dela. Fotografe só com permissão, e descreva sem nomear o local se houver qualquer risco. | | **Vídeo ou gravação de tela em teste de usabilidade** | Peça explicitamente e diga o que vai ser gravado (a tela e a voz, não o rosto — é o padrão, e basta). | | **Nome e contato** | Só colete se você **vai** usar: para voltar a falar com a pessoa, ou para o professor conferir. Guarde separado das respostas. | --- ## Observação em espaço público Observar o movimento de uma praça, de uma fila, de um ginásio não exige pedir permissão a cada pessoa — mas exige três cuidados: 1. **Não registre rosto, placa, crachá, documento ou tela alheia** sem pedir. 2. **Se alguém perguntar o que você está fazendo, responda a verdade.** Você é aluno, está fazendo um trabalho, e vai embora. Observador que se esconde perde o direito de estar ali. 3. **Se o lugar tem dono ou responsável** — comércio, escola, posto de saúde, empresa —, apresente-se a ele antes. Entrar sem avisar e depois ser descoberto queima o campo para você e para as próximas turmas. --- ## Campo virtual A Q1 diz que **espaço virtual conta**, e boa parte das técnicas tem versão à distância. As regras mudam: | Situação | O que fazer | |---|---| | **Observar comunidade online** (grupo, fórum, comentários) | Ler é uma coisa; **reproduzir** é outra. Não cole print com nome de usuário, foto de perfil ou texto que identifique alguém. Parafraseie, ou peça autorização à pessoa. Grupo fechado não é espaço público: entrar para pesquisar sem dizer a que veio é o mesmo que observar escondido. | | **Chamada de vídeo** | Peça para gravar **antes** de apertar o botão, e de novo já gravando. Diga se o rosto entra ou só a voz. Ferramenta que transcreve sozinha também é gravação: avise. | | **Teste de usabilidade remoto** | Grave tela e voz, não a câmera. Lembre a pessoa de fechar aba, notificação e qualquer coisa pessoal antes de compartilhar a tela — a responsabilidade de avisar é sua. | | **Formulário** | Não peça dado que você não vai usar. Se pedir e-mail ou telefone, diga para quê, e não torne obrigatório. | | **Print de conversa** (WhatsApp, chat) | É dado de duas pessoas, não de uma. Peça às duas, ou tarje. | --- ## A pessoa pode mudar de ideia depois Consentimento não é assinatura que encerra o assunto. Se a pessoa procurar você depois da conversa e pedir para retirar o que disse, ou apagar a gravação, **atenda** — mesmo que já esteja na entrega. Diga isso a ela no começo: > "Se depois você quiser que eu tire alguma coisa, me avisa que eu tiro." Guarde um jeito de encontrar o material dela: se você não sabe qual gravação é de quem, não consegue cumprir a promessa. --- ## E a lei No Brasil vale a **LGPD** (Lei 13.709/2018). Você não precisa virar especialista, mas três noções mudam decisões concretas: - **Dado pessoal** é o que identifica alguém — nome, telefone, e-mail, imagem, voz, e também o que identifica **por combinação** ("o enfermeiro do turno da noite daquele posto"). - **Dado sensível** — saúde, origem racial ou étnica, convicção religiosa, opinião política, filiação sindical, vida sexual, biometria — tem regra mais estrita. Se o seu projeto encosta nisso, fale com o professor **antes** de coletar. - **Finalidade e prazo:** você coleta para o trabalho da disciplina, e apaga no fim do semestre. Usar depois para outra coisa — um artigo, uma startup, um portfólio — é outra finalidade e exige pedir de novo. ⚠️ Isto é orientação de bolso, não parecer jurídico. Em dúvida, pergunte ao professor. --- ## Quem não pode consentir sozinho - **Menores de 18 anos:** o consentimento é de quem responde por eles. Se o seu projeto é sobre adolescentes, isso não é detalhe de execução — é uma restrição de escopo que muda o cronograma. Fale com o professor **antes da Q1**. - **Pessoa em situação de dependência em relação a você** (seu funcionário, seu aluno, alguém que espera algo de você): o "sim" dela não é livre. Procure outra pessoa. - **Pessoa que não entendeu o que você pediu.** Se você não conseguiu explicar em duas frases o que vai fazer com o material, o problema é seu, não dela. --- ## Enquanto o material existe - **Guarde no lugar da equipe, não no seu celular pessoal** — e num lugar em que quem saiu da equipe deixa de ter acesso. - **Não publique bruto.** Nem no repositório do projeto, nem no slide do Demoday, nem no grupo da turma. Na apresentação vai o **achado**, não a gravação; se for indispensável mostrar um trecho, peça de novo à pessoa, especificamente para isso. - **Anonimize na entrega.** "Jorge, 53 anos, usuário do parque" é persona. "Jorge Silva, (81) 9xxxx-xxxx, mora na rua tal" é dado pessoal e não entra em documento que circula. - **Apague no fim do semestre.** Diga isso à pessoa no começo, e depois cumpra. --- ## O que a IA não faz aqui Este é um ponto em que a máquina não ajuda, e tentar usá-la piora: - **Não peça à IA que invente a fala de um entrevistado**, nem para "completar" uma entrevista curta. Se você tem cinco minutos de conversa e precisa de vinte, volte a campo. - **Não cole gravação nem transcrição com nome, contato ou dado de saúde de terceiro** numa ferramenta de IA sem saber o que ela faz com aquilo. Anonimize antes: troque nomes por iniciais, tire telefone e endereço. - **Transcrever e organizar o que a pessoa disse** é uso legítimo (🟡 com apoio). **Escrever o que ela teria dito** não é uso: é invenção de evidência, e é o erro que mais desqualifica um projeto. --- ## O teste de uma frase Antes de registrar qualquer coisa, pergunte-se: > **Se essa pessoa visse depois o que eu guardei, e onde guardei, ela se sentiria enganada?** Se a resposta for "talvez", peça de novo — agora explicando a parte que você não explicou. --- ## Fontes - **IDEO**, *HCD Toolkit* (pt-BR) — a fase *Ouvir*: apresentar-se, explicar o propósito e pedir permissão antes de registrar - **Holtzblatt, Wendell & Wood**, *Rapid Contextual Design* — o acordo explícito com o participante no começo da sessão de indagação contextual - **Steve Krug**, *Não me faça pensar* / *Rocket Surgery Made Easy* — a prática de gravar tela e voz, não rosto, e de avisar o participante do que está sendo gravado. Krug vai além e prescreve um **formulário de autorização de gravação, assinado antes da sessão**; num trabalho de disciplina o pedido verbal gravado costuma bastar, mas se a sessão vai ser gravada em vídeo, ou o material pode sair da equipe, use o formulário - **Lei 13.709/2018 (LGPD)** — as noções de dado pessoal, dado sensível, finalidade e prazo - ⚠️ O restante deste arquivo é **orientação da disciplina**, não regra publicada no site do Projetão nem parecer jurídico. Em projeto que envolva população vulnerável ou dado sensível, a palavra final é do professor e do comitê de ética da instituição. --- # Modo de IA — como esta disciplina trata o uso de inteligência artificial Leia isto antes de trabalhar em qualquer quest. Vale para o aluno e para a IA que o acompanha. ## A premissa **Todo aluno usa IA.** Não é concessão nem tolerância — é o ponto de partida da disciplina. Nenhuma atividade do Projetão é desenhada fingindo que a IA está fora da mesa. Disso decorrem duas consequências que mudam o trabalho. **A régua sobe.** Se a máquina faz em minutos o que antes levava uma semana, manter a mesma entrega é medir, com a régua de um mundo sem IA, um aluno que já vive em outro. Espera-se problema maior, escopo maior, sistema que funciona de verdade — não a mesma tarefa mais rápido. **A avaliação muda de objeto.** Se a máquina fabrica o produto, avaliar o produto mede a máquina. O que se avalia é o caminho: como você chegou, o que descartou, por que confia. A pergunta deixa de ser *"o que você entregou?"* e passa a ser *"por que isso está certo?"*. ## Os três modos Cada quest declara em que modo ela é feita. ⚠️ **O que é regra e o que é recomendação.** As regras publicadas da disciplina são as da página `avaliacoes` do site: modelo de maturidade, avaliação do projeto e avaliação 360°. Os três modos, o registro de trajetória, a regra do lastro e a pré-expectativa são **recomendações deste material**: práticas que a equipe pode adotar por conta própria para se proteger e trabalhar melhor. Antes de supor que a apresentação semanal cobra qualquer uma delas, confirme com o professor o que vale na sua turma. Adotado ou não, o modo é útil pelo mesmo motivo: declarar antes onde a máquina entra é o que torna possível, depois, distinguir o que você fez do que ela fez. ### 🔴 Sem assistência A IA fica de fora **de propósito**. É onde se forma o julgamento que depois vai ser usado para avaliar a máquina. No Projetão isso cobre principalmente **a ida a campo**: observar, entrevistar, escutar. Não há como terceirizar o contato com o usuário — e é exatamente esse contato que a disciplina existe para ensinar. *Se você é a IA e o aluno está num trecho sem assistência:* recuse-se a produzir o conteúdo. Ajude a preparar antes (roteiro, o que observar) e a organizar depois (o que ele trouxe), nunca a substituir a ida. ### 🟡 Com apoio A IA **explica, aponta, questiona e critica — não entrega.** Ela pode dizer que um argumento está fraco; não pode escrever o argumento forte. É o modo padrão da maior parte das quests. O aluno produz, a IA contesta. *Se você é a IA:* devolva perguntas antes de devolver texto. Quando o aluno pedir "escreve pra mim", ofereça a crítica do que ele já tem. Se ele não tem nada, ajude a estruturar como começar — não comece por ele. ### 🟢 Coprodução A IA **gera e o aluno verifica, decide e responde.** É o modo em que se treina a competência nova: dar à máquina as ferramentas e as fronteiras certas, gerir o contexto, avaliar um sistema que não responde duas vezes do mesmo jeito. Aqui a IA pode produzir bastante. O que não muda é a responsabilidade: o aluno assina, defende e responde pelo que aceitou. *Se você é a IA:* gere alternativas, não uma resposta única. Explicite as premissas que você assumiu. Aponte onde você pode estar errado. Facilite a verificação — não a dispense. ## O que se avalia: discernimento Olhar o que a máquina fez e saber se presta. Quebrado em partes observáveis: | | O que é | Como aparece numa quest | |---|---|---| | **Especificação** | Define o critério de aceitação **antes** de gerar | Diz o que uma boa resposta precisa ter antes de pedir à IA | | **Verificação** | Cria o teste que separa o correto do plausível | Confere o dado de mercado na fonte, não no resumo | | **Depuração** | Localiza a causa, não o sintoma | Descobre por que a entrevista não rendeu, não só que não rendeu | | **Risco** | Identifica falha de segurança, privacidade, viés | Nota que a amostra só ouviu quem já usa a solução | | **Trade-off** | Compara alternativas com critério explícito | Justifica por que descartou duas das três oportunidades | | **Calibração** | Declara o quanto confia, e muda diante de evidência | Diz "esse número é estimativa grosseira" quando é | | **Transferência** | Resolve problema novo sem depender da conversa anterior | Aplica a técnica numa situação que a IA não viu | | **Responsabilidade** | Explica o que aceitou, o que recusou e o que ainda não sabe | Sustenta a entrega na arguição | ## O registro de trajetória Toda entrega de quest vem acompanhada de um registro curto — **meia página basta**: 1. **Modo** em que a quest foi feita, e onde você saiu dele (se saiu). 2. **O que a IA gerou e você descartou** — e por quê. Este é o item mais informativo dos quatro. 3. **O que você verificou** e como. Que afirmação você foi conferir na fonte? 4. **O que ainda não sabe.** Incerteza declarada não tira ponto; incerteza escondida, sim. Não é burocracia de controle. É o material sobre o qual a nota é formada — e o único jeito de o mérito do aluno aparecer quando o artefato poderia ter saído de qualquer lugar. ## O que a disciplina não faz - **Não usa escore de detector de IA como prova.** Detectores erram de forma desigual: num teste com redações do **TOEFL** escritas por humanos, sete detectores classificaram como geradas por IA **61%** das redações de quem não é falante nativo de inglês, contra **5%** das de nativos (Liang, Yuksekgonul, Mao, Wu & Zou, *GPT detectors are biased against non-native English writers*, arXiv:2304.02819, 2023 — publicado em *Patterns*). ⚠️ O estudo mede texto em inglês; não há medida equivalente para português, e um contra-estudo do ETS com detectores mais recentes encontra viés menor (Jiang, Bosch, Attali & LaFlair, *Do AI detectors discriminate against non-native English writers?*, ETS Research, 2024). O ponto que sustenta a decisão não depende do número exato: **detector produz suspeita, não prova**, e o erro não se distribui por igual. - **Não trata declaração de não-uso como mecanismo de controle.** Além de não ser cumprida pela maioria, expõe justamente quem declara com honestidade. O que substitui os dois é mais trabalhoso e é o que forma: avaliar o processo e o raciocínio. ## Duas obrigações que valem nos dois sentidos **Acesso.** Assumir que todo aluno usa IA e deixar cada um arcar sozinho com a ferramenta converteria capacidade de pagamento em desempenho. A disciplina se compromete a viabilizar acesso por modelos gratuitos, quotas e parcerias. Se você está sem acesso, isso é problema da disciplina, não seu — avise. **Custo.** Use o modelo adequado à tarefa, não o maior por reflexo, e declare a escolha quando ela for relevante. Formar alguém para usar bem uma tecnologia inclui formá-lo para perguntar quanto ela custa — e não apenas em dinheiro. --- *Baseado no manifesto do Porto Digital sobre formação em tecnologia na era da IA (Residência Tecnológica, 2026). A adoção no Projetão está em curso: o que funcionar e o que não funcionar será medido e publicado.* --- # Visão geral — como as quests se encadeiam ## De onde vem O Projetão é um framework de projeto de inovação criado e desenvolvido na UFPE desde 2002, idealizado originalmente pelos professores **Geber Ramalho** e **Cristiano Araújo** (Centro de Informática), **Luciano Meira** (Psicologia) e **André Neves** (Design). A disciplina reúne estudantes de cursos diferentes em equipes que precisam se auto-gerenciar, e termina num evento público — o **Demoday** — onde os projetos são apresentados a uma banca de profissionais do mercado. O princípio de ensino que organiza tudo é "aproximar a sala de aula do mundo real": formar quem **acha o problema**, e não apenas quem executa a ideia de outra pessoa. *Origem, fundadores e princípio conforme o site institucional da disciplina (projetao.cin.ufpe.br), consultado em agosto de 2026.* ## A lógica das dez quests Cada quest responde a uma pergunta, e a resposta de uma é insumo da seguinte. Pular etapa não economiza tempo — desloca o retrabalho para mais adiante, quando ele custa mais caro. ``` ┌─ DIVERGE: sair a campo e ampliar ────────────┐ Q1 Temáticas .................... que assunto? Q2 Oportunidades ................ que dores? Q3 Análise de Similares ......... quem já tentou? └──────────────────────────────────────────────┘ ▼ Q4 Oportunidade Escolhida ....... ⚠️ CHECKPOINT — converge para UMA ▼ ┌─ CONSTRÓI: da aposta ao produto ─────────────┐ Q5 Proposta Única de Valor ...... que valor só nosso? Q6 MVP & Prova de Conceito ...... menor produto que entrega Q7 Modelo de Receita ............ como se paga? Q8 Prototipação & Usabilidade ... o usuário consegue usar? └──────────────────────────────────────────────┘ ▼ ┌─ ENTREGA ────────────────────────────────────┐ Q9 Plano de Projeto ............. como chegamos lá Q10 Preparação para o Demoday .... como isso é contado └──────────────────────────────────────────────┘ ``` **Q1 a Q3 divergem.** O trabalho é ampliar: mais lugares, mais pessoas, mais problemas, mais alternativas. Fechar cedo aqui é o erro que mais reprova projeto. **Q4 converge.** É checkpoint formal — os professores validam a escolha contra as evidências. Daqui em diante a equipe tem um problema só. **Q5 a Q8 constroem.** Da aposta de valor ao produto testado com gente. **Q9 e Q10 entregam.** Planejar a execução e contar a história. ## Quem alimenta quem | Se você está na… | precisa ter fechado… | e vai alimentar… | |---|---|---| | Q2 | os lugares e personas da Q1 | a escolha da Q4 | | Q3 | os 2–3 problemas da Q2 | a PUV da Q5 | | Q4 | os similares e vazios da Q3 | tudo o que vem depois | | Q5 | a oportunidade e o usuário afoito da Q4 | o escopo do MVP na Q6 | | Q6 | a PUV e a curva de valor da Q5 | o preço da Q7 e o teste da Q8 | | Q7 | o MVP da Q6 | de volta ao escopo do MVP | | Q8 | o MVP definido na Q6 e o efeito do preço da Q7 — **o protótipo é construído aqui**, não antes | as mudanças no plano da Q9 | | Q9 | tudo o que ainda falta construir | o que dá para demonstrar na Q10 | | Q10 | o produto e os números | a banca | Se você chegou a uma quest sem o insumo dela, o correto não é improvisar — é voltar. ## Vocabulário da disciplina Termos com sentido específico aqui. Usar com o sentido corrente gera confusão nas apresentações. | Termo | Significa | |---|---| | **Quest** | Uma das dez entregas semanais da disciplina. Cada uma tem perguntas próprias e uma apresentação. | | **Temática** | Assunto amplo dentro do qual se procuram oportunidades. Não é o projeto. | | **Problema / dor** | Algo que incomoda significativamente — a ponto de a pessoa pagar ou adotar solução. **Não** é ausência de software. | | **Gambiarra** | Solução improvisada que compensa a falta de solução adequada. Sua presença valida **a dor** — não a disposição a pagar —, e só conta se a pessoa estiver insatisfeita com ela. | | **Usuário × Cliente** | Usuário usa; cliente paga. Podem ser pessoas diferentes, com expectativas diferentes. | | **Similares** | Concorrentes + referências. | | **Concorrente** | Quem desempenha **função** semelhante — não quem se parece materialmente. | | **Referência / inspiração** | Solução de outro domínio que entrega valor de um jeito que interessa. Informa primeiro **o quê** e **quanto vale**; usá-la como molde do *como* produz curva convergente. | | **Valor** | Benefício percebido, tangível ou intangível. **Não** é funcionalidade. | | **PUV** | O valor que só a sua solução entrega. | | **Vantagem de lascar** | O que não pode ser facilmente copiado ou comprado. Diferente da PUV. | | **Usuário afoito** (*early adopter*) | Quem topa usar antes de estar pronto porque a dor é forte — **e tem, ou consegue, orçamento**. Ver a escala de cinco degraus na Q4. | | **MVP** | Produto mínimo **viável** — escopo pequeno, produto inteiro. | | **PoC** | Prova de conceito: teste barato, antes do MVP, de que o usuário vê valor. | | **Curva de valor** | Gráfico comparando produto e concorrentes pelos **fatores de competição** do setor — não só funcionalidades: preço, canal, marca e serviço entram. Ordem das ações: **eliminar → reduzir → elevar → criar**. | | **ARM** | Aquisição, Retenção, Monetização. | | **Milestone** | Um dos 13 critérios de maturidade, medidos de 0 a 5. | | **Demoday** | Evento final de apresentação, com banca do mercado. | ## As frases que atravessam tudo Três eixos, na redação canônica. Se você encontrar outra redação em algum material, esta é a que vale. > **Não projetamos para nós mesmos; projetamos para os outros.** > **Toda afirmação sobre o usuário precisa de evidência de campo.** > **Se a máquina fabrica o produto, avaliar o produto mede a máquina.** E duas formulações da disciplina que dizem a mesma coisa por outro ângulo: - **A competência mais importante é identificar problemas e resolvê-los** — não ser a mão que executa a ideia de um cliente. - **Não é a convicção de alguém, mas a demonstração empírica com base em evidências, que define o caminho do projeto.** ## Uma nota sobre a numeração A metodologia já teve **9 quests**. A Q4 atual (Oportunidade Escolhida & Organização da Equipe) foi acrescentada depois, como checkpoint, e tudo de Q4 em diante deslocou uma posição. Material antigo — inclusive a página de Visão Geral e a planilha de maturidade publicadas no site — ainda usa a numeração de 9. Esta skill está inteiramente na numeração atual de **10 quests**. Se você encontrar divergência entre um material da disciplina e o que está aqui, é provavelmente isso. Ver `avaliacao.md` para o mapeamento corrigido dos 13 milestones. --- # AEIOU Framework **Para quê:** categorizar e interpretar observações de campo. **Quests:** 1, 2 · **Modo:** 🔴 sem assistência no campo, 🟡 com apoio na análise ## O que é Um jeito estruturado de fazer e registrar observações de pessoas e suas atividades em contexto. Serve para que a observação não vire um caderno de impressões soltas. ## Origem Criado por **Rick Robinson, Ilya Prokopoff, John Cain e Julie Pokorny**, no **Doblin Group**, em Chicago, em **1991**, a partir da análise de uma quantidade enorme de horas de gravação das interações de pessoas numa rede de lanchonetes — dos dois lados do balcão. Agrupar e categorizar aquele volume foi tão difícil que se criou um sistema de observação para viabilizar a análise. É esse o problema que o AEIOU resolve: **volume de observação sem estrutura é inanalisável.** ⚠️ **Correção ao material do site.** A página da disciplina credita o método apenas a Rick Robinson, nos anos 1990. A atribuição completa é a acima (Hanington & Martin, *Universal Methods of Design*). ## As cinco categorias | | | Perguntas | |---|---|---| | **A** | Atividades | Quais as ações e comportamentos das pessoas? Quais seus objetivos? | | **E** | Ambientes | Em que ambiente acontecem? As atividades são adequadas àquele espaço, ou estão fora de contexto? | | **I** | Interações | Que interações ocorrem entre as pessoas para que atinjam seus objetivos? Que efeitos as atividades e o espaço produzem nelas? | | **O** | Objetos | O que constitui o ambiente? Que objetos são usados e amparam pessoas, atividades e interações? | | **U** | Usuários | Quem são as pessoas observadas? Como é sua personalidade? Como lidam com quem está em volta? | ## Como aplicar Monte uma tabela de cinco campos e anote em cada um o que observar, conforme a categoria. Ao fim da observação os dados já saem razoavelmente estruturados para análise. **Na prática:** leve a tabela impressa ou no celular e preencha *durante*, não depois. O campo E costuma ser o mais abandonado e é o que mais rende — objeto fora de lugar e atividade em espaço inadequado são pistas fortes de gambiarra. O que for levantado em **U** alimenta diretamente as `personas.md`. ## Erro comum Preencher as cinco colunas com conclusões em vez de observações. "Ambiente mal projetado" vai na sua análise, não na tabela. Na tabela vai "quatro pessoas em pé, três cadeiras vazias do outro lado da sala". --- ## Fontes - **Hanington & Martin**, *Universal Methods of Design* — origem, autoria completa e as cinco categorias (o **E** original é *Environments*) - Página `tecnicas/aeiou` do site da disciplina — o relato da rede de lanchonetes e as perguntas de cada categoria - Ver **Observação de campo — Quest #1** (`../quests/q01-tematicas/referencias/observacao-de-campo.md`) para posturas de observação, indagação contextual e efeito Hawthorne --- # Blue Ocean Strategy **Para quê:** orientar o desenvolvimento de produto inovador em relação à concorrência. **Quest:** 5 · **Modo:** 🟡 com apoio ## A ideia Em vez de competir num mercado existente disputando os mesmos atributos que todos os concorrentes disputam — o "oceano vermelho", tingido pela concorrência —, criar um espaço onde a comparação direta deixa de fazer sentido. Isso não se faz sendo melhor em tudo. Faz-se **escolhendo uma combinação diferente de atributos**: abrir mão do que o setor considera obrigatório e investir onde ninguém investe. ## O instrumento: a grade de quatro ações Sobre cada atributo do setor, pergunte: | Ação | Pergunta | |---|---| | **Eliminar** | Que atributos que o setor considera indispensáveis devem ser eliminados? | | **Reduzir** | Quais devem ser reduzidos bem abaixo do padrão? | | **Elevar** | Quais devem ser elevados bem acima do padrão? | | **Criar** | Que atributos nunca oferecidos pelo setor devem ser criados? | As duas primeiras são as que geram a inovação de custo — e são as que quase toda equipe pula. Um produto que só soma atributos custa mais que o dos concorrentes e não cabe num semestre. ## Como se conecta ao Projetão A Q5 pede a **curva de valor** (ver `curva-de-valor.md`). A ordem das quatro ações é **eliminar → reduzir → elevar → criar** — os cortes antes dos acréscimos. A convenção didática da disciplina acrescenta o **preço como primeiro fator do eixo**, para obrigar a decidir posicionamento antes de sonhar com funcionalidade; isso não é regra do livro, e está explicado em `../quests/q05-puv/SKILL.md`. A Q6 repete o exercício, agora sobre o próprio produto, e é ali que a grade vira escopo de MVP. ## Materiais da disciplina Aula *Blue ocean strategy*, de Geber Ramalho. Bibliografia: *A estratégia do oceano azul*, de W. Chan Kim e Renée Mauborgne. --- ## Fontes - **Kim & Mauborgne**, *A estratégia do oceano azul* — a grade das quatro ações (eliminar, reduzir, elevar, criar) e a inovação de valor - Páginas `tecnicas/blueocean` (⚠️ quase vazia no acervo capturado) e `MetQ5` do site da disciplina --- # Brainstorm **Para quê:** gerar alternativas em grupo. **Quests:** 4 a 10 · **Modo:** 🟢 coprodução — com uma ressalva importante ## O que é Método tradicional de ideação: técnica para elaborar novas ideias em grupo, separando deliberadamente o momento de **gerar** do momento de **julgar**. ## As regras clássicas 1. **Adiar o julgamento.** Nenhuma crítica durante a geração. 2. **Buscar quantidade.** Volume primeiro; qualidade se seleciona depois. 3. **Acolher ideia estranha.** É de onde vem o que ninguém mais teria. 4. **Combinar e melhorar** as ideias dos outros. As quatro acima são as de Osborn. A disciplina acrescenta uma quinta, de condução: 5. **Um assunto por vez**, e uma pergunta bem formulada. A regra 1 é a que mais se quebra, e quebrá-la mata a sessão em cinco minutos. ## A ressalva da era da IA Pedir 50 ideias a um modelo generativo é trivial, e o resultado tem uma característica traiçoeira: é **plausível e médio**. O modelo produz o centro da distribuição — exatamente o oposto do que o brainstorm existe para encontrar. Use a IA aqui de dois jeitos que funcionam: - **Depois** da geração humana, para ampliar e combinar o que a equipe produziu. - Como **provocação enviesada**: peça ideias sob restrição forte ("e se fosse ilegal usar tela?", "e se o usuário tivesse 8 anos?", "e se o orçamento fosse zero?"). Restrição é o que tira o modelo — e as pessoas — da média. O que não funciona: gerar a lista pronta e escolher da lista. A equipe passa a escolher entre opções que ninguém entende profundamente. ## Alternativa quando o grupo é desigual Ver `brainwriting.md`. Em equipe onde algumas pessoas dominam a fala, o brainwriting produz mais e melhor. --- ## Fontes - **Alex Osborn** — as regras clássicas, via **Hanington & Martin**, *Universal Methods of Design*, que datam *Your Creative Power* em **1948** e a 3ª edição de *Applied Imagination* em **1993**; a página do site situa o método na "década de 1950" - Página `tecnicas/brainstorm` do site da disciplina - A ressalva sobre uso de IA na geração é da disciplina, não das fontes acima --- # Brainwriting **Para quê:** gerar alternativas sem que a dinâmica de grupo distorça o resultado. **Quests:** 4 a 6 · **Modo:** 🔴 sem assistência na rodada silenciosa, 🟡 com apoio depois ## O que é Variação do brainstorm, criada por **Bernd Rohrbach**, em que as ideias são **escritas**, não faladas, e circulam entre os participantes para serem desenvolvidas. ## Por que existe O brainstorm falado tem dois problemas conhecidos: quem fala mais influencia demais, e quem tem menos status social no grupo se autocensura. Numa turma de Projetão, com equipes multidisciplinares e formações diferentes, isso é frequente — e o efeito é que a ideia do mais falante vira a ideia da equipe. Escrever antes de falar neutraliza os dois. ## Como rodar (formato 6-3-5) 1. Enuncie **uma** pergunta clara e visível para todos. 2. Cada participante escreve **3 ideias** em uma folha, em silêncio, em **5 minutos**. 3. Passa a folha para o colega ao lado. 4. Cada um lê as 3 ideias recebidas e escreve **mais 3**, ampliando, combinando ou contrapondo. 5. Repita até a folha voltar ao dono. Com seis pessoas, a folha volta ao dono depois de **seis** passagens: 6 × 3 × 6 = **108 ideias em cerca de meia hora**, todas com autoria distribuída. (Se você parar em cinco rodadas, são 90 — o número muda com o tamanho do grupo, e é a rotação completa que fecha o exercício.) ## Depois Agrupe por semelhança, elimine duplicatas, e só então discuta. A discussão fica melhor porque todos já pensaram sozinhos antes de ouvir os outros. ## Quando preferir ao brainstorm - Equipe nova, que ainda não se conhece - Equipe com diferença marcada de senioridade ou de curso - Tema em que alguém já tem posição forte declarada - Sessão remota (onde o brainstorm falado degrada muito) --- ## Fontes - Página `tecnicas/brainwriting` do site da disciplina — o método, o formato **6-3-5** e o crédito a **Bernd Rohrbach**, seu criador - ⚠️ *Universal Methods of Design* **não traz brainwriting**; não o cite como fonte deste método. O efeito do falante dominante e a autocensura por status são leitura da disciplina sobre por que a variação escrita existe. - Página `tecnicas/brainstorm` do site da disciplina — o brainstorm falado, do qual esta é a variação escrita - O ajuste ao tamanho de equipe do Projetão é da disciplina --- # Curva de Valor **Para quê:** identificar os valores nos quais o produto deve se focar. **Quests:** 5, 6 · **Modo:** 🟡 com apoio ## O que é Ferramenta da Blue Ocean Strategy que compara, num mesmo gráfico, o **desempenho dos concorrentes e o do seu produto** ao longo de um conjunto de atributos. Através dela é possível entender qual deve ser o foco inovador, de forma a criar algo **mais simples e enxuto e ao mesmo tempo mais eficaz** em entregar o que o usuário deseja. ## As duas regras que a disciplina destaca **1. O eixo X traz fatores de competição, não valores abstratos.** A curva mostra **como o valor é implementado e disputado**. "Conveniência" não é ponto do eixo; "entrega em 24h" é. ⚠️ **Correção ao material do site, e uma ressalva sobre o termo.** A página da disciplina diz "funcionalidades". O livro diz **atributos** — "o eixo horizontal representa a variedade de atributos nos quais o setor investe e compete". *Fatores de competição* é **rótulo desta disciplina**, não expressão de Kim & Mauborgne; usamos porque deixa explícito o que "funcionalidades" esconde: preço, canal, marca, atendimento e esforço de marketing entram no eixo e não são funcionalidades de produto. O Cirque du Soleil eliminou **animais, astros e os três picadeiros** — nenhum é funcionalidade. Reduzir o eixo a funcionalidades empurra a equipe para o foco interno, que é o vício que a ferramenta existe para quebrar. **2. Respeite a ordem de montagem:** 1. **preço** 2. **o que vou eliminar** 3. **o que vou reduzir** 4. **o que vou elevar** 5. **o que vou criar** Do item 2 ao 5, é a grade **eliminar–reduzir–elevar–criar** do livro, nessa ordem: as duas ações de corte vêm antes das duas de acréscimo, senão a equipe só soma. ⚠️ **Origem.** Começar pelo **preço** é convenção didática da disciplina, não regra de Kim & Mauborgne. Ela existe porque o preço ancora todo o resto da curva. Não a cite como se fosse do livro. ## Como montar 1. Liste os atributos que o setor disputa. Três fontes, nesta ordem: a tabela de alternativas da Q3; as palavras que o **usuário afoito** usou; e as **alternativas fora do setor** — como o cliente atenderia à mesma necessidade por outro caminho. Não é a coluna de funcionalidades da Q3: preço, canal, marca e atendimento também entram. 2. Coloque o **preço como primeiro item** do eixo. 3. Dê uma nota de desempenho a cada concorrente em cada atributo. Escala simples (0 a 5) basta. 4. Ligue os pontos de cada concorrente: são as curvas deles. Onde elas se sobrepõem está o consenso do setor — e é ali que não há oportunidade. 5. Só então desenhe a sua, seguindo a ordem das cinco ações. ## Diagnóstico da sua curva - **Curva paralela à dos concorrentes, um pouco acima** → você fez "igual, mas melhor". Não é estratégia; é gasto. - **Curva só subindo** → você não excluiu nada. Não vai caber no semestre. - **Curva que mergulha em dois ou três atributos e sobe forte em um** → é o formato que se procura. ## Aviso A curva de valor é a peça que mais frequentemente é feita depois, para justificar uma decisão já tomada. Feita assim, ela não decide nada. Monte a dos concorrentes **antes** de decidir a sua. --- ## Fontes - **Kim & Mauborgne**, *A estratégia do oceano azul* — a matriz de avaliação de valor, os fatores de competição, os três critérios de uma boa curva e o caso Cirque du Soleil - Página `tecnicas/curvas` do site da disciplina — a ordem de montagem - ⚠️ Começar pelo preço é convenção da disciplina; a ordem eliminar→reduzir→elevar→criar é do livro --- # Usuário afoito (*early adopter*) **Para quê:** ter com quem validar antes de o produto existir. **Quests:** 4 a 9 · **Modo:** 🔴 sem assistência no contato ## O que são Todo produto conta com um pequeno grupo de pessoas que quer usá-lo ou experimentá-lo **antes de estar completo**. São os early adopters, ou usuários afoitos. São pessoas que enxergam mais rápido o **valor** da solução — seja porque estão mais envolvidas com os problemas que ela resolve, seja porque conhecem com profundidade as alternativas disponíveis e não se sentem contempladas por nenhuma. De um jeito ou de outro, dispõem-se a adotar uma solução ainda imperfeita, e podem contribuir para aperfeiçoá-la. ## O que NÃO são Não é "quem gosta de tecnologia", nem "estudantes universitários", nem qualquer faixa demográfica. O critério é **intensidade da dor**, não perfil. Regra prática do Projetão: quem você viu usando a **gambiarra** mais elaborada na Q2 é seu candidato mais forte. Quem já gasta energia contornando o problema é quem mais quer que ele suma. ## Como trabalhar com eles Mesmo sem protótipo, os usuários afoitos ajudam a desenhar características e atributos da solução. A forma mais simples de envolvê-los é **construir uma comunidade** — começando com pessoas próximas que se qualifiquem como potenciais usuárias, e agregando novos membros aos poucos. Manter diálogo permanente com essa comunidade — apresentando avanços e ideias, permitindo que experimentem o que está em desenvolvimento, observando o uso e consultando sobre o que acham — cria engajamento com o projeto. A comunidade se torna a **base de validação** da solução. ## Ao longo das quests Aparecem quando se definem os públicos (Q4) e vão até a organização do processo produtivo (Q9) e a base de testes. Toda decisão de projeto precisa ser validada com usuários — e são eles que tornam isso possível. ## Teste de realidade Se você não consegue listar **cinco pessoas com nome** que usariam sua solução amanhã do jeito que ela está, você ainda não tem usuário afoito. Tem público-alvo, que é outra coisa. --- ## Fontes - **Ash Maurya**, *Running Lean* — o usuário afoito definido por intensidade do problema, não por demografia - **Steve Blank**, *The Four Steps to the Epiphany* — os cinco degraus do earlyvangelist - Página `tecnicas/afoitos` do site da disciplina - Ver **O usuário afoito — Quest #4** (`../quests/q04-escolha/referencias/usuario-afoito.md`) para os degraus abertos um a um --- # Entrevistas **Para quê:** aprofundar as questões junto ao usuário. **Quests:** 2, 3, 4 — e eventualmente 6 e 7 · **Modo:** 🔴 sem assistência na condução, 🟡 com apoio no roteiro e na análise ## O que é Forma de obter informação com pessoas interessadas ou envolvidas no assunto do projeto. É o modo mais comum de pesquisa com usuários. ## Em que se baseiam Vêm das sondagens de audiência, intenção, gosto e opinião pública desenvolvidas ao longo do século XX pelos meios de comunicação de massa e por grandes corporações. Eram ferramentas de sociólogos e psicólogos comportamentais para colocar em prática a chamada **teoria hipodérmica** — influenciar comportamento de massa por estímulos pontuais aplicados a indivíduos isolados. Apesar dessa origem próxima de processos de manipulação e controle social — sobretudo na intersecção dos estudos sobre informação com a Cibernética de **Norbert Wiener** e com **Paul Lazarsfeld** —, a entrevista segue sendo mecanismo importante para entender pessoas, suas necessidades, suas formas de atribuir significado e valor, e sua prática e cultura. Conhecer a origem serve a um propósito prático: entrevista **é** um instrumento capaz de induzir a resposta que se quer ouvir. Saber disso é o que permite não fazê-lo. ## Modalidades **Entrevista estruturada** — questionário com perguntas previamente elaboradas, construídas para circunscrever e qualificar um assunto. As perguntas são desenhadas estrategicamente para avaliar algo específico e para **detectar resposta inconsistente** (o entrevistado não tem opinião formada, não entende o que responde, é falso-positivo, ou age de má fé), o que permite avaliar a confiabilidade dos dados. *Cuidado à distância:* um formulário distribuído numa rede social já impõe viés. Pesquisa sobre aversão à tecnologia divulgada no Facebook produz distorção óbvia. **Grupo de opinião (focus group)** — debate conduzido com várias pessoas em espaço fechado, para que as questões emerjam espontânea e organicamente pela interação. Revela questões menos óbvias. Costuma ser filmado — preferencialmente sem que os participantes se sintam constrangidos ou policiados — porque comportamento corporal, gesticulação e intensidade também são indícios. **Entrevista em profundidade / semi-estruturada** — com uma única pessoa, sem organização prévia das questões, construída em cima das próprias respostas. É diálogo, busca aprofundar questão já conhecida. Recomenda-se pesquisador experiente: depende da intimidade com o tema e da habilidade de formular perguntas pertinentes dinamicamente. Semi-estruturada porque, embora não haja formulário, é essencial haver **estratégia** para capturar o que se deseja investigar. **Cadernos de sensibilização** — forma indireta, para assunto sensível ou constrangedor (questões médicas, sexualidade, tabus). O entrevistado recebe um caderno previamente elaborado e o preenche onde se sinta à vontade, ao longo de dias ou meses, após breve orientação. Devolve ao pesquisador sem se identificar. **Sondas culturais (cultural probes)** — parecidas com os cadernos, mas o entrevistado recebe um kit de artefatos e é orientado a interagir com eles: anotações, colagens, customização. Dão abordagem mais lúdica e engajam mais quando o tema exige esforço criativo ou imaginativo. Podem ser entendidas como entrevista indireta e menos verbal. ## As duas armadilhas **Não peça a solução ao entrevistado.** "Qual a solução para este problema?" não produz a resposta — ele não tem obrigação de saber, e tem menos obrigação ainda de saber o que você quer descobrir. Se precisar testar direção, apresente opções e pergunte qual parece mais adequada, e por quê. **Não force concordância.** "Você gosta deste produto que meu grupo criou?" põe a pessoa numa posição em que ela evita ferir seus sentimentos. A resposta virá educada e inútil. ## O roteiro do Running Lean Para a Q2 e a Q6 há roteiros específicos e cronometrados — Problem Interview e Solution Interview. Ver `../leituras/running-lean/00-indice.md`. --- ## Fontes - Página `tecnicas/entrevistas` do site da disciplina — a origem histórica (sondagens de massa, teoria hipodérmica, Wiener e Lazarsfeld) e as modalidades - **Ash Maurya**, *Running Lean* — os roteiros cronometrados de entrevista de problema e de solução - **Holtzblatt, Wendell & Wood**, *Rapid Contextual Design* — a indagação contextual, que esta ficha **não** cobre; abra **Observação de campo — Quest #1** (`../quests/q01-tematicas/referencias/observacao-de-campo.md`) quando a conversa for durante o trabalho da pessoa, e não uma entrevista marcada --- # Jornada do Usuário **Para quê:** mapear o que acontece com o usuário ao longo de um período. **Quests:** 1, 2, 4 (jornada atual) e 6 (jornada nova) · **Modo:** 🟡 com apoio ## O que é Mapeamento do que acontece com o usuário ao longo de um período — as etapas, os pontos de contato, o que ele faz, sente e encontra pelo caminho. ## As duas jornadas do Projetão A disciplina pede a mesma técnica em dois momentos, com propósitos opostos: **Jornada atual (Q4)** — passo a passo de como ele resolve o problema **hoje**, sem a sua solução. É diagnóstico. Se ela estiver bonita demais, você não observou: jornada real tem espera, retrabalho e gambiarra. **Jornada nova (Q6)** — como a persona resolve o problema **usando o que vocês propõem**. É projeto. E é o teste mais honesto do MVP: se você não consegue descrever passo a passo, a solução ainda está vaga. Colocar as duas lado a lado é o slide mais eficiente do pitch da Q10. ## Como montar 1. Defina o recorte temporal — do gatilho até a resolução (ou a desistência). 2. Liste as etapas em ordem, na linguagem do usuário. 3. Para cada etapa: o que ele faz, com quem/o quê interage, quanto tempo leva, o que sente. 4. Marque os **pontos de dor** e os **momentos de decisão** (onde ele poderia desistir ou escolher outra coisa). 5. Some o tempo total. O número costuma surpreender e é ótimo material de pitch. ## Erro comum Mapear a jornada dentro do seu produto em vez da jornada do problema. A jornada começa antes de o usuário saber que você existe, e frequentemente termina depois que ele fecha o app. --- ## Fontes - **Stickdorn & Schneider**, *This Is Service Design Thinking* — jornada do usuário e pontos de contato - **Hanington & Martin**, *Universal Methods of Design* — variações do método (mapa de experiência, blueprint de serviço), que esta ficha não abre - Páginas `tecnicas/journey`, `MetQ4` e `MetQ6` do site da disciplina — o uso em dois momentos (jornada atual e jornada nova) --- # Lean Innovation **Para quê:** desenvolver inovação de forma enxuta. **Quests:** transversal, com peso em 4, 5 e 6 · **Modo:** 🟡 com apoio ## A ideia Filosofia que alia um negócio altamente focado às vantagens mercadológicas da inovação: em vez de planejar longamente e construir de uma vez, **documenta-se a hipótese, identifica-se o que é mais arriscado, e testa-se sistematicamente** — corrigindo o rumo com evidência. O princípio que organiza tudo: **desperdício é qualquer atividade que consome recurso e não cria valor.** Construir o que ninguém quer é a forma mais cara de desperdício num projeto de inovação. ## Os três passos 1. **Documente seu plano A.** Escrever a visão inicial e compartilhá-la com pelo menos outra pessoa. Hipótese que só existe na cabeça de quem a teve serve para reforçar a própria convicção. 2. **Identifique as partes mais arriscadas.** Priorização errada de risco é das maiores fontes de desperdício. 3. **Teste sistematicamente.** Converta hipótese em algo falseável, teste, e corrija. ## Por que isso importa no Projetão A metodologia das quests é uma implementação disso: a Q1 e a Q2 documentam o terreno, a Q3 e a Q4 identificam onde está o risco e escolhem por onde começar, e as quests seguintes testam — conceito na Q6, preço na Q7, usabilidade na Q8. O que a disciplina acrescenta e o lean puro não enfatiza: o campo vem **antes** da hipótese. Você não começa com o seu plano A; começa observando. ## Materiais Aula *Inovação*, de Geber Ramalho. Ver também `../leituras/running-lean/00-indice.md`, que é a versão operacional detalhada desta filosofia, e a bibliografia oficial (*A startup enxuta*, de Eric Ries). --- ## Fontes - **Ash Maurya**, *Running Lean* — os três passos (documentar o plano A, identificar as partes mais arriscadas, testar sistematicamente) - **Eric Ries**, *A startup enxuta* — o ciclo construir-medir-aprender, que sustenta a filosofia descrita aqui mas não é detalhado nesta ficha; ver **Running Lean — nota de leitura operacional** (`../leituras/running-lean/00-indice.md`) - **Womack & Jones**, *Lean Thinking* — a definição de desperdício, citada por Maurya - Página `tecnicas/lean` do site da disciplina --- # Mapa de Empatia **Para quê:** registrar o ponto de vista de quem atribui sentidos diferentes dos seus. **Quests:** 1, 2, 3 · **Modo:** 🟡 com apoio ## O que é Diagrama para registrar e entender o ponto de vista das pessoas para as quais se projeta — pessoas que atribuem **valores** e sentidos diferentes dos de quem projeta. ## Em que se baseia Nos princípios de **empatia** e **alteridade**. São diagramas usados por antropólogos em estudos etnográficos, na tentativa de mapear a origem dos sentidos que as pessoas observadas atribuem às coisas. Nas atividades de projeto isso se chama **escuta altruísta**: considerar tanto a alteridade — a diferença entre as pessoas, e entre o ponto de vista do projetista e o dos usuários — quanto se colocar no lugar delas para entender seus valores. ## Como preencher | Região | O que vai ali | |---|---| | **Superior** | O que o usuário **pensa e sente** sobre o assunto | | **Direita** | O que ele **vê** | | **Esquerda** | O que ele **ouve** a respeito | | **Inferior** | O que ele **fala e faz** | | **Canto inferior esquerdo** | **Dores** — o que o incomoda | | **Canto inferior direito** | **Necessidades e desejos** | Templates disponíveis em SVG, Miro e Figma no site da disciplina. ## Onde ele rende mais Na **divergência entre quadrantes**. Quando o que a pessoa *fala* não bate com o que ela *faz*, ou quando o que ela *ouve* contradiz o que ela *vê*, há uma tensão — e tensão é onde mora oportunidade. Mapa em que tudo é coerente costuma ser mapa preenchido de cabeça. Um mapa por persona. Mapa de "o usuário" em geral não serve para nada. --- ## Fontes - Página `tecnicas/EmpathyMap` do site da disciplina — os princípios de empatia e alteridade, e a **escuta altruísta** - **XPLANE** — o mapa de empatia é ferramenta dessa consultoria; **Osterwalder & Pigneur** o reproduzem em *Business Model Generation* creditando-a explicitamente ("a tool developed by visual thinking company XPLANE"), e não o reivindicam - ⚠️ O formato de quadrantes usado nesta ficha é o da página do site, não o de Osterwalder (que organiza em seis perguntas numeradas) - ⚠️ O **HCD Toolkit** da IDEO ensina a escutar, e é a leitura complementar natural — mas **não traz mapa de empatia**; a expressão não aparece nele --- # Microinterações **Para quê:** dar feedback ao usuário através do comportamento dos elementos. **Quests:** 6 (contenção) e 8 (conserto) · **Modo:** 🟢 coprodução ## O que são Pequenos comportamentos dos elementos da interface que produzem **feedback** para o usuário: o botão que reage ao toque, o campo que confirma que aceitou, a transição que mostra de onde veio o conteúdo novo. ## Por que importam Uma interface sem feedback deixa o usuário na dúvida sobre se sua ação teve efeito — e a dúvida produz repetição (clicar duas vezes), abandono ou desconfiança. A microinteração responde três perguntas silenciosas: *funcionou?*, *o que aconteceu?*, *onde eu estou agora?* ## Anatomia 1. **Gatilho** — o que inicia (ação do usuário ou evento do sistema) 2. **Regras** — o que acontece e sob que condições 3. **Feedback** — o que o usuário percebe 4. **Modo e ciclo** — o que muda se repetir, e o que permanece depois ## No Projetão Não é onde investir cedo. Numa Q6, microinteração é penduricalho — o que se cobra ali é o valor sendo entregue. Ela ganha importância na Q8, quando os testes revelam que o usuário **não percebeu** que algo aconteceu: esse é um problema de microinteração, e costuma ser barato de resolver. Sinal no teste de usabilidade: a pessoa clica duas vezes no mesmo botão, ou pergunta "deu certo?". É feedback faltando. ## Bibliografia *Designing Interface Animation*, de Val Head. --- ## Fontes - Página `tecnicas/microinteractions` do site da disciplina — o conceito e o porquê; ela se apoia em gestalt, ergonomia, usabilidade e comunicação - **Val Head**, *Designing Interface Animation* — a bibliografia declarada por aquela página - ⚠️ A anatomia em quatro partes (gatilho, regras, feedback, modos e ciclos) é vocabulário corrente da área, popularizado por Dan Saffer em *Microinteractions* (2013). **Esse livro não está no acervo da disciplina** e a página não o cita — não o apresente como fonte verificada aqui. - **Donald Norman**, *O design do dia a dia* — feedback, significantes e o Golfo da Avaliação - Página `tecnicas/microinteractions` do site da disciplina --- # Percepção de Valor **Para quê:** entender o conceito central da inovação. **Quests:** 3, 4, 5 · **Modo:** 🟡 com apoio ## Valor não é preço A primeira coisa que se pensa ao falar de valor é preço. Preço é uma forma de valor — mas apenas uma entre as diversas formas pelas quais atribuímos valor às coisas. **O conceito vai muito além.** ## Valor e novidade não são a mesma coisa Valor é central para a inovação porque **a inovação está justamente na mudança daquilo a que damos valor**. E assim como associamos valor a preço, associamos inovação a novidade — mas nem toda novidade é inovadora. **Muita novidade, pouco valor:** um avião particular com dez vezes mais autonomia é feito de engenharia e grande novidade no mercado de aviação. Mas tem quase nenhum valor para a maior parte das pessoas, que não tem recursos para possuir um avião — e provavelmente pouco valor até para quem tem, porque dar duas voltas no globo sem parada não é um requisito cobiçado. Aumentar autonomia é aperfeiçoar uma característica, não incorporar um valor novo. **Pouca novidade, muito valor:** mouse e teclado sem fio não têm nenhuma novidade frente às versões cabeadas — são exatamente os mesmos objetos, sem os fios. Mas liberdade de movimento, conforto e a sensação de não estar preso a cabos que enroscam são valores tão importantes que muita gente já não consegue trabalhar com equipamento cabeado. > **A inovação acontece quando se entrega valor junto com a novidade.** ## Valores são particulares — e é isso que cria o nicho Por valor entende-se atributos tangíveis e intangíveis desejáveis pelos usuários, **mesmo quando eles não sabem que existem**. Boa parte do encantamento com a inovação está justamente no reconhecimento de valores que a pessoa não sabia que desejava. Muitos são subjetivos — mais bonito, mais arrojado, mais sedutor — e ainda assim profundamente significativos. Como compartilhamos valores dentro de uma mesma cultura, existem grupos que valorizam as mesmas coisas. **Esses grupos são os nichos de mercado** para os quais soluções inovadoras são desenvolvidas: pessoas com necessidades e desejos comuns, que entendem certas características (ou suas ausências) como relevantes para suas vidas. ## A consequência prática Quando se entrega valor relevante, **muda-se o significado da solução**: ela deixa de ser mais um produto disponível e passa a ser algo essencial, sem o qual as atividades que ela medeia seriam completamente diferentes — e provavelmente piores. Como o desejo por determinados valores não é universal, conhecer bem o público específico é vital. > **Conhecer realmente bem o usuário é metade da solução de um projeto.** ## Uso operacional na Q3 e na Q5 Monte sempre **duas colunas separadas**: valor (o benefício percebido) e funcionalidade (o mecanismo que o entrega). Se as duas ficarem iguais, você preencheu funcionalidade nas duas. --- ## Fontes - Página `tecnicas/valores` do site da disciplina — valor além do preço, valor × novidade e os exemplos trabalhados - ⚠️ O corpo desta ficha é reescrita da página da disciplina. **Kim & Mauborgne** (inovação de valor) e **Tim Brown** (desejabilidade, viabilidade, exequibilidade) tratam do mesmo território e aprofundam, mas nada do que está escrito acima vem deles — consulte-os para ir além, não como lastro do que está aqui --- # Personas **Para quê:** tornar o usuário tangível para a equipe. **Quests:** 1, 2, 3 — e de novo em 6 e 10, como recurso narrativo · **Modo:** 🟡 com apoio ## O que é Representação dos usuários do projeto: um arquétipo, um personagem que sintetiza quem é o usuário — fruto da observação e da identificação de características e valores de quem vai usufruir do projeto. Elenca características, atividades, motivações, relações, opiniões, desejos e interesses, de modo que se pareça com uma pessoa real. ## Origem Técnica criada por **Alan Cooper** (*About Face*, *The Inmates Are Running the Asylum*). A intenção era tornar o usuário final uma figura próxima e tangível para a equipe de desenvolvimento: Cooper percebeu que equipes lidando com uma ideia abstrata de "usuário" — genérico, sem rosto, distante — se preocupavam pouco com suas necessidades e davam pouca atenção a como ele se sentiria usando o produto. Criar uma persona produz identificação entre projetistas e usuários, e isso aproxima — sobretudo no que diz respeito a entender como o usuário deseja que o produto seja e se comporte. ## Como construir Não há forma certa ou errada. Em geral: uma **foto**, um **nome**, idade, profissão e informações demográficas; e os interesses e relações que essa pessoa estabeleceria com o projeto. A página da disciplina relata que **na IDEO se imprimem usuários de corpo inteiro em dimensões reais e se fixam as imagens nas paredes das salas de reunião**, como se estivessem ali de pé, participando de cada decisão. ⚠️ A fonte é a própria página `tecnicas/Personas`; a prática **não consta de nenhum livro do acervo**, então trate como relato da disciplina, não como estudo. O princípio por trás dela é o que importa e esse se sustenta: a persona só serve se estiver **visível durante a decisão** — guardada num anexo, não muda nada. ## Dicas da disciplina - **Inclua personalidade, humor, gostos e interesses.** Ajuda a entender o que o usuário quer e como ele verá o projeto. - **Evite características depreciativas** ou que tornem a persona antipática. O objetivo é criar laço e afeição da equipe pelo usuário — nunca a sensação de que ele não merece o esforço. - **Não use ilustração, desenho ou foto de pessoa pública.** A persona precisa presentificar o usuário, não produzir uma relação de representação ou imaginação sobre ele. Você deve sentir que ele existe e é aquele ali na foto. - O diagrama não precisa ser sofisticado para funcionar — mas enriquecê-lo com informação que faz diferença no projeto o torna mais útil. ## Cuidado na era da IA Persona é o artefato mais fácil de gerar sinteticamente e o mais inútil quando é. Uma persona inventada por modelo generativo é a média estatística de textos sobre pessoas — exatamente o oposto do que a técnica existe para produzir. Se a IA ajudar a redigir, que seja **a partir das suas notas de campo**. E declare no registro de trajetória o que veio de observação e o que veio de preenchimento. --- ## Fontes - **Hanington & Martin**, *Universal Methods of Design* — persona construída a partir de dado, e o que a invalida - **IDEO**, *HCD Toolkit* (pt-BR) — a fase *Ouvir* e a síntese que antecede a persona (o Toolkit não usa o termo "persona") - Página `tecnicas/Personas` do site da disciplina — o formato e as dicas - ⚠️ O relato sobre a IDEO vem da página `tecnicas/Personas` da disciplina, não de livro do acervo --- # Vantagem de Lascar (Unfair Advantage) **Para quê:** entender o que impede que copiem você. **Quest:** 5 e seguintes · **Modo:** 🟡 com apoio ## O que é Aquilo que **não pode ser facilmente copiado ou comprado**. É a resposta à pergunta que a banca do Demoday costuma fazer: "e o que impede uma empresa grande de fazer isso na semana que vem?" ## Não confunda com a PUV - **Proposta Única de Valor** é o que você **promete** ao usuário. - **Vantagem de lascar** é o motivo pelo qual **outro não entrega a mesma promessa**. São coisas diferentes e a Q5 cobra a primeira. Mas apresentar a PUV como se fosse vantagem competitiva é um erro comum. ## O que não é vantagem de lascar - **Uma funcionalidade.** Copiável num sprint. - **Ser o primeiro.** Só vale se o pioneirismo se converteu em outra coisa (base de usuários, dado, marca). - **"Nosso time é muito bom."** Time se contrata. - **Tecnologia genérica.** Se está num tutorial, não é vantagem. ## O que costuma ser - **Comunidade** engajada, que não se transfere - **Dado acumulado** que melhora o produto com o uso - **Acesso privilegiado** — a um canal, a um parceiro, a um público - **Conhecimento de domínio raro**, obtido em campo e não disponível publicamente - **Efeito de rede** — o produto fica melhor a cada usuário novo - **Autoridade pessoal** de quem construiu ## Num projeto de semestre É aceitável **não ter ainda** — e é mais honesto dizer isso do que inventar. O que se espera é que a equipe saiba: (a) que não tem, (b) qual seria a candidata mais plausível, e (c) o que precisaria acontecer para construí-la. Frequentemente, num projeto do Projetão, a candidata real é o **conhecimento de campo**: você passou um semestre com um público que ninguém mais estudou. Isso é uma vantagem legítima, se souber nomeá-la. --- ## Fontes - **Ash Maurya**, *Running Lean* — o bloco *Unfair Advantage* do Lean Canvas e a advertência de que quase toda equipe deixa a caixa vazia - **Jason Cohen**, citado por Maurya — "o que não pode ser copiado nem comprado" - Página `tecnicas/unfairadvantage` do site da disciplina — ⚠️ no acervo capturado ela está praticamente vazia; o conteúdo desta ficha vem de Maurya e de `MetOverview` --- # Wireframe **Para quê:** planejar a interface antes de desenhá-la. **Quests:** 6 e 8 · **Modo:** 🟢 coprodução ## O que é Organização espacial e dimensionamento das interfaces — o esqueleto: o que fica onde, com que peso, em que ordem de leitura. Sem cor, sem tipografia definitiva, sem imagem final. ## Por que sem estética Porque a estética sequestra a conversa. Mostre um wireframe cinza e as pessoas discutem se a informação está no lugar certo; mostre a mesma tela colorida e discutem o tom do azul. Na fase em que você ainda está decidindo a estrutura, a segunda conversa é desperdício. Vale ainda mais agora que gerar interface bonita ficou barato: a facilidade de produzir alta fidelidade não é motivo para pular a estrutura. ## Como fazer 1. Liste as **tarefas** que o usuário precisa cumprir naquela tela (vem da jornada da Q6). 2. Ordene os elementos por importância para a tarefa — não por o que é fácil de posicionar. 3. Defina a hierarquia com **tamanho e espaço**, não com cor. 4. Deixe explícito o que é ação primária. Se há três botões do mesmo peso, não há ação primária. 5. Anote as regras que a tela não mostra: o que acontece no estado vazio, no erro, no carregamento. O item 5 é o mais esquecido, e estado vazio é a primeira coisa que todo usuário novo vê. ## Ligação com a Q8 O wireframe navegável é um ótimo material de teste de usabilidade — barato de mudar e sem inibir a crítica. Ver `../quests/q08-prototipo/SKILL.md`. --- ## Fontes - **Steve Krug**, *Não me faça pensar* — testar estrutura antes de estética - ⚠️ **Norman** (affordances e significantes) é a leitura seguinte, não a fonte desta ficha: nada aqui depende dele. Ele entra na Q8, em **Diagnóstico de erro — Quest #8** (`../quests/q08-prototipo/referencias/diagnostico-de-erro.md`) - Página `tecnicas/wireframe` do site da disciplina - A observação sobre geração barata de alta fidelidade é da disciplina --- # Quest #1 — Temáticas > **Objetivo.** Identificar temáticas potenciais que contenham oportunidades de inovação, para que os grupos possam ser formados. | | | |---|---| | **Modo de IA** | 🔴 sem assistência no campo · 🟡 com apoio no preparo e na síntese | | **Milestone** | nenhum ainda (*Usuário* abre na Q2) — mas esta quest é o alicerce de todos os 13 | | **Entrega** | levantamento de campo + personas + enquadramento em ODS | | **Erro que mais reprova** | chegar com a solução já decidida e usar o campo para confirmá-la | --- ## Antes de responder qualquer coisa Faça estas três perguntas ao aluno. Não comece a produzir conteúdo antes de tê-las respondidas: 1. **Você já foi a campo?** Se não, o trabalho agora é preparar a ida — não escrever a entrega. 2. **Você já tem um projeto em mente?** Se sim, é sinal de alerta. Ver *A armadilha da semana 1*. 3. **Sozinho ou em equipe temporária?** Na Q1 os grupos ainda não estão formados; a temática é que vai formá-los. --- ## A armadilha da semana 1 Esta quest **não é** definir seu projeto. É um levantamento preliminar de contextos e questões que existem **concretamente** — não fruto de suposição. Junto com o que as outras equipes trouxerem, ele vai ajudar a achar assuntos e públicos para aprofundar depois. Três formas que a armadilha assume: **"Já sei o que quero fazer, só preciso do campo para justificar."** Aí o campo vira caça a evidência confirmatória. É o oposto do exercício, e o resultado é reconhecível: nada te surpreende. **"Tenho um projeto de outra disciplina."** Não vale. É preciso aprender a escutar e observar, e ideia pronta impede isso. Você pode trazer algo interessante, mas refaz o processo do início: evidência, problema real, relevância, escala. **"O tema não me interessa."** Ver *Perguntas frequentes*. > A competência mais importante desenvolvida aqui é identificar problemas e resolvê-los. A disciplina existe para formar quem **acha** o problema — não a mão que executa a ideia dos outros. > > — material da disciplina (projetao.cin.ufpe.br) --- ## As perguntas da entrega **1. Qual a temática que a equipe resolveu investigar, e por quê?** **2. Por que ela é relevante? Como impacta a sociedade? A qual ODS se relaciona? Quais os principais desafios?** Precisa de **evidência** — artigo, reportagem, dado — mostrando que o assunto importa para alguém além de você. **3. Em que evidências vocês se baseiam? Conversaram com quem conhece o assunto? Fizeram pesquisa? O que mais chamou atenção?** **4. Que lugares poderiam ser visitados e que pessoas entrevistadas para aprofundar nas próximas quests?** E, a partir do levantamento: **personas** dos grupos observados, o que mais chamou atenção no lugar, e o que você acredita serem as questões mais importantes a tratar ali. > Ex.: Jorge, 53 anos. Mora perto do parque e usa o espaço regularmente para se exercitar. Tem 3 filhos, trabalha meio período e adora comer o abacaxi na saída do parque. Faça persona para **todo grupo que conseguir identificar** — comece pelos mais visíveis, depois complemente com os que passariam despercebidos. É frequente a inovação nascer justamente desses. --- ## O procedimento ### Antes de ir — 🟡 com apoio 1. **Escolha 2 ou 3 lugares**, um deles fora da sua zona de conforto. Ver *Onde observar*. 2. **Escolha a postura de observação.** Mosca-na-parede? Observador reconhecido? Participante? A escolha muda o que você consegue ver e o quanto você contamina a cena. → **Observação de campo — Quest #1** (neste arquivo) 3. **Monte a grade.** O AEIOU é o padrão da disciplina. → **Observação de campo — Quest #1** (neste arquivo) 4. **Defina o registro:** caderno, foto, áudio. Combine quem faz o quê. 5. **Escreva antes o que você espera encontrar.** Serve para medir depois o quanto o campo te surpreendeu — e campo que não surpreende foi mal observado. ### No campo — 🔴 sem assistência 6. **Observe antes de perguntar.** Fique tempo suficiente para o lugar parar de te notar. 7. **Separe fato de inferência.** "Três pessoas revezaram o mesmo banco em 20 minutos" é fato. "Falta assento" é inferência. Registre os dois, em colunas diferentes. 8. **Preste atenção nos papéis periféricos** — quem limpa, quem vende, quem espera, quem fiscaliza. 9. **Converse informalmente, sem roteiro.** Ainda não é a entrevista estruturada da Q2. 10. **Confirme suas interpretações ali mesmo**, com quem está no local. Interpretação não checada vira projeto errado. (princípio da indagação contextual) ### Depois — 🟡 com apoio 11. **Descarregue as anotações antes de dormir.** Memória de campo evapora em horas. 12. **Sintetize por afinidade** antes de tirar conclusão. → **Síntese e personas — Quest #1** (neste arquivo) 13. **Construa as personas a partir dos agrupamentos** — não do que você imagina. 14. **Busque evidência externa** para as questões que apareceram, e **confira na fonte**, não no resumo. 15. **Enquadre nos ODS** e escreva a entrega. → **ODS — enquadrar a temática sem forçar** (neste arquivo) --- ## Onde observar **Vá onde a atividade acontece.** Se te interessa inovar em atividade esportiva, vá a um ginásio; melhor ainda, a um lugar onde vários papéis convivem — um clube em dia de treino, com jogadores, técnicos, assistentes, imprensa e torcedores ao mesmo tempo. **Evite o óbvio e o familiar.** Shopping, praça de alimentação, sala de aula, laboratório. Em espaço que já frequentamos tendemos a não enxergar o que acontece — presumimos que conhecemos. É mais fácil ver com clareza onde não temos presunção. **Espaço virtual conta.** Mas o que importa não é o local: é o contexto, a situação, as dificuldades e os interesses das pessoas naquele cenário. Alguém operando na Bolsa — o relevante não é a Bolsa, é *de que maneira* essa pessoa faz isso. Na praia sob um guarda-sol? Num escritório, com assessor no telefone? É no cenário e nas questões em volta da atividade que moram os bons problemas. --- ## Referências desta quest Carregue conforme a necessidade — não leia todas de uma vez. | Arquivo | Quando | |---|---| | **Observação de campo — Quest #1** (neste arquivo) | Antes de ir a campo. Posturas de observação, AEIOU detalhado, indagação contextual, sondas culturais, efeito Hawthorne | | **Síntese e personas — Quest #1** (neste arquivo) | Depois do campo. Diagrama de afinidades, como construir persona a partir de dado, o que invalida uma persona | | **ODS — enquadrar a temática sem forçar** (neste arquivo) | No fechamento. Os 17 objetivos e como enquadrar sem forçar | | **Autodiagnóstico — Quest #1** (neste arquivo) | Antes de entregar. Rubrica 0–5 e os sinais de cada nível | --- ### Antes de registrar pessoas | Arquivo | Quando | |---|---| | `../../metodo/consentimento.md` | Antes de ir a campo. O que pedir antes de fotografar ou anotar nome de alguém | --- ### Técnicas desta quest Fichas curtas de consulta rápida. Abra quando o procedimento acima mencionar a técnica. | Ficha | Para quê | |---|---| | **AEIOU Framework** (neste arquivo) | grade de observação de campo | | **Personas** (neste arquivo) | arquétipos a partir do observado | | **Mapa de Empatia** (neste arquivo) | o que o usuário vê, ouve, fala e pensa | | **Jornada do Usuário** (neste arquivo) | o que acontece com ele ao longo do tempo | --- ## Perguntas frequentes **"Não me sinto motivado, o tema não me interessa."** Os temas saem da Q1 e são votados por todos — nenhum é imposto. Se o que te agrada não venceu, há três possibilidades: você não trouxe evidência de algo realmente interessante; a evidência não convenceu ninguém além de você (o que já indica que o tema não se sustenta); ou você quer trabalhar sobre algo que imagina, sem evidência. Nos três casos, a resposta é a mesma — sem evidência de relevância, não é caminho a seguir. Sobre motivação, vale separar duas coisas: o resultado do semestre, por melhor que fique, estará longe de um produto maduro. O que permanece é o aprendizado e a experiência. Um tema sem graça continua oferecendo isso por inteiro. **"Posso observar um espaço virtual?"** Pode. Ver *Onde observar*. **"Uma persona por grupo, ou só a mais comum?"** Todas que você conseguir identificar e enquadrar. **"Quanto tempo preciso ficar no local?"** Não há número oficial. Regra prática: até parar de anotar coisas novas. Se você saiu em 15 minutos com a folha cheia, provavelmente anotou o óbvio. --- ## Bibliografia desta quest | Obra | O que ela dá para a Q1 | |---|---| | **IDEO — HCD Toolkit** (pt-BR, integral) | A fase *Ouvir*: como se preparar, como escutar, como registrar | | **Hanington & Martin — Universal Methods of Design** | Os métodos de observação, um a um, com origem e quando usar | | **Stickdorn & Schneider — This Is Service Design Thinking** | Observação de serviço, jornada, pontos de contato | | **Holtzblatt, Wendell & Wood — Rapid Contextual Design** | A indagação contextual em detalhe: o modelo mestre/aprendiz | | **Maurya — Running Lean** (cap. 6) | O preparo para conversar com pessoas; ele terceiriza a observação para os títulos acima | | **Blank — The Four Steps to the Epiphany** | Customer discovery: por que sair do prédio vem antes de tudo | # Autodiagnóstico — Quest #1 Faça este exercício **antes** de entregar. Ele é o mesmo que o mentor vai fazer depois. --- ## A escala A Q1 não alimenta um milestone próprio — o primeiro, *Usuário*, abre na Q2. Mas ela é o alicerce de todos os 13, e a qualidade dela determina o teto das seguintes. Use a mesma escala 0–5 da disciplina: | Nível | Significado | |---|---| | **0** | O critério ainda não aparece. | | **1** | Já aparece, mas sem clareza nem coerência. Normal na primeira vez. | | **2** | Falta clareza **ou** falta coerência. A resposta ainda está no terreno da insegurança. | | **3** | Coerente, mas ainda não totalmente claro. Resta uma parcela de incerteza. | | **4** | Claro e coerente com toda a proposta. Ainda cabe aperfeiçoar, mas a equipe responde com segurança. | | **5** | Perfeitamente alinhado ao conjunto. As respostas são sólidas. | O salto que trava a maioria é o **3 → 4**: sair de "faz sentido" para "eu sustento isso sob pergunta". O que falta quase nunca é redação — é evidência de campo. --- ## Rubrica por dimensão ### 1. Ida a campo | | | |---|---| | **2** | Fomos a um lugar que já conhecíamos, ficamos pouco tempo, e conversamos com quem estava por perto. | | **3** | Fomos a um lugar novo e ficamos tempo razoável, mas não registramos de forma sistemática. | | **4** | Lugar novo, permanência até parar de anotar novidade, registro estruturado (AEIOU ou equivalente), com fato separado de inferência. | | **5** | O acima, mais uma segunda visita com postura diferente da primeira, e interpretações checadas com quem estava lá. | ### 2. Evidência de relevância | | | |---|---| | **2** | "É um problema conhecido", ou uma reportagem citada sem link. | | **3** | Fonte externa citada, mas genérica ou desatualizada — ou lida em resumo. | | **4** | Dado de fonte primária, com ano e link, **aberto e conferido**, que dimensiona o problema. | | **5** | O acima, mais o reconhecimento explícito de onde o dado não cobre o que vocês observaram. | ### 3. Personas | | | |---|---| | **2** | Perfis demográficos ("mulher, 25–34, classe B"). Não dá para apontar de que observação vieram. | | **3** | Personas com narrativa, mas parte foi preenchida por plausibilidade. | | **4** | Cada persona é rastreável a observações concretas; há padrões de comportamento, não só demografia; os grupos menos visíveis aparecem. | | **5** | O acima, mais contradições internas realistas e ao menos uma persona que vocês não esperavam encontrar. | ### 4. Enquadramento em ODS | | | |---|---| | **2** | Um número de ODS citado, sem meta, que serviria para qualquer projeto. | | **3** | ODS coerente com o tema, mas sem meta específica nem dado. | | **4** | ODS principal + meta numerada + dado que dimensiona a lacuna daquela meta. | | **5** | O acima, com a justificativa de por que **este** ODS e não o vizinho. | ### 5. Postura de investigação | | | |---|---| | **2** | O campo confirmou o que a equipe já achava. | | **3** | A equipe cita algo que aprendeu, mas o rumo geral não mudou. | | **4** | A equipe nomeia pelo menos uma coisa que a surpreendeu e mudou de ideia por causa dela. | | **5** | O acima, com registro do que se esperava encontrar **antes** da ida, para comparação. | --- ## Checklist rápido - [ ] Fui a um lugar onde **não** costumo estar? - [ ] Tenho registro do que **vi**, separado do que **concluí**? - [ ] Minhas personas vieram de pessoas observadas, ou são invenção plausível? - [ ] Consigo citar uma coisa que me **surpreendeu**? - [ ] A evidência de relevância é externa e verificável — e eu **abri** a fonte? - [ ] O enquadramento em ODS diz algo específico, ou serviria para qualquer projeto? - [ ] Listei lugares e pessoas concretas para a Q2, com nome? - [ ] Declarei o que ainda não sei? **Sinal de alerta:** se a sua temática coincide exatamente com o app que você já queria fazer antes da aula, volte ao campo. --- ## 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 Q1 o campo é 🔴 sem assistência. Se a IA participou da observação, isso precisa estar declarado — e provavelmente invalida o levantamento.* 2. **O que a IA gerou e você descartou — e por quê.** Este é o item mais informativo dos quatro. *Típico da Q1: a IA propõe personas plausíveis a partir do tema. Descartar e refazer a partir das notas é exatamente o comportamento esperado.* 3. **O que você verificou, e como.** *Típico da Q1: o dado de relevância. Diga qual afirmação você foi conferir na fonte primária.* 4. **O que ainda não sabe.** --- ## Como o mentor vai ler Três perguntas que aparecem com regularidade na apresentação da Q1. Se você tem resposta para as três, está em 4: 1. **"Quantas pessoas vocês observaram, onde, e por quanto tempo?"** Resposta fraca: "várias". Resposta forte: número, local, duração, e quantas visitas. 2. **"O que vocês esperavam encontrar e não encontraram?"** Não ter resposta indica que o campo foi confirmatório. 3. **"De onde veio esse número?"** Se a resposta for "eu vi numa matéria", a pergunta seguinte é qual matéria, e a seguinte é qual a fonte dela. Divergência entre a sua auto-avaliação e a leitura do mentor é informação útil, não constrangimento. Equipe que se dá 5 no que o mentor vê como 2 tem um problema anterior ao do projeto. # Observação de campo — Quest #1 Tudo o que você precisa decidir **antes** de sair para o campo, e como registrar enquanto está lá. --- ## 1. A decisão que ninguém toma e devia: qual postura de observação A página do Projetão diz "vá observar". Isso esconde uma escolha que muda o resultado. Há quatro posturas, e elas trocam **fidelidade** por **profundidade**. ### Mosca-na-parede (*fly-on-the-wall*) Você coleta informação **sem participar e sem interferir** — olhando e ouvindo, de fora. **Ganha:** minimiza o viés e a influência sobre o comportamento observado. **Perde:** reduz sua capacidade de conectar empaticamente e de sondar a motivação por trás do comportamento. Zeisel distingue dois graus: - **Estranho secreto** — observador distante, num ponto de vista que o remove dos participantes. Minimiza qualquer influência sua ou do equipamento de registro. Limitação: captura pouco da nuance individual da interação. - **Estranho reconhecido** — os observados sabem da sua pesquisa e do seu papel, mas você se posiciona de forma natural e discreta no ambiente. **Quando usar na Q1:** é a postura padrão para a primeira visita, quando você ainda não sabe o que está procurando. ### Observação participante Método fundacional da antropologia, adaptado para design. Você **participa da atividade** para entender a situação por dentro, formando conexão e empatia com as pessoas e com o que importa para elas — vivendo os eventos do mesmo jeito que elas. Zeisel distingue dois níveis: - **Participante marginal** — você se mistura ao ambiente como observador natural da atividade. Ex.: pegar o ônibus para observar quem usa transporte; ir ao jogo para observar a torcida. **É este o nível viável num semestre.** - **Participante pleno** — tornar-se membro completo do grupo, em casos extremos por infiltração. Não é papel típico do pesquisador de design: há questões éticas, investimento de tempo e risco. Virar garçom para estudar restaurante é caro; virar equipe médica para estudar hospital é impossível. **Quando usar na Q1:** na segunda visita, depois que a mosca-na-parede já mapeou o terreno. ### Indagação contextual (*contextual inquiry*) Método imersivo de observar **e** entrevistar ao mesmo tempo, que revela a estrutura de trabalho subjacente — aquela que é invisível para quem a executa. Criado por Karen Holtzblatt. Quatro princípios definem o método: | Princípio | O que significa | |---|---| | **Contexto** | Você tem de passar tempo **onde a coisa acontece**. É preciso entender a experiência *em curso*, não a experiência *resumida*. Perguntar "como você costuma fazer?" devolve o resumo; observar devolve o real. | | **Parceria** | Modelo **mestre/aprendiz**. Como um aprendiz, você observa, pergunta com respeito e busca entender por que as coisas são feitas daquele jeito; o mestre ensina fazendo e falando sobre a tarefa enquanto ela acontece. A transferência de conhecimento é mais confiável quando a pessoa fala do trabalho **enquanto trabalha**. | | **Interpretação** | O que você viu e ouviu é só o ponto de partida. Todo dado precisa ser interpretado antes de virar implicação de projeto. E é **crítico checar a interpretação ali mesmo, com a pessoa** — se você perde essa chance, a má interpretação vira ideia de projeto errada. | | **Foco** | Você precisa expandir os limites do seu foco pessoal e ver mais do mundo do participante. Toda vez que você se surpreende, ou que algo do participante contraria sua expectativa, é ali que há algo a aprender. | **Por que isso importa na Q1:** o princípio da **parceria** resolve o problema mais comum do aluno tímido — ele não sabe o que dizer no campo. A resposta é: você não é entrevistador, é aprendiz. Peça para a pessoa te ensinar o que ela faz. E o princípio da **interpretação** resolve o segundo problema mais comum: o aluno volta do campo com conclusões que ninguém validou. Checar na hora custa uma frase: *"então, se eu entendi, você faz assim porque…?"* ### Sondas culturais (*cultural probes*) Instrumentos provocativos entregues aos participantes para inspirar novas formas de autocompreensão e de comunicação sobre suas vidas, ambientes, pensamentos e interações. Consistem em materiais projetados para fazer a pessoa considerar seu contexto e responder de forma criativa: cartões-postais, mapas, diários, câmeras, gravadores, textos e imagens — empacotados juntos num kit. São deliberadamente flexíveis e abertos. No estudo original (Gaver, Dunne & Pacenti, 1999), com idosos em três comunidades europeias: postais com imagens obscuras, pré-endereçados para devolução, com perguntas abertas sobre ambiente, vida e tecnologia; mapas em papéis variados pedindo que marcassem zonas para encontrar gente, para ficar só, para sonhar, e para ir aonde não podiam ir; câmeras descartáveis para fotografar coisas atribuídas e escolhidas, montando uma história num álbum; e um diário de mídia sobre interações com tecnologia. **Ponto essencial:** sondas culturais **não são para análise formal**. Servem como peças inspiracionais que identificam padrões e temas, em conjunto com outros métodos. **Quando usar na Q1:** quando o tema é sensível, íntimo ou constrangedor, e a observação direta seria invasiva. > ⚠️ A página do Projetão descreve sondas culturais e cadernos de sensibilização sem citar a origem. A fonte canônica é **Gaver, Dunne & Pacenti, "Cultural Probes", *interactions*, jan-fev 1999, pp. 21–29**. --- ## 2. O efeito Hawthorne — e por que ele importa para você Mesmo com o melhor esforço para ficar distante e discreto, há uma desvantagem persistente: **as pessoas mudam de comportamento quando sabem que estão sendo observadas.** O nome vem de um estudo de produtividade nos Hawthorne Works da Western Electric, em Chicago, nos anos 1920–30. Manipulava-se o nível de iluminação para medir efeito na produtividade. A produtividade subia **independentemente** da manipulação — e caía quando o estudo terminava. A conclusão foi que a própria intervenção, ou o interesse demonstrado pelos trabalhadores, é que produzia o ganho. **Consequência prática na Q1:** se você entra num lugar com prancheta e crachá, o que você vê já não é o que acontece quando você não está. Duas mitigações: fique tempo suficiente para o efeito decair, e prefira a mosca-na-parede na primeira visita. **Segundo alerta:** *partidarismo percebido*. Se você é associado a uma facção do ambiente — a gerência, a direção, a fiscalização —, o comportamento à sua volta muda de forma dirigida. Pense em quem te apresentou ao local. --- ## 3. AEIOU — a grade padrão da disciplina Framework organizacional que lembra o pesquisador de atender, documentar e codificar informação sob uma taxonomia guia. | | | A pergunta | |---|---|---| | **A** | **Atividades** | Conjuntos de ações dirigidas a um objetivo. Que caminhos as pessoas percorrem em direção ao que querem realizar, incluindo ações e processos específicos? | | **E** | **Ambientes** (*Environments*) | A arena inteira em que as atividades acontecem. O que descreve a atmosfera e a função do contexto, incluindo espaços individuais e compartilhados? | | **I** | **Interações** | Entre uma pessoa e alguém ou algo mais — são os blocos que constroem as atividades. Qual a natureza das interações rotineiras e especiais, entre pessoas, entre pessoas e objetos, e a distância? | | **O** | **Objetos** | Os blocos que constroem o ambiente. Elementos-chave às vezes postos em usos complexos ou não pretendidos, mudando função, significado e contexto. Que objetos e dispositivos as pessoas têm, e como se relacionam com suas atividades? | | **U** | **Usuários** | As pessoas cujos comportamentos, preferências e necessidades estão sendo observados. Quem está presente? Quais seus papéis e relações? Quais seus valores e vieses? | **Os elementos não são independentes** — são partes inter-relacionadas, com interações críticas entre si. É aí que mora o achado: um **objeto** fora do **ambiente** esperado, sustentando uma **atividade** que ninguém previu, é a definição de gambiarra — e gambiarra é o que a Q2 vai procurar. ### Como aplicar Monte uma planilha com os cinco campos e preencha **durante** a observação, não depois. Ao fim, os dados já saem estruturados para análise. O que for levantado em **U** alimenta diretamente as personas. > ⚠️ **Correção de atribuição.** A página do Projetão credita o AEIOU a Rick Robinson, nos anos 1990, a partir da análise de horas de vídeo numa rede de lanchonetes. A atribuição completa é **Rick Robinson, Ilya Prokopoff, John Cain e Julie Pokorny, no Doblin Group, em Chicago, em 1991**; Robinson depois levou o framework para a E-Lab, onde apareceu em material de divulgação no fim dos anos 1990. Vale citar assim num trabalho acadêmico. > > Nota de tradução: o **E** original é *Environments* — **ambientes**, não apenas "espaço". A diferença importa: ambiente inclui atmosfera e função, não só a planta física. --- ## 4. Estruturada ou semiestruturada? Observação é habilidade fundamental de pesquisa: olhar atento e registro sistemático de fenômenos — pessoas, artefatos, ambientes, eventos, comportamentos e interações. Os métodos se caracterizam pelo **grau de formalidade**. **Semiestruturada (ou casual)** — típica da fase exploratória. A intenção é coletar informação de base por imersão, sobretudo em território novo para você. Pode haver um conjunto de perguntas-guia, mas se observa com mente aberta, e **desvios do plano são permitidos** diante do inesperado. Apesar da informalidade, deve ser sistemática, cuidadosa e bem documentada — notas, esboços, fotos, vídeo bruto. **Estruturada (ou sistemática)** — formalizada pelo grau de pré-estrutura: planilhas, checklists ou formulários para codificar comportamentos e eventos. Ideal quando os elementos-alvo já estão bem definidos, tipicamente por uma observação semiestruturada anterior. Exemplos de pré-estrutura: intervalos regulares de tempo, categorias predeterminadas de interação, contagem de acertos e erros. **Para a Q1: comece semiestruturada.** Você não sabe o que procura — e não deve saber. ### Dois cuidados que valem a nota **1. Evite achar o que você foi procurar.** É a tendência natural quando há categorias prontas. A recomendação é **sempre incluir uma categoria "outros"** na sua grade. O que cai em "outros" costuma ser o achado. **2. Separe fato de inferência.** As observações devem diferenciar **comportamentos factuais testemunhados** de **inferências** — a especulação sobre significado e motivação por trás das ações. As inferências podem ser verificadas por pergunta ao participante durante ou após a observação. Na prática, use duas colunas: | Vi | Infiro | |---|---| | Três pessoas revezaram o mesmo banco em 20 min | Falta assento no horário de pico | | Moça anota pedido num caderno e depois digita no sistema | O sistema não funciona no salão | A coluna da esquerda é dado. A da direita é hipótese — e cada linha dela é uma pergunta a fazer antes de ir embora. --- ## 5. Qual método escolher Deixe a **adequação à situação e à pergunta de pesquisa** guiar. Um roteiro rápido para a Q1: | Sua situação | Método | |---|---| | Primeira visita, não sei o que procuro | Mosca-na-parede, semiestruturada, com AEIOU na mão | | Já mapeei o terreno, quero entender o porquê | Indagação contextual (mestre/aprendiz) | | A atividade só se entende fazendo | Observação participante marginal | | Tema íntimo, sensível ou constrangedor | Sondas culturais / caderno de sensibilização | | Preciso comparar dois locais com o mesmo critério | Observação estruturada, com grade fixa e categoria "outros" | --- ## 6. Checklist da ida a campo **Levar** - [ ] Grade AEIOU impressa, com espaço para "outros" - [ ] Duas colunas para *vi* e *infiro* - [ ] Combinado de quem observa e quem registra - [ ] O que você **espera** encontrar, escrito antes **No local** - [ ] Fiquei tempo suficiente para o lugar me ignorar - [ ] Olhei para os papéis periféricos, não só para os protagonistas - [ ] Checei pelo menos três interpretações com quem estava lá - [ ] Anotei o que me surpreendeu **Ao sair** - [ ] Descarreguei tudo antes de dormir - [ ] Marquei quais linhas são fato e quais são hipótese - [ ] Listei as pessoas que valeria entrevistar na Q2 --- ## Fontes - **Hanington & Martin**, *Universal Methods of Design* — métodos 02 (AEIOU), 20 (Contextual Inquiry), 24 (Cultural Probes), 42 (Fly-on-the-Wall), 57 (Observation), 59 (Participant Observation) - **Holtzblatt & Beyer**, *Contextual Design* e **Holtzblatt, Wendell & Wood**, *Rapid Contextual Design* — os quatro princípios da indagação contextual - **Zeisel, John**, *Inquiry by Design* — as posturas do observador - **Gaver, Dunne & Pacenti**, "Cultural Probes", *interactions*, 1999 — a origem das sondas - **Landsberger**, *Hawthorne Revisited*, Cornell, 1958 — o efeito Hawthorne - **IDEO**, *HCD Toolkit* (pt-BR) — a fase Ouvir # ODS — enquadrar a temática sem forçar ## O que são Em setembro de 2015 os 193 países membros das Nações Unidas adotaram a **Agenda 2030 para o Desenvolvimento Sustentável**. O lema é *não deixar ninguém para trás*. Foram estabelecidos **17 Objetivos de Desenvolvimento Sustentável (ODS)** com **169 metas**, a serem alcançadas por ação conjunta entre níveis de governo, organizações, empresas e sociedade — nos âmbitos internacional, nacional e local. ## Por que o Projetão pede isso na semana 1 Não é ornamento burocrático. O enquadramento força, logo na primeira quest, a pergunta que a Q2 vai cobrar com evidência: > **Isso importa para quem, além de mim?** Um tema que não encaixa em nenhum ODS sem violência provavelmente é um interesse pessoal, não uma oportunidade de inovação. E um tema que encaixa em nove ODS provavelmente está formulado de forma vaga demais para ser trabalhado. ## Os 17 | # | Objetivo | |---|---| | 1 | Erradicação da pobreza | | 2 | Fome zero e agricultura sustentável | | 3 | Saúde e bem-estar | | 4 | Educação de qualidade | | 5 | Igualdade de gênero | | 6 | Água potável e saneamento | | 7 | Energia limpa e acessível | | 8 | Trabalho decente e crescimento econômico | | 9 | Indústria, inovação e infraestrutura | | 10 | Redução das desigualdades | | 11 | Cidades e comunidades sustentáveis | | 12 | Consumo e produção responsáveis | | 13 | Ação contra a mudança global do clima | | 14 | Vida na água | | 15 | Vida terrestre | | 16 | Paz, justiça e instituições eficazes | | 17 | Parcerias e meios de implementação | --- ## Como enquadrar bem ### O teste do encaixe frouxo Quase qualquer projeto pode ser encaixado no **ODS 8** (trabalho decente e crescimento econômico) ou no **ODS 9** (indústria, inovação e infraestrutura) — porque quase tudo gera alguma atividade econômica ou envolve alguma tecnologia. **Se o seu enquadramento serviria igualmente bem para o projeto de qualquer outra equipe, ele não está dizendo nada.** Teste rápido: leia sua justificativa de ODS substituindo o seu tema pelo tema de outro grupo. Se continua fazendo sentido, refaça. ### Desça para a meta, não pare no objetivo Cada ODS tem metas numeradas (169 no total). Citar "ODS 3 — Saúde e bem-estar" é genérico. Citar a meta específica, com o número, mostra que você foi ler. O salto de qualidade é este: | Nível | Como aparece | |---|---| | Fraco | "Nosso tema se relaciona com o ODS 3, saúde e bem-estar." | | Bom | "ODS 3, meta 3.4 — reduzir por prevenção e tratamento a mortalidade prematura por doenças não transmissíveis, e promover saúde mental e bem-estar." | | Forte | O acima, mais o dado nacional ou local que mostra o tamanho da lacuna naquela meta específica. | ### Um principal, dois secundários Problema real quase sempre toca mais de um objetivo. Mas escolha **um principal** — aquele em que a sua intervenção teria efeito direto — e no máximo dois secundários, onde o efeito é indireto. Listar sete ODS não demonstra abrangência; demonstra que você não decidiu. ### Cuidado com a direção da seta Erro comum: enquadrar pelo **efeito colateral desejado** em vez do **problema observado**. > "Nosso app de caronas se enquadra no ODS 13, ação contra a mudança do clima." Talvez. Mas se o que você observou em campo foi gente perdendo duas horas por dia no trânsito, o ODS que descreve o problema é o **11** (cidades e comunidades sustentáveis) — e o 13 é uma consequência possível, não a evidência. Enquadre pelo que você viu, não pelo que você espera causar. --- ## Onde buscar dado Para a pergunta 2 da entrega ("por que ela é relevante, como impacta a sociedade") você precisa de evidência externa e verificável. Fontes com dado aberto, brasileiro e citável: - **IBGE** — demografia, domicílios, trabalho, PNAD Contínua - **DataSUS / Ministério da Saúde** — morbidade, mortalidade, cobertura - **INEP** — educação básica e superior, Censo Escolar - **IPEA** — séries socioeconômicas - **Atlas do Desenvolvimento Humano / PNUD** — recortes municipais - **ODS Brasil (IBGE)** — indicadores nacionais organizados por objetivo e meta - **Cetic.br / CGI.br** — TIC Domicílios, TIC Educação, acesso e uso de internet **Regra da disciplina:** abra a fonte. Um número que você encontrou num resumo, numa notícia ou numa resposta de IA e não conferiu no original é um número que você não pode defender na banca — e a pergunta "de onde veio esse dado?" é das mais frequentes. Se o dado que você precisa não existe, isso também é um achado: diga que não existe, diga o que existe de mais próximo, e declare a incerteza. Incerteza declarada não tira ponto. --- ## Modelo de resposta Para a pergunta 2 da entrega: > **Temática:** [uma frase] > > **ODS principal:** [número e nome] · **meta [x.y]:** [texto da meta] > **ODS secundários:** [até dois] > > **Por que importa:** [o problema como você o observou, em duas frases] > > **Evidência:** [dado, com fonte, ano e link — que você abriu] > > **Desafios da temática:** [o que torna isso difícil de resolver — se fosse fácil, já estaria resolvido] > > **O que ainda não sabemos:** [a incerteza que a Q2 vai atacar] O último campo é o que separa uma Q1 de nível 2 de uma de nível 4. Equipe que declara o que ainda não sabe demonstra que entendeu o que observou; equipe que apresenta tudo resolvido na semana 1 não foi a campo. # Síntese e personas — Quest #1 O que fazer **depois** do campo. Esta é a parte que a maioria das equipes pula, indo direto das anotações para as conclusões — e é onde a Q1 ganha ou perde a nota. --- ## O problema que a síntese resolve Enquanto o dado da pesquisa está guardado como conhecimento tácito na cabeça das pessoas, ou enterrado em transcrições de entrevista, **a equipe tem dificuldade de sintetizar o que foi observado**. Cada um lembra de uma coisa, e a discussão vira disputa de impressão. Sem uma etapa formal de síntese, o que acontece na prática é: a pessoa mais convincente da equipe descreve o que ela achou, e isso vira a conclusão do grupo. O campo inteiro foi desperdiçado. --- ## Diagrama de afinidades Processo para **externalizar** e agrupar de forma significativa as observações e os insights da pesquisa, mantendo a equipe ancorada no dado enquanto projeta. Cada observação, preocupação ou requisito vai para **um post-it próprio**, para que a implicação de projeto de cada um possa ser considerada isoladamente. Depois os post-its são agrupados por afinidade, formando temas baseados em pesquisa. ### O procedimento (variante da indagação contextual) 1. **Registre entre 50 e 100 observações por pessoa observada**, cada uma em seu próprio post-it. 2. **Referencie a origem** em cada post-it — de que visita, de que pessoa, de que anotação veio. Se surgir dúvida depois, você precisa poder voltar à fonte. Este passo é o que separa síntese de invenção. 3. **Cubra uma parede com papel de formato grande** e cole os post-its ali. (O papel permite mover o diagrama inteiro depois.) 4. **Interprete cada nota**, em equipe, considerando o significado subjacente de cada uma. 5. **Agrupe as que compartilham intenção, problema ou questão semelhante** — as que têm afinidade. 6. Do trabalho **emerge uma história** sobre as pessoas, suas tarefas e a natureza dos problemas delas. O passo 6 é o teste: se ao final você não consegue contar uma história, o agrupamento foi feito por categoria óbvia (por lugar, por idade) em vez de por afinidade real. ### Regras que fazem diferença - **Não rotule os grupos antes de formá-los.** Rótulo antecipado atrai post-its para dentro dele. Agrupe primeiro, nomeie depois. - **Um post-it, uma ideia.** Post-it com duas afirmações não pode ser agrupado. - **Deixe um grupo "não sei".** É onde costuma estar a coisa interessante que ainda não tem nome. - **Faça em silêncio na primeira rodada.** Quem fala primeiro define o agrupamento dos outros. ### Origem O diagrama de afinidades foi introduzido nos anos 1960, junto com a **Técnica KJ**, pelo antropólogo japonês **Jiro Kawakita**. A variante usada em design vem de Holtzblatt & Beyer, *Contextual Design* (1998). --- ## Personas Consolidam descrições arquetípicas de padrões de comportamento do usuário em perfis representativos, para humanizar o foco de projeto, testar cenários e ajudar na comunicação. ### Por que existem Projetar para todo mundo resulta em solução sem foco ou incoerente, então algum grau de consolidação é necessário. Mas os dois atalhos comuns falham: - **Pesquisa quantitativa e survey** tendem a produzir caricaturas abstratas e desumanizadas. - **Segmentos tradicionais de mercado não funcionam**, porque descrevem **populações demográficas** em vez de **agregados de comportamento**. Persona feita de pesquisa de campo sólida resolve isso: captura comportamentos comuns em perfis significativos e relacionáveis. A descrição humana facilita empatia e comunicação; as distinções criam alvos úteis de projeto. > **Guarde esta frase:** persona não é demografia. "Mulher, 25–34, classe B, universitária" é segmento de mercado. Persona é padrão de comportamento. ### Como construir — a partir do dado, não da imaginação 1. Reúna informação suficiente para descrever vários usuários. 2. **Procure padrões e temas de comportamento** que constituam pontos em comum. 3. Use **diagrama de afinidades** (acima) para chegar às descrições consolidadas. 4. Agrupe as semelhanças entre usuários para formar os arquétipos agregados. ### O formato Descrição de **uma página ou menos**, contendo: - um **nome** - uma **foto** — use banco de imagens, para evitar vínculo com uma identidade real - uma **narrativa** descrevendo em detalhe os aspectos-chave da situação de vida, dos objetivos e dos comportamentos relevantes para a investigação - opcionalmente, imagens suplementares do estilo de vida: espaços, objetos e atividades típicos ### Quantas **A referência canônica recomenda de 3 a 5 por projeto**, para manter o foco gerenciável e evitar mirar em casos extremos. > ⚠️ **Tensão com a orientação da disciplina — e como resolver.** A página do Projetão pede persona para **todo grupo que você conseguir identificar**, começando pelos mais relevantes e complementando com os menos visíveis. Isso parece contradizer o "3 a 5". > > Não contradiz, se você entender o momento. A **Q1 é divergente**: quanto mais grupos você enxergar, melhor — inclusive os que passariam despercebidos, de onde a disciplina diz que a inovação costuma nascer. A convergência para 3–5 acontece **da Q4 em diante**, quando já há uma oportunidade escolhida e o foco precisa ser gerenciável. > > Na prática: levante todas na Q1, e declare quais são as principais. A partir da Q4, trabalhe com 3 a 5. ### Dicas da disciplina - **Inclua personalidade, humor, gostos e interesses.** Ajuda a entender o que o usuário quer e como ele verá o projeto. - **Evite características depreciativas** ou que tornem a persona antipática. O objetivo é criar laço e afeição da equipe pelo usuário — nunca a sensação de que ele não merece o esforço. - **Não use ilustração, desenho ou foto de pessoa pública.** A persona precisa presentificar o usuário, não produzir uma relação de representação ou imaginação sobre ele. ### Origem Introduzida no design de interação por **Alan Cooper** (*The Inmates Are Running the Asylum*). Cooper começou usando gerentes de projeto e de TI reais que ele conhecia como modelos aproximados dos usuários para quem projetava. O método depois evoluiu para personas fictícias baseadas em padrões distintos de comportamento emergidos de entrevistas, cada uma capturando diferenças importantes de objetivo, tarefa e nível de habilidade. Cooper percebeu que equipes lidando com uma ideia abstrata de "usuário" — genérico, sem rosto, distante — se preocupavam pouco com suas necessidades. Circula no meio uma prática atribuída à IDEO — imprimir os usuários em tamanho real e fixá-los nas paredes da sala de reunião, para que ninguém decida sem eles na frente. **Não consegui localizar essa afirmação em nenhuma das obras do acervo**; trate como relato de segunda mão, não como fonte. O princípio por trás dela, esse sim documentado, é o de Cooper: equipe que lida com um usuário abstrato decide como se ele não existisse. --- ## O que invalida uma persona Cheque cada uma antes de entregar: | Sinal | O que significa | |---|---| | Descreve idade, renda e escolaridade, e mais nada | É segmento de mercado, não persona | | Você não consegue apontar de que observação ela veio | Foi inventada | | Ela quer exatamente o que o seu projeto faz | Foi construída para justificar a solução | | Todas as suas personas concordam entre si | Você não observou grupos diferentes, observou o mesmo grupo | | Não tem nenhuma contradição interna | Pessoa real tem contradição; persona sem contradição é caricatura | | Foi gerada por IA a partir do nada | Ver abaixo | ### Persona e IA — o cuidado específico Persona é o artefato mais fácil de gerar sinteticamente e o mais inútil quando é. Um modelo generativo produz **a média estatística de textos sobre pessoas** — exatamente o oposto do que a técnica existe para produzir, que é o padrão de comportamento específico daquele grupo naquele contexto. Se a IA ajudar a redigir, que seja **a partir das suas notas de campo**, e declare no registro de trajetória o que veio de observação e o que veio de preenchimento. Teste rápido: peça à IA que aponte, para cada afirmação da persona, qual observação a sustenta. O que ela não conseguir ancorar, você inventou. --- ## Da síntese para a entrega O caminho completo, sem pular etapa: ``` notas de campo (fato | inferência) ↓ post-its, um por observação, com origem marcada ↓ agrupamento por afinidade → temas ↓ padrões de comportamento ↓ personas ↓ "as questões mais importantes a serem tratadas ali" ↓ enquadramento em ODS → entrega ``` Se você conseguir mostrar esse caminho na apresentação — do post-it à conclusão — a pergunta "de onde vocês tiraram isso?" já está respondida antes de ser feita. --- ## Fontes - **Hanington & Martin**, *Universal Methods of Design* — métodos 03 (Affinity Diagramming), 63 (Personas) - **Holtzblatt & Beyer**, *Contextual Design* (Morgan Kaufmann, 1998) — a variante de afinidades para indagação contextual - **Kawakita, Jiro**, *The Original KJ Method* (1982) — a origem - **Cooper, Alan**, *The Inmates Are Running the Asylum* — a origem das personas; e "The Origin of Personas" (2003) - **IDEO**, *HCD Toolkit* (pt-BR) --- # Quest #2 — Oportunidades > **Objetivo.** Identificar 2 a 3 oportunidades de inovação dentro da temática. | | | |---|---| | **Modo de IA** | 🔴 sem assistência na entrevista · 🟡 com apoio no roteiro e na análise | | **Milestone** | **Usuário** (abre aqui) | | **Entrega** | 2 ou 3 problemas/desejos com evidência de campo e de mercado | | **Erro que mais custa** | escrever a solução ao contrário e chamar de problema | --- ## A virada desta quest A Q1 foi esforço operacional — ir, olhar, registrar. A Q2 é **esforço intelectual**: abstração e raciocínio sobre o que foi visto. A equipe volta a um dos espaços observados e procura **conversar com quem entende do assunto**. Muda também quem você procura: na Q1 você observou qualquer um; aqui você busca quem tem a dor e quem conhece o terreno. --- ## Problema: a definição operacional **Algo que incomoda significativamente as pessoas observadas.** O teste: se o problema é de fato relevante, elas estariam dispostas a **pagar ou adotar** uma solução. O problema **não é** a ausência de solução. *"O problema da Fulana é que ela não tem um sistema pra fazer isso"* não é problema — é a sua solução escrita ao contrário. ### A escala de intensidade Todo problema levantado precisa ser classificado. A escala usada na entrevista: | | Significado | |---|---| | **must-have** | A pessoa já age para resolver. É aqui que mora oportunidade. | | **nice-to-have** | Ela gostaria, mas convive bem sem. Vai para o backlog. | | **don't need** | Não faz diferença. Sai do roteiro. | > **Refino útil.** Existe um modelo mais fino, o de Kano, com cinco categorias em vez de três: *obrigatório* (a ausência decepciona, a presença não encanta), *desejado* (relação linear com satisfação), *encantador* (encanta se houver, não frustra se faltar — são **necessidades latentes**, que a maioria não pensaria em pedir), *neutro* e **anti-atributo** (a presença **piora** a satisfação). > > Por que importa: "don't need" mistura duas coisas bem diferentes — o neutro (indiferente) e o anti-atributo (rejeição ativa, às vezes a pessoa paga para *não* ter). E o *encantador* explica por que a ausência de reclamação não prova ausência de oportunidade. ### O teste que separa dor real de resposta educada > **Não pergunte ao cliente o que ele quer. Meça o que ele faz.** — Ash Maurya É comum a pessoa mentir na entrevista — por educação, ou porque simplesmente não sabe. O teste operacional: - Se ela declara *must-have* mas **não está fazendo nada** para resolver, e vive bem assim → a dor não é aguda. - Se ela usa uma solução caseira ou de concorrente **e está insatisfeita** → aí sim é problema que vale resolver. Quando alguém classifica um problema como *must-have* e não age, **há uma desconexão** — e é seu trabalho notá-la. --- ## Gambiarra **Solução improvisada que compensa a ausência de solução adequada.** É o achado mais valioso da quest: ninguém improvisa por esporte. > ⚠️ **Duas correções ao que se costuma dizer.** > > **1. Gambiarra valida a dor, não a disposição a pagar.** Na escala canônica de cinco degraus, a gambiarra é o **degrau 4**: (1) tem um problema; (2) sabe que tem; (3) procura ativamente e tem prazo; (4) **improvisou uma solução provisória**; (5) tem ou consegue orçamento. O cliente que interessa está em 4 **e** 5. Gambiarra sozinha não prova que alguém pagaria. > > **2. A gambiarra só conta se a pessoa estiver insatisfeita com ela.** Gambiarra estável e satisfatória é um problema **já resolvido**, não uma oportunidade. > > **3. A recíproca é falsa.** Ausência de gambiarra **não** prova ausência de problema — as necessidades latentes (os "encantadores" de Kano) são justamente aquelas que ninguém pensaria em pedir, e para as quais ninguém improvisou nada. Procure gambiarra explicitamente: pergunte *"como você faz hoje quando isso acontece?"* e depois *"pode me mostrar?"*. Olhe para o que a pessoa **faz**, não para o que ela diz que deveria existir. --- ## Cliente ≠ usuário — e por que o par é grosseiro demais A regra base: **cliente é quem paga; usuário não paga.** Mas o "cliente" se decompõe em papéis distintos, e ignorar isso derruba projeto: | Papel | Quem é | |---|---| | **Usuário final** | quem usa — e às vezes tem a **menor** influência na compra | | **Influenciador** | opina e é ouvido | | **Recomendador** | pode fazer ou quebrar a venda | | **Comprador econômico** | tem o orçamento | | **Decisor** | pode estar acima do comprador econômico | | **Sabotador** | perde estabilidade, verba ou espaço se o seu produto entrar | O último é o mais esquecido e o que mais mata piloto em organização. **O que entregar:** não um par binário, mas um **mapa de influência** — quem usa, quem decide, quem paga, quem pode barrar. Uma tabela de quatro linhas basta. Esse mapa é insumo direto da Q3, que analisa os similares **por lado** (o que o comprador valoriza raramente é o que o usuário valoriza), e da Q4, que vai formalizá-lo. --- ## Aprofundar: dois "por quê" diferentes Existem dois encadeamentos de pergunta, e **eles não são a mesma coisa**. Misturá-los numa "árvore" única é erro de método. ### Cinco porquês — desce na cadeia causal Pergunta *por que isso acontece*, buscando a causa abaixo do sintoma. Cada etapa exige uma explicação convincente do caminho causal. > ⚠️ **O limite de cinco é deliberado**, e a justificativa contraria a intuição de "vá até a causa primária": limitar a cinco estágios impede que o processo perca relevância ao se afastar demais da pergunta original. Não há promessa de chegar à causa raiz — há um teto pragmático. ### Laddering — sobe da funcionalidade ao valor Pergunta ***"por que isso é importante para você?"***, ligando **atributo → consequência → valor**. O exemplo canônico, que todo aluno deveria conhecer: > Usuário pede: *"quero um campo 'código do cargo' no relatório"* → por quê → *"só eu posso reportar esse dado"* → por que é confidencial → *"monitoramos salários para garantir que minorias sejam pagas com justiça"*. > > **A necessidade não é um campo de formulário. É a importância de salário justo.** É o laddering que separa **requisito falso** de necessidade real. Sete valores costumam aparecer como motivação não dita: autoestima, realização, pertencimento, autorrealização, família, satisfação e segurança. **Qual usar quando:** cinco porquês quando você quer entender *por que o problema acontece*; laddering quando alguém te pede uma funcionalidade e você precisa descobrir o que está por baixo. --- ## As perguntas da entrega 1. **Que lugares visitaram e que pessoas entrevistaram?** 2. **Que dores ou desejos ficaram mais evidentes?** O que incomoda mais? O que é tacitamente desejado? 3. **Que produtos, serviços, artefatos e discursos** as pessoas usam nas atividades ligadas ao tema? 4. **Que gambiarras** (tecnológicas ou não) têm usado? 5. **Que artefatos ou processos já existentes poderiam estar sendo usados, e não estão?** 6. **Quais são os 2 ou 3 problemas/desejos principais**, e por que vale a pena abordá-los? 7. O problema é **(a)** muito crítico para um grupo limitado (quais?) ou **(b)** importante para um grande público (quantas pessoas?) 8. **Qual a evidência na mídia ou em publicações** do impacto ou tamanho do mercado? A pergunta 7 é uma bifurcação estratégica, não formalidade: dor aguda em nicho pequeno e dor branda em público grande levam a projetos, modelos de receita e estratégias de tração completamente diferentes. --- ## A entrevista de problema Roteiro cronometrado, ~30 minutos. Detalhe completo em **Entrevista de problema — Quest #2** (neste arquivo). | Bloco | Tempo | O que testa | |---|---|---| | Boas-vindas — preparar o terreno | 2 min | — | | Coletar demografia | 2 min | segmento de cliente | | Contar uma história | 2 min | contexto do problema | | **Ranqueamento dos problemas** | 4 min | o problema | | **Explorar a visão de mundo** | 15 min | o problema + alternativas existentes | | Fechamento — gancho e pedido | 2 min | permissão de retorno + indicações | | Documentar | 5 min | — | **Critério de saída:** você terminou quando entrevistou **pelo menos 10 pessoas — por equipe, não por aluno** — e consegue (a) identificar a demografia do usuário afoito, (b) nomear um problema *must-have*, e (c) descrever como o cliente resolve isso hoje. **Faça a conta antes de começar.** A taxa típica de conversão é de cerca de **um em cada dez contatos** virar entrevista marcada. Dez entrevistas exigem, portanto, algo como cem abordagens — o que só cabe numa semana se **a equipe inteira prospectar em paralelo, no primeiro dia**. Numa equipe de sete, são quinze contatos por pessoa. Se a prospecção começar na quarta-feira, não vai dar. **Ritmo:** 10 a 15 pessoas por semana. **Não mude o roteiro no meio da semana** — revise em lote, no fim. --- ## Referências desta quest | Arquivo | Quando | |---|---| | **Entrevista de problema — Quest #2** (neste arquivo) | Antes de entrevistar. Roteiro completo, falas literais, formulário, critérios de saída | | **Aprofundar — Quest #2** (neste arquivo) | Quando a resposta ficar rasa. Laddering, incidente crítico, cinco porquês, Kano, cartas de amor e término | | **Quem entrevistar — Quest #2** (neste arquivo) | Ao montar a lista. Papéis de compra, como achar gente, ritmo de prospecção | | **Autodiagnóstico — Quest #2** (neste arquivo) | Antes de entregar | --- ## Armadilhas nomeadas pelos livros 1. **Survey no lugar de entrevista.** O survey pressupõe que você já sabe as perguntas certas — e, pior, as respostas certas, ao fixar as alternativas. E você não vê a pessoa. 2. **Focus group.** Degenera em pensamento de grupo. 3. **Enviesar o ranqueamento pela ordem.** Reordene a lista de problemas entre entrevistas. 4. **Conduzir ou vender.** Não lidere nem convença ninguém do mérito de um problema. 5. **Perguntar quanto pagaria.** Não há justificativa econômica para o cliente dar outra coisa que não um número baixo — e a pergunta o deixa desconfortável. 6. **Ficar dentro do prédio.** Não existem fatos dentro do prédio, só opiniões. 7. **Aceitar o problema como enunciado.** Parte do seu trabalho é garantir que o problema declarado é o melhor problema a atacar. 8. **Efeito Hawthorne.** As pessoas mudam de comportamento quando sabem que estão sendo observadas. --- ### Antes de registrar pessoas | Arquivo | Quando | |---|---| | `../../metodo/consentimento.md` | Antes da primeira entrevista. Como pedir para gravar, e o que fazer se a pessoa recusar | --- ### Técnicas desta quest Fichas curtas de consulta rápida. Abra quando o procedimento acima mencionar a técnica. | Ficha | Para quê | |---|---| | **Entrevistas** (neste arquivo) | as modalidades e quando usar cada uma | | **Mapa de Empatia** (neste arquivo) | tensão entre o que fala e o que faz | | **Personas** (neste arquivo) | refinar com o que a entrevista trouxe | | **Jornada do Usuário** (neste arquivo) | a jornada atual, com as dores | --- ## Perguntas frequentes **"Posso entrar em qualquer grupo formado depois da Q1?"** Não. Os grupos são balanceados por curso de origem, para que formações horizontais não se concentrem num grupo só e as verticais não se diluam em todos. Se você não estava na formação, procure o professor presencialmente. **"Quantas entrevistas são suficientes?"** Dez é o piso. Mas o critério real não é número: **você terminou quando para de aprender** — quando consegue prever o que a pessoa vai dizer com duas perguntas de qualificação. --- ## Bibliografia desta quest | Obra | O que ela dá para a Q2 | |---|---| | **Maurya — Running Lean** | A entrevista de problema, cronometrada, com formulário e critério de saída | | **Blank — The Four Steps to the Epiphany** | A escala de dor, os papéis de compra, o ritmo de prospecção | | **Hanington & Martin — Universal Methods of Design** | Laddering, incidente crítico, Kano, cartas de amor e término | | **Stickdorn & Schneider — This Is Service Design Thinking** | Cinco porquês, shadowing, stakeholders | | **Vianna et al. — Design thinking: inovação em negócios** | Dizem/fazem/sabem; arqueologia do artefato; cartões de evocação | | **IDEO — HCD Toolkit** · **Stickdorn** · **Hanington** | Bibliografia oficial da quest no site | # Aprofundar — Quest #2 Abra este arquivo quando a resposta ficar rasa: a pessoa respondeu, você anotou, e não há nada ali que você já não soubesse. Cada técnica abaixo resolve um tipo diferente de raso. --- ## Qual técnica para qual raso | O que aconteceu na entrevista | Técnica | O que ela devolve | |---|---|---| | Pediu uma funcionalidade específica | **Laddering** | O valor por baixo do pedido | | Falou no genérico: "às vezes dá problema" | **Incidente crítico** | Um episódio datado, com causa, ação e desfecho | | Você entendeu o sintoma, não a origem | **Cinco porquês** | A cadeia causal, inclusive o que o usuário não vê | | Você tem funcionalidades e não sabe priorizar | **Análise de Kano** | A categoria de cada atributo, inclusive os que pioram a satisfação | | A pessoa é formal, curta, ou desconhecida | **Cartas de amor e de término** | Sentimento, em formato que dá licença para exagerar | | Descreve o que faz, e você desconfia | **Arqueologia do artefato** | O que os objetos dizem, independentemente do relato | | Não verbaliza medo, desejo ou frustração | **Cartões de evocação cultural** | Histórias que ela nunca contaria se perguntadas | A lista é longa por uma razão. Um mapa clássico da pesquisa em design separa três camadas: o que as pessoas **dizem e pensam** (explícito, alcançado por entrevista), o que **fazem e usam** (observável, alcançado por observação) e o que **sabem, sentem e sonham** (tácito e latente, alcançado por sessões generativas). Entrevista sozinha só chega à primeira camada. --- ## 1. Laddering — subir do atributo ao valor **Quando usar:** sempre que alguém pedir uma funcionalidade. Separa **requisito falso** de necessidade real. Técnica de entrevista individual que torna explícita a ligação entre três níveis: | Nível | O que é | Exemplo do livro (cremes antienvelhecimento) | |---|---|---| | **Atributo** | A característica física e óbvia | ingredientes antienvelhecimento | | **Consequência** | O benefício, o impacto sobre a pessoa | usa-se para se **sentir** jovem | | **Valor** | A causa-raiz de por que aquilo ressoa | saúde, bem-estar e longevidade | A pergunta que constrói a escada é uma só, repetida: ***"por que isso é importante para você?"*** ### O exemplo canônico O caso que todo aluno deveria conhecer, porque é o formato exato em que o erro aparece num projeto de software (adaptado de Hanington & Martin): > — Preciso que vocês adicionem um campo "código do cargo" neste relatório. > — Por que o "código do cargo" é importante para você? > — Porque sou a única pessoa que pode reportar esse dado. > — Por que você é a única responsável? > — Porque é informação confidencial de funcionário. > — Pode me contar mais sobre por que esse dado é confidencial? > — Ajuda a monitorar salários, para garantir que minorias estão sendo pagas com justiça. > **A necessidade não era um campo de formulário. Era a importância de salário igual para trabalho igual.** Repare no custo de atender ao pedido literal: entrega-se o campo, a pessoa fica satisfeita naquele dia, e o problema real — monitorar equidade salarial — continua sendo resolvido na mão, por uma pessoa só, num processo frágil. O campo é a **gambiarra**, e a equipe acabou de automatizá-la. ### Os sete valores A pesquisa citada por Hanington & Martin identifica sete valores frequentes como motivação não dita do comportamento de compra: **autoestima, realização, pertencimento, autorrealização, família, satisfação e segurança**. Não use como cardápio. Use como teste: se a sua escada terminou num lugar que não se parece com nenhum dos sete, provavelmente ela parou cedo demais. ### Cuidados Laddering funciona melhor **no início do processo de projeto**, ou sempre que a discussão interna da equipe travar em funcionalidades. A conversa começa por atributos — é normal; o erro é ficar neles. Cada "por quê?" desloca o foco um passo para longe do produto e um passo para dentro da vida da pessoa: se a resposta ainda menciona a ferramenta, continue. --- ## 2. Técnica do incidente crítico **Quando usar:** quando a pessoa fala no genérico. "Às vezes trava", "de vez em quando dá problema", "geralmente funciona". Um **incidente crítico** é um episódio em que houve uma **lacuna entre o resultado esperado e o que de fato aconteceu** — para pior ou para melhor. Os dois contam: a tentativa de corrigir uma situação que a piorou, e a decisão simples cujo desfecho surpreendeu positivamente. Peça que a pessoa **descreva retrospectivamente** uma situação concreta que, na avaliação dela, terminou bem ou terminou mal. Do relato você extrai cinco coisas: | | Pergunta | |---|---| | **Causa** | Que eventos levaram até ali? | | **Ações** | Que comportamentos ocorreram durante? | | **Sentimento** | Como a pessoa se sentiu durante e depois? | | **Desfecho** | Ela mudou de comportamento? O que aconteceria se nada mudasse? | | **Desfecho ideal** | Se o comportamento mudasse, que futuros seriam possíveis? | Um incidente é **efetivo** se ajudou a resolver o problema, e **inefetivo** se falhou, criou problemas novos ou exigiu ações adicionais. **Incidentes positivos e negativos são analisados e reportados separadamente** — misturá-los apaga o padrão. > ⚠️ **Sobre o tamanho da amostra.** A literatura citada por Hanington & Martin fala em **50 a 100 incidentes** para uma amostra de trabalho. Isso não é alcançável numa quest. O que é alcançável: usar a técnica como **estrutura de pergunta** dentro das suas dez entrevistas, colhendo um ou dois incidentes por pessoa. Você não terá base para inferência estatística — e deve dizer isso na apresentação. Terá episódios concretos e datados, que valem mais que "às vezes dá problema". A técnica foi desenvolvida por John C. Flanagan durante a Segunda Guerra, a partir de estudos do programa de psicologia da aviação das Forças Aéreas do Exército dos Estados Unidos. --- ## 3. Cinco porquês — descer na cadeia causal **Quando usar:** quando você entendeu o sintoma e precisa da origem. Revela **etapas do processo que o cliente não vê**. Uma cadeia de perguntas que escava abaixo dos sintomas aparentes de uma experiência para descobrir as motivações na raiz. Quem responde precisa produzir uma **explicação convincente para cada etapa** do caminho causal. O exemplo de Stickdorn & Schneider (tradução nossa): > **Por que** demora tanto para atender um cliente? — Estamos sempre ocupados; sempre há fila na hora do almoço. > **Por que** há sempre fila na hora do almoço? — É o pico do dia e não temos gente suficiente. > **Por que** não temos gente suficiente nos picos? — Não há espaço para mais funcionários; eles só atrapalhariam. > **Por que** não há espaço? — A área de serviço é entulhada: o equipamento é grande e volumoso. > **Por que** há tanto equipamento ali? — Compramos em lote para economizar, e isso resulta em coisas baratas e volumosas, que depois temos que contornar. Note onde a cadeia termina: numa **política de compras**, não num problema de atendimento. Nenhum cliente da fila poderia ter dito isso. É esse o valor da técnica — um benefício explícito é **incluir etapas do processo que o cliente não enxerga**, o que permite classificar problemas como internos ou externos à organização. > ⚠️ **O limite de cinco é deliberado, e a justificativa contraria a intuição.** Não é "vá até a causa primária". É o contrário: **limitar o caminho a cinco estágios impede que o processo perca relevância ao se afastar demais da pergunta original**. Não há promessa de chegar à causa raiz. Há um teto pragmático. Se no quinto porquê você está falando de economia mundial, você passou do ponto. **Cinco porquês não é laddering.** Um desce na causalidade (*por que isso acontece*), o outro sobe na motivação (*por que isso importa para você*). Misturar os dois numa "árvore de problema" única produz um diagrama que não se sustenta sob pergunta. --- ## 4. Análise de Kano — priorizar sem "mais é melhor" **Quando usar:** quando você já tem atributos candidatos e precisa decidir o que entra. É a técnica que impede a equipe de tratar toda funcionalidade como ganho. A tese de partida: **acrescentar funcionalidades continuamente — a lógica do "mais é melhor" — é estratégia ineficaz para melhorar a satisfação do cliente.** Cada atributo cai numa de cinco categorias. | Categoria | Termo original | Comportamento | |---|---|---| | **Obrigatório** | *atari mae* | Linha de base. A presença não aumenta satisfação; a ausência tem impacto negativo. Privacidade, segurança e exigências legais entram aqui | | **Desejado** | *ichi gen teki* | Relação linear: se tem, o valor percebido sobe; se falta, cai | | **Encantador** | *mi ryoku teki* | Surpreende e encanta. Se não estiver lá, em geral **não** frustra. São as **necessidades latentes** — a maioria não pensaria em pedir | | **Neutro** | *mu kan shin* | Sem sentimento forte nos dois sentidos | | **Anti-atributo** | *gyaku* | A presença **piora** a satisfação. Às vezes o cliente **paga mais para não ter** — o aplicativo gratuito com anúncios cuja versão paga não os tem — ou escolhe o concorrente que não o usa | ### O par de perguntas Para cada atributo, escreva **duas** perguntas: *se [o atributo] estiver presente, como você se sentiria?* e *se [o atributo] não estiver presente, como você se sentiria?* Exemplo do livro: *"se o wi-fi do hotel for gratuito, como você se sentiria?"* / *"se o wi-fi do hotel não for gratuito, como você se sentiria?"* Em cada uma, a pessoa escolhe entre **satisfeita**, **neutra** ou **insatisfeita**. O cruzamento define a categoria: | | **Presente: satisfeita** | **Presente: neutra** | **Presente: insatisfeita** | |---|---|---|---| | **Ausente: satisfeita** | questionável | anti-atributo | anti-atributo | | **Ausente: neutra** | encantador | neutro | anti-atributo | | **Ausente: insatisfeita** | desejado | obrigatório | questionável | As células "questionável" indicam resposta contraditória — normalmente a pergunta foi mal formulada. Não force a resposta numa categoria; refaça. ### Por que isso importa na Q2 A escala *must-have* / *nice-to-have* / *don't need* é operacional e rápida, e por isso é o que você usa em campo. Mas ela **funde duas coisas diferentes** dentro de "don't need": o neutro (indiferença) e o anti-atributo (rejeição ativa). Só o segundo é informação estratégica. E a categoria *encantador* explica por que **ausência de reclamação não prova ausência de oportunidade**: as necessidades latentes são, por definição, aquelas que ninguém pensaria em pedir — e para as quais ninguém improvisou gambiarra nenhuma. Hanington & Martin recomendam repetir a análise ao longo do tempo, **particularmente quando houver mudança cultural, econômica ou tecnológica**, porque essas mudanças reclassificam atributos. --- ## 5. Cartas de amor e de término **Quando usar:** quando você precisa de sentimento e a conversa está formal. Funciona bem em grupo — oficina, entrevista coletiva, quebra-gelo. Peça à pessoa que **personifique um produto ou serviço** e escreva uma carta pessoal a ele. O formato é imediatamente compreendido, e os resultados costumam ser inesperadamente profundos sobre a relação que as pessoas mantêm com os objetos do cotidiano. | | O que revela | |---|---| | **Carta de amor** | O que a pessoa sente nos momentos de conexão. Encanto, paixão, lealdade — e por que ela permanece com aquilo mesmo com outros produtos disputando sua atenção | | **Carta de término** | Como, quando e onde a relação azedou; por que se abandona uma marca. As pessoas contam com que produto novo estão felizes agora, e o que ele tem que o abandonado não tinha | **Regras de aplicação:** máximo de **dez minutos** para escrever — prazo maior faz a pessoa pensar demais e a espontaneidade se perde; peça voluntários para **ler em voz alta**; registre a leitura em vídeo, porque expressão e voz carregam pistas que a carta sozinha não tem; e **guarde as cartas físicas** como artefato — o cuidado na construção (papel, letra, desenhos) comunica o grau de afeto ou de decepção. A carta de término é especialmente útil na Q3: ela devolve **por que alguém abandonou uma alternativa existente**, que é exatamente a lacuna que a análise de similares procura. Método criado pela Smart Design em 2009. --- ## 6. Duas técnicas do repertório brasileiro Vianna et al. descrevem uma imersão para uma seguradora de automóveis, com entrevistas com segurados e corretores em três grandes cidades brasileiras. Duas técnicas usadas ali cabem bem na Q2. **Arqueologia do artefato.** A maneira como as pessoas usam os objetos revela o que elas fazem e pensam, independentemente do que dizem. Na imersão citada, pedia-se para observar **onde o segurado guarda a apólice**, como o corretor organiza o arquivo, o que o guincheiro guarda no porta-luvas. Na Q2: peça para ver a gaveta, a pasta, o caderno, a tela do celular. **Cartões de evocação cultural.** Cartões com imagens capazes de evocar memória e estimular o entrevistado a resgatar histórias que jamais seriam mencionadas. No caso citado, mostrar a imagem de um caixão ou de uma ilha deserta levava o segurado a descrever medos e sonhos; pedir a corretores que organizassem logotipos de seguradoras por critério próprio revelava a relação deles com as marcas — **sem que isso tivesse sido perguntado diretamente**. É essa a chave das duas: elas contornam a pergunta direta. Servem quando o assunto é constrangedor, quando a pessoa tem incentivo para dar a resposta socialmente aceitável, ou quando ela não tem palavras para o que sente. --- ## Modo de IA | Etapa | Modo | |---|---| | Escolher qual técnica se aplica ao seu raso | 🟡 com apoio | | Formular os pares de perguntas de Kano | 🟢 coprodução — verifique se cada par testa **um** atributo e não induz | | Conduzir laddering, incidente crítico, evocação | 🔴 sem assistência | | Montar a matriz de Kano a partir das respostas | 🟢 coprodução — é classificação mecânica | | Interpretar a escada de laddering | 🟡 com apoio — peça que aponte **onde a escada parou cedo**, não que a complete | O pedido perigoso: *"gere a escada de laddering para o meu problema."* Ela vai gerar, será plausível, e não terá vindo de ninguém. --- ## Fontes - **Hanington & Martin**, *Universal Methods of Design* — métodos 52 (Laddering, o exemplo do "código do cargo", os sete valores), 22 (Critical Incident Technique), 50 (Kano Analysis, as cinco categorias, o par de perguntas e a matriz), 54 (The Love Letter & the Breakup Letter) - **Stickdorn & Schneider**, *This Is Service Design Thinking* — os cinco porquês, o exemplo da fila do almoço e a justificativa do limite de cinco - **Vianna et al.**, *Design thinking: inovação em negócios* — arqueologia do artefato e cartões de evocação cultural, no caso da seguradora; o mapa dizem/pensam · fazem/usam · sabem/sentem/sonham - **Reynolds & Gutman** (1982, 1988), **Kano, Seraku & Takahashi** (1984) e **Flanagan** (*Psychological Bulletin*, 1954) — fontes primárias citadas por Hanington & Martin # Autodiagnóstico — Quest #2 Faça este exercício **antes** de entregar. É o mesmo que o mentor vai fazer depois. --- ## O milestone que abre aqui A Q2 alimenta o milestone **Usuário** — clareza sobre quem é o usuário/consumidor potencial. É o primeiro dos 13, e a aprovação exige nível 4 em todos. A escala 0–5 está em `metodo/avaliacao.md`. O salto que trava a maioria é o **3 → 4**. Na Q2 ele tem nome preciso: sair de *"achamos que o usuário é assim"* para *"conversamos com dez pessoas e o padrão é este, com estas exceções"*. --- ## Rubrica por dimensão ### 1. Campo — quantas pessoas, e quem | | | |---|---| | **2** | Três ou quatro conversas informais, com gente do próprio círculo, sem roteiro. | | **3** | Sete a dez entrevistas com roteiro, mas todas com o mesmo tipo de pessoa. | | **4** | Dez ou mais entrevistas com roteiro cronometrado, cobrindo mais de um papel de compra, com registro individual. | | **5** | O acima, mais um segundo lote depois de revisar o roteiro, com sinal demonstravelmente mais forte. | ### 2. Definição do usuário afoito | | | |---|---| | **2** | Demografia genérica, que serviria para qualquer projeto ("jovens de 18 a 30, classe B"). | | **3** | Perfil com comportamento, mas sem o que separa quem sentiu a dor de quem não sentiu. | | **4** | Atributos que **qualificam**: com duas ou três perguntas vocês preveem se a pessoa tem o problema. | | **5** | O acima, mais os segmentos **descartados** e por quê. | ### 3. Intensidade do problema | | | |---|---| | **2** | Os problemas estão listados sem classificação, ou todos foram classificados como *must-have*. | | **3** | Classificação feita, mas apoiada só no que a pessoa declarou. | | **4** | Classificação conferida contra comportamento: para cada *must-have*, vocês dizem **o que a pessoa faz hoje** a respeito. | | **5** | O acima, com uma **desconexão nomeada** — alguém que declarou *must-have* e não age, ou o contrário — e a leitura dela. | ### 4. Alternativa existente e gambiarra | | | |---|---| | **2** | "Não existe nada parecido" — resposta que quase nunca é verdadeira. | | **3** | Alternativas listadas por busca na web, não por relato de campo. | | **4** | Para cada problema, **como o cliente resolve isso hoje**, com nome, custo e satisfação; gambiarras descritas, não só citadas. | | **5** | O acima, mais o registro de quem **não faz nada** e convive bem — o que delimita o tamanho da oportunidade. | ### 5. Mapa de influência | | | |---|---| | **2** | Um par cliente/usuário, sem mais. | | **3** | Papéis nomeados, mas só o usuário final foi entrevistado. | | **4** | Os papéis do contexto mapeados, dois deles entrevistados, e uma hipótese explícita de **sabotador**. | | **5** | O acima, com a ordem em que cada papel precisaria ser convencido, e o que cada um perde. | ### 6. Escolha das 2–3 oportunidades | | | |---|---| | **2** | As oportunidades são a solução que a equipe já queria fazer, escrita ao contrário. | | **3** | São problemas de verdade, mas a escolha entre eles não está justificada. | | **4** | Cada uma tem evidência de campo, evidência de mídia ou publicação, e a resposta à bifurcação — dor aguda em grupo limitado **ou** dor branda em público grande, com número. | | **5** | O acima, mais o que foi **descartado** e o critério do descarte. | --- ## Checklist rápido - [ ] Entrevistei pelo menos 10 pessoas, com roteiro, e tenho ficha de cada uma? - [ ] Consigo enunciar **um** problema *must-have* — não três? - [ ] Para esse problema, sei descrever como a pessoa resolve isso hoje? - [ ] Anotei **as palavras dela**, ou só a minha paráfrase? - [ ] Reordenei a lista de problemas entre entrevistas? - [ ] Entrevistei alguém que **não** é o usuário final? - [ ] Tenho hipótese de quem perderia alguma coisa se o projeto existisse? - [ ] Alguma entrevista me fez mudar de ideia — ou todas confirmaram o que eu já achava? - [ ] O número de impacto que eu vou citar veio de uma fonte que eu **abri**? **Sinal de alerta:** se nenhuma das dez entrevistas mudou nada no seu entendimento, ou o roteiro estava vendendo em vez de perguntando, ou você só falou com quem já concordava. **Segundo sinal:** se os seus 2–3 problemas são "as pessoas não têm um app para X", isso é a sua solução escrita ao contrário. --- ## 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 Q2 a entrevista é 🔴 sem assistência e o roteiro é 🟡 com apoio. Se a IA gerou perguntas que foram a campo sem revisão sua, diga.* 2. **O que a IA gerou e você descartou — e por quê.** *Típico da Q2: uma lista plausível de "dores do usuário" gerada a partir do tema, antes de qualquer entrevista. Mantê-la como hipótese a testar é correto; entregá-la como achado de campo, não.* 3. **O que você verificou, e como.** *Típico da Q2: o número de mercado da pergunta 8 da entrega. Diga qual afirmação você foi conferir, em que fonte, e o que encontrou de diferente.* 4. **O que ainda não sabe.** *Exemplos honestos: "não falamos com nenhum comprador econômico"; "só ouvimos gente do turno da manhã".* --- ## Como o mentor vai ler Quatro perguntas que aparecem com regularidade na apresentação da Q2. Se você responde às quatro, está em 4. 1. **"Quantas pessoas vocês entrevistaram, e quem eram?"** Resposta fraca: "várias, do público-alvo". Forte: número, papéis, como chegaram até elas. 2. **"Como essas pessoas resolvem isso hoje?"** Se a resposta for "não resolvem", não ter encontrado a alternativa existente é falha de entrevista, não ausência de concorrente. 3. **"Alguém está fazendo alguma coisa a respeito, ou só reclamou?"** É o teste que separa dor real de resposta educada. 4. **"O que vocês ouviram que não esperavam ouvir?"** Não ter resposta indica campo confirmatório. Divergência entre a sua auto-avaliação e a leitura do mentor é informação útil, não constrangimento. # Entrevista de problema — Quest #2 Abra este arquivo **antes** de marcar a primeira conversa. Aqui está o roteiro completo, o que dizer em cada bloco, o formulário de registro, o que fazer nos cinco minutos seguintes e como saber que você terminou. O roteiro vem de Ash Maurya (*Running Lean*). As falas abaixo são **tradução e adaptação nossas** ao contexto brasileiro e universitário — o original é sobre um serviço de fotos para pais. O que não muda é a estrutura, os tempos e a ordem. --- ## 1. As sete decisões que você toma antes de marcar Elas parecem detalhe operacional e não são: cada uma protege a entrevista de um viés diferente. | Decisão | O que fazer | Por quê | |---|---|---| | **Formato** | Presencial sempre que der | Você lê linguagem corporal, e o encontro cria proximidade que a chamada de vídeo não recria | | **Local** | Neutro e informal — cantina, praça, corredor do centro acadêmico | No local de trabalho da pessoa a conversa vira "reunião de negócio" e soa a apresentação de venda | | **Quem vai** | Duas pessoas da equipe, uma conduzindo e outra anotando | O empreendedor é otimista por natureza e vulnerável ao **viés de expectativa** — ver o que quer ver. A segunda pessoa é o controle | | **Duração pedida** | 20 a 30 minutos, combinados de antemão | Sem apertar, e respeitando o tempo de quem cedeu | | **Incentivo** | Nenhum. Não pague, não dê brinde | Em teste de usabilidade incentivo é aceitável; aqui não. Você procura quem pagaria **a você**, não o contrário | | **Gravação** | Evite | Maurya relata que gravar deixa parte das pessoas autoconsciente — mais um caso de viés do observador — e que ele nunca voltava a ouvir as gravações | | **Registro** | Cinco minutos imediatamente depois, ainda no local | Detalhe de memória decai rápido, e o que você lembra depois já está filtrado pelo que você queria ouvir | **O enquadramento que decide tudo:** monte a conversa como **aprendizado, não como venda**. Numa apresentação de venda quem fala é você, e fica fácil para a pessoa fingir que concorda — ou simplesmente mentir. No enquadramento de aprendizado os papéis se invertem: você define o contexto e depois cala a boca. E as pessoas costumam ajudar quando o pedido é de conselho, não de compra. --- ## 2. O roteiro, bloco a bloco Trinta minutos, sete blocos. **Não improvise a ordem.** ### Boas-vindas — preparar o terreno (2 min) Diga como a conversa vai funcionar. Cinco elementos obrigatórios: agradecimento, de onde veio a ideia, que não há produto pronto, que o objetivo é aprender e não vender, e o pedido de acordo. > Obrigado por reservar esse tempo. A gente está numa disciplina de projeto no CIn e está estudando [o tema]. A ideia surgiu porque [origem concreta e honesta — o que vocês observaram na Q1]. > > Antes de sair construindo qualquer coisa, a gente quer entender se outras pessoas vivem isso também. > > A conversa funciona assim: eu começo descrevendo os problemas que a gente acha que existem, e depois pergunto se algum deles faz sentido pra você. Só reforçando: **não existe produto pronto, e o objetivo é aprender com você, não vender nada.** Tudo bem assim? A última frase não é gentileza — é o que autoriza a pessoa a discordar de você. ### Coletar demografia (2 min) Perguntas introdutórias que capturam os atributos pelos quais você pretende **segmentar e qualificar** o usuário afoito. Escolha antes quais atributos importam; não pergunte tudo. Se o seu tema é deslocamento no campus, os atributos podem ser: como vem para a universidade, quantas vezes por semana, de onde, em que horário, se paga do próprio bolso. Se o tema é alimentação, são outros. **O teste de uma boa pergunta demográfica: a resposta muda a sua segmentação?** Se não muda, corte. ### Contar uma história (2 min) Ilustre os problemas com uma narrativa concreta, em primeira pessoa ou a partir do que vocês observaram na Q1 — não com uma lista abstrata. > Depois que a gente passou a semana passada observando [o lugar], notou uma coisa: [descrição factual do que foi visto, com detalhe]. Aí conversando com quem estava lá, apareceu [o incômodo]. Parece que [consequência]. > > Alguma coisa disso ressoa com você? Se o bloco da história for genérico, tudo o que vem depois vira concordância educada. ### Ranqueamento dos problemas (4 min) Enuncie de um a três problemas e peça que a pessoa os ordene. Termine com uma pergunta aberta. > Especificamente: > — Você também [problema 1]? > — [Problema 2] te atrapalha? > — [Problema 3] acontece com você? > — Tem algum outro incômodo nisso que eu não citei? > ⚠️ **Reordene a lista entre uma entrevista e outra.** A ordem em que você enuncia enviesa o ranqueamento. Isso é fácil de esquecer e barato de corrigir: mantenha três versões impressas do roteiro, com a lista em ordens diferentes, e alterne. A última pergunta — a aberta — é onde aparecem os problemas que você não tinha imaginado. Se ela nunca rende nada em dez entrevistas, o problema é o clima da conversa, não o entrevistado. ### Explorar a visão de mundo (15 min) Metade do tempo total. **O melhor roteiro aqui é "sem roteiro".** Vá problema por problema. Pergunte como a pessoa lida com aquilo **hoje**, e depois se cale. Deixe entrar em tanto detalhe quanto ela quiser. Faça perguntas de seguimento, mas **não lidere e não convença** ninguém do mérito de um problema — nem de uma solução. As quatro perguntas que sustentam o bloco: 1. **Como você faz isso hoje?** 2. **Consegue me guiar pelo passo a passo?** 3. **Que ferramentas, apps ou artefatos você usa? Como você ficou sabendo deles?** 4. **Pode me mostrar?** Enquanto ela responde, você faz duas coisas simultâneas: - **Classifica.** Além da resposta literal, julgue postura e tom para estimar como ela classificaria aquilo: *must-have*, *nice-to-have* ou *don't need*. - **Confere.** Este bloco existe também para **confirmar o ranqueamento anterior**. Às vezes a pessoa mente sem perceber — por educação ou porque não sabe. Se declarou *must-have* e não está fazendo nada a respeito, **há uma desconexão**, e ela é o achado. Se surgir um problema novo no meio, explore-o do mesmo jeito. Não volte ao roteiro para "cumprir o roteiro". ### Fechamento — gancho e pedido (2 min) Três coisas, nesta ordem: um gancho, a permissão de retorno e o pedido de indicação. O **gancho** existe porque você ainda não vai falar da solução em detalhe, mas precisa deixar algo memorável — uma frase curta que a pessoa consiga repetir para outra. Maurya usa o formato "X sem Y", construído sobre a alternativa existente que a própria pessoa acabou de citar. > Como eu disse no começo, não existe produto pronto. Mas a ideia é [frase de uma linha, ancorada no que ela usa hoje]. > > Com base no que a gente conversou, você toparia ver isso quando tiver alguma coisa pronta? > > E a gente está procurando conversar com mais pessoas como você. Você conhece alguém que passa por isso e que poderia me apresentar? O pedido de indicação é o que sustenta o ritmo das semanas seguintes. Peça em **todas** as entrevistas, inclusive nas ruins. ### Documentar (5 min) Nos cinco minutos seguintes, antes de qualquer outra coisa. **Cada um da dupla preenche o formulário sozinho, primeiro.** Só depois vocês comparam e consolidam uma entrada única. Preencher junto contamina: o primeiro a falar ancora o segundo. --- ## 3. O formulário de registro Estrutura mínima, adaptada de Maurya. Faça em formulário eletrônico — não em papel solto — porque no fim da semana você vai precisar cruzar respostas. ``` ENTREVISTA DE PROBLEMA Data: ____________ Local: ____________ Quem conduziu / quem anotou: ____________ CONTATO Nome: ______________________ Contato: ______________________ Como chegamos até essa pessoa: ______________________ DEMOGRAFIA (os atributos que vocês escolheram para segmentar) [atributo 1]: ______ [atributo 2]: ______ [atributo 3]: ______ PROBLEMA 1: ______________________________________________ Posição no ranqueamento: ____ Intensidade (must-have / nice-to-have / don't need): ____ Como resolve hoje: ______________________________________ Está satisfeita com isso? (sim / não / convive): ____ Tem gambiarra? Qual: ____________________________________ PROBLEMA 2: (idem) PROBLEMA 3: (idem) PROBLEMAS NOVOS QUE ELA TROUXE: __________________________ PALAVRAS DELA (verbatim — as expressões que ela usou para descrever o processo) __________________________________________________________ DESCONEXÃO OBSERVADA (declarou must-have e não faz nada? declarou irrelevante e improvisou solução?) __________________________________________________________ INDICAÇÕES: ______________________________________________ NOTAS: ___________________________________________________ ``` Dois campos merecem explicação. **Palavras dela (verbatim).** O melhor jeito de descobrir as palavras-chave da sua futura PUV é ouvir com atenção **como o cliente descreve o próprio fluxo de trabalho**. Anote a expressão exata, não a sua paráfrase. Isso é insumo direto da Q5. **Desconexão observada.** É o campo que separa a entrevista útil da entrevista simpática. Registre a contradição sem resolvê-la ali. --- ## 4. Revisão em lote, no fim da semana **Não mude o roteiro durante a semana.** Junte o lote inteiro, revise no fim, ajuste, e rode a semana seguinte com a versão nova. Trocar o roteiro no meio destrói a comparabilidade — você perde a capacidade de dizer se o sinal mudou porque as pessoas mudaram ou porque a pergunta mudou. O que se ajusta na revisão semanal: | Sinal no lote | Ajuste | |---|---| | Um problema levou *don't need* em bloco | Tire do roteiro | | Apareceu um *must-have* que não estava previsto | Entre no roteiro da semana seguinte | | Um subgrupo respondeu muito melhor que o resto | Estreite a demografia nessa direção | | Um subgrupo respondeu mal em bloco | Abandone esse segmento | | Uma expressão se repetiu em várias bocas | Marque — é candidata a virar o vocabulário da PUV | O objetivo declarado do ajuste é obter, a cada lote, **sinal mais forte e mais consistente que o lote anterior**. Se o sinal não melhora entre semanas, o problema está no segmento, não no roteiro. O destino final desse afunilamento é **um problema *must-have*** — que é o mesmo que dizer uma proposta única de valor. --- ## 5. Critérios de saída Você terminou quando entrevistou **pelo menos 10 pessoas** e consegue: - [ ] **Identificar a demografia do usuário afoito** — não "jovens universitários", mas os atributos concretos que separam quem sentiu a dor de quem não sentiu - [ ] **Nomear um problema *must-have*** — um, não três - [ ] **Descrever como o cliente resolve isso hoje** — a alternativa existente, com nome, custo e nível de satisfação Dez é o piso formal. O critério real é outro: **você terminou quando para de aprender** — quando consegue prever com precisão o que a pessoa vai dizer depois de duas ou três perguntas de qualificação. Para calibrar expectativa: Maurya recomenda preparar-se para 30 a 60 entrevistas em quatro a seis semanas, e no estudo de caso dele foram 15 antes de a equipe sentir que entendia o problema. Num semestre de Projetão, dez é uma meta honesta por oportunidade investigada — e é bem mais do que a maioria das equipes faz. --- ## 6. Modo de IA neste procedimento | Etapa | Modo | O que vale | |---|---|---| | Escolher os atributos demográficos e escrever a história do bloco 3 | 🟡 com apoio | A IA critica o roteiro, aponta pergunta que induz resposta, sugere onde você está vendendo em vez de perguntar | | A entrevista | 🔴 sem assistência | Não há como terceirizar. Se a IA participou, isso invalida o levantamento e precisa ser declarado | | Transcrição e organização do lote | 🟢 coprodução | Organizar, agrupar, contar. Mas a classificação *must-have* / *nice-to-have* é sua — ela depende de tom e postura que só quem estava lá viu | | Síntese semanal | 🟡 com apoio | Peça à IA que aponte contradições entre entrevistas e que **liste o que os dados não sustentam**, antes de pedir conclusão | Um pedido útil à IA depois do lote: *"aqui estão as dez fichas; me diga quais afirmações da minha síntese não estão sustentadas por nenhuma delas."* --- ## 7. Os modos de falha desta entrevista 1. **Virou pitch.** Você falou mais que a pessoa. Sintoma: o campo "palavras dela" está vazio. 2. **Ranqueamento enviesado pela ordem.** Você leu a lista sempre igual. 3. **Aceitar o *must-have* declarado.** Não conferiu se ela faz alguma coisa a respeito. 4. **Perguntar quanto pagaria.** Não há razão econômica para o cliente responder outra coisa que não um número baixo — e a pergunta o constrange. Se você precisa mesmo testar disposição a pagar, o teste é um pedido real, não uma pergunta hipotética. 5. **Trocar entrevista por formulário.** O formulário pressupõe que você já sabe as perguntas certas e, ao fixar as alternativas, as respostas certas. Ele serve **depois**, para verificar quantitativamente o que a entrevista revelou — nunca antes. 6. **Só entrevistar quem já concorda com você.** Amigos servem para treinar o roteiro e para chegar a gente dois ou três graus adiante. Não servem como amostra. 7. **Não documentar na hora.** Duas horas depois você já não tem a entrevista; tem a sua interpretação dela. --- ## Fontes - **Maurya, Ash**, *Running Lean*, cap. 6 e 7 — o roteiro cronometrado, o formulário, os critérios de saída, a revisão semanal em lote, as sete decisões logísticas, a âncora das alternativas existentes - **Blank, Steve**, *The Four Steps to the Epiphany* — a apresentação de problema como quebra-gelo que **elicita** em vez de convencer; "não tente convencer o cliente de que ele tem o problema que você descreve" - **Krug, Steve**, *Rocket Surgery Made Easy*, citado por Maurya — "recrute com folga e avalie na curva" # Quem entrevistar — Quest #2 Abra este arquivo ao montar a lista de pessoas. Ele responde três perguntas: **quem** você precisa ouvir (os papéis), **como achar** essas pessoas, e **o que dizer** ao pedir a conversa. --- ## 1. Os seis papéis de compra A regra base do Projetão — cliente é quem paga, usuário não paga — é um começo, e é grosseira demais para sustentar um projeto. Steve Blank decompõe o lado do cliente em cinco papéis, mais um sexto que ninguém procura e que aparece sozinho. | Papel | Quem é | O que ele decide | Onde erra a equipe | |---|---|---|---| | **Usuário final** | Quem usa no dia a dia — aperta os botões, toca, ama e odeia o produto | Nada, em muitos casos | Assumir que quem usa decide. Crianças são um grande mercado consumidor e usuárias de muitos produtos — quem compra são os pais | | **Influenciador** | Quem acha que tem participação na entrada do produto na empresa ou na casa | Opina, e é ouvido | Ignorar o técnico da área ou o filho de dez anos cujas preferências moldam a escolha da família | | **Recomendador** | Também influencia, mas com uma diferença: **pode fazer ou quebrar a venda** | Veta ou endossa | Confundir com influenciador. O chefe de departamento que decreta "os computadores novos serão da marca X" é recomendador, não influenciador | | **Comprador econômico** | Quem tem o orçamento e precisa aprovar a despesa | Libera ou não o dinheiro | Não descobrir quem é. Pode ser o adolescente com verba semanal de música, ou o cônjuge com o orçamento da viagem | | **Decisor** | Pode ser o comprador econômico, ou alguém acima dele. Tem a palavra final, independentemente de todos os anteriores | Decide | Parar no comprador econômico | | **Sabotador** | Quem perde estabilidade, quadro de pessoal, verba ou espaço se o seu produto entrar. **Você não vai procurá-lo — ele vai ver você chegando** | Atrasa, complica, esvazia | Achar que só existe em empresa grande. Na compra doméstica, pode ser o membro da família que se acostumou com o carro velho e não quer dirigir algo diferente | Nem todo produto tem hierarquia tão complexa. Mas **quase toda venda envolve mais de uma pessoa**. Em produto de consumo os papéis continuam existindo, só que com nomes familiares: mãe, pai, filho, colega de apartamento, coordenador do curso. ### O que fazer com o sabotador É o papel mais esquecido e o que mais mata piloto dentro de organização. A recomendação de Blank é operacional, não retórica: **preveja quem seria mais ameaçado pelo seu produto, entenda a influência dessa pessoa na organização, e monte uma estratégia que na pior das hipóteses neutralize essa influência e na melhor a converta em aliada.** No Projetão isso costuma aparecer quando a equipe propõe um sistema que substitui o trabalho manual de alguém — a pessoa que hoje é a única que sabe fazer o processo, e cuja importância vem exatamente disso. Se você não a entrevistou, não sabe se o projeto entra. --- ## 2. O mapa de influência A entrega da Q2 não é um par binário cliente/usuário. É um **mapa de influência**, e ele se monta em duas etapas. **Etapa 1 — mapa organizacional.** Liste todas as pessoas que você consegue imaginar influenciando a decisão de compra, e desenhe quem cerca o usuário do produto. Na venda para empresa, inclua cargo e posição na estrutura. Na venda para consumidor o diagrama parece enganosamente simples — mas o consumidor também tem uma teia de influenciadores. **Etapa 2 — mapa de influência.** Sobre o mapa organizacional, responda: **quem precisa ser convencido, e em que ordem, para que a adoção aconteça?** É isso que transforma uma lista de pessoas num mapa. **Formato sugerido para a entrega:** | Papel | Nome/função concreta | Já entrevistamos? | O que essa pessoa ganha | O que essa pessoa perde | Precisa ser convencida antes de quem? | |---|---|---|---|---|---| | Usuário final | | | | | | | Influenciador | | | | | | | Recomendador | | | | | | | Comprador econômico | | | | | | | Decisor | | | | | | | Sabotador | | | | | | Duas colunas fazem o trabalho pesado. **"Já entrevistamos?"** expõe o buraco: quase sempre a equipe ouviu só o usuário final. **"O que essa pessoa perde"** é o que produz o sabotador — se todas as linhas estão em branco ali, você ainda não pensou no assunto. Se o comprador econômico já tem orçamento previsto para algo do seu tipo, anote. Se você vai precisar convencê-lo a **criar** verba, isso é um risco de projeto, não um detalhe. ### A escala de reconhecimento do problema, aplicada por papel Blank propõe classificar **cada tipo de cliente** — usuário, influenciador, recomendador, comprador econômico, decisor — num de três estágios de reconhecimento do problema: | Estágio | O que caracteriza | |---|---| | **Necessidade latente** | A pessoa tem o problema, ou tem o problema e sabe que tem | | **Necessidade ativa** | Reconhece o problema, está em dor e procura ativamente uma solução — mas ainda não fez nenhum trabalho sério para resolvê-lo | | **Visão** | Tem ideia de como seria a solução, pode até ter montado uma solução caseira e, no melhor caso, está preparada para pagar por algo melhor | O ponto operacional: **os papéis costumam estar em estágios diferentes.** O usuário final pode estar em "visão", com a gambiarra montada, enquanto o comprador econômico está em "latente" e nem sabe que existe um problema. Essa defasagem é a explicação mais comum para projetos que agradam a todos e não são adotados por ninguém. --- ## 3. Como achar as pessoas ### O princípio de partida **Comece por quem você já conhece** e que se encaixa no perfil. Depois use essas pessoas para chegar a dois ou três graus de distância. Isso serve para duas coisas ao mesmo tempo: você treina o roteiro com quem não custa caro errar, e consegue apresentações quentes para quem custa. Sobre a objeção previsível — "amigo é amostra enviesada": é verdade, e a resposta de Maurya é direta. **Falar com alguém é melhor que falar com ninguém.** Use amigos e família para praticar o roteiro e para chegar a gente mais distante, não como base de conclusão. ### Uma lista de 50 Blank recomenda montar uma lista de **50 contatos potenciais** antes de começar. Parece muito e acaba rápido. As fontes que ele lista, traduzidas para a realidade de uma equipe do CIn: | Fonte de Blank | Equivalente no Projetão | |---|---| | Redes sociais e amigos | Grupos de curso, entidades estudantis, WhatsApp de bairro | | Recrutadores, advogados, contadores | Professores, técnicos administrativos, coordenação | | Revistas e livros de referência do setor | Associações, sindicatos, conselhos profissionais da área do tema | | Investidores e fundadores | Empresas do Porto Digital, incubadoras, egressos | | — | As pessoas que vocês observaram na Q1. Voltem lá | **Priorize, sempre que possível, encontrar pessoas pelo mesmo canal que você usaria para conquistar clientes de verdade.** Se você só consegue entrevistar quem chega por indicação pessoal, isso já é uma informação sobre a viabilidade do seu canal. ### A lista paralela: inovadores Junto com a lista de contatos, monte uma **lista de inovadores** — empresas, departamentos ou pessoas da sua área que são respeitadas e costumam estar à frente do assunto. Em produto de consumo, é a pessoa a quem todo mundo pede opinião sobre o tema. Ela serve para duas coisas: essas pessoas "entendem" ideias novas com menos atrito, e a lista vira o começo de um conselho consultivo informal. E a pergunta que mantém a lista crescendo, feita em toda entrevista: ***"quem é a pessoa mais preparada que você conhece nesse assunto?"*** ### Amplie antes de estreitar Um erro comum é filtrar cedo demais em busca do usuário afoito perfeito. **Lance uma rede mais larga no começo**, para não travar num máximo local, e estreite entre os lotes semanais. Você terá oportunidade de apertar o filtro na rodada seguinte. --- ## 4. O que dizer ao pedir a entrevista ### Modelo A — pedido de apresentação, para você mandar a um conhecido Adaptado de Maurya. Duas partes: a mensagem para o conhecido, e o texto pronto que ele encaminha. A segunda parte existe porque **quanto menos trabalho o intermediário tiver, mais provável é que ele encaminhe**. > Oi [nome], tudo bem? Tenho um pedido rápido. > > Estou numa disciplina de projeto no CIn e a gente está tentando entender melhor a rotina de [público]. A ideia é conversar com algumas pessoas para entender o dia a dia delas e avaliar se vale a pena seguir com o projeto. > > Se você conhecer alguém que se encaixe, ficaria muito grato se pudesse encaminhar a mensagem abaixo. Pode adaptar como quiser. > > --- > > Olá, > > Sou aluno do Centro de Informática da UFPE. Estou numa disciplina de projeto em que a gente está estudando [tema, em uma frase concreta]. > > Gostaria muito de 30 minutos do seu tempo para entender como é o seu dia a dia em [atividade]. **Não estou vendendo nada** — estou pedindo conselho, e o que a gente aprender vai definir se o projeto continua ou não. > > Posso ir até onde for melhor para você. Tem algum horário nesta semana? > > Obrigado, > [nome] Três elementos não são opcionais: **"não estou vendendo nada"**, o pedido explícito de **conselho**, e o **tempo declarado**. Sem eles a pessoa não sabe em que está entrando e recusa por precaução. ### Modelo B — abordagem fria, por telefone ou mensagem Blank chama isso de **história de referência**. Ela tem quatro partes, nesta ordem: quem indicou, o problema que você tenta entender, o que você quer, e o que a pessoa ganha. > Oi, aqui é [nome], do CIn/UFPE. Como você viu, fui indicado pelo [nome de quem indicou]. > > A gente está estudando [o problema] e queria entender como você e a sua equipe lidam com isso hoje. **Não quero vender nada** — quero vinte minutos para entender o seu processo. > > Achei que você poderia me dar uma visão sobre isso e, em troca, posso compartilhar o que a gente levantou até agora sobre como esse assunto está sendo tratado em outros lugares. A última frase é a contrapartida, e ela precisa ser verdadeira. Se você não tem nada para devolver ainda, ofereça o que terá: o relatório da pesquisa, um resumo dos achados. **Transformar a conversa numa entrevista de verdade** — com direito a um texto, um post ou um vídeo publicado — é uma contrapartida que funciona. Duas frases que ajudam a abrir portas: - **A referência.** "Fulano me disse para falar com você" transpõe barreiras que nenhuma outra frase transpõe. Por isso você pede indicação em toda entrevista. - **A carta local.** Maurya observa que enfatizar a cidade no corpo da mensagem foi eficaz para marcar reuniões — as pessoas topam mais quando conseguem se identificar com quem pede. "Somos alunos daqui do Recife, do CIn" faz trabalho real. ### E quando a pessoa recusa Sempre pergunte: ***"se você está sem tempo, com quem eu deveria falar?"*** A recusa que devolve um nome custou nada e valeu uma entrevista. --- ## 5. Ritmo de prospecção Os números de Blank e Maurya, e a tradução honesta para um semestre de Projetão. | | Blank / Maurya | Numa quest | |---|---|---| | Lista inicial | 50 contatos | 20 a 30 nomes concretos, com nome e forma de contato | | Chamadas por dia | 10, por fundador, até encher a agenda | Uma rodada de contatos por dia útil, dividida na equipe | | Taxa de conversão | 50 contatos → 5 a 10 visitas marcadas | Espere a mesma ordem de grandeza. Se 20 contatos rendem 2 entrevistas, está normal | | Entrevistas por semana | 10 a 15 | 10 é a meta da quest, e é agressiva | | Total | 30 a 60 pessoas em 4 a 6 semanas | 10 por oportunidade investigada | Duas práticas que economizam tempo: - **Guarde estatísticas de acerto.** Que história de referência funcionou melhor? Que fonte de contato rendeu mais? Você está mais eficaz falando com que tipo de pessoa? Isso se descobre contando, não lembrando. - **A maior fonte de desperdício é a espera** — esperar retorno, cruzar agendas. Concentre a agenda: reserve blocos fixos de horário em que qualquer entrevista cabe, e ofereça esses blocos. E a expectativa emocional, que vale dizer em voz alta: **acostume-se a ser recusado.** Maurya descreve o próprio percurso de aversão ao contato direto com cliente; Blank descreve encarar o telefone, dar voltas em torno dele e não ligar. Não é sinal de que você não serve para isso. É a parte chata, e ela passa. --- ## 6. Modo de IA | Etapa | Modo | Observação | |---|---|---| | Montar o mapa de influência a partir do que você já ouviu | 🟡 com apoio | A IA pergunta "quem mais toca nisso?" e aponta papéis vazios | | Gerar hipóteses de sabotador | 🟢 coprodução | Bom uso: peça três candidatos a sabotador e o que cada um perderia. Você confere em campo | | Redigir a mensagem de pedido de entrevista | 🟢 coprodução | Gere variações, escolha uma, e **mande você mesmo**, do seu contato | | Encontrar as pessoas | 🔴 sem assistência | Achar gente é o trabalho da quest, não um resultado a ser gerado | | Estimar quantas pessoas o problema atinge | 🟡 com apoio | Qualquer número que a IA der precisa ser conferido na fonte primária antes de entrar na apresentação | --- ## Fontes - **Blank, Steve**, *The Four Steps to the Epiphany*, cap. 3 — os cinco tipos de cliente mais o sabotador; o mapa organizacional e o mapa de influência; a escala de reconhecimento do problema (latente / ativa / visão); a lista de 50, a lista de inovadores, a história de referência, o ritmo de 10 chamadas por dia e a taxa de 50 contatos para 5–10 visitas - **Maurya, Ash**, *Running Lean*, cap. 6 — começar por contatos de primeiro grau; o modelo de mensagem para encaminhamento; a carta local; oferecer contrapartida; ampliar antes de estreitar; 30 a 60 pessoas em 4 a 6 semanas; a resposta à objeção do viés de amigos --- # Quest #3 — Análise de Similares > **Objetivo.** Analisar os similares para poder fazer a escolha da oportunidade. | | | |---|---| | **Modo de IA** | 🟢 coprodução no levantamento · 🔴 sem assistência na verificação de cada similar · 🟡 com apoio na análise | | **Milestones** | **Problema** e **Similares** (ambos abrem aqui) | | **Entrega** | mapa de concorrentes e referências, com os valores que entregam e os que não entregam | | **Erro que mais custa** | listar cinco apps do mesmo setor e chamar isso de análise competitiva | --- ## Antes de começar 1. **Traga os 2–3 problemas da Q2.** A análise é feita **por problema**, não em geral. Sem isso, você vai listar concorrentes de uma categoria, não de uma dor. 2. **Traga as gambiarras que você observou.** Cada gambiarra é uma alternativa existente — e frequentemente a mais forte. 3. **Confirme quem é usuário e quem é cliente.** Num presente, quem paga não é quem usa, e os dois julgam valor de forma diferente. A análise precisa de duas colunas. --- ## O conceito que organiza a quest A pergunta que a maioria faz é *"quem são meus concorrentes?"*. Ela convida a uma lista de empresas do mesmo setor, e é por isso que a Q3 costuma sair rasa. A pergunta certa é a do Lean Canvas: > **Como o cliente resolve esse problema hoje?** — a pergunta do bloco Problema do Lean Canvas (Maurya) A resposta chama-se **alternativa existente**, e no Lean Canvas ela fica dentro do bloco **Problema** — não do bloco Solução. Isso não é detalhe de diagramação: a alternativa existente é um **fato observável sobre o problema**, a descrição do estado atual que o cliente aceita. É por isso que ela vira, mais adiante, a **âncora de preço e de expectativa** contra a qual o cliente vai julgar a sua solução. Duas consequências que derrubam projeto: - **A alternativa costuma não vir de um concorrente óbvio.** A maior alternativa às ferramentas de colaboração online não é outra ferramenta: é e-mail. - **Não fazer nada é alternativa viável**, se a dor não for aguda o bastante. No caso que o Maurya narra, a hipótese da equipe era competir com Flickr e SmugMug. As entrevistas mostraram que **60% dos clientes usavam apenas e-mail**. Toda a estratégia mudou. --- ## Similares = concorrentes + referências ### Concorrentes Soluções que as pessoas adotam para lidar com o problema — **mesmo quando não funcionam bem**. A definição que vale aqui não é a de setor, é a de função: > Concorrentes não são os que se parecem materialmente, mas os que **desempenham função semelhante**. ### Referências (ou inspirações) Soluções que **não têm relação com o problema escolhido**, mas que entregam valor de um jeito que interessa. > ⚠️ **Refino importante.** O site do Projetão diz que referências "dizem respeito ao **como** da solução". Cuidado: usar a referência como molde de implementação é o caminho mais rápido para uma curva de valor convergente — o padrão que Kim & Mauborgne descrevem como 1.600 vinícolas "diferentes da mesma maneira". > > A referência serve primeiro para informar **o quê** e **quanto vale** — qual nível de valor o usuário passou a esperar, e onde há lacuna. O *como* vem depois, e de preferência diferente. Ver **Alternativas existentes e referências — Quest #3** (neste arquivo). ### Os dois concorrentes que toda equipe esquece - **A gambiarra** que você achou na Q2. É o concorrente real, e frequentemente é boa. - **Não fazer nada.** Se a alternativa dominante é a inércia, seu desafio não é ser melhor que um app — é ser melhor que a acomodação. --- ## As perguntas da entrega 1. **Quem são os principais concorrentes?** Que soluções são usadas para resolver o mesmo problema que vocês pretendem atacar? 2. **Quais são as principais referências?** Soluções voltadas a outros problemas, mas que inspiram por entregarem algum valor que interessa. 3. **Que valores concorrentes e referências entregam?** 4. **Como eles entregam esses valores?** Funcionalidades e características principais. 5. **Que valores eles NÃO entregam?** A pergunta 5 sustenta a Q5 inteira. É ali que mora a sua proposta única de valor, se houver uma. --- ## Valor não é funcionalidade A confusão mais frequente da quest, e ela contamina a Q5. - **Valor** é o benefício percebido: conveniência, segurança, pertencimento, economia de tempo, status. - **Funcionalidade** é o mecanismo que entrega o valor: notificação push, mapa, ranking. "Tem notificação" não é valor. "Não me deixa esquecer" é valor; a notificação é um dos jeitos de entregá-lo — e pode não ser o melhor. Monte a tabela em **duas colunas separadas**. Se ficarem idênticas, você preencheu funcionalidade nas duas. --- ## O procedimento 1. **Volte à Q2** e liste os 2–3 problemas. 2. **Pergunte a campo:** "como você resolve isso hoje?" — e depois "pode me mostrar?". A resposta é a sua lista inicial, e é mais confiável que a busca na web. 3. **Amplie o espaço competitivo** pelas seis fronteiras, não pela lista de apps do setor. → **As seis fronteiras — Quest #3** (neste arquivo) 4. **Amplie com busca** (🟢 coprodução aqui a IA acelera muito): concorrentes diretos, indiretos, funcionais, internacionais, e os que já morreram — concorrente que fechou é informação valiosa. 5. **Verifique cada um.** Abra. Use, se der. Preço, público, o que promete. A IA vai citar produtos descontinuados e features que não existem mais. 6. **Teste os principais com usuários**, se der tempo — mesmas tarefas, mesmo roteiro, para você e para eles. → **Teste competitivo e auditorias — Quest #3** (neste arquivo) 7. **Separe valores de funcionalidades** em duas colunas. 8. **Monte a matriz de avaliação de valor dos concorrentes.** Só deles, ainda não a sua. → **Matriz de avaliação de valor — Quest #3** (neste arquivo) 9. **Marque os vazios.** Que valor ninguém entrega, ou todos entregam mal — e por quê. O passo 9 tem uma pergunta implícita que vale a nota: **por que esse vazio existe?** Frequentemente há um motivo estrutural — é caro, é chato, dá pouco lucro, é regulado — e esse motivo também vai valer para você. Descobrir isso na Q3 é barato. --- ## Referências desta quest | Arquivo | Quando | |---|---| | **As seis fronteiras — Quest #3** (neste arquivo) | No início. Como redefinir o espaço competitivo — setores alternativos, grupos estratégicos, cadeia de compradores, ofertas complementares, apelo funcional/emocional, tempo | | **Alternativas existentes e referências — Quest #3** (neste arquivo) | Ao montar a lista. O conceito de alternativa existente, âncora de preço, e o que fazer com referências | | **Matriz de avaliação de valor — Quest #3** (neste arquivo) | Ao consolidar. Como montar a matriz dos concorrentes, o que os eixos significam, como ler convergência | | **Teste competitivo e auditorias — Quest #3** (neste arquivo) | Se houver tempo de testar. Teste competitivo, auditoria de conteúdo e de experiência | | **Autodiagnóstico — Quest #3** (neste arquivo) | Antes de entregar | --- ### Antes de registrar pessoas | Arquivo | Quando | |---|---| | `../../metodo/consentimento.md` | Antes de ir perguntar "como você resolve hoje?" | --- ### Técnicas desta quest Fichas curtas de consulta rápida. Abra quando o procedimento acima mencionar a técnica. | Ficha | Para quê | |---|---| | **Percepção de Valor** (neste arquivo) | o que é valor, e por que não é preço nem funcionalidade | | **Usuário afoito (*early adopter*)** (neste arquivo) | com quem confirmar as alternativas | | **Entrevistas** (neste arquivo) | a pergunta "como você resolve hoje?" | --- ## Perguntas frequentes **"E se já existe alguém fazendo exatamente isso?"** Ótima notícia — significa que o problema é real, e alguém já pagou para descobrir isso. A pergunta passa a ser: o que essa pessoa não entrega, e por quê? Ver o passo 9. **"A equipe demora muito para se alinhar e decidir."** Se decisões travam, há dificuldade de entrosamento. Isso quase sempre melhora quando o grupo consegue estar concentrado na mesma coisa ao mesmo tempo, de preferência no mesmo lugar. A tecnologia permite distribuir o trabalho, mas discutir presencialmente costuma destravar. **"Quantos concorrentes preciso listar?"** Não há número. O critério é cobertura: se todos os seus similares vêm do mesmo setor e da mesma faixa de preço, você mapeou um grupo estratégico, não o espaço competitivo. --- ## Bibliografia desta quest | Obra | O que ela dá para a Q3 | |---|---| | **Kim & Mauborgne — A estratégia do oceano azul** | As seis fronteiras, a matriz de avaliação de valor, as armadilhas do oceano vermelho | | **Maurya — Running Lean** | Alternativa existente, âncora de preço, a pergunta certa na entrevista | | **Hanington & Martin — Universal Methods of Design** | Teste competitivo (15), inventário e auditoria de conteúdo (18), auditoria de experiência (25) | | **Anderson — A cauda longa** | O que muda quando o mercado é de nicho e a rivalidade deixa de ser soma zero | | **Osterwalder & Pigneur — Business Model Generation** | O mapa de ambiente: forças de mercado, da indústria, tendências e macroeconomia | | **Ries — A startup enxuta** | Bibliografia oficial da quest no site | # Alternativas existentes e referências — Quest #3 Abra este arquivo ao montar a lista de similares. Ele trata dos dois conceitos que a Q3 mais confunde: o que é uma **alternativa existente** e o que fazer com uma **referência**. --- ## 1. A alternativa existente ### A definição e a pergunta que a produz Alternativa existente é a resposta à pergunta: **como o seu usuário afoito resolve esse problema hoje?** A formulação de Maurya é econômica e vale decorar: *a menos que você esteja resolvendo um problema inteiramente novo — improvável —, a maioria dos problemas já tem solução em uso. E muitas vezes essa solução não vem de um concorrente óbvio.* Duas consequências, ditas explicitamente por ele: - **A maior alternativa às ferramentas de colaboração online não é outra ferramenta de colaboração: é e-mail.** - **Não fazer nada também é alternativa viável**, se a dor não for aguda o bastante. ### O caso que mostra o custo do erro Ao entrar nas entrevistas do CloudFire, a equipe esperava que a maioria dos pais estivesse usando SmugMug ou Flickr. Descobriu que **60% deles usavam apenas e-mail** para compartilhar fotos. Perguntados por que, citaram facilidade de uso — interessantemente, **não a própria facilidade, mas a de quem recebia**, tipicamente os avós. Apesar do limite de tamanho de anexo, todo mundo já sabia usar e-mail. O impacto disso na estratégia é o ponto: 80% dos entrevistados expressaram alguma frustração com a solução que usavam, mas 60% se viravam com uma **alternativa gratuita**. Ou seja, seria preciso justificar valor contra algo que não custa nada. > **A frase que resume o caso:** os clientes dos seus clientes também são seus clientes. ### Por que ela fica no bloco Problema do Lean Canvas Isto não é detalhe de diagramação, e é a parte que mais equipe erra. No Lean Canvas, a alternativa existente é listada **dentro do bloco Problema**, junto com os um a três problemas principais. A razão: ela é um **fato observável sobre o problema** — a descrição do estado atual que o cliente aceita — e não uma proposta sua. Colocá-la no bloco Solução transformaria uma observação de campo numa hipótese de projeto. A consequência prática aparece depois, na definição de preço. ### Âncora de preço e de expectativa Duas passagens de Maurya sustentam isso. Na análise das entrevistas: **os usuários afoitos usarão as alternativas existentes como âncoras contra as quais julgarão a sua solução, o seu preço e o seu posicionamento.** Se as alternativas são todas gratuitas, o seu produto tem de prometer e entregar valor suficiente para superar o fato de que o concorrente é de graça. Na definição de preço: uma das técnicas para estabelecer o preço inicial é **precificar contra a lista de alternativas existentes do bloco Problema** — elas fornecem âncoras de preço de referência. No caso do CloudFire, as âncoras iam de US$ 24 a US$ 39 por ano (Flickr, SmugMug) até US$ 99 por ano (MobileMe, que entregava bem mais que fotos e vídeos); o preço inicial escolhido foi US$ 49 por ano. **O que isso significa na Q3:** a coluna de preço da sua tabela de similares não é decoração. É o insumo da Q7. Levante o preço de cada alternativa existente agora, com o valor e a data, e guarde. ### A gambiarra é uma alternativa existente E costuma ser a mais forte, porque foi construída pela própria pessoa, sob medida, e já está integrada à rotina dela. Traga da Q2 todas as gambiarras que você observou e coloque-as na tabela de similares como linhas de pleno direito, com as mesmas colunas dos concorrentes formais. Uma gambiarra estável e satisfatória é um problema **já resolvido**. Isso é informação, não fracasso — só custa caro descobrir depois. ### Onde procurar alternativas que não aparecem na busca | Fonte | O que ela devolve | |---|---| | A pergunta "como você faz hoje?" na entrevista | A lista real, e é mais confiável que a busca na web | | A pergunta "pode me mostrar?" | O que a pessoa esqueceu de mencionar porque é automático | | Almoçar com os entrevistados mais receptivos | Blank recomenda perguntar a eles quem são os concorrentes potenciais, internos e externos, e quem mais é inovador nesse espaço. É notável quanto se aprende com quem eventualmente vai comprar | | Concorrentes mortos | Um produto descontinuado é evidência de que alguém tentou e de por que não deu | | Processos internos | Numa organização, a alternativa pode ser uma planilha mantida por uma pessoa há oito anos | --- ## 2. Referências ### O que são Soluções que **não têm relação com o problema escolhido**, mas que entregam algum valor de um jeito que interessa. É o que Osterwalder e Pigneur, no mapa de ambiente, chamariam de olhar para tradições de modelo de negócio de outros mercados — a pergunta útil deles é: *de que tradição de modelo de negócio vêm esses produtos substitutos?*, com exemplos como trem de alta velocidade contra avião, telefone celular contra câmera fotográfica. ### A correção que mais importa nesta quest > ⚠️ **O site do Projetão diz que as referências "dizem respeito ao *como* da solução". Essa formulação é imprecisa e leva a um erro previsível.** > > **Por que é imprecisa:** se a referência entra como molde de implementação — "vamos fazer o *onboarding* igual ao do app X" —, o resultado é uma solução construída com os mesmos mecanismos que todo mundo já usa. Kim & Mauborgne descrevem exatamente esse padrão na indústria vinícola americana: mais de 1.600 vinícolas concorrendo em 2000, com **enorme convergência** entre as curvas de valor. Todas as marcas premium exibiam basicamente o mesmo perfil estratégico — preço alto e alto nível de oferta em todos os fatores de competição. Nas palavras dos autores, aos olhos do mercado **todos eram "diferentes da mesma maneira"**. > > **A formulação corrigida:** a referência serve primeiro para informar **o quê** e **quanto vale** — qual nível de valor o usuário passou a esperar em alguma dimensão, e onde há lacuna. O *como* vem depois, e de preferência diferente. Um exemplo do próprio livro mostra a diferença entre copiar o *como* e importar o *quê*: o Cirque du Soleil incorporou à sua curva de valor fatores **não circenses** — tema, várias produções simultâneas, ambiente refinado para o espectador, música e dança artística — vindos do teatro, uma alternativa de entretenimento. Não copiou o formato do teatro; importou o nível de valor que o teatro estabeleceu em ambiente e narrativa, e o entregou por outro mecanismo. ### Como registrar uma referência sem que ela vire cópia Use três colunas, e preencha nesta ordem: | Referência | Valor que ela entrega bem (o **quê**) | Mecanismo que ela usa (o **como**) | |---|---|---| | | | | E depois responda duas perguntas por linha: 1. **O meu usuário já experimentou esse nível de valor em algum lugar?** Se sim, ele virou expectativa — e não entregar isso será percebido como falta, não como escolha. 2. **Existe outro mecanismo que entregue o mesmo valor no meu contexto?** Se você não consegue imaginar nenhum, provavelmente está copiando. A segunda pergunta é a que separa referência de plágio de interface. ### Onde a referência costuma ser mais útil - Quando o valor em questão é **transversal** — confiança, previsibilidade, rastreabilidade, sensação de progresso. - Quando o seu setor **treinou o usuário a esperar pouco**. Nesse caso, o padrão de outro setor é a única régua honesta disponível. O caso EFS, narrado por Kim & Mauborgne, ilustra isso: o serviço que os clientes mais valorizavam era **confirmação rápida das transações**, algo que a indústria de câmbio corporativo nunca havia oferecido. A solução final incluiu rastreamento de pagamentos "do mesmo jeito que a FedEx e a UPS fazem com entregas expressas". A referência veio da logística, e o que foi importado foi o **valor** — saber onde a coisa está —, não o software da FedEx. --- ## 3. As duas listas na entrega A pergunta 3 da entrega ("que valores concorrentes e referências entregam?") só é respondível se as duas listas estiverem separadas e se cada linha tiver a mesma estrutura. | Coluna | Concorrente | Referência | |---|---|---| | Nome | obrigatório | obrigatório | | Como você chegou nele | entrevista / busca / observação | — | | Resolve qual dos seus problemas | obrigatório | não resolve nenhum — é o que a define | | Valor entregue | obrigatório | obrigatório | | Funcionalidade que entrega esse valor | obrigatório | obrigatório, mas em coluna separada | | Preço e modelo de cobrança | obrigatório — é âncora | opcional | | Público | obrigatório | opcional | | Nível de satisfação de quem usa | obrigatório, e vem de campo | — | | Valor que **não** entrega | obrigatório | obrigatório | A última linha sustenta a Q5 inteira. E uma verificação de sanidade: se a sua tabela de concorrentes não tem nenhuma linha que seja **uma gambiarra** ou **não fazer nada**, ela está incompleta — porque a Q2 quase sempre encontra as duas. --- ## 4. Modo de IA | Etapa | Modo | Observação | |---|---|---| | Ampliar a lista de concorrentes e referências | 🟢 coprodução | É onde a IA acelera mais. Peça por fronteira (ver `seis-fronteiras.md`), não em geral | | Verificar cada item | 🔴 sem assistência, na prática | Abra o produto. Use, se der. Confira preço e público na página oficial, com data. A IA cita produtos descontinuados e funcionalidades que não existem mais | | Separar valor de funcionalidade | 🟡 com apoio | Bom pedido: "aponte quais das minhas linhas de 'valor' são na verdade funcionalidade" | | Definir a âncora de preço | 🟡 com apoio | O número precisa vir da página do produto, não da IA | --- ## Fontes - **Maurya, Ash**, *Running Lean*, cap. 3 e 7 — alternativa existente listada no bloco Problema; o e-mail como maior alternativa às ferramentas de colaboração; não fazer nada como alternativa viável; o caso CloudFire (60% usavam só e-mail; 80% frustrados; a facilidade era a de quem recebia); a alternativa existente como âncora de julgamento e de preço; o preço inicial de US$ 49/ano ancorado em US$ 24–39 e US$ 99 - **Kim, W. Chan & Mauborgne, Renée**, *A estratégia do oceano azul*, cap. 2 e 4 — as mais de 1.600 vinícolas com curvas convergentes e "diferentes da mesma maneira"; os fatores não circenses do Cirque du Soleil vindos do teatro; o caso EFS e a confirmação rápida de transações - **Blank, Steve**, *The Four Steps to the Epiphany*, cap. 3 — perguntar aos próprios clientes quem são os concorrentes e quem são os inovadores do espaço - **Osterwalder, Alexander & Pigneur, Yves**, *Business Model Generation* — o mapa de ambiente e as perguntas sobre produtos e serviços substitutos, incluindo de que tradição de modelo de negócio eles vêm # Autodiagnóstico — Quest #3 Faça este exercício **antes** de entregar. É o mesmo que o mentor vai fazer depois. --- ## Os dois milestones que abrem aqui A Q3 alimenta dois dos treze milestones, avaliados separadamente: **Problema** (compreensão do problema efetivo que se tenta resolver) e **Similares** (profundidade sobre concorrentes, práticas e boas referências). A escala 0–5 está em `metodo/avaliacao.md`. O salto 3 → 4 tem forma específica aqui: sair de *"listamos os concorrentes"* para *"sabemos o que cada um entrega, o que nenhum entrega, e por que esse vazio existe"*. --- ## Milestone **Problema** ### 1. Formulação | | | |---|---| | **2** | O problema é a ausência da sua solução ("as pessoas não têm um sistema para X"). | | **3** | É um problema de verdade, mas enunciado de forma tão ampla que serviria a vários projetos. | | **4** | Enunciado como incômodo observado, com quem sente, em que situação, e com que frequência. | | **5** | O acima, mais o que a equipe **descartou** do enunciado original e por quê. | ### 2. Evidência de que o problema é sentido | | | |---|---| | **2** | "É um problema conhecido." | | **3** | Relato de entrevista, sem verificação de comportamento. | | **4** | Para cada problema, há gente que **faz alguma coisa** a respeito — gambiarra, produto pago, processo manual — e a equipe descreve o quê. | | **5** | O acima, mais o registro de quem convive sem fazer nada, e o que isso diz sobre o tamanho da oportunidade. | ### 3. Alternativa existente e dimensionamento | | | |---|---| | **2** | "Não existe nada parecido", e um número grande citado sem fonte. | | **3** | Alternativas listadas sem preço nem satisfação; fonte citada, mas genérica ou lida em resumo. | | **4** | Para cada problema, **como o cliente resolve isso hoje**, com preço e satisfação, incluindo a gambiarra e o "não fazer nada" — e a bifurcação respondida com dado de fonte primária, com ano, conferido. | | **5** | O acima, com a âncora de preço explicitada e o reconhecimento de onde o dado **não** cobre o que a equipe observou. | --- ## Milestone **Similares** ### 4. Cobertura do espaço competitivo | | | |---|---| | **2** | Cinco aplicativos do mesmo setor, achados na mesma busca. | | **3** | Lista mais larga, mas todos na mesma faixa de preço e atendendo ao mesmo papel de compra. | | **4** | A lista passa no teste das seis fronteiras: há similar de outro setor, de outra faixa de preço, atendendo a outro papel, fora do momento "durante", com outro apelo, e um produto que morreu. | | **5** | O acima, com a explicação de por que cada fronteira devolveu o que devolveu — inclusive as vazias. | ### 5. Valor separado de funcionalidade | | | |---|---| | **2** | Uma coluna só, ou duas colunas com o mesmo conteúdo. | | **3** | Colunas separadas, mas a de valor ainda contém mecanismo ("tem mapa", "manda notificação"). | | **4** | A coluna de valor descreve benefício percebido, na língua do usuário; a de funcionalidade descreve mecanismo. Dá para trocar o mecanismo sem trocar o valor. | | **5** | O acima, com um caso em que o mesmo valor é entregue por mecanismos diferentes em concorrentes diferentes. | ### 6. Verificação | | | |---|---| | **2** | A lista veio de uma conversa com IA, ou de uma matéria, e ninguém abriu nada. | | **3** | Os principais foram abertos; os demais, não. | | **4** | Cada similar foi aberto, com preço, público e promessa conferidos na fonte, com data. Os não verificáveis estão marcados como tal. | | **5** | O acima, mais teste com usuários em dois similares, com tarefas idênticas. | ### 7. Referências | | | |---|---| | **2** | Não há referências, ou as "referências" são concorrentes. | | **3** | Há referências, mas registradas como inspiração de interface. | | **4** | Cada referência tem o **valor** separado do **mecanismo**, e a equipe diz que expectativa ela criou no usuário. | | **5** | O acima, com hipótese explícita de mecanismo **diferente** para entregar o mesmo valor no contexto do projeto. | ### 8. Os vazios | | | |---|---| | **2** | Não há coluna de "valor que não entregam". | | **3** | Os vazios estão listados, mas sem explicação. | | **4** | Os vazios estão nomeados e há uma hipótese de **por que cada um existe** — é caro, é chato, dá pouco lucro, é regulado, exige escala. | | **5** | O acima, com a avaliação honesta de quais desses motivos também valem para a equipe. | --- ## Checklist rápido - [ ] A análise foi feita **por problema**, ou em geral? - [ ] A gambiarra da Q2 e o "não fazer nada" estão na tabela, como linhas próprias? - [ ] Eu **abri** cada similar que estou citando, e tenho o preço com data? - [ ] As minhas duas colunas — valor e funcionalidade — estão diferentes uma da outra? - [ ] Algum similar da lista **não** veio de busca por palavra-chave? - [ ] Consigo dizer, em uma frase, o que cada concorrente promete? - [ ] Para cada vazio, tenho uma hipótese de por que ele existe? - [ ] As curvas de valor dos meus concorrentes se parecem entre si — e eu percebi isso? **Sinal de alerta:** se todos os seus similares vêm do mesmo setor e da mesma faixa de preço, você mapeou um grupo estratégico, não o espaço competitivo. **Segundo sinal:** se você não achou nenhum concorrente, o problema é da busca, não do mercado. Volte à pergunta de campo: *como você resolve isso hoje?* --- ## Registro de trajetória (modo de IA) Meia página, entregue junto. A Q3 é a quest em que o registro mais rende, porque é onde a IA mais gera e mais erra. 1. **Modo em que a quest foi feita, e onde você saiu dele.** *Na Q3, o levantamento é 🟢 coprodução e a análise de valor é 🟡 com apoio.* 2. **O que a IA gerou e você descartou — e por quê.** *Típico da Q3: produtos descontinuados, funcionalidades que não existem mais, preços desatualizados, concorrentes que nunca existiram. Diga quantos itens da lista gerada sobreviveram à verificação — essa fração já é um resultado.* 3. **O que você verificou, e como.** *Quais preços você conferiu na página oficial, em que data, e onde a IA estava errada.* 4. **O que ainda não sabe.** *Exemplos honestos: "não testamos o concorrente X porque exige assinatura paga"; "não achamos ninguém que já tivesse usado a alternativa Y".* --- ## Como o mentor vai ler 1. **"Como as pessoas resolvem isso hoje?"** Se a resposta for "não resolvem", a Q2 não foi bem feita. 2. **"Por que esse vazio existe?"** A pergunta que separa 3 de 4. Se ninguém entrega aquele valor, alguém já tentou e desistiu — ou o custo é proibitivo. 3. **"O que vocês testaram, e o que só leram?"** Uma lista de similares não verificados é uma lista de hipóteses. 4. **"Se já existe alguém fazendo isso, por que vocês?"** A resposta certa não é "faremos melhor". É o que a matriz mostra que ninguém está fazendo. Divergência entre a sua auto-avaliação e a leitura do mentor é informação útil, não constrangimento. # Matriz de avaliação de valor — Quest #3 Abra este arquivo ao consolidar a Q3, depois de ter a lista de similares. Aqui está como montar a matriz **dos concorrentes** — ainda não a sua —, o processo de quatro etapas em equipe, e como ler o desenho resultante. --- ## 1. O que a matriz é, e o que ela não é A matriz de avaliação de valor tem dois eixos. | Eixo | O que representa | |---|---| | **Horizontal** | Os **fatores de competição** — os atributos em que o setor investe e concorre hoje | | **Vertical** | O **nível de oferta** de cada fator, **segundo a percepção dos compradores**. Pontuação mais alta significa que a empresa oferece mais naquele atributo, e portanto investe mais nele | A **curva de valor** é a representação gráfica do desempenho relativo de uma empresa em cada fator. É o componente básico da matriz. Duas observações sobre o eixo vertical que evitam a maioria dos erros: - **A percepção é a do comprador, não a sua.** Kim & Mauborgne dão o exemplo do gerente de refeições de uma companhia aérea: ele tem sensibilidade apurada para comparar lanches, e é justamente esse foco que dificulta a avaliação consistente — o que parece diferença enorme para ele pode não importar para o cliente, que olha a oferta inteira. - **Preço é um fator como os outros, com uma inversão a lembrar:** pontuação mais alta em preço significa **preço mais alto**. E o aviso dos próprios autores, que vale para calibrar a expectativa da equipe: **desenhar a matriz nunca é fácil**, e mesmo identificar os fatores críticos não é nada simples. **A lista final costuma ser muito diferente da primeira versão.** Se a sua saiu redonda de primeira, provavelmente ela é a lista de funcionalidades que vocês já tinham na cabeça. --- ## 2. O que entra no eixo horizontal Os fatores de competição não são funcionalidades. São **as dimensões em que o setor disputa**, formuladas na linguagem do comprador. | Errado (funcionalidade / jargão) | Certo (fator de competição) | |---|---| | "tem notificação push" | previsibilidade, ou não deixar esquecer | | "megahertz" | velocidade | | "temperatura das fontes termais" | água quente | | "integra com API X" | quanto trabalho manual sobra | O teste dos autores é linguístico e é rápido: **os fatores estão expressos em termos que o comprador compreende e valoriza, ou em jargão operacional?** A linguagem da matriz revela se a visão da equipe é de fora para dentro, orientada ao mercado, ou de dentro para fora, movida pelas operações internas. **Quantos fatores.** Não há número consagrado no livro, mas as matrizes reproduzidas nele trabalham com algo entre seis e dez. Menos que isso apaga diferença; mais que isso vira planilha e deixa de ser leitura visual. **De onde vêm.** Três fontes, nesta ordem de confiabilidade: 1. **O que os entrevistados da Q2 disseram valorizar**, nas palavras deles. 2. **O que os similares anunciam** na própria comunicação — é o que eles acham que importa. 3. **O que vocês acham.** Última, e marcada como hipótese. --- ## 3. O processo de quatro etapas Kim & Mauborgne descrevem um processo estruturado, desenvolvido ao longo de vinte anos, para desenhar e analisar matrizes. Ele foi aplicado no caso EFS — um grupo de serviços financeiros — e é adaptável a uma equipe de Projetão quase sem mudança. As quatro etapas abaixo são as do livro; o que está em cada linha "na quest" é adaptação nossa. ### Etapa 1 — Despertar visual **O problema que ela resolve:** discutir mudança de estratégia antes de resolver as divergências sobre a situação atual. A equipe fala de futuro sem concordar sobre o presente, e a conversa não fecha. **O que a EFS fez:** reuniu mais de vinte gerentes seniores, dividiu em duas equipes, e pediu que cada uma produzisse a curva de valor da empresa comparada à dos concorrentes — **em 90 minutos**. O raciocínio por trás do prazo: se a estratégia fosse nítida, 90 minutos bastariam. **O que aconteceu:** foi doloroso. As equipes discutiram acaloradamente o que constituía um fator de competição. Regiões diferentes reivindicavam fatores próprios. Alguém defendeu confirmação instantânea de transação — serviço que ninguém mais considerava necessário e que a indústria jamais oferecera. Ao fim, os gráficos revelaram **falta de foco** (investimento espalhado em muitos fatores) e, pior, **semelhança com os concorrentes**. **Na quest:** dê 90 minutos, cronometrados, para a equipe desenhar a curva de valor dos três principais similares, **sem consultar nada**. Depois compare com os dados levantados. A discordância dentro da equipe é o produto desta etapa, não um obstáculo a ela. ### Etapa 2 — Exploração visual **O problema que ela resolve:** desenhar a matriz de dentro do prédio. **A regra:** *nunca terceirize seus olhos e ouvidos.* Os autores comparam ao pintor que não pinta a partir da descrição de outra pessoa. E observam que o insight de Michael Bloomberg — de que quem fornece informação financeira também precisa oferecer análise on-line — deveria ser óbvio para qualquer um que **tivesse observado operadores usando os serviços concorrentes**, com papel, lápis e calculadora ao lado da tela. **Quem observar, em ordem:** | Quem | Por quê | |---|---| | Clientes | o óbvio, e insuficiente | | **Não clientes** | quem escolheu não usar nada | | **Usuários, quando o cliente não é o usuário** | eles julgam valor por outro critério | | Produtos e serviços complementares | fonte de ideias de pacote | | **Alternativas de outro setor** | como as pessoas atendem à mesma necessidade por outro caminho | E o ponto que separa esta etapa de uma rodada de entrevistas: **não basta conversar com essas pessoas, é preciso observá-las em ação.** **O que a EFS fez:** mandou os gerentes a campo por quatro semanas para explorar as seis fronteiras. Cada gerente deveria entrevistar e observar dez pessoas — incluindo clientes perdidos, clientes novos, clientes de concorrentes e clientes das alternativas. **O resultado inverteu conclusões da etapa 1.** Os gerentes de relacionamento, vistos por quase todos como fator crítico de sucesso e motivo de orgulho da empresa, eram o calcanhar de aquiles: os clientes detestavam perder tempo com eles. Na visão dos clientes, os gerentes de relacionamento eram "salvadores de relacionamento", porque a EFS não cumpria o que prometia. E o fator mais valorizado — confirmação rápida das transações — era exatamente o que **um único gerente** havia sugerido antes, e todo o resto havia ignorado. **Na quest:** este é o passo que a maioria pula, e é o que separa a Q3 rasa da Q3 boa. Volte a campo com a lista de similares na mão e pergunte a quem usa. Inclua quem **abandonou** um similar. ### Etapa 3 — Feira de estratégia visual **O problema que ela resolve:** decidir por política interna em vez de por mérito. **O que a EFS fez:** as equipes apresentaram as matrizes num evento com executivos e, sobretudo, **público externo** — pessoas que os gerentes encontraram em campo: não clientes, clientes de concorrentes e alguns dos clientes mais exigentes. As regras do formato, que são o que interessa reproduzir: | Regra | Racional declarado | |---|---| | **Dez minutos por curva**, no máximo | qualquer ideia que leve mais de dez minutos para explicar é provavelmente complicada demais para ser boa | | Desenhos **afixados na parede**, visíveis a todos | comparação simultânea, não sequencial | | Cada avaliador convidado recebe **cinco adesivos** para colar ao lado das estratégias preferidas | pode colar os cinco numa só, se achar cativante | | Depois da votação, cada um **justifica** — inclusive por que **não** votou nas outras | a justificativa da recusa é a informação mais rica | O efeito colateral que os autores destacam: a transparência e o imediatismo do método **eliminam as considerações políticas** que costumam ser endêmicas no planejamento estratégico. Os gestores tinham de confiar na clareza das curvas, não na posição hierárquica. **O que a EFS aprendeu ali:** cerca de **um terço** do que julgavam ser fatores de competição básicos era, na verdade, secundário para os clientes. Outro terço estava mal articulado ou fora ignorado na etapa 1. **Na quest:** faça a feira com gente de fora da equipe — outra equipe do Projetão, os entrevistados da Q2, o mentor. Cinco adesivos por pessoa, dez minutos por curva. **Peça a justificativa da recusa**, não só a do voto. ### Etapa 4 — Comunicação visual **O que a EFS fez:** distribuiu um diagrama de **uma página** comparando o perfil estratégico novo com o anterior, para que todos vissem onde a empresa estava e onde deveria concentrar esforço. Os gestores que participaram reuniram suas equipes para explicar o gráfico — o que seria eliminado, reduzido, elevado e criado. **Na quest:** a matriz consolidada da Q3 é o artefato que vocês vão levar para a Q5, e é o que a banca vai ver. Se ela não couber numa página legível, ela não comunica. --- ## 4. Como ler a matriz As curvas contêm conhecimento estratégico sobre a situação presente e futura de um negócio. Cinco leituras, todas do livro — e todas aplicáveis **à matriz dos concorrentes**, que é o que a Q3 entrega. | Padrão no desenho | Diagnóstico | O que fazer na Q3 | |---|---|---| | **Curvas que se confundem entre si** | O setor se perdeu no oceano vermelho. A disputa é por custo ou qualidade, e o crescimento tende a ser lento, exceto por sorte de setor dinâmico | Este é o achado mais valioso da quest. Convergência entre todos os similares é o vazio que a Q5 vai ocupar | | **Curva alta em todos os fatores** | Excesso de oferta. A pergunta é se fatia de mercado e rentabilidade justificam o investimento. Provavelmente há entrega em excesso de elementos que só agregam valor incremental | Marque: há espaço para alguém **eliminar e reduzir**, não só elevar e criar | | **Contradição estratégica** | Nível alto num fator, com abandono de outro que o sustenta. O exemplo do livro: investir pesado em facilidade de uso do site e não corrigir a lentidão. Ou "menos por mais" — menos serviço que o melhor concorrente, a preço maior | Cada contradição observada é uma hipótese de por que aquele concorrente não domina o mercado | | **Rótulos em jargão** | Visão de dentro para fora. Se a matriz fala em megahertz em vez de velocidade, a empresa está longe de criar demanda | Reescreva os fatores na língua do comprador antes de continuar | | **Uma curva que se destaca das demais** | Alguém já encontrou o vazio | Estude essa. É o similar mais informativo da lista | ### As três qualidades de uma boa curva Servem como teste inicial de viabilidade comercial, e você vai usá-las na Q5. Na Q3, use-as para avaliar os **concorrentes**: | Qualidade | O que significa | Sintoma de ausência | |---|---|---| | **Foco** | A empresa não dispersa esforço entre todos os fatores | Estrutura de custo alta, modelo complexo de executar | | **Singularidade** | A forma da curva diverge das demais — resultado de observar as alternativas, não de comparar-se aos rivais | Estratégia é mera imitação | | **Mensagem consistente** | Uma frase clara, que anuncia oferta verdadeira | Empresa orientada para si própria, ou inovação pela inovação | O teste da mensagem, na formulação dos autores: **uma boa maneira de testar a força de uma estratégia é verificar se ela possibilita a criação de um slogan vigoroso e autêntico.** Tente escrever, em uma linha, o que cada concorrente da sua lista promete. Se você não consegue para nenhum deles, o setor inteiro está sem foco — e isso é uma descoberta. --- ## 5. Erros previsíveis na matriz da Q3 1. **Desenhar a sua própria curva agora.** Não é a hora. A Q3 entrega o mapa do que existe; a sua curva é Q5. Desenhar cedo faz a equipe escolher fatores em que ela já sabe que ganha. 2. **Fatores que são funcionalidades.** Se a linha do eixo horizontal poderia virar uma tarefa de desenvolvimento, ela é funcionalidade. 3. **Pontuar por impressão.** Cada ponto do eixo vertical deveria ser rastreável a alguma coisa: um preço, um teste que você fez, uma frase de entrevistado. Onde não for, marque como estimativa — e diga isso na apresentação. 4. **Só concorrentes diretos no gráfico.** Inclua a gambiarra e o "não fazer nada" como curvas. Elas costumam ser altas em fatores que ninguém esperava — custo zero, familiaridade, controle. 5. **Matriz que não cabe numa página.** --- ## 6. Modo de IA | Etapa | Modo | Observação | |---|---|---| | Gerar candidatos a fator de competição | 🟢 coprodução | Peça mais do que você vai usar, e corte | | Traduzir jargão para língua de comprador | 🟢 coprodução | Uso legítimo e rápido | | Pontuar os concorrentes no eixo vertical | 🔴 sem assistência | A pontuação precisa vir de uso, preço conferido ou fala de entrevistado. Nota gerada é nota inventada | | Ler a matriz | 🟡 com apoio | Bom pedido: "quais dessas pontuações não estão sustentadas por nenhuma evidência que eu te dei?" | --- ## Fontes - **Kim, W. Chan & Mauborgne, Renée**, *A estratégia do oceano azul*, cap. 2 e 4 — os dois eixos e a definição de curva de valor; o exemplo do gerente de refeições; o processo de quatro passos (despertar visual, exploração visual, feira de estratégia visual, comunicação visual) e o caso EFS completo, incluindo os 90 minutos, as quatro semanas de campo, os dez minutos por curva, os cinco adesivos, o terço de fatores secundários, os gerentes de relacionamento e a confirmação de transações; as cinco leituras da curva; as três qualidades (foco, singularidade, mensagem consistente) e o teste do slogan; a linguagem da matriz como indicador de foco interno # As seis fronteiras — Quest #3 Abra este arquivo **no início** da Q3, antes de listar concorrente nenhum. Ele existe para impedir que a sua lista de similares seja uma lista de apps do mesmo setor. --- ## O problema que as seis fronteiras resolvem Kim & Mauborgne identificaram seis condições básicas para reformular as fronteiras de um mercado. Elas não exigem previsão do futuro nem visão especial: **baseiam-se na observação de dados já conhecidos, de uma nova perspectiva.** Cada fronteira ataca um pressuposto que as empresas de um setor adotam sem questionar. Os seis pressupostos, na formulação dos autores — e é útil ler a lista pensando na sua própria equipe: 1. Definem o setor de atuação como os concorrentes definem, e se empenham em ser as melhores nesse contexto. 2. Analisam o setor pela ótica dos grupos estratégicos aceitos, e tentam se sobressair dentro do próprio grupo. 3. Focam o mesmo grupo de adquirentes que todo o setor foca. 4. Definem o escopo de produtos e serviços do mesmo jeito que o setor define. 5. Aceitam os apelos funcionais e emocionais vigentes no setor. 6. Concentram-se no mesmo ponto no tempo — geralmente nas ameaças competitivas de hoje. > Quanto mais as empresas comungarem da mesma sabedoria convencional sobre suas ações competitivas, **maior será a convergência competitiva entre elas.** Na Q3 isso tem tradução direta: se todos os seus similares vieram da mesma busca ("apps de [tema]"), você mapeou um grupo estratégico, não o espaço competitivo — e a sua Q5 vai nascer estreita. --- ## Primeira fronteira — setores alternativos **O conceito.** É preciso separar dois termos que o uso corrente mistura: | | Definição | Exemplo do livro | |---|---|---| | **Substituto** | Forma **diferente**, mesma função ou utilidade básica | Para gerenciar finanças pessoais: um software, um contador ou lápis e papel | | **Alternativa** | Forma **e** função diferentes, **mesmo propósito** | Restaurante e cinema: características físicas e funções distintas, mas as pessoas vão aos dois com o mesmo objetivo — passar uma noite agradável fora de casa | Em cada decisão, o comprador pesa alternativas implicitamente, quase sempre de forma inconsciente: *quer passar duas horas agradáveis? cinema, massagem ou um livro no café da esquina?* O raciocínio é intuitivo para qualquer pessoa — e, observam os autores, costuma ser abandonado justamente por quem está vendendo. **Os exemplos.** A NetJets observou que a empresa que precisa mandar alguém viajar tem duas escolhas: classe executiva em voo comercial, ou comprar o próprio avião. Perguntou por que se escolhe uma e não a outra, concentrou-se nos atributos decisivos de cada uma e eliminou o resto — vendendo 6,25% da propriedade de uma aeronave, compartilhada com outros quinze clientes, com direito a 50 horas de voo por ano. A Southwest Airlines tratou **o automóvel** como alternativa ao avião. A Intuit tratou **o lápis** como principal alternativa ao software de finanças pessoais. **Aplique ao seu projeto:** > Quando alguém decide **não** usar uma solução do seu setor para resolver o seu problema, o que essa pessoa faz no lugar? Liste três coisas que **não são do seu setor** e que ocupam o mesmo tempo, o mesmo dinheiro ou a mesma intenção. Para cada uma, escreva por que alguém a escolheria — e o que o seu setor não dá. --- ## Segunda fronteira — grupos estratégicos **O conceito.** Grupo estratégico é o conjunto de empresas que, dentro de um setor, adotam estratégias semelhantes. Eles se ordenam hierarquicamente por dois critérios: **preço e desempenho** — cada ajuste de preço tende a puxar um ajuste correspondente no desempenho. A maioria das empresas se empenha em melhorar a posição **dentro** do próprio grupo, e nenhum grupo presta muita atenção ao que os outros fazem, porque não parecem estar competindo entre si. O que rompe isso é entender **os fatores que levam o cliente a subir ou descer de um grupo para outro.** **O exemplo.** A Curves, rede de academias para mulheres cujo franqueamento começou no Texas em 1995, aproveitou os atributos decisivos de dois grupos estratégicos do setor de *fitness* nos Estados Unidos — as academias tradicionais e os programas de exercício em casa — e eliminou ou reduziu todo o resto. Em dez anos ultrapassou dois milhões de membros, com crescimento movido quase inteiramente por boca a boca e indicação. **Aplique ao seu projeto:** > Ordene os seus similares por preço. Você vai ver dois ou três blocos. Escolha dois blocos vizinhos e responda: **o que faz alguém subir do bloco de baixo para o de cima, e o que faz alguém descer?** O que essa pessoa aceita perder na troca? --- ## Terceira fronteira — cadeia de compradores **O conceito.** Setores inteiros convergem para um único grupo de compradores. Mas existe uma **cadeia**: quem paga pode não ser o usuário final, e às vezes há ainda os influenciadores. Os três grupos costumam se sobrepor, mas raramente se confundem — e **suas definições de valor quase sempre são diferentes**. O agente de compras de uma empresa se interessa mais por custo; o usuário, por facilidade de uso. Kim & Mauborgne registram a convergência por setor: a indústria farmacêutica foca predominantemente os influenciadores (os médicos), a de equipamentos de escritório foca os compradores (os departamentos de compra), a de vestuário vende quase sempre para os usuários finais. Às vezes há razão econômica forte para o foco; **geralmente é resultado de prática setorial nunca questionada**. **Os exemplos.** A Novo Nordisk deslocou o foco dos médicos para os próprios pacientes, e descobriu que a insulina em ampolas obrigava o paciente a manusear seringas e agulhas — com incômodo e estigma social. Daí a NovoPen, de 1985, com formato de caneta-tinteiro e cartucho para uma semana. A Bloomberg deslocou o foco dos gerentes de TI, que valorizavam sistemas padronizados, para os operadores e analistas, que ganham ou perdem milhões por dia e para quem cada segundo importa — e os próprios operadores pressionaram os gerentes de TI a comprar os terminais. A Canon fez o mesmo movimento no setor de copiadoras, dos compradores corporativos para os usuários finais; a SAP fez o inverso, do usuário funcional para o comprador da empresa. **Aplique ao seu projeto:** > Volte ao mapa de influência da Q2. Todos os seus similares atendem ao **mesmo** papel? Escolha o papel que ninguém no seu conjunto de similares está servindo e responda: **o que essa pessoa considera valor, que é diferente do que o papel atendido considera?** --- ## Quarta fronteira — ofertas complementares **O conceito.** Poucos produtos são usados no vácuo — outros produtos e serviços afetam o valor deles. Mas os rivais convergem dentro dos limites da própria oferta. O exemplo de abertura dos autores: a facilidade e o custo de conseguir babá e estacionamento afetam a percepção de valor de ir ao cinema, e esses serviços estão fora dos limites tradicionais do setor. Poucas salas de projeção se preocupam com isso — **e deveriam, porque afeta a demanda pelo negócio.** **O método é simples e é o que interessa aqui:** pense no que acontece **antes, durante e depois** do uso do produto ou serviço, e defina a **solução total** que o comprador procura. **O exemplo.** A NABI, fabricante húngara de ônibus, notou que o setor competia pelo menor preço de compra, enquanto os municípios mantinham os veículos em circulação por doze anos em média. O maior componente de custo não era o ônibus: era a manutenção ao longo da vida útil — consertos, combustível, desgaste, combate à ferrugem. A resposta foi trocar aço por fibra de vidro: menos corrosão, conserto por recorte e substituição em vez de troca de painel inteiro, 30% a 35% mais leve, menos combustível, menos poluição. O preço de compra ficou acima da média; o custo de vida útil, bem abaixo. **Aplique ao seu projeto:** > Escreva a linha do tempo do seu usuário em três blocos — **antes, durante, depois**. Em cada bloco, liste o que ele precisa fazer, comprar, aprender ou esperar. Qual desses itens custa mais tempo ou dinheiro do que o seu produto custaria? **Esse item está fora do escopo do seu setor por decisão ou por hábito?** --- ## Quinta fronteira — apelos funcionais e emocionais **O conceito.** Setores convergem também numa de duas fontes de apelo: alguns concorrem sobretudo por preço e utilidade, apelando à razão; outros recorrem aos sentimentos. Raramente um produto se enquadra inteiramente num tipo — o apelo predominante costuma ser **resultado de como as empresas competiram no passado**, moldando inconscientemente a expectativa do consumidor num círculo que se reforça. Por isso, dizem os autores, pesquisa de mercado raramente revela algo novo sobre o que atrai o cliente: **o setor treinou o cliente sobre o que esperar dele**, e a resposta ecoa a ladainha "mais do mesmo por menos". Dois padrões comuns: | Setor com orientação | Movimento possível | |---|---| | **Emocional** | Oferece extras que aumentam o preço sem aumentar a funcionalidade. Eliminá-los cria modelos mais simples, mais baratos | | **Funcional** | Produtos comoditizados podem ganhar vida com doses de emoção, estimulando demanda nova | **Os exemplos.** A Swatch converteu a indústria de relógios populares, voltada à funcionalidade, em indústria de moda; a Body Shop fez o oposto. A QB House transformou o corte de cabelo masculino no Japão: eliminou toalhas quentes, massagem nos ombros, chá e café, criou um sistema de aspiração dos fios no lugar da lavagem e secagem, reduziu o corte de uma hora para dez minutos, e o preço de 3.000–5.000 ienes para 1.000. A Cemex foi na direção contrária, transformando cimento — produto funcional barato — em presente, apoiada na *tanda*, o sistema tradicional mexicano de poupança comunitária. A Direct Line eliminou o corretor de seguros, apostando que o cliente não precisa de conforto emocional se a empresa for eficaz em liquidar sinistros rápido e sem papelada. **Aplique ao seu projeto:** > Os seus similares competem por razão ou por emoção? Se por emoção: **que extras poderiam ser eliminados** sem que o usuário perdesse o que ele foi buscar? Se por razão: **que elemento emocional está sendo ignorado** — e por que o setor decidiu que ele não importa? --- ## Sexta fronteira — o transcurso do tempo **O conceito.** Todo setor sofre tendências externas. A maioria das empresas se adapta de forma gradual e passiva, e concentra-se em **projetar a tendência em si** — para onde a tecnologia vai, como será adotada, em que escala. Os autores dizem que o insight não vem daí. Vem de especular **como a tendência mudará o valor para o cliente** e como impactará o modelo de negócio. Não se trata de prever o futuro, mas de desenvolver percepções a partir de tendências observáveis **hoje**. **Os três testes.** Para servir de pilar, uma tendência precisa ser: 1. **Decisiva** para o negócio; 2. **Irreversível**; 3. **De trajetória clara**. Em geral, entre muitas tendências simultâneas, apenas uma ou duas exercem impacto decisivo sobre um negócio específico. Identificada uma, examine como seria o mercado se ela prosseguisse até a conclusão lógica — e retroceda dali para descobrir o que precisa mudar hoje. **Os exemplos.** A Apple observou o compartilhamento ilegal de música — em 2003, mais de 2 bilhões de arquivos trocados por mês — e lançou o iTunes, com música avulsa a 99 centavos e álbum a 9,99 dólares, eliminando a obrigação de comprar o CD inteiro por uma ou duas faixas. A Cisco partiu de uma tendência decisiva e irreversível de trajetória clara: a demanda crescente por intercâmbio de dados em alta velocidade. A CNN partiu da globalização. **Aplique ao seu projeto:** > Nomeie **uma** tendência que afeta o seu tema e teste as três condições: é decisiva? é irreversível? a trajetória é clara? Se as três passarem, descreva como será o comportamento do seu usuário quando a tendência estiver completa — e o que isso torna necessário **hoje**. > ⚠️ Cuidado com a tendência genérica. "A IA vai mudar tudo" não passa no teste da trajetória clara: não diz **o que** muda no comportamento do seu usuário específico. Uma tendência utilizável é enunciável como mudança de comportamento, não como categoria tecnológica. --- ## Como usar as seis numa quest Não use as seis como um formulário a preencher. Use como **teste de cobertura** da lista de similares que você já tem. | Fronteira | Sintoma de que você não a percorreu | |---|---| | Setores alternativos | Todos os similares resolvem o problema pelo mesmo mecanismo | | Grupos estratégicos | Todos estão na mesma faixa de preço | | Cadeia de compradores | Todos atendem ao mesmo papel do seu mapa de influência | | Ofertas complementares | Nenhum similar está fora do momento "durante" | | Funcional / emocional | Todos vendem o mesmo tipo de argumento | | Transcurso do tempo | Nenhum similar da lista está morto, e nenhum é recente | Uma lista de similares que passa nos seis testes é rara. Uma que falha nos seis é uma busca por palavra-chave. O modo de IA aqui é **🟢 coprodução na varredura** — a IA é boa em gerar candidatos por fronteira — **e 🟡 com apoio na escolha**. Verifique cada candidato: abra, use se der, confira preço e público. A IA cita com frequência produtos descontinuados e funcionalidades que não existem mais. --- ## Fontes - **Kim, W. Chan & Mauborgne, Renée**, *A estratégia do oceano azul*, cap. 3 — o modelo das seis fronteiras; a distinção entre substituto e alternativa; os seis pressupostos do oceano vermelho; os casos NetJets, i-mode, Home Depot, Southwest, Intuit, Curves, Novo Nordisk, Bloomberg, Canon, SAP, NABI, QB House, Cemex, Direct Line, Apple/iTunes, Cisco e CNN; os três critérios de avaliação de tendência # Teste competitivo e auditorias — Quest #3 Abra este arquivo se houver tempo de **testar** os similares, e não apenas listá-los. É a diferença entre dizer "o concorrente X tem essa funcionalidade" e dizer "cinco pessoas tentaram fazer essa tarefa no concorrente X e três desistiram". Três métodos, do mais caro ao mais barato. Escolha pelo tempo que sobrar. --- ## 1. Teste competitivo ### O que é Pesquisa para avaliar a **usabilidade e a facilidade de aprendizado** dos produtos dos concorrentes. Hanington & Martin situam o método por contraste: acompanhar a atividade da concorrência é prática de marketing comum — receita, lucro operacional, tamanho da empresa, mistura de produtos —, mas essas auditorias de negócio **raramente adotam a perspectiva do usuário**, e não consideram as realidades sociais, econômicas e técnicas que moldam o contexto em que produtos e serviços ajudam pessoas a realizar objetivos no dia a dia. O teste competitivo dá à equipe a oportunidade de avaliar o produto do concorrente **do ponto de vista de quem usa**. E há uma diferença que vale marcar: outros métodos levantam **atitude** em relação ao produto do concorrente — formulário, grupo focal. O teste competitivo se concentra no **comportamento** de quem tenta cumprir tarefas que existem nos dois produtos. ### Como se faz O procedimento descrito no livro: 1. **Escolha três ou quatro produtos concorrentes** e teste a usabilidade deles — e a do seu próprio, quando houver. 2. **Reaproveite os mesmos roteiros, cenários e tarefas** que você usaria para testar a sua própria interface. É o que torna os resultados comparáveis. 3. **Teste também o que é diferente.** Identificar as similaridades a testar é importante, mas é igualmente importante isolar e testar as funcionalidades do produto concorrente que **não existem no seu**. É aí que aparecem as lacunas que indicam diferenciação ou especialização de mercado. 4. **Acompanhe os resultados ao longo do tempo**, repetindo o teste em intervalos. Sobre o tamanho do efeito que se pode esperar: o livro cita estudo de Jakob Nielsen segundo o qual a diferença entre o seu site e o dos concorrentes pode revelar uma **lacuna de 68% em usabilidade**. O livro não descreve a metodologia por trás desse número; use-o como ordem de grandeza, não como medida. ### Os cuidados de viés São três, e todos são fáceis de violar sem perceber: | Cuidado | Por quê | |---|---| | **Não revele o nome da sua equipe ou do seu produto** ao recrutar | Se o participante sabe de quem é o teste, ele passa a avaliar em relação a você | | **Cuidado com a linguagem corporal** | Um estremecimento, um sorrisinho, um aceno de cabeça — o livro é explícito de que mesmo os sinais mais sutis influenciam a reação do participante e alteram o comportamento dele | | Considerar um **terceiro** para conduzir | A recomendação do livro é contratar consultoria externa. No Projetão, o equivalente viável é **outra equipe conduzir o teste dos seus similares** e vice-versa | Acrescente um quarto, que decorre da Q1 e vale sempre: o **efeito Hawthorne** — as pessoas mudam de comportamento quando sabem que estão sendo observadas. ### Adaptação para uma quest | Item | Livro | Numa quest | |---|---|---| | Produtos testados | 3 a 4 concorrentes + o seu | 2 a 3 similares. Inclua a gambiarra como um deles, se ela for testável | | Participantes | conforme o desenho | 3 a 5 pessoas por produto, do perfil da Q2 | | Tarefas | as mesmas em todos | 3 tarefas, idênticas, escritas antes | | Quem conduz | consultoria externa | outra equipe | | Registro | por sessão | tempo até concluir, número de desistências, ponto exato onde travou, frase dita na hora | **Escreva as tarefas antes de escolher os produtos.** Se você escrever depois, vai escrever tarefas em que o seu favorito se sai bem. **O que registrar tem de ser comparável.** Uma tabela por tarefa, com uma coluna por produto, é mais útil que um relatório por produto. --- ## 2. Auditoria de conteúdo ### O que é Duas coisas distintas, e a distinção é o método: > **O inventário de conteúdo diz o que o seu conteúdo é. A auditoria de conteúdo recomenda o que ele deveria ser.** Conteúdo é mais que texto: é tudo que você empacota e publica em benefício do cliente. Tudo que uma pessoa pode ler, assistir, ouvir ou com que possa interagir conta como conteúdo, porque cada uma dessas atividades tem papel importante em como ela vai se sentir sobre o produto ou serviço. O **inventário** é exercício quantitativo, feito em planilha: linhas são itens de conteúdo, colunas são atributos. A **auditoria** é quantitativa e qualitativa. A parte quantitativa avalia critérios de governança; a qualitativa avalia qualidade, e pode identificar **temas e padrões que unificam** as fontes de conteúdo. ### As colunas | Informação geral | Governança | Qualidade (escala baixo/médio/alto) | |---|---|---| | Sistema de identificação/numeração | Criado por | Tem credibilidade? | | Título/nome | Data de criação | É original? | | URL ou fonte do dado | Data de atualização | É preciso? | | Tipo de documento | Responsável | É relevante para o público? | | Comentários/notas | Prazo | É relevante para o negócio? | | | Exige revisão jurídica? | É acessível? | | | Marcas ou direitos autorais | | ### Para que serve na Q3 O livro lista três situações de uso — redesenho de site, fusão ou divisão de sites, e preparação para distribuição multicanal. Nenhuma é o caso da Q3. **O uso aqui é outro**, e é interpretação nossa: aplicar o inventário e a auditoria **ao conteúdo dos concorrentes** responde a duas perguntas que a lista de funcionalidades não responde: - **O que o concorrente ensina ao usuário?** Ajuda, tutorial, perguntas frequentes e mensagem de erro revelam onde ele sabe que o usuário trava. - **O que ele promete?** A promessa publicada é a curva de valor declarada, e comparar declarado com observado costuma render. Uma advertência do livro que vale respeitar: **inventário e auditoria são baratos, mas consomem muito tempo e cuidado** para serem feitos bem e de forma abrangente. Numa quest, faça de um ou dois concorrentes, não de todos. --- ## 3. Auditoria de experiência ### O que é Captura o contexto do dia a dia em que as pessoas se relacionam com o produto ou serviço. O princípio de partida: **experiências não existem no vácuo** — elas se desenrolam ao longo do tempo e são moldadas por muitos fatores. A auditoria de experiência captura **o que os clientes fazem, pensam e usam** enquanto completam uma tarefa ou perseguem um objetivo que envolve o produto ou serviço. Ela oferece um enquadramento para isolar momentos específicos de **encanto, apatia ou frustração** ao longo da experiência inteira. ### O antes, durante e depois A estrutura da auditoria é essa, e é o que a torna diferente de um teste de usabilidade: | Fase | O que se captura | |---|---| | **Antes** | O que a pessoa faz, sabe, teme e organiza para chegar até o produto | | **Durante** | O uso propriamente dito | | **Depois** | O que resta — obrigação, arrependimento, cobrança, alívio | Ao quebrar a experiência em seus momentos salientes, dá para avaliar como **cada momento contribui para a experiência ou a diminui** — independentemente de envolver direta ou indiretamente o produto. Individualmente, esses momentos viram fonte de inspiração e apontam oportunidades de inovação. Repare na proximidade com a **quarta fronteira** de Kim & Mauborgne: pensar no que acontece antes, durante e depois do uso é exatamente o método deles para descobrir ofertas complementares. As duas ferramentas fazem a mesma pergunta por caminhos diferentes — uma pela estratégia, outra pela experiência. ### O que a auditoria exige para funcionar O livro é explícito: é preciso emoldurar o trabalho com **dado qualitativo rico**, que reflita as realidades sociais, ambientais e financeiras das pessoas, além das crenças, valores e desejos subjacentes. Entrevista e narrativa dirigida revelam as jornadas e alimentam o conteúdo da auditoria. E a razão disso é operacional, não retórica: **os eventos factuais que compõem uma auditoria de experiência só ganham vida quando a equipe entende o contexto — o enquadramento — da experiência, que pode ser diferente para pessoas diferentes.** Sem esse entendimento não dá para saber quais pontos de contato são gatilhos emocionais, quais são influenciados pelo contexto, onde o cliente precisa de ajuda e onde prefere se virar sozinho, e **quais momentos são habituais ou "corriqueiros" — e portanto maduros para inovação**. A última categoria é a mais útil na Q3. O momento que todo mundo aceita como inevitável é o que ninguém está atacando. A auditoria também ajuda a isolar **onde falta pesquisa** e onde existem lacunas na oferta de serviço ou produto. --- ## 4. Qual usar, com que tempo | Tempo disponível | Método | O que você leva para a Q5 | |---|---|---| | Uma tarde | Auditoria de conteúdo de um concorrente | O que ele promete e onde ele sabe que o usuário trava | | Dois ou três dias | Auditoria de experiência de um similar, com 2 a 3 usuários | Os momentos de frustração e os momentos "corriqueiros" | | Uma semana | Teste competitivo com 2 a 3 similares, 3 a 5 pessoas cada | Comparação de comportamento, com número, e as lacunas entre produtos | Fazer um dos três bem vale mais que fazer os três pela metade. --- ## 5. Modo de IA | Etapa | Modo | Observação | |---|---|---| | Escrever as tarefas do teste | 🟡 com apoio | Bom pedido: "quais dessas tarefas favorecem um dos produtos?" | | Conduzir o teste | 🔴 sem assistência | É contato com usuário | | Inventário de conteúdo | 🟢 coprodução | Preencher planilha a partir de páginas é exatamente o que a IA faz bem — mas confira as URLs, porque ela inventa | | Avaliação qualitativa da auditoria | 🟡 com apoio | Credibilidade, originalidade e relevância são julgamento seu | | Consolidar os resultados por tarefa | 🟢 coprodução | Contagem e tabulação | ⚠️ Um cuidado específico: se você pedir à IA que **descreva** a experiência de usar um concorrente em vez de usá-lo você mesmo, o resultado vai ser plausível, fluente e frequentemente falso — descrevendo versões antigas ou funcionalidades que nunca existiram. Auditoria de experiência sem experiência não é auditoria. --- ## Fontes - **Hanington, Bruce & Martin, Bella**, *Universal Methods of Design* — método 15 (Competitive Testing: reaproveitar roteiros e tarefas, testar 3–4 concorrentes, testar também o que é diferente, os cuidados de viés e a lacuna de 68% atribuída a Nielsen), método 18 (Content Inventory & Audit: a distinção inventário/auditoria e as colunas de informação geral, governança e qualidade), método 25 (Customer Experience Audit: antes/durante/depois, os momentos de encanto, apatia e frustração, e a identificação dos momentos corriqueiros) - **Nielsen, Jakob**, "How Big is the Difference Between Websites?" (2004) e "Parallel & Iterative Design + Competitive Testing = High Usability" (2011), citados por Hanington & Martin - **Kim, W. Chan & Mauborgne, Renée**, *A estratégia do oceano azul*, cap. 3 — o antes, durante e depois como método da quarta fronteira --- # Quest #4 — Oportunidade Escolhida & Organização da Equipe > **Objetivo.** Apresentar a oportunidade escolhida e a organização da equipe. | | | |---|---| | **Modo de IA** | 🔴 sem assistência nas conversas de confirmação · 🟡 com apoio no resto — a decisão é da equipe | | **Milestones** | consolida **Usuário**, **Problema** e **Similares** | | **Entrega** | uma oportunidade, com evidência; papéis definidos | | **Erro que mais custa** | escolher por votação, e não por evidência | | **Natureza** | ⚠️ **checkpoint** — os professores validam aqui, conforme as evidências | --- ## Por que esta quest existe Ela foi acrescentada quando a metodologia passou de 9 para 10 quests, e o motivo é observável: as equipes escolhiam mal, cedo demais, e descobriam tarde. **Não é votação.** Escolher por maioria dentro da equipe não vale — e não porque a democracia seja ruim, mas porque a escolha da maioria não é necessariamente validada pelos professores. **Eles vão olhar as evidências.** A escolha vem do que vocês observaram dos usuários e clientes. Tem de ficar claro: 1. que o problema é **relevante** — porque impacta muita gente, ou porque impacta muito algumas pessoas; 2. que as **soluções atuais não resolvem satisfatoriamente**, e portanto há espaço. --- ## Como escolher: risco, não preferência ### Primeiro, separe incerteza de risco São coisas diferentes, e confundi-las faz a equipe paralisar diante de "tudo é incerto". - **Incerteza** — falta de certeza completa: existe mais de uma possibilidade. - **Risco** — um estado de incerteza em que **alguma das possibilidades envolve perda**, catástrofe ou outro resultado indesejável. Você pode ser incerto sobre muitas coisas que não são arriscadas. O que qualifica uma incerteza como risco é haver **perda associada**. E risco se mede combinando **probabilidade** com **perda quantificada**: "40% de chance de o poço sair seco, com perda de R$ 12 milhões" é uma medição de risco. "É arriscado" não é. Consequência prática na Q4: o risco que você deve atacar primeiro não é o que parece mais assustador — é o que combina probabilidade alta **com** perda alta. Um evento catastrófico de probabilidade ínfima pode esperar. Detalhamento e as fórmulas em **Decidir sob incerteza — Quest #4** (neste arquivo). ### Depois, ranqueie as oportunidades — nesta ordem Coloque as 2–3 oportunidades lado a lado. A ordem de peso, da maior para a menor: | # | Critério | Por quê | |---|---|---| | 1 | **Nível de dor do cliente** | Priorize o segmento que mais precisa. A meta é ter um dos seus três problemas como ***must-have*** — não *nice-to-have* | | 2 | **Facilidade de alcance (canais)** | Construir caminho até o cliente é das partes mais difíceis. Alcance fácil não garante problema válido nem negócio viável, mas **tira você do prédio mais rápido e acelera o aprendizado** — e num semestre isso pesa mais que numa startup | | 3 | **Preço e margem** | O que se pode cobrar é largamente determinado pelo segmento. Mais margem = menos clientes para se pagar | | 4 | **Tamanho de mercado** | Grande o bastante **dados os objetivos** do projeto | | 5 | **Viabilidade técnica** | Por último — e note que é o único critério que a maioria das equipes de computação usa primeiro | Os três tipos de risco que você está ranqueando: **risco de produto** (acertar o produto), **risco de cliente** (construir caminho até ele), **risco de mercado** (viabilizar o negócio). > A priorização incorreta de risco é um dos maiores contribuintes de desperdício. --- ## As perguntas da entrega 1. **Qual a oportunidade escolhida?** Por que ela seria a mais relevante? **Quais evidências mostram isso?** 2. **Quem é o cliente e quem é o usuário?** São a mesma pessoa? 3. **Quem é o público mais disposto a interagir com a equipe?** Quem é o **usuário afoito**? 4. **Qual a jornada do usuário?** Passo a passo de como ele resolve o problema **hoje**, sem a sua solução. 5. **Qual o mercado-alvo e o tamanho dele?** Com evidência. 6. **Por que a concorrência não resolve plenamente?** 7. **Quem são as lideranças da equipe e suas funções?** --- ## Cliente ≠ usuário > **Um cliente é alguém que paga pelo seu produto. Um usuário não.** — Ash Maurya Regras que acompanham: - **Divida segmentos amplos em menores.** Você não consegue construir, projetar e posicionar um produto para todo mundo. Até o Facebook começou com um usuário muito específico: alunos de Harvard. - **Em modelo de dois lados**, comece com um único canvas usando cor ou etiqueta por segmento, e divida só depois. - **Seus usuários gratuitos não são seus clientes** — ainda. Dois grupos são segmentos **distintos** quando: suas necessidades justificam oferta distinta; são alcançados por canais diferentes; exigem relacionamento diferente; têm rentabilidade substancialmente diferente; ou pagam por aspectos diferentes da oferta. --- ## Usuário afoito — a escala de dor O termo técnico é *early adopter*, e há uma definição operacional muito mais útil que "quem gosta de novidade". São clientes visionários que **não só espalham a notícia sobre produtos inacabados e não testados, como também os compram**. A escala de cinco degraus: 1. O cliente **tem** um problema. 2. O cliente **entende** que tem um problema. 3. O cliente está **ativamente procurando** solução, e tem prazo para achá-la. 4. O problema dói o bastante para o cliente ter **montado uma solução provisória** — a gambiarra. 5. O cliente **comprometeu, ou consegue rapidamente, orçamento** para resolver. > **O usuário afoito está nos degraus 4 e 5.** Quem está nos degraus de baixo é adotante tardio (*late adopter*), e o feedback dele não serve agora. Isso conecta direto com a Q2: **quem você viu usando a gambiarra mais elaborada é o seu candidato mais forte** — porque a gambiarra *é* o degrau 4. Duas ressalvas: usuários afoitos estão em papéis **operacionais**, não em laboratórios de pesquisa ou comitês de avaliação técnica — estes influenciam a compra mas não têm autoridade de adoção. E eles querem falar com quem constrói, não com um vendedor. Identifique **nominalmente**. "Estudantes universitários" não é usuário afoito; é demografia. --- ## Tamanho de mercado sem inventar número Duas ferramentas que substituem o chute e o "segundo o IBGE, 1 milhão de pessoas": **Decomposição de Fermi.** Quebre o número grande em fatores que você consegue estimar. Além de produzir a estimativa, a decomposição mostra **de onde vem a incerteza** — e o fator mais incerto é justamente o que vale a pena medir. **Faixa calibrada de 90%, não número único.** Em vez de "o mercado é de 1 milhão", diga "entre 400 mil e 1,6 milhão, com 90% de confiança". É mais honesto e mais defensável na banca. E a notícia boa para quem acha que precisa de 400 respostas: **você precisa de menos dados do que pensa.** As primeiras observações são as de maior retorno em redução de incerteza. Ver **Decidir sob incerteza — Quest #4** (neste arquivo) para a **Regra dos 5** — e o argumento de por que cinco pessoas já dizem muito. --- ## Organização da equipe Papéis que a disciplina espera ver, cada um com **nome de pessoa ao lado**: - **Gerente de projeto** — mantém o projeto andando numa direção - **Líder técnico** — implementação - **Líder de UX / experiência** — usabilidade, testes com usuário - **Líder de negócios** — modelo de receita, mercado - **Relacionamento com usuários e comunidade de testes** — pode acumular, mas precisa ter dono Três achados que ajudam a dimensionar: **Tamanho.** A formulação clássica é sete pessoas, mais ou menos duas. Acima de nove, a velocidade **cai**. Os canais de comunicação crescem por n(n−1)/2: cinco pessoas geram 10 canais; nove geram 36. Num levantamento de 491 projetos, grupos de 3 a 7 pessoas exigiram cerca de **um quarto do esforço** de grupos de 9 a 20 para o mesmo trabalho. Regra: erre para o lado pequeno — se a turma impõe equipes grandes, **subdivida em frentes com dono**. **Um único dono do "quê".** Separe quem decide **o que** deve ser feito de quem cuida de **como** o time trabalha. Duas pessoas decidindo prioridade é a origem mais comum de paralisia. **Multifuncionalidade.** O time precisa ter todas as habilidades necessárias para completar o projeto — não pode depender de alguém de fora para fechar uma entrega. --- ## Atenção **As decisões desta quest não são definitivas.** É comum que sejam revistas, e em alguns casos abandonadas em favor de outro projeto. Nenhuma escolha é irreversível. Mas isso não autoriza escolher de qualquer jeito. **Escolha errada vira aprendizado; escolha impensada, feita só para se livrar da tarefa, vira bola de neve.** --- ## Referências desta quest | Arquivo | Quando | |---|---| | **Decidir sob incerteza — Quest #4** (neste arquivo) | Ao comparar as oportunidades. Incerteza × risco, valor da informação, estimativa calibrada, regra dos 5, Fermi | | **Usuário afoito — Quest #4** (neste arquivo) | Ao definir com quem falar. A escala de dor, onde encontrar, o que perguntar | | **Organização da equipe — Quest #4** (neste arquivo) | Ao distribuir papéis. Tamanho, canais de comunicação, os três papéis, conflito | | **Autodiagnóstico — Quest #4** (neste arquivo) | Antes de entregar | --- ### Técnicas desta quest Fichas curtas de consulta rápida. Abra quando o procedimento acima mencionar a técnica. | Ficha | Para quê | |---|---| | **Usuário afoito (*early adopter*)** (neste arquivo) | como reconhecer o usuário afoito | | **Jornada do Usuário** (neste arquivo) | a jornada atual, sem a sua solução | | **Lean Innovation** (neste arquivo) | por que priorizar risco em vez de preferência | | **Brainstorm** (neste arquivo) | gerar alternativas de recorte | --- ## Perguntas frequentes **"Me sinto perdido na equipe — uns sobrecarregados, outros parados."** Um dos desafios da disciplina é operar em equipe grande que precisa se auto-gerenciar: ninguém gerencia de fora. Duas coisas resolvem a maior parte disso. **Papéis e responsabilidades claros.** E **colaboração ativa**: mesmo sem entender de design, você pode ajudar a construí-lo. Ninguém é especialista profundo em nada numa startup. Se algo não está sendo feito, faça — na pior hipótese, alguém melhora o que você começou. **"O ambiente está tóxico, há muito conflito, não me sinto ouvido."** Conflito e discussão não são o problema — são sinal de que o resto do mundo não pensa como você. O que resolve disputa não é convicção: é teste e evidência. Se você não está sendo ouvido, traga evidência do caminho que propõe — e esteja aberto a estar errado se ela apontar o contrário. A opinião de qualquer integrante é irrelevante frente às decisões de projeto. Se suas contribuições são opinativas, não ser ouvido é até bom sinal. Se for o oposto — você traz hipótese testada e a equipe ignora em favor de preferência pessoal —, aí talvez seja caso de mudar de grupo. --- ## Bibliografia desta quest | Obra | O que ela dá para a Q4 | |---|---| | **Hubbard — How to Measure Anything** | Incerteza × risco, valor da informação, estimativa calibrada, regra dos 5, Fermi | | **Maurya — Running Lean** | Priorização por risco, ordem de ranqueamento, cliente × usuário | | **Blank — The Four Steps to the Epiphany** | O earlyvangelist e a escala de cinco degraus | | **Osterwalder & Pigneur — Business Model Generation** | Quando dois grupos são segmentos distintos; plataforma multilateral | | **Sutherland — Scrum** | Tamanho de equipe, canais de comunicação, separação dos papéis | | **Ries — A startup enxuta** | Bibliografia oficial da quest no site | # Autodiagnóstico — Quest #4 Rode isto **dois dias antes** do checkpoint, não na véspera. A Q4 consolida três milestones — **Usuário**, **Problema** e **Similares** — e os professores validam conforme as evidências. Um dia sobrando é o que permite ir a campo tapar um buraco. Pontue cada milestone de 0 a 5. **Some no fim e leia a régua.** --- ## Rubrica — Usuário | Nota | Estado | |---|---| | 0 | O usuário é uma demografia: "estudantes", "pequenos comerciantes", "professores". | | 1 | Há um recorte, mas ninguém da equipe falou com ninguém desse recorte. | | 2 | Houve conversas, mas com quem estava à mão — colegas, parentes, quem já era conhecido. | | 3 | Cliente e usuário estão distinguidos e nomeados, e a equipe sabe dizer se são a mesma pessoa. | | 4 | Há pessoas identificadas **nominalmente** no degrau 3 da escala de dor: procuram solução ativamente, com prazo. | | 5 | Há pelo menos duas pessoas nominalmente identificadas no **degrau 4 ou 5** — com gambiarra observada, registrada com data e local — e todas estão em **papel operacional**, não em papel de avaliação ou consultoria. | --- ## Rubrica — Problema | Nota | Estado | |---|---| | 0 | O problema é a ausência da solução que a equipe queria construir. | | 1 | O problema está descrito, mas a evidência é a experiência pessoal de alguém da equipe. | | 2 | Há evidência de campo, mas ela não distingue **fato observado** de **inferência**. | | 3 | A jornada atual do usuário está mapeada passo a passo, **sem a solução de vocês**. | | 4 | A relevância está sustentada por um dos dois caminhos: impacta muita gente, **ou** impacta muito algumas pessoas — e há número, com origem declarada, para o caminho escolhido. | | 5 | O problema aparece entre os três primeiros na **ordenação feita pelos próprios usuários**, e há indício de que é *must-have* e não *nice-to-have*. O custo do problema para o usuário está quantificado — em tempo, dinheiro ou clientes perdidos. | --- ## Rubrica — Similares | Nota | Estado | |---|---| | 0 | "Não existe nada parecido." | | 1 | Há uma lista de concorrentes diretos, montada por busca na internet. | | 2 | A lista inclui **alternativas existentes** que não são produtos: planilha, caderno, grupo de mensagens, não fazer nada. | | 3 | Para cada alternativa existente está registrado **o que ela entrega** e **o que ela deixa de entregar**. | | 4 | O "não resolve plenamente" está sustentado por fala de usuário, não por avaliação técnica da equipe. | | 5 | A equipe sabe dizer **por que a alternativa sobrevive** apesar das falhas — o que ela faz bem e vocês teriam de fazer igual ou melhor. Isso é a matéria-prima da curva de valor da Q5. | --- ## Rubrica — Escolha e equipe | Nota | Estado | |---|---| | 0 | A oportunidade foi escolhida por votação ou por preferência técnica. | | 1 | Há justificativa escrita, mas ela é argumentativa e não cita evidência. | | 2 | As 2–3 oportunidades foram comparadas, mas só em viabilidade técnica. | | 3 | A comparação seguiu a ordem de peso: dor, alcance, preço e margem, tamanho, viabilidade técnica. | | 4 | Cada oportunidade tem **risco medido** — probabilidade e perda quantificada em semanas de equipe —, não apenas adjetivado. | | 5 | Está calculada a perda de oportunidade esperada de cada alternativa, e as medições cujo custo é menor que ela viraram tarefas com prazo e dono. Os papéis estão distribuídos com **nome de pessoa**, e quem decide **o quê** não é a mesma pessoa que cuida do **como**. | --- ## A régua | Soma (0–20) | Leitura | |---|---| | 0–7 | A escolha ainda é preferência disfarçada. Volte a campo antes do checkpoint. | | 8–13 | Há material, mas concentrado num milestone só. Olhe qual ficou para trás: quase sempre é **Similares**. | | 14–17 | Defensável. Prepare-se para a pergunta sobre o milestone de menor nota — ela virá. | | 18–20 | Pronta. Use o tempo que sobra para melhorar a estimativa de mercado, que é onde a banca costuma insistir. | --- ## Checklist do checkpoint **As sete perguntas da entrega, respondidas por escrito** - [ ] Qual a oportunidade escolhida, por que é a mais relevante, e **quais evidências mostram isso** - [ ] Quem é o cliente e quem é o usuário — e se são a mesma pessoa - [ ] Quem é o usuário afoito, **nominalmente**, com o degrau e a evidência do degrau - [ ] A jornada do usuário hoje, passo a passo, sem a solução de vocês - [ ] Mercado-alvo e tamanho, como **faixa de 90%** com fórmula de decomposição e origem de cada fator - [ ] Por que a concorrência não resolve plenamente, com fala de usuário - [ ] Lideranças e funções, com nome ao lado de cada papel **Higiene da evidência** - [ ] Toda afirmação sobre o usuário tem data, local e quem observou - [ ] Fato e inferência estão em colunas separadas - [ ] Nenhum número aparece sem origem declarada - [ ] Nenhum número aparece como valor único onde deveria ser faixa - [ ] Nada que a equipe não observou está escrito como se tivesse observado **Preparo da defesa** - [ ] A equipe sabe apontar **qual é o fator mais incerto** da estimativa de mercado, e como pretende medi-lo - [ ] A equipe sabe dizer o que **descartou** e por quê - [ ] Uma pessoa está designada para responder cada uma das sete perguntas --- ## Registro de trajetória As decisões desta quest **não são definitivas** — é comum revê-las, e às vezes abandonar o projeto em favor de outro. Isso só funciona se o caminho ficar registrado; senão, a equipe refaz a mesma discussão dois meses depois. Mantenha um arquivo curto, atualizado a cada decisão, com quatro campos: | Campo | O que registrar | |---|---| | **Data** | Quando a decisão foi tomada | | **O que foi decidido** | Uma frase | | **A evidência que sustentou** | Observação, contagem, conversa — com origem | | **O que faria a equipe voltar atrás** | A observação que mudaria a decisão | A quarta coluna é a que vale mais: uma decisão sem condição de reversão declarada não é decisão sob incerteza — é aposta que ninguém vai auditar. E é ela que separa as duas situações que o `SKILL.md` distingue: **escolha errada vira aprendizado; escolha impensada, feita para se livrar da tarefa, vira bola de neve.** Quando uma oportunidade for descartada, registre **por que** na mesma tabela. Duas semanas depois, alguém vai propor exatamente aquela ideia de novo. # Decidir sob incerteza — Quest #4 Abra este arquivo quando a equipe tiver duas ou três oportunidades na mesa e precisar escolher **uma**, com argumento que sobreviva ao checkpoint; e quando precisar apresentar tamanho de mercado sem inventar número. --- ## 1. Incerteza e risco: quatro definições, não duas Hubbard define os dois termos **e** como se mede cada um. É a segunda metade que a equipe pula, e é ela que resolve a paralisia do "tudo é incerto". | Termo | Definição | |---|---| | **Incerteza** | Falta de certeza completa: existe mais de uma possibilidade. O resultado, estado ou valor verdadeiro não é conhecido. | | **Medição da incerteza** | Um conjunto de **probabilidades** atribuído a um conjunto de possibilidades. | | **Risco** | Um estado de incerteza em que **alguma das possibilidades envolve perda**, catástrofe ou outro resultado indesejável. | | **Medição do risco** | Um conjunto de possibilidades, cada uma com **probabilidade quantificada e perda quantificada**. | Os exemplos do livro: para incerteza, "há 60% de chance de este mercado mais que dobrar em cinco anos, 30% de chance de crescer a taxa menor e 10% de encolher"; para risco, "há 40% de chance de o poço proposto sair seco, com perda de US$ 12 milhões em custos de perfuração exploratória". Repare no que essas frases têm e "é arriscado" não tem: **um número de probabilidade e um número de perda**. Enquanto a equipe não escrever a oportunidade nesse formato, não mediu risco — declarou desconforto. E a definição de medição do livro é igualmente operacional: **uma redução de incerteza, expressa quantitativamente, baseada em uma ou mais observações.** Redução basta; eliminação não é exigida. Mas **precisa haver observação** — reunião não é medição, consenso de equipe também não. **Acionável:** uma linha por oportunidade, três colunas — *o que pode dar errado* / *chance (%)* / *o que se perde, em semanas de equipe*. Semanas de equipe é a moeda do Projetão; use-a no lugar de reais, que vocês não têm. --- ## 2. Quanto vale medir: perda de oportunidade e valor da informação | Sigla | Nome | Fórmula | |---|---|---| | **OL** | Perda de oportunidade | O custo se você escolher aquele caminho e ele se revelar errado | | **EOL** | Perda de oportunidade esperada | chance de estar errado × custo de estar errado | | **EVI** | Valor esperado da informação | EOL antes da medição − EOL depois | | **EVPI** | Valor esperado da informação perfeita | o **EOL da alternativa que você escolheria** sem medir nada | A última linha é o atalho: com informação perfeita a EOL cairia a zero, logo o valor de eliminar toda a incerteza é a EOL da sua decisão-padrão. Você calcula o teto do que vale investigar **antes** de investigar. **O exemplo do livro.** Campanha publicitária: US$ 40 milhões de lucro se funcionar, US$ 5 milhões de perda (o custo da campanha) se falhar, com 40% de chance de fracasso segundo especialistas calibrados. | | Aprovar | Rejeitar | |---|---|---| | Perda de oportunidade | US$ 5 M (custo da campanha) | US$ 40 M (ganho abandonado) | | **EOL** | 5 × 40% = **US$ 2 M** | 40 × 60% = **US$ 24 M** | A decisão-padrão é aprovar, por ter a menor EOL. E o valor de eliminar qualquer incerteza sobre o sucesso é **US$ 2 milhões** — não 24, não 40. Gastar US$ 3 milhões numa pesquisa para decidir isso destruiria valor. Duas leituras do livro: a EOL **é uma expressão de risco** — a solução neutra ao risco, que multiplica chance por tamanho da perda sem ajustar para aversão; e, rodando o cálculo em dezenas de casos de negócio, apenas **uma a quatro variáveis** por caso eram incertas o bastante *e* pesavam o bastante para justificar medição. **A maioria tem valor de informação zero.** **O mesmo em semanas de equipe.** ⚠️ Exemplo construído; os números foram inventados por mim para demonstrar o procedimento. A oportunidade A depende de integração com terceiros — 6 semanas perdidas se não for liberada, com 30% de chance: EOL = **1,8 semana**. A oportunidade B não depende de terceiros, mas o público é difícil de alcançar — 3 semanas, 50%: EOL = **1,5 semana**. As EOLs são próximas, e isso já é um achado: **as duas são quase equivalentes em risco**, e a discussão de três horas sobre qual é "mais arriscada" não tinha do que se alimentar. Mas o EVPI de A é 1,8 semana e descobrir se a integração sai custa **um e-mail e dois dias**: custo muito abaixo do valor da informação, logo mede-se antes de decidir. **Acionável:** escreva a EOL de cada oportunidade em semanas e, ao lado, o **custo de descobrir**, em dias. Toda linha em que descobrir custa menos que a EOL é tarefa da semana. As outras, esqueça: você já sabe o suficiente. --- ## 3. A inversão da medição > **Em um caso de negócio, o valor econômico de medir uma variável costuma ser inversamente proporcional à atenção de medição que ela normalmente recebe.** Hubbard chegou ao padrão aplicando o cálculo de valor da informação em projetos de TI, pesquisa e desenvolvimento, logística militar, meio ambiente, capital de risco e expansão de instalações: as variáveis de alto valor eram, repetidamente, **as que o cliente nunca media**. As duas razões que ele aponta: **as pessoas medem o que sabem medir** — é a piada do bêbado que procura o relógio na rua iluminada, embora saiba que o perdeu no beco escuro, "porque a luz é melhor aqui" — e **medem o que tende a produzir boa notícia**. **Na Q4.** A variável que equipes de computação medem com carinho é a **viabilidade técnica** — última na ordem de ranqueamento do `SKILL.md`. As que ninguém mede: se o público atende ao telefone, se alguém já paga por algo parecido, quanto custa chegar ao primeiro usuário. **Acionável:** liste o que a equipe já mediu nas Quests 1 a 3 e, ao lado, as três variáveis de maior EOL. Se as listas não se cruzam, você está no meio da inversão — e a segunda lista é a agenda da semana. --- ## 4. Estimativa calibrada de 90% Uma pessoa é **calibrada** quando acerta 80% das vezes em que diz estar 80% confiante, e assim por diante. A pesquisa citada mostra que quase todo mundo é enviesado, e **a grande maioria é superconfiante**. | Achado do teste de calibração | Número | |---|---| | Pessoas que acertam 5 ou menos de 10 intervalos de 90% | 56% | | Chance de uma pessoa **realmente calibrada** ter esse desempenho | 1 em 612 | | Acertos esperados nas questões verdadeiro/falso | 74% | | Acertos reais | 62% | Mais da metade erra tanto que, se fosse calibrada, seria azar de 1 em 612. Não é azar; é superconfiança sistemática. **Por que isso importa na banca.** "O mercado é de 1,2 milhão de pessoas" afirma certeza que a equipe não tem, e a primeira pergunta a desmonta. "Entre 400 mil e 1,6 milhão, com 90% de confiança, e o fator mais incerto é X" afirma o que se sabe **e** o que não se sabe. O livro reporta que a maioria fica quase perfeitamente calibrada após **meio dia de treino**, e que a habilidade transfere de conhecimentos gerais para qualquer área de estimativa. --- ## 5. As quatro técnicas de calibração O livro é explícito: **nenhuma isolada corrige a superconfiança**; é a combinação que funciona. Quem tentou replicar os workshops e obteve resultado pior invariavelmente deixara de fora alguma delas — em especial a primeira. **Aposta equivalente.** Escolha entre duas formas de ganhar R$ 1.000: (A) você ganha se o valor verdadeiro estiver dentro dos limites que deu; (B) você gira uma roleta com uma fatia de 90% e outra de 10%, e ganha se cair na grande. Se prefere a roleta, acha que ela tem mais chance de pagar — logo **o intervalo que você deu não é o seu intervalo de 90%**. Para o superconfiante, a correção é **alargar** até as opções ficarem indiferentes; para o subconfiante, estreitar. O livro registra que **fingir apostar dinheiro já melhora significativamente** a avaliação de probabilidades. **Prós e contras.** Liste um **pró** (por que a estimativa é razoável) e um **contra** (por que ela pode estar superconfiante). O exemplo: sua projeção está em linha com lançamentos de gasto publicitário parecido; mas há incerteza sobre fracassos catastróficos, sucessos descontrolados e crescimento do mercado — e a faixa se reavalia. Pesquisa acadêmica citada mostra que **este método sozinho já melhora a calibração significativamente**. **Cada limite como binário separado.** Um intervalo de 90% tem 5% acima do teto e 5% abaixo do piso; logo você precisa estar **95% certo** de que o valor é menor que o teto. Se não estiver, suba-o; idem para o piso. Isso combate a **ancoragem** — pensar num número único e somar um "erro" produz faixas estreitas demais. **Teste da absurdidade.** **Parta de uma faixa absurdamente larga e vá cortando.** Para o custo de uma fábrica de injeção plástica: comece em US$ 1.000 a US$ 10 bilhões; o equipamento sozinho custa US$ 12 milhões, então suba o piso; US$ 1 bilhão é mais que todas as suas outras fábricas somadas, então baixe o teto. A pergunta muda de "que valor eu acho que isso pode ter?" para **"que valores eu sei que são ridículos?"** — e onde o valor deixa de ser absurdo e vira improvável-mas-plausível está a borda do seu conhecimento. É a técnica para quem diz "não tenho como saber isso": **sempre há valores que a pessoa sabe serem absurdos**. **Acionável:** para cada número que for ao checkpoint, rode as quatro nesta ordem — absurdidade, limites separados, prós e contras, aposta equivalente. Quem não passou pela aposta equivalente não terminou. --- ## 6. A Regra dos 5 > **Há 93,75% de chance de a mediana de uma população estar entre o menor e o maior valor de qualquer amostra aleatória de cinco dessa população.** A demonstração tem quatro passos. **(1)** A regra estima a **mediana** — metade acima, metade abaixo —, não a média. **(2)** Por definição, a chance de um valor sorteado cair acima da mediana é 50%: é cara ou coroa. **(3)** A mediana só fica fora do intervalo se os cinco valores caírem todos acima ou todos abaixo; cinco caras seguidas é 1 em 32, ou 3,125%, e cinco coroas o mesmo. **(4)** Logo, 100% − (3,125% × 2) = **93,75%**. A aritmética generaliza para 1 − 2 × (½)ⁿ — o caderno de exercícios de Hubbard propõe exatamente esse cálculo, a "Regra de X", para X de 2 a 10: | n | 2 | 3 | 4 | **5** | 6 | 7 | |---|---|---|---|---|---|---| | Chance | 50% | 75% | 87,5% | **93,75%** | 96,88% | 98,44% | Do 2 para o 5 ganham-se 44 pontos; do 5 para o 7, 4,7. **É a razão de a quinta conversa valer muito mais que a vigésima.** O livro diz o mesmo: a curva de valor da informação é mais íngreme no começo — as primeiras 100 amostras reduzem muito mais incerteza que as segundas 100. **Três armadilhas.** A amostra **precisa ser aleatória**: Hubbard tapa os olhos e sorteia nomes da lista de funcionários; entrevistar os cinco colegas do laboratório não carrega os 93,75%. **Vieses continuam existindo** — uma obra temporária pode inflar o tempo de deslocamento de todos, e quem tem o trajeto mais longo pode faltar e não entrar na amostra. E **a regra não serve para escolher entre opções**: o caderno de exercícios traz o gerente que quer usá-la para decidir em qual de doze restaurantes fazer a confraternização — não funciona, porque ela estima a mediana de uma população de valores. --- ## 7. Faixa de 90% sem matemática, para amostras maiores Com mais de cinco observações, dá para estreitar a faixa sem variância, raiz quadrada nem tabela t: basta **contar para dentro** a partir dos extremos. | Amostra | 5 | 8 | 11 | 13 | 16 | 18 | 21 | 23 | 26 | 28 | 30 | |---|---|---|---|---|---|---|---|---|---|---|---| | Use o n-ésimo maior e menor | 1º | 2º | 3º | 4º | 5º | 6º | 7º | 8º | 9º | 10º | 11º | | Confiança real | 93,8% | 93,0% | 93,5% | 90,8% | 92,3% | 90,4% | 92,2% | 90,7% | 92,4% | 91,3% | 90,1% | Hubbard calculou a tabela por métodos não paramétricos e conferiu com simulação de Monte Carlo; ela é ligeiramente **conservadora**, porque as confianças reais ficam acima de 90%. Ele recomenda decorar os quatro primeiros tamanhos: **5, 8, 11 e 13**. Duas vantagens sobre a tabela t: **os dois limites são valores que existem nos seus dados** — no exemplo do livro sobre tempo assistindo a reality shows, a tabela t produzia um piso de *menos* 30 minutos, e a tabela sem matemática devolvia 0 a 4 horas; e **quase toda a variância está nos extremos**, já que abaixo de 12 observações ela é praticamente só o maior e o menor valor. --- ## 8. Decomposição de Fermi para tamanho de mercado Fermi pedia aos alunos que estimassem **quantos afinadores de piano há em Chicago**. Eles diziam não ter como saber; ele então pedia estimativas mais fáceis: população da cidade (pouco mais de 3 milhões nas décadas de 1930 a 1950), pessoas por domicílio (2 ou 3), fração de domicílios com piano afinado regularmente (não mais que 1 em 10, não menos que 1 em 30), frequência de afinação (talvez 1 por ano), pianos por afinador por dia (4 ou 5) e dias trabalhados por ano (uns 250). ``` Afinadores = população ÷ pessoas por domicílio × fração de domicílios com piano afinado × afinações por ano ÷ (afinações por afinador por dia × dias úteis por ano) ``` Conforme os valores, sai entre 20 e 200, com cerca de 50 sendo comum — sempre mais perto do real do que os alunos teriam chutado. Duas observações do livro: **a decomposição ainda não é medição**, porque não se baseia em observação nova; e **o ganho principal não é o número, é saber de onde vem a incerteza** — a maior fonte aponta a medição que mais reduz incerteza. O caso de mercado do livro é o de Chuck McKay avaliando abrir uma corretora de seguros em Wichita Falls, Texas, só com buscas na internet: 62.172 carros; prêmio médio anual no Texas de US$ 837,40; como o seguro é obrigatório, receita bruta local de US$ 52.062.833 por ano; comissão média de 12%, logo US$ 6.247.540 de bolo; 38 corretoras na cidade; dividindo, **US$ 164.409 por corretora ao ano** — antes do custo de escritório, e numa cidade que encolhera de 104.197 habitantes em 2000 para 99.846 em 2005. Conclusão: uma corretora nova não teria boa chance de ser lucrativa. Note a forma do argumento: **o resultado é uma recomendação de não entrar**, vinda de aritmética com números públicos. ### Um exemplo construído, no contexto brasileiro ⚠️ **Exemplo construído.** Todos os números abaixo foram inventados por mim para demonstrar o procedimento. **Nenhum é dado real, nenhum veio de fonte, e nenhum pode ser citado na entrega.** Copiem a estrutura, não os valores. Uma equipe quer atender salões de beleza de bairro que agendam por aplicativo de mensagem e perdem receita com furo de horário. Ninguém publica esse número: ``` Salões no alvo = ruas comerciais na área atendível × salões por rua comercial × fração que agenda por mensagem e tem furo ``` | Fator | Faixa de 90% | De onde veio | Teto ÷ piso | |---|---|---|---| | Ruas comerciais na área | 400 a 900 | contagem no mapa, com absurdidade | 2,3 | | Salões por rua comercial | 0,5 a 2 | **nada ainda** | 4,0 | | Fração com agendamento por mensagem e furo | 0,3 a 0,7 | impressão das Quests 1–2 | 2,3 | | Mensalidade suportável (R$) | 30 a 120 | **nada ainda** | 4,0 | Multiplicando pisos e tetos: **60 a 1.260 salões no alvo**, e receita anual potencial entre R$ 21,6 mil e R$ 1,81 milhão. A faixa é enorme de propósito — ela é honesta. E a coluna da direita diz onde medir: **"salões por rua" e "mensalidade suportável" são os mais incertos**, com fator 4 entre teto e piso. O primeiro custa uma tarde — sorteiem cinco ruas, contem, apliquem a Regra dos 5. O segundo custa cinco conversas. ⚠️ **Sobre multiplicar extremos.** Multiplicar pisos entre si e tetos entre si produz uma faixa **mais larga** que a de 90% verdadeira do produto, porque é improvável que todos os fatores estejam simultaneamente no piso. A agregação correta, no livro, é por **simulação de Monte Carlo**. Para a Q4 multiplicar extremos serve — o erro é para o lado conservador, e vocês devem dizer isso ao apresentar, em vez de deixar a banca descobrir. **Acionável:** a resposta à pergunta 5 da quest tem três peças: a **fórmula da decomposição**, a **tabela de fatores com faixas e origem de cada uma**, e **qual fator vocês vão medir em seguida, e como**. Um número solto não passa. --- ## Fontes - **Hubbard, Douglas W.**, *How to Measure Anything* — incerteza, risco e suas medições; definição de medição; OL, EOL, EVI e EVPI com o exemplo da campanha; a inversão da medição; teste de calibração e seus percentuais; aposta equivalente, prós e contras, limites binários e teste da absurdidade; Regra dos 5 e sua demonstração; tabela de 90% sem matemática; decomposição de Fermi, os afinadores de Chicago e a corretora de Wichita Falls; Monte Carlo para agregar faixas. - **Hubbard, Douglas W.**, *How to Measure Anything Workbook* — o exercício da "Regra de X"; a limitação da Regra dos 5 em problemas de seleção. - Os dois exemplos marcados como **construídos** são meus, escritos para demonstrar procedimento. Não são dados. # Organização da equipe — Quest #4 Abra este arquivo ao responder a pergunta 7 da entrega — "quem são as lideranças da equipe e suas funções?" — e sempre que a equipe travar por disputa de prioridade, por gente parada ou por reunião que não acaba. O `SKILL.md` dá os papéis que a disciplina espera. Aqui está de onde vêm os números, o que separa quem decide **o quê** de quem cuida do **como**, o que caracteriza um time excelente na pesquisa, e o que fazer quando o tamanho da equipe é imposto de fora. --- ## 1. Tamanho: por que sete, mais ou menos dois A formulação clássica é **sete pessoas, mais ou menos duas**. Sutherland relata ter visto times de três funcionando em alto nível, e registra o achado contraintuitivo: **acima de nove pessoas, a velocidade do time cai**. Mais gente faz o time andar mais devagar. ### As duas evidências **A lei de Brooks.** Formulada por Fred Brooks em 1975, em *The Mythical Man-Month*: **"acrescentar mão de obra a um projeto de software atrasado o atrasa ainda mais."** **O levantamento de Putnam.** Lawrence Putnam dedicou a carreira a estudar quanto tempo as coisas levam para ser feitas e por quê. Seus dados mostravam repetidamente que projetos com vinte ou mais pessoas usavam mais esforço que os de cinco ou menos — e não um pouco mais: **um time grande usava cerca de cinco vezes o número de horas de um time pequeno.** Em meados dos anos 1990, ele estudou **491 projetos de porte médio** em centenas de empresas diferentes, todos exigindo criação de produto ou funcionalidade nova (não reaproveitamento de versão anterior). Separando por tamanho de time, o padrão apareceu na hora: passando de oito pessoas, os times demoravam dramaticamente mais. **Grupos de 3 a 7 pessoas exigiram cerca de 25% do esforço de grupos de 9 a 20 para produzir o mesmo trabalho.** ### As duas causas Brooks identificou duas razões para o efeito. A primeira é o tempo de colocar gente nova a par — que atrasa todo mundo enquanto acontece. A segunda tem a ver com o limite físico do que o cérebro consegue processar. **Os canais de comunicação crescem por n(n−1)/2.** | Pessoas | Canais | |---|---| | 5 | 10 | | 6 | 15 | | 7 | 21 | | 8 | 28 | | 9 | 36 | | 10 | 45 | E há um limite duro do outro lado. Sutherland registra que o clássico estudo de George Miller, de 1956, dizia que a memória de curto prazo retém sete itens — mas que pesquisa posterior o refutou. Em 2001, **Nelson Cowan**, da Universidade do Missouri, revisou a literatura e concluiu que o número é **quatro**. O exemplo do livro: dê a alguém a sequência de doze letras `fbicbsibmirs`; a pessoa lembra de umas quatro — a menos que perceba que dá para agrupá-las em siglas conhecidas (FBI, CBS, IBM, IRS). Amarrar em memória de longo prazo aumenta a capacidade; a parte consciente, que foca, segura cerca de quatro itens distintos. ### O que acontece quando o time passa do ponto Sutherland descreve o desenrolar, e ele é reconhecível em turma de Projetão: - todo mundo deixa de saber o que todo mundo está fazendo; - o time **se quebra social e funcionalmente em subgrupos que passam a trabalhar com propósitos cruzados**; - **a multifuncionalidade se perde**; - **reuniões que levavam minutos passam a levar horas**. **Acionável:** conte os canais da sua equipe antes de discutir processo. Uma equipe de nove tem 36 canais; nenhuma ferramenta de gestão consegue compensar isso. A resposta não é uma reunião a mais — é reduzir o número de pessoas que precisam se sincronizar entre si. --- ## 2. Quem decide o quê, e quem cuida do como Este é o ponto que resolve mais paralisia por linha escrita. O Scrum tem **três papéis**: quem faz o trabalho (o time), quem ajuda o time a descobrir como trabalhar melhor (o Scrum Master), e quem decide **qual** trabalho deve ser feito (o Product Owner). O dono do produto é dono da lista de trabalho — do que está nela e, **mais importante, da ordem em que está**. A origem da separação é reveladora. Sutherland se inspirou no **Engenheiro-Chefe da Toyota**, responsável por uma linha inteira de produto (o Corolla, o Camry), que precisa mobilizar grupos especializados sem ter autoridade para mandar: tem de persuadir, convencer e demonstrar que o seu caminho é o melhor. Sutherland observa que **esse papel costuma exigir alguém com trinta anos de experiência** — e que pouquíssimas pessoas têm essa combinação. Por isso ele **dividiu o papel em dois: o Scrum Master ficou com o "como" e o Product Owner com o "quê"**. ### As quatro exigências do dono do "quê" | # | Exigência | O que significa na prática | |---|---|---| | 1 | **Conhecer o domínio** | Entender o processo que o time executa bem o bastante para saber o que dá e o que **não** dá para fazer; e conhecer o mercado bem o bastante para saber o que faz diferença. | | 2 | **Ter poder de decidir** | Assim como a gerência não deve interferir no time, o dono do produto precisa de margem para decidir a visão e o caminho, e para **se manter firme** sob pressão de vários interessados. Responde pelos resultados, mas deixa o time decidir como. | | 3 | **Estar disponível** | Precisa ser confiável, consistente e acessível. Sem acesso a ele, o time não sabe o que fazer nem em que ordem. **É por isso que Sutherland raramente recomenda que um alto executivo seja o dono do produto: falta tempo.** | | 4 | **Responder por valor** | O que é "valor" varia — receita, número de sucessos, atendimento a um público. O essencial é **decidir qual é a medida de valor** e cobrar dele mais dela. | Sutherland acrescenta que o primeiro dono de produto que ele nomeou não veio da engenharia, e sim do marketing de produto: alguém que conhecia o produto **do ponto de vista de quem o usa**, e não do ponto de vista técnico. ⚠️ **A tradução para o Projetão.** A exigência 3 é a que mais derruba equipes: elege-se dono do produto a pessoa mais ocupada, que também é a líder técnica, que também faz estágio. O papel exige disponibilidade, não prestígio. E a exigência 2 tem um corolário que o `SKILL.md` enuncia: **duas pessoas decidindo prioridade é a origem mais comum de paralisia.** O que decide não é quem tem razão — é que só uma pessoa pode ordenar a lista. **Acionável:** na entrega, escreva quem é o dono do "quê" e quem é o dono do "como", com nome. Se a mesma pessoa aparecer nos dois, a equipe não fez a separação. --- ## 3. O que caracteriza um time excelente ### Os três atributos da pesquisa original Takeuchi e Nonaka, no artigo que deu origem ao Scrum, descreveram as características dos times que observaram nas melhores empresas do mundo — entre elas Honda, Fuji-Xerox, 3M e Hewlett-Packard: | Atributo | O que significa | |---|---| | **Transcendente** | Têm um senso de propósito além do ordinário. A própria decisão de não ser mediano, e sim excelente, muda como se veem e o que se julgam capazes de fazer. | | **Autônomo** | São auto-organizados e autogeridos: têm o poder de decidir como fazem o trabalho, e poder para que essas decisões valham. | | **Multifuncional** | Têm **todas as habilidades necessárias para completar o projeto** — planejamento, projeto, produção, venda, distribuição —, e essas habilidades se alimentam mutuamente. | Sutherland resume os três em uma linha do sumário do capítulo: **times excelentes são multifuncionais, autônomos e empoderados, com um propósito transcendente.** A multifuncionalidade é o atributo mais operacional dos três para a Q4: se a equipe precisa de alguém de fora para fechar uma entrega, ela não é multifuncional, e cada entrega vai depender da agenda de terceiros. ### Interdisciplinar não é o mesmo que multidisciplinar Brown faz uma distinção que muda o comportamento em reunião: - Num time **multidisciplinar**, cada pessoa vira **advogada da própria especialidade técnica**, e o projeto vira uma negociação prolongada entre elas — que provavelmente termina num **compromisso cinzento**. - Num time **interdisciplinar**, **as ideias têm propriedade coletiva** e todo mundo assume responsabilidade por elas. O que permite a segunda forma é o que Brown chama de pessoa em **"T"** — termo popularizado pela McKinsey. O traço vertical é a profundidade numa habilidade que permita contribuir de forma tangível para o resultado. O traço horizontal é a **capacidade e a disposição** de colaborar através das disciplinas. Brown observa que juntar diversidade de formações exige paciência, porque é preciso encontrar pessoas **seguras o bastante da própria especialidade para irem além dela**. ⚠️ **É esta a leitura correta da pergunta frequente do `SKILL.md`** — "mesmo sem entender de design, você pode ajudar a construí-lo". Não é apelo à boa vontade: é o traço horizontal do T. Um time em que cada pessoa só faz o que está no seu rótulo produz o compromisso cinzento. ### As três competências mínimas Maurya define o time de problema/solução por competências, não por cargos, e diz que o time ideal nessa fase tem **duas ou três pessoas**: | Competência | O que abrange | |---|---| | **Desenvolvimento** | Capacidade de construir, com experiência prévia de ter construído coisas e domínio da tecnologia escolhida. | | **Design** | Estética **e** usabilidade. Um produto não é uma coleção de funcionalidades, e sim uma coleção de fluxos de uso. | | **Marketing** | "Todo o resto." Escrita, comunicação, e entendimento de métricas, preço e posicionamento. | Ele acrescenta duas advertências. A primeira: **desconfie de terceirizar qualquer uma das três** — um protótipo inicial até dá, mas ficar refém da agenda de outra pessoa limita a capacidade de iterar e aprender. A segunda é categórica: > **A única coisa que você nunca deve terceirizar é aprender sobre os clientes.** --- ## 4. Quando a turma impõe equipe grande O Projetão trabalha com equipes maiores que sete. Isso não invalida os números da seção 1 — significa que a equipe tem de administrar as consequências deles conscientemente. A saída que aparece nas duas fontes é a mesma: **times pequenos dentro de um time grande, com dono declarado em cada frente.** Brown descreve o padrão: acaba-se com um time grande em favor de **vários pequenos**. É comum ver times criativos grandes, mas **quase sempre na fase de implementação**; a fase de inspiração pede um grupo pequeno e focado, cujo trabalho é estabelecer o enquadramento geral. O exemplo dele: quando o projetista-chefe Tom Matano apresentou o conceito do Mazda Miata à direção, em agosto de 1984, estava acompanhado de **dois outros projetistas, um planejador de produto e dois engenheiros** — seis pessoas. Quando o projeto se aproximou da conclusão, o time tinha **trinta ou quarenta**. O mesmo vale, ele observa, para qualquer grande projeto de arquitetura, software ou entretenimento: um núcleo pequeno define o conceito, e "os exércitos" chegam depois. Sutherland, do lado oposto, dá a regra de bolso: **erre para o lado pequeno.** **Como aplicar na Q4:** 1. Defina **frentes**, não cargos decorativos. Cada frente tem no máximo três ou quatro pessoas e **um nome de dono**. 2. **Uma única pessoa ordena a lista de trabalho** do projeto inteiro, atravessando as frentes (seção 2). 3. Não replique a decisão de prioridade dentro de cada frente. Frente decide **como**; a ordem do **quê** vem de fora. 4. Meça o efeito pelo sintoma certo: se as reuniões gerais voltaram a durar horas, os canais venceram a estrutura, e é preciso reduzir o que precisa ser sincronizado — não aumentar a frequência das reuniões. --- ## 5. Conflito: como resolver sem culpar pessoa Sutherland dedica um trecho longo ao **erro fundamental de atribuição**: a tendência de explicar o comportamento dos outros pelo caráter deles e o nosso pela situação. Quando somos nós, enxergamos bem os fatores situacionais que nos levaram até ali — e, diz ele, quando falamos de nós mesmos, estamos absolutamente certos. O erro é usar o outro critério para os outros. O exemplo mais direto que ele traz é um experimento feito num seminário teológico no início dos anos 1970 (o livro não nomeia os autores). Os participantes foram informados de que tinham de dar um sermão do outro lado do campus. A alguns disseram que precisavam se apressar, porque já estavam atrasados e havia gente esperando; a outros, não. No caminho, cada um passou por alguém gemendo por socorro numa porta. **Entre os que foram apressados, 10% pararam para ajudar.** Seminaristas. A conclusão que o livro tira, e que serve como protocolo de conflito de equipe: > **Culpa é burrice. Não procure gente ruim; procure sistemas ruins — os que incentivam mau comportamento e recompensam mau desempenho.** Em vez de procurar um culpado, o Scrum examina o sistema que produziu a falha e o conserta. Em outra passagem, Sutherland enuncia a mesma regra de outro jeito: **quando você estiver cercado de gente insuportável, não procure pessoas ruins; procure sistemas ruins que as recompensam por agir assim.** ### O protocolo, para a Q4 | Sintoma | Pergunta errada | Pergunta certa | |---|---|---| | Alguém não entregou | "Por que fulano não fez?" | Que parte do nosso jeito de trabalhar tornou fácil não fazer? | | Uns sobrecarregados, outros parados | "Quem está de corpo mole?" | Onde falta dono declarado de frente? Onde a fila de trabalho não é visível para todos? | | A mesma discussão volta toda semana | "Quem está certo?" | Que evidência decidiria isso, e quanto custa consegui-la? | A última linha é a regra da disciplina, e ela vem direto da lógica das quests: **o que resolve disputa não é convicção, é teste e evidência.** Se você não está sendo ouvido, traga evidência do caminho que propõe — e esteja aberto a estar errado se ela apontar o contrário. Vale notar o corolário desconfortável: se as suas contribuições são opinativas, não ser ouvido é sinal de que a equipe está funcionando. **Modo de IA.** 🟡 com apoio. A IA pode reformular um conflito de pessoa em conflito de sistema, listar que evidência decidiria a disputa e apontar onde falta dono — não pode arbitrar a disputa nem decidir a prioridade. Essa decisão é de uma pessoa nomeada. --- ## Fontes - **Sutherland, Jeff**, *Scrum: The Art of Doing Twice the Work in Half the Time* — sete mais ou menos dois e a queda de velocidade acima de nove; a lei de Brooks (1975); o levantamento de Putnam com 491 projetos e a proporção de 25% de esforço entre grupos de 3–7 e de 9–20; a fórmula n(n−1)/2 e a tabela de canais; Miller (1956) refutado por Cowan (2001) e o limite de quatro itens; a degradação de times grandes; os três papéis e a divisão "Scrum Master fica com o como, Product Owner com o quê", inspirada no Engenheiro-Chefe da Toyota; as quatro exigências do dono do produto; os três atributos de Takeuchi e Nonaka; o erro fundamental de atribuição, o experimento do seminário teológico e a regra de procurar sistemas ruins, não pessoas ruins. - **Brown, Tim**, *Change by Design* — a distinção entre time multidisciplinar e interdisciplinar; a pessoa em "T", termo popularizado pela McKinsey; o padrão de vários times pequenos no lugar de um grande, e o exemplo do Mazda Miata (seis pessoas na concepção, trinta ou quarenta na conclusão). - **Maurya, Ash**, *Running Lean* — o time de problema/solução de duas ou três pessoas; as três competências mínimas (desenvolvimento, design, marketing); as advertências sobre terceirização e sobre nunca terceirizar o aprendizado sobre clientes. - As traduções para o contexto da disciplina marcadas com ⚠️ e o protocolo de conflito da seção 5 são leituras minhas sobre as fontes citadas. # Usuário afoito — Quest #4 Abra este arquivo ao responder a pergunta 3 da entrega — "quem é o público mais disposto a interagir com a equipe?" — e antes de marcar a primeira rodada de conversas depois do checkpoint. O `SKILL.md` dá a escala de cinco degraus. Aqui está o que caracteriza cada degrau na fala da pessoa, onde encontrar quem está nos degraus de cima, o que perguntar quando encontrar, e por que a gambiarra que vocês viram na Q2 é o atalho. --- ## 1. De onde vem o termo, e por que ele não é "quem gosta de novidade" Blank precisou de uma palavra nova. Entusiastas que espalham a boa notícia sobre um produto já se chamavam evangelistas; faltava nome para o cliente visionário que **não só espalha a notícia sobre produtos inacabados e não testados como também os compra**. Daí *earlyvangelist* — em português, **usuário afoito**. A razão de existir da categoria é econômica, e vale trazer para o Projetão sem adaptação: **nenhuma equipe consegue construir, no primeiro ciclo, um produto com todas as funcionalidades que um cliente de mercado de massa precisa.** O produto ficaria pronto tarde demais e já obsoleto. A saída é construir de forma incremental para um grupo pequeno de clientes iniciais que compraram a visão, e usar o retorno deles para definir o que vem depois. Num semestre de 14 semanas, isso deixa de ser conselho e vira restrição. --- ## 2. Os cinco degraus, na fala da pessoa Blank constrói a escala com um exemplo único: um banco cuja fila dá a volta no quarteirão às sextas-feiras, e uma equipe cujo produto reduziria a espera para 10 minutos. Cada degrau é uma resposta diferente do presidente do banco. | Degrau | O que caracteriza | Como soa na conversa | O que fazer | |---|---|---|---| | **1. Tem o problema** | O problema existe, mas a pessoa não o reconhece. **Necessidade latente.** | *"Que problema?"* | Não é cliente nos dois primeiros anos de vida do produto, e **o retorno dele sobre necessidade de produto é inútil**. Agradeça e siga. | | **2. Entende que tem o problema** | Reconhece, se incomoda, mas nunca se moveu além de disfarçar o sintoma. **Ainda necessidade latente** — em Blank, latente cobre "tem o problema" *e* "tem o problema e sabe que tem". | *"Sim, é um problema terrível. Me sinto mal, distribuo copos d'água para quem está na fila nos dias mais quentes."* | Dá bom retorno **sobre o tipo de problema**. Não estará na primeira fila para comprar. Provavelmente vende-se para ele depois, com produto de mercado. | | **3. Procura ativamente, com prazo** | Procura solução de verdade, e já **visualizou** o que quer: com que integra, quanto pode custar, quando precisa. **Necessidade ativa.** | *"Estamos perdendo mais de US$ 500 mil por ano. Procuro software que corte 70% do tempo de processamento, tem de integrar com o Oracle, custar menos de US$ 150 mil e chegar em seis meses."* | Está esquentando. Ainda não é o alvo. | | **4. Montou uma gambiarra** | A dor foi grande o bastante para a pessoa construir uma solução provisória com o que tinha à mão. | *"Não achei um único pacote que resolvesse, então pedi ao meu setor de TI para fazer. Eles emendaram uma solução, mas ela vive travando na mão dos caixas."* | **Alvo.** | | **5. Tem, ou consegue rápido, orçamento** | Além da gambiarra, há dinheiro reservado ou mobilizável. | *"Se aparecesse um fornecedor que resolvesse isso, eu gastaria com ele os US$ 500 mil que tenho orçados."* | **Alvo.** | Os três estágios de Blank — latente, ativa, visão — mapeiam assim: **latente** nos degraus 1 e 2, **ativa** no 3, **visão** no 4 e no 5. É a mesma escala descrita em **Quem entrevistar — Quest #2** (**Quem entrevistar — Quest #2** (neste arquivo)), vista pelo lado do comportamento em vez do lado do reconhecimento. > **O usuário afoito está nos degraus 4 e 5.** Nos degraus de baixo está o *late adopter* — o adotante tardio —, e o retorno dele não serve agora. Blank é explícito sobre o degrau 4 valer tanto em contexto corporativo quanto de consumo: pode ser um setor de TI que emendou um sistema, ou alguém que em casa **prendeu com fita um garfo, uma lâmpada e um aspirador de pó**. A escala é a mesma; só mudam os zeros. **A conexão com a Q2 é direta e é o atalho da quest.** O degrau 4 *é* a gambiarra. Quem vocês viram, nas Quests 1 e 2, mantendo a planilha paralela, o caderno ao lado do sistema, o grupo de mensagens que substitui o processo oficial — essa pessoa já está no degrau 4 por definição. **Não é preciso procurar usuário afoito do zero: é preciso voltar à lista de gambiarras e ordenar por elaboração.** Quanto mais trabalho a pessoa teve para montar a gambiarra, mais alto o degrau. --- ## 3. Por que eles estão em papéis operacionais Esta é a ressalva que Blank marca como importante, e é a que mais custa a equipes de computação. Muitos fundadores acham que o usuário afoito está no laboratório de pesquisa e desenvolvimento, no grupo de avaliação técnica do cliente, ou — em produto de consumo — no laboratório de testes de produtos novos, onde o trabalho da pessoa é justamente avaliar coisas novas. **Não são esses.** Blank diz que às vezes eles são influenciadores críticos numa compra, mas **não têm papel operacional no dia a dia e não têm autoridade para garantir adoção e implantação**. O usuário afoito é quem está em papel operacional, tem o problema, procurou solução, tentou resolver e tem orçamento. **A tradução para o Projetão.** O professor da área, o coordenador do laboratório, o colega que "manja do assunto" e o especialista que a equipe conhece são todos influenciadores. Eles opinam bem e não adotam nada. O usuário afoito é a pessoa que **executa a tarefa hoje** e cuja semana melhora ou piora conforme o problema seja resolvido. Segunda ressalva do livro, igualmente prática: usuários afoitos **não querem falar com vendedor**. Querem ver e ouvir os fundadores e a equipe técnica. Numa equipe de Projetão isso é uma vantagem — vocês são exatamente quem eles topam receber. Vá quem constrói. --- ## 4. Onde encontrar Blank descreve um procedimento numérico, e o número tem função: ele existe para a equipe não se contentar com as três pessoas fáceis. **Monte uma lista de 50 nomes.** Fontes que ele cita: redes sociais, amigos, investidores, fundadores, advogados, recrutadores, revistas do setor, livros de referência de negócios, contadores. Nessa fase, **cargo e nível hierárquico são irrelevantes**; e em produto de consumo, se a pessoa tem hoje algum interesse no produto também é irrelevante. O que importa é quem lhe dará algum tempo e se encaixa, mesmo folgadamente, no perfil que vocês hipotetizaram. **Monte em paralelo uma lista de inovadores.** São empresas, setores ou pessoas do campo que são inteligentes, respeitadas e costumam estar à frente do assunto. Em produto de consumo, pode ser o "fanático por novidade" a quem todo mundo pede conselho. Serve para duas coisas: encontrar quem "entende" ideias novas, e formar lista de conselheiros e influenciadores. **Os números do contato.** Blank prescreve **10 telefonemas por dia**, até a agenda ter três visitas por dia. Como regra prática, **50 ligações rendem de 5 a 10 visitas marcadas**. Habitue-se a ouvir não — e sempre pergunte: *"se você está sem tempo, com quem eu deveria falar?"* **Suba a cadeia alimentar da expertise.** A pergunta que Blank repete em todo contato é: **"quem é a pessoa mais inteligente que você conhece?"** O objetivo do primeiro surto de ligações não é só falar com quem está na lista; é usar cada contato para chegar ao seguinte. ⚠️ **Ajuste de escala para o semestre.** 50 nomes e 10 ligações por dia é o ritmo de uma startup em tempo integral. Numa equipe de Projetão com cinco a nove pessoas, **50 nomes divididos entre os integrantes é uma tarde de trabalho**, e mantém a proporção do método. O que não se deve ajustar é a **taxa de conversão**: se a equipe montou uma lista de 8 nomes, deve esperar 1 visita — e isso não é evidência de nada. --- ## 5. O que perguntar ### A apresentação do problema Blank chama de *problem presentation*, e a diferença em relação a uma apresentação de produto é o objetivo: ela **não foi feita para convencer o cliente; foi feita para extrair informação dele**. Em contexto corporativo, cabe em **um slide de três colunas**. Em conversa com consumidor, onde slide seria estranho, um papel serve. | Coluna 1 | Coluna 2 | Coluna 3 | |---|---|---| | Os problemas, como vocês os entendem | Como se resolve isso hoje | A solução de vocês — a ideia grande, **não a lista de funcionalidades** | O procedimento é uma sequência de **pausas**: 1. Mostre a coluna 1. **Pare.** Pergunte o que a pessoa acha que são os problemas, o que está faltando na lista, e como ela **ordenaria** os problemas. 2. Se ela concordar, peça que explique **por que** acha importante resolver. E pergunte, casualmente: *"quanto esse problema custa para você hoje — em receita perdida, clientes perdidos, tempo, irritação?"* 3. Mostre a coluna 2. **Pare.** Pergunte quais são as soluções atuais, se falta alguma, e como ela ordenaria a viabilidade delas. 4. Ainda na coluna 2, pergunte: **"quem mais tem esse problema?"** Outras unidades? Outras pessoas na mesma empresa? Outros no setor? Outros com o mesmo cargo? 5. Mostre a coluna 3. **Pare e observe a reação.** A pessoa entende as palavras? Diz "ah, se vocês fizerem isso, meu problema acaba"? Ou diz "como assim?" e continua sem entender depois de vinte minutos de explicação? A pergunta 4 tem peso desproporcional: Blank escreve que **um conjunto de pessoas com problemas em comum equivale a uma proposta de valor em comum**. É literalmente a matéria-prima da Q5. > **Não tente convencer o cliente de que ele tem os problemas que você descreve. Ele é quem tem o talão de cheques — você quer que ele convença você.** E se o cliente disser que as questões que vocês achavam importantes não são: Blank insiste que isso é **um dado ótimo**, não um fracasso. Pode não ser o que se queria ouvir, mas é excelente saber disso cedo. ### O entendimento em profundidade Depois da apresentação do problema, o objetivo muda: entender como a vida ou o trabalho da pessoa realmente funciona. As perguntas que Blank lista: - Como o fluxo de trabalho acontece de fato? A tarefa é feita isoladamente? Se não, com quais outras áreas ou pessoas ela interage? - Que outros produtos a pessoa usa? - O problema é só dela, ou outros na organização compartilham? Dá para quantificar o impacto — em dinheiro, tempo, custo — na organização inteira? - O que faria a pessoa **mudar o jeito atual de fazer**? Preço? Funcionalidade? Um novo padrão? - *"Se você tivesse um produto assim [descrito em termos conceituais], que porcentagem do seu tempo você passaria usando? Quão crítico ele seria? Resolveria a dor que você mencionou? Quais seriam as barreiras para adotar?"* - Como a pessoa **fica sabendo de produtos novos**? Quem ela lê e respeita? - Essa pessoa pode ajudar de novo? Numa próxima rodada? Como conselheira? Indicando outros? ### A regra das três coisas Depois de algumas conversas, as respostas embaralham. Blank recomenda levar as hipóteses escritas e, **antes de cada conversa, reduzir a lista a "quais são as três coisas que preciso aprender antes de sair daqui?"**. Garanta essas três. Conforme forem se confirmando, troque as perguntas. **Modo de IA.** 🔴 sem assistência na conversa: quem fala com a pessoa é a equipe, e a IA não escreve resposta de usuário. 🟡 com apoio antes e depois: use a IA para criticar o roteiro de três colunas, apontar perguntas que induzem resposta, e organizar as notas depois — não para gerar as conclusões. --- ## 6. Identifique nominalmente O critério de aprovação da pergunta 3 da entrega é simples: **"estudantes universitários" não é usuário afoito; é demografia.** Uma resposta aceitável tem nome, papel operacional, o degrau em que a pessoa está e a evidência do degrau. Formato sugerido: | Nome | Papel operacional | Degrau | Evidência do degrau | Contato conseguido por | |---|---|---|---|---| | | | 4 ou 5 | a gambiarra observada, com data e local | | Se nenhuma linha da tabela chega ao degrau 4, a equipe ainda não encontrou usuário afoito — e essa é a tarefa da semana, não um detalhe da entrega. --- ## Fontes - **Blank, Steve**, *The Four Steps to the Epiphany* — origem do termo *earlyvangelist*; a escala de cinco degraus de dor e o exemplo do banco em todos os degraus; necessidade latente, necessidade ativa e solução visualizada; a ressalva sobre laboratórios de pesquisa e grupos de avaliação técnica; a preferência por falar com quem constrói; a lista de 50 nomes, a lista de inovadores, os números de ligações e visitas, a pergunta pela pessoa mais inteligente; a apresentação do problema em três colunas e o protocolo de pausas; "quem mais tem esse problema" e a proposta de valor em comum; as perguntas de entendimento em profundidade; a regra das três coisas por conversa; a instrução de não convencer o cliente. - A ligação com a gambiarra da Q2 e o ajuste de escala do número de contatos para o semestre são leituras minhas, marcadas no texto. --- # Quest #5 — Proposta Única de Valor > **Objetivo.** Apresentar a proposta única de valor. | | | |---|---| | **Modo de IA** | 🟡 com apoio — a IA critica e ajuda a testar; a aposta é da equipe | | **Milestone** | **PUV** (abre aqui) | | **Entrega** | o valor que só a sua solução entrega + curva de valor dos concorrentes | | **Erro que mais custa** | "igual, mas melhor" | --- ## Inovação de valor — o conceito que sustenta a quest A maioria das equipes chega aqui achando que precisa escolher entre **ser diferente** (e caro) ou **ser barato** (e igual). Esse é o dilema valor-custo, e a quest existe para quebrá-lo. > A inovação de valor ocorre na área em que as ações da empresa afetam favoravelmente **tanto** sua estrutura de custos **quanto** sua proposição de valor para os compradores. **Obtêm-se economias de custo mediante a eliminação e a redução dos atributos da competição setorial. Aumenta-se o valor para os compradores ampliando-se e criando-se atributos nunca oferecidos pelo setor.** > > — Kim & Mauborgne, *A estratégia do oceano azul* Não há mágica: o **baixo custo** vem das duas primeiras ações (eliminar, reduzir) e o **diferencial** vem das duas últimas (elevar, criar). São operações sobre **conjuntos diferentes de atributos** — por isso podem acontecer ao mesmo tempo. E, contra a intuição de turma de computação: **inovação de valor não é inovação tecnológica.** Starbucks, Cirque du Soleil, Southwest — nenhum deles inventou tecnologia. --- ## O modelo das quatro ações Sobre cada atributo, pergunte: 1. Que atributos considerados **indispensáveis pelo setor** devem ser **eliminados**? 2. Que atributos devem ser **reduzidos bem abaixo** dos padrões setoriais? 3. Que atributos devem ser **elevados bem acima** dos padrões setoriais? 4. Que atributos **nunca oferecidos pelo setor** devem ser **criados**? O que cada uma força: - **Eliminar** — considerar atributos que há muito servem de base para a concorrência e que são tidos como indispensáveis **ainda que não gerem mais valor, ou até o destruam**. - **Reduzir** — expor o **excesso de engenharia**: entregar muito além do que o cliente pede, inflando custo à toa. - **Elevar** — identificar e corrigir as limitações que o setor impõe aos clientes. - **Criar** — descobrir fontes inteiramente novas de valor e mudar a estratégia de preços do setor. **Eliminar e criar são as de maior alavancagem** — forçam a ir além de maximizar atributos já estabelecidos, tornando irrelevantes as regras atuais da competição. ### Por que a matriz, e não só a curva A curva é um gráfico; a matriz ERRC é um **compromisso escrito em quatro quadrantes**. A diferença prática: a curva pode ser desenhada só "para cima" — a matriz deixa **duas caixas visivelmente vazias** se a equipe não cortou nada. > **Duas caixas vazias em "eliminar" e "reduzir" = a equipe não fez inovação de valor, fez lista de desejos.** A matriz denuncia na hora quem só eleva e cria, inflando a estrutura de custo — e num projeto de semestre isso significa um escopo que não cabe. --- ## A matriz de avaliação de valor **Eixo X** — os **fatores de competição** do setor: aquilo em que os concorrentes investem e o comprador percebe. > ⚠️ **Correção ao material do site, e uma ressalva sobre o termo.** É comum ouvir que "apesar do nome, a curva traz **funcionalidades** no eixo X". A intenção está certa — não vão ali valores abstratos como "confiança" ou "sustentabilidade". Mas "funcionalidades" esconde o essencial: nos exemplos canônicos, a maioria dos itens do eixo **não é funcionalidade de produto**. > > O livro chama esses itens de **atributos** ("o eixo horizontal representa a variedade de atributos nos quais o setor investe e compete"). **Fatores de competição** é o rótulo desta disciplina, adotado por ser mais explícito — não é expressão de Kim & Mauborgne, e não deve ser citada como tal. > > No vinho: preço, imagem de nobreza na embalagem, investimento em marketing, envelhecimento, prestígio do vinhedo, complexidade do sabor, amplitude da linha. Na aviação de baixo custo: preço, serviço amigável, velocidade, frequência, refeições, salas de espera, escolha de assento, conexões. No circo: tema, várias produções, ambiente refinado, música e dança. > > **Preço, canal, marca, marketing, experiência, serviço e conveniência são fatores legítimos.** Reduzir o eixo a "funcionalidades" empurra a equipe para o vício do **foco interno** — falar "megahertz" onde o cliente diz "velocidade" — e mata os cortes de custo mais valiosos. Os cortes do Cirque du Soleil foram *animais, astros e picadeiros*: nenhum deles é funcionalidade. **Eixo Y** — o **nível de oferta de cada fator segundo a percepção do comprador**. Nota alta = entrega mais e investe mais. **No caso do preço, nota alta significa preço mais alto.** ### Sobre a ordem "preço → excluir → diminuir → aumentar → criar" A ordem **eliminar → reduzir → elevar → criar** é do livro, e tem razão de ser: os cortes vêm antes dos acréscimos, senão o custo explode. Já **"preço primeiro" não é regra enunciada** — é convenção didática do Projetão, e é útil (obriga a decidir o posicionamento antes de sonhar com funcionalidades). O que o livro de fato prescreve com o preço à frente é outra coisa, e vale ensinar separado: **custeie a partir do preço estratégico, nunca precifique a partir do custo.** --- ## Os três critérios de uma boa curva Uma estratégia eficaz apresenta três qualidades. Sem elas, a estratégia será confusa, indistinta, difícil de comunicar e cara. | Critério | O que é | Como falha | |---|---|---| | **Foco** | Ênfase em poucos fatores, não no espectro todo | Curva alta em tudo → custo alto, modelo complexo | | **Singularidade** | A forma da curva **diverge** da dos rivais | Curva reativa, sobreposta à do concorrente — "perdeu-se no oceano vermelho" | | **Mensagem consistente** | Um slogan vigoroso e **verdadeiro** | Sem mensagem → inovação pela inovação, sem potencial comercial | O teste da mensagem é operacional: **se a estratégia não permite um slogan forte e autêntico, ela não está pronta.** E o slogan tem de anunciar oferta verdadeira, para o cliente não perder a confiança. ### Diagnóstico de curva ruim | Sintoma | Diagnóstico | |---|---| | Alta e plana em tudo | Sem foco. Custo alto, modelo complexo | | Sobreposta à dos concorrentes | Oceano vermelho. Crescimento só por sorte setorial | | Alta em tudo sem retorno | Excesso de oferta. Falta decidir **o que eliminar e reduzir** | | **Contradição estratégica** | Alto num fator e baixo no que o sustenta — investir na facilidade do site e não corrigir a lentidão dele | | **Foco interno** | Rótulos em jargão: "megahertz" em vez de "velocidade" | --- ## As perguntas da entrega 1. **Para a oportunidade escolhida, quais valores os concorrentes entregam e como?** → faça a curva de valor **deles** primeiro 2. **Qual valor só a sua solução vai entregar?** O que a torna única? 3. **O valor entregue é o mesmo para usuário e cliente**, se houver essa distinção? A pergunta 3 é curta e derruba projeto. Se a escola paga e o aluno usa, a PUV que encanta o aluno pode ser irrelevante para quem assina o cheque. Frequentemente é preciso **uma PUV para cada**, e elas precisam ser compatíveis. --- ## Como escrever a PUV A definição operacional: **por que você é diferente e vale a pena conquistar atenção.** Note a formulação — não é "vale a pena comprar". A primeira batalha nem é vender; é conseguir atenção. Visitantes de primeira viagem gastam cerca de **8 segundos** numa página antes de decidir se ficam. ### Três regras 1. **Seja diferente, mas garanta que a diferença importa.** A chave é derivar a PUV **diretamente do problema nº 1** que você resolve. Se o problema vale a pena, você já está mais da metade do caminho. 2. **Mire o usuário afoito**, não o meio. Mensagem para o meio sai diluída — e o seu produto ainda não é para o mercado de massa. 3. **Foque no benefício da história terminada.** ### Feature, benefício e benefício da história terminada | Nível | Exemplo (serviço de currículos) | |---|---| | Funcionalidade | "modelos projetados profissionalmente" | | Benefício | "um currículo que chama atenção" | | **História terminada** | **"conseguir o emprego dos seus sonhos"** | Benefício ainda exige que o cliente traduza para a visão de mundo dele. A boa PUV entra na cabeça dele e foca no que ele obtém **depois** de usar. ### A fórmula > **Headline de clareza instantânea = resultado final que o cliente quer + prazo específico + tratamento da objeção** Os dois últimos são ótimos se couberem, mas **não são obrigatórios**. O exemplo canônico junta os três: *"Pizza quente entregue na sua porta em 30 minutos ou é de graça."* ### Quatro testes antes de fechar Dois vêm do livro e dois são heurísticas da disciplina — a distinção está marcada porque importa saber o que você pode citar como fonte. | Teste | Como aplicar | Origem | |---|---|---| | **Público** | Se a frase serve para todo mundo, não serve para o usuário afoito. Mensagem para o meio sai diluída | Maurya | | **Palavras próprias** | Escolha poucas palavras-chave e seja dono delas (Performance = BMW; Design = Audi; Prestígio = Mercedes) | Maurya | | **Substituição** | Troque o nome do seu produto pelo de um concorrente. Se a frase continua verdadeira, refaça | heurística da disciplina | | **Superlativo** | Se depende de "melhor", "mais fácil", "mais rápido" sem número, não diz nada | heurística da disciplina | --- ## Pitch de alto conceito — e por que ele NÃO vai no site Destilação estilo Hollywood: *"YouTube: Flickr para vídeo"*, *"Aliens: Tubarão no espaço"*. > **Não confunda com a PUV, e não use na landing page.** Há o risco de os conceitos em que o pitch se apoia serem desconhecidos do seu público. Onde ele serve: **no fecho de uma entrevista**, como gancho memorável que ajuda a pessoa a espalhar a ideia. E note a torção: ancore na ferramenta que **o interlocutor** já usa — *"o SmugMug sem precisar fazer upload"*, trocando "SmugMug" pelo serviço que aquela pessoa citou. --- ## Nome e slogan — comece a pensar agora A Q10 vai pedir **nome comercial e slogan**, e equipe que só pensa nisso na véspera improvisa. O insumo nasce aqui: o slogan é o teste da mensagem consistente (acima), e o nome costuma sair das palavras-chave que você escolheu ser dono. Não decida agora — só anote os candidatos junto com a PUV. Na Q10 você escolhe entre o que já existe. > **Slogan não é PUV.** A PUV explica por que você é diferente; o slogan é a versão que cabe num banner e que a pessoa repete. Um sai do outro, mas eles não são o mesmo texto. --- ## Vantagem de lascar ≠ PUV - **PUV** é o que você **promete**. - **Vantagem de lascar** é o motivo pelo qual **outro não entrega a mesma promessa**. A definição: algo que **não pode ser facilmente copiado ou comprado**. Funcionalidade não é — é copiável num sprint. Comunidade, dado acumulado, acesso privilegiado, conhecimento de domínio raro e efeito de rede são. Num projeto de semestre é aceitável **não ter ainda** — e é mais honesto dizer isso do que inventar. A vantagem real costuma ser o **conhecimento de campo**: você passou um semestre com um público que ninguém mais estudou. --- ## Procedimento 1. Traga a tabela de valores da Q3 — os que os concorrentes entregam e os que não. 2. Marque os que o **seu usuário afoito** disse que importam. Não os que você acha. 3. **Monte a curva dos concorrentes primeiro.** Só deles. Isso já revela onde o setor todo se acumula — e onde não há oportunidade. 4. Preencha a **matriz ERRC**, nesta ordem. Se as caixas de eliminar e reduzir ficarem vazias, pare e volte. 5. Desenhe a sua curva. Aplique os três critérios. 6. Escreva a PUV em uma frase. Aplique os quatro testes. 7. **Volte a campo e mostre a frase para 5 pessoas.** Se ninguém entender sem explicação, o problema é a frase. 8. Se usuário e cliente forem distintos, repita 6 e 7 para o cliente. --- ## Referências desta quest | Arquivo | Quando | |---|---| | **Curva de valor — Quest #5** (neste arquivo) | Ao montar. Passo a passo, o processo de quatro etapas em equipe, exemplos trabalhados | | **Escrever a PUV — Quest #5** (neste arquivo) | Ao redigir. Fórmula, testes, exemplos, o que não fazer | | **Autodiagnóstico — Quest #5** (neste arquivo) | Antes de entregar | --- ### Técnicas desta quest Fichas curtas de consulta rápida. Abra quando o procedimento acima mencionar a técnica. | Ficha | Para quê | |---|---| | **Blue Ocean Strategy** (neste arquivo) | a grade das quatro ações | | **Curva de Valor** (neste arquivo) | como montar e como ler | | **Percepção de Valor** (neste arquivo) | valor × novidade | | **Vantagem de Lascar (Unfair Advantage)** (neste arquivo) | o que não se copia | | **Brainstorm** (neste arquivo) | gerar candidatos a valor único | --- ## Perguntas frequentes **"E se descobrirmos que não temos nada de único?"** É resultado legítimo, e melhor descobrir agora do que na Q8. Duas saídas: mudar de segmento (o mesmo produto pode ser único para um público mais específico) ou mudar o mecanismo. O que não funciona é seguir para a Q6 fingindo. **"Podemos perguntar aos clientes o que tornaria a solução única?"** Não espere resposta útil. Os próprios clientes não conseguem imaginar como criar espaço novo; a perspectiva deles tende a "me dê mais por menos". A singularidade vem de observar as **alternativas** e os **não clientes**, não de pedir sugestão. --- ## Bibliografia desta quest | Obra | O que ela dá para a Q5 | |---|---| | **Kim & Mauborgne — A estratégia do oceano azul** | Inovação de valor, quatro ações, matriz ERRC, os três critérios, diagnóstico de curva | | **Maurya — Running Lean** | O bloco PUV, a fórmula do headline, feature/benefício/história terminada, pitch de alto conceito | | **Osterwalder & Pigneur — Business Model Generation** | O vocabulário de fontes de valor: novidade, desempenho, customização, design, marca, preço, redução de risco, acessibilidade, conveniência | | **Brown — Change by Design** | O filtro desejabilidade / viabilidade / exequibilidade | | **Ries — A startup enxuta** | Bibliografia oficial da quest no site | # Autodiagnóstico — Quest #5 Rode isto **depois** de a curva estar desenhada e a frase escrita, e **antes** de mostrar para alguém de fora. O milestone **PUV** abre aqui, e a **Prova de conceito** começa a ser gestada — o que significa que o erro desta quest se paga com escopo na próxima. Pontue cada bloco de 0 a 5. **Some no fim e leia a régua.** --- ## Rubrica — Curva dos concorrentes | Nota | Estado | |---|---| | 0 | Não foi desenhada; foi direto para a curva da equipe. | | 1 | Foi desenhada, mas o eixo X só tem funcionalidades de produto. | | 2 | Há fatores não funcionais (preço, canal, conveniência), mas os rótulos estão em jargão da equipe. | | 3 | Os rótulos usam **palavras que os usuários disseram**, e o eixo inclui pelo menos uma **alternativa existente que não é produto** — planilha, caderno, grupo de mensagens, não fazer nada. | | 4 | Estão representadas também as **alternativas fora do setor**: o outro jeito pelo qual o usuário atende à mesma necessidade hoje. | | 5 | A equipe consegue apontar, olhando o desenho, **onde o setor todo se acumula** — e portanto onde não há oportunidade. Se as curvas dos concorrentes saíram quase idênticas, isso está registrado como achado, não corrigido como erro. | --- ## Rubrica — Matriz eliminar-reduzir-elevar-criar | Nota | Estado | |---|---| | 0 | Não foi preenchida, ou só há a curva. | | 1 | As caixas **eliminar** e **reduzir** estão vazias. É lista de desejos. | | 2 | Há algo em eliminar e reduzir, mas são itens que a equipe já não ia fazer mesmo. | | 3 | Há pelo menos um item eliminado que **o setor considera indispensável**. | | 4 | Para cada corte, está escrito **por que ele não destrói valor para o usuário** — com evidência de campo, não com raciocínio da equipe. | | 5 | Os cortes reduzem custo ou escopo de forma verificável **e** os acréscimos vêm de fora do setor ou dos não clientes. A equipe sabe dizer o que o corte libera: tempo de semestre, dependência de terceiro, complexidade. | --- ## Rubrica — A sua curva | Nota | Estado | |---|---| | 0 | Alta em tudo. | | 1 | Diverge dos concorrentes em um fator só, e é um fator que ninguém percebe. | | 2 | Tem foco, mas há **contradição estratégica**: alto num fator e baixo no que o sustenta. | | 3 | Passa nos três critérios — foco, singularidade e mensagem consistente. | | 4 | Passa nos cinco diagnósticos de curva ruim (falta de foco, sobreposição, excesso sem retorno, contradição, foco interno). | | 5 | A curva é **desenhável de memória** por qualquer integrante da equipe, e a mensagem sai junto com o desenho. | --- ## Rubrica — A frase | Nota | Estado | |---|---| | 0 | Descreve a solução: "uma plataforma que integra...". | | 1 | Está no nível da funcionalidade. | | 2 | Está no nível do benefício, mas exige que o leitor traduza para a vida dele. | | 3 | Está no nível do **benefício da história terminada**, e responde **o quê** e **quem**. | | 4 | Passa nos quatro testes: substituição, superlativo, público, palavras próprias. | | 5 | Foi mostrada a **cinco pessoas do público-alvo sem explicação prévia** e todas entenderam. Se há prazo específico ou tratamento de objeção, eles são verdadeiros — a mensagem anuncia oferta que existe. | --- ## Rubrica — Usuário e cliente | Nota | Estado | |---|---| | 0 | A distinção nem foi considerada. | | 1 | Foi considerada e a equipe concluiu, sem verificar, que são a mesma pessoa. | | 2 | São distintos e há **uma única PUV**, escrita para o usuário. | | 3 | Há uma PUV para cada. | | 4 | As duas PUVs são **compatíveis**: nada que encanta um inviabiliza o outro. | | 5 | Cada PUV foi testada com o seu próprio público, separadamente. | --- ## A régua | Soma (0–25) | Leitura | |---|---| | 0–9 | Provavelmente é "igual, mas melhor". Volte à curva dos concorrentes. | | 10–15 | Há diferença, mas ela ainda não foi verificada com ninguém de fora. | | 16–21 | Defensável. Ataque o bloco de menor nota antes de seguir para a Q6. | | 22–25 | Pronta. Use o tempo restante para começar a converter a curva em escopo de prova de conceito. | --- ## Os sinais de "igual, mas melhor" Este é o erro que mais custa nesta quest. Cinco sinais, e basta um: - [ ] A frase sobrevive à troca do nome do produto pelo de um concorrente - [ ] A curva da equipe tem a **mesma forma** da dos concorrentes, só que mais alta - [ ] As caixas de eliminar e reduzir têm menos itens do que as de elevar e criar - [ ] A diferença que a equipe reivindica é uma funcionalidade - [ ] A justificativa da diferença começa com "a gente acha que" --- ## Antes de entregar - [ ] Curva dos concorrentes e curva da equipe, na **mesma escala**, na **mesma página** - [ ] Matriz eliminar-reduzir-elevar-criar com as quatro caixas preenchidas - [ ] A PUV em uma frase, com subtítulo se necessário - [ ] Resposta explícita à pergunta 3 da entrega: o valor é o mesmo para usuário e cliente? - [ ] Registro de quem foram as cinco pessoas do teste da frase, e o que cada uma entendeu - [ ] Nenhuma nota do eixo Y vinda de avaliação da equipe: elas vêm da percepção declarada pelo usuário --- ## O filtro para a próxima quest A PUV é uma promessa; a prova de conceito é o começo de honrá-la. Brown propõe avaliar ideias por três restrições que se sobrepõem: **desejabilidade** (o que faz sentido para as pessoas e para as pessoas), **exequibilidade** (o que é funcionalmente possível num futuro previsível) e **viabilidade** (o que tem chance de virar parte de um modelo de negócio sustentável). Um projetista competente resolve cada uma; o que distingue o pensamento de projeto é **trazê-las a um equilíbrio harmonioso** — e o peso entre elas varia de projeto para projeto. **Na virada para a Q6:** classifique cada elemento da sua curva nas três colunas. Um fator que só existe em desejabilidade, sem nota em exequibilidade, é promessa que o semestre não paga — melhor descobrir agora, enquanto a curva ainda é um desenho. --- ## Fontes - **Kim & Mauborgne**, *A estratégia do oceano azul* — os três critérios e os diagnósticos de curva ruim, que estruturam os blocos 1 a 3. - **Maurya**, *Running Lean* — funcionalidade, benefício e benefício da história terminada, e as regras que estruturam o bloco 4. - **Brown**, *Change by Design* — as três restrições sobrepostas e a observação de que o peso entre elas varia por projeto. # Curva de valor — Quest #5 Abra este arquivo quando for **desenhar** — não quando for discutir. A curva é o instrumento da pergunta 1 da entrega ("quais valores os concorrentes entregam e como?") e a base de tudo que vem depois. --- ## 1. Passo a passo da montagem A **matriz de avaliação de valor** captura a situação vigente do espaço de mercado conhecido e, ao fazê-lo, **explicita a necessidade de mudança**. Kim e Mauborgne relatam que basta pedir a executivos que desenhem a própria curva para que a discussão sobre mudar deixe de ser opinião: eles chamam isso de "estridente toque de despertar". É por isso que se desenha **a curva dos concorrentes primeiro**. **Passo 1 — Liste os fatores de competição (eixo X).** Fontes, nesta ordem: a tabela de alternativas existentes da Q3; as palavras que o usuário afoito usou; e as **alternativas fora do setor** — o livro insiste em observar como o cliente poderia atender à mesma necessidade por outro caminho, e dá o exemplo de que em percursos curtos o automóvel é a alternativa ao avião, com vantagens que precisam ser analisadas. ⚠️ **A armadilha número um, descrita no livro com precisão.** O gerente de fornecimento de refeições de uma companhia aérea tem muita sensibilidade para comparar a empresa em lanches — e é esse foco que atrapalha uma avaliação consistente: **o que parece uma grande diferença para ele pode não importar ao cliente, que olha a oferta completa.** O segundo caso é ainda mais próximo de vocês: um diretor de informática valoriza a estrutura de TI pela capacidade de exploração de dados, atributo **não percebido pela maioria dos clientes**, interessados em velocidade e facilidade de uso. Traduzindo: cada pessoa vai propor como fator aquilo que sabe fazer, e a curva vira o organograma da equipe. **Passo 2 — Marque o nível de oferta (eixo Y).** É o nível **segundo a percepção do comprador**; nota alta significa entregar mais e investir mais. **No caso do preço, nota alta significa preço mais alto.** Três níveis bastam; não invente escala de 0 a 10, que só gera discussão falsa entre 6 e 7. **Passo 3 — Desenhe só as curvas dos concorrentes.** Se saírem quase idênticas, isso é um **achado**: no caso da Southwest, as curvas das rivais eram tão semelhantes que puderam ser resumidas numa **única curva**. **Passo 4 — Preencha a matriz eliminar-reduzir-elevar-criar.** Nesta ordem, com as duas caixas de corte cheias. A pesquisa dos autores registra que **raramente os gestores se esforçam para eliminar e reduzir de forma sistemática** os investimentos nos atributos que são a base da concorrência — e a consequência são custos crescentes e modelos de negócio complexos. **Passo 5 — Desenhe a sua curva e escreva a mensagem.** A mensagem faz parte do desenho. --- ## 2. O processo de quatro passos, em equipe Kim e Mauborgne desenvolveram, ao longo de 20 anos, um processo estruturado para desenhar e analisar essas matrizes. O caso descrito é o de um grupo de serviços financeiros chamado no livro de **EFS**, cuja estratégia resultante gerou **30% de aumento de receita no primeiro ano**. ### Passo 1 — Despertar visual, com limite de 90 minutos Mais de 20 gerentes seniores, de quatro continentes, em duas equipes: uma desenharia a curva do negócio tradicional de câmbio corporativo, outra a do negócio on-line, ambas contra as dos concorrentes. **Ambas tinham 90 minutos** — e a razão está escrita no livro: **se a EFS tivesse uma estratégia nítida, esse tempo seria suficiente.** O livro registra que "a experiência foi dolorosa": discutiu-se calorosamente o que eram os fatores; europeus e americanos discordavam sobre o que importava; várias pessoas defendiam fatores que só interessavam a elas. Alguém da equipe on-line argumentou que os clientes seriam atraídos por **confirmação instantânea das transações** — serviço que ninguém mais achava necessário e que o setor jamais oferecera. Guarde essa pessoa. O que os gráficos mostraram: séria falta de foco, curvas **muito semelhantes às dos concorrentes**, e nenhuma mensagem consistente. Havia ainda uma contradição visível — o negócio on-line investira muito na facilidade de uso do site, **chegando a receber prêmios**, mas o site era um dos mais lentos do setor. E o concorrente mais forte, chamado no livro de *Clearskies*, tinha estratégia com foco e originalidade, comunicável com facilidade: **"One-click E-Z FX."** Diante de prova gráfica, os executivos não puderam defender o que haviam demonstrado ser uma estratégia deficiente — **as tentativas de desenhar as matrizes foram mais convincentes quanto à necessidade de mudança do que qualquer argumento baseado em números e palavras.** **Na equipe:** duas subequipes, 90 minutos cronometrados, sem material novo. Não conseguir desenhar a curva do setor em 90 minutos não é falta de tempo — é o setor ainda não entendido. ### Passo 2 — Exploração visual, em campo > **As empresas jamais devem terceirizar seus olhos e ouvidos. Nada substitui a própria percepção.** O livro observa que os gestores quase sempre delegam essa parte, confiando em relatórios de terceiros afastados por um ou dois níveis do mundo que descrevem. A EFS mandou os gerentes a campo por **quatro semanas**; **cada um entrevistou e observou 10 pessoas**, incluindo clientes perdidos, clientes novos e clientes dos concorrentes e das alternativas. Foram além das fronteiras do setor, visitando empresas que ainda **não** usavam o serviço mas talvez viessem a usar; entrevistaram os **usuários finais** — contabilidade e tesouraria, não só quem contratava; e examinaram serviços auxiliares. Os resultados **reverteram** conclusões do passo 1. Os gerentes de relacionamento, tidos por quase todos como fator crítico de sucesso e motivo de orgulho, eram o calcanhar de aquiles: os clientes detestavam perder tempo com eles e os viam como "salvadores de relacionamento", já que a empresa não cumpria promessas. E o fator mais valorizado pelos clientes era **a confirmação rápida das transações** — exatamente o que um único gerente sugerira e todos descartaram. Quem observar, segundo o livro: | Quem | Por quê | |---|---| | Clientes | Primeiros a opinar, mas **não se pode ficar só neles** | | **Não clientes** | Quem poderia usar e não usa | | Usuários, quando o cliente não é o usuário | O exemplo é Bloomberg, que mudou o foco dos compradores de TI para os **usuários** de TI — operadores e analistas | | Produtos e serviços **complementares** | Fonte de ideias de pacote | | **Maneiras alternativas** de atender à mesma necessidade | Como o automóvel para o avião | Sobre Bloomberg, uma observação que serve de antídoto contra a expectativa de genialidade: ele mesmo dizia que a ideia **deveria ser óbvia para qualquer pessoa que algum dia tivesse observado os operadores** usando os serviços concorrentes. De volta à prancheta, **cada equipe teve de desenhar seis novas curvas** — número deliberado, para forçar propostas inovadoras — e escrever, para cada uma, **uma mensagem consistente**. Entre elas: "Deixa com a gente", "Multiplique minha inteligência", "Transações em confiança". ### Passo 3 — Feira de estratégia, com limite de 10 minutos por ideia Depois de duas semanas de desenhos e redesenhos, as 12 curvas foram apresentadas. A plateia tinha executivos seniores e, **em maioria, gente de fora**: não clientes, clientes de concorrentes e os clientes mais exigentes da empresa. As regras: - **Duas horas para 12 curvas.** - **No máximo 10 minutos por curva**, sob a teoria de que **qualquer ideia cuja explicação leve mais de 10 minutos é provavelmente complicada demais para ser boa**. - Desenhos **afixados nas paredes**. - Cada juiz recebe **cinco notas adesivas** e as prende ao lado das preferidas, podendo colocar todas numa só. - Depois da votação, **cada juiz justifica as escolhas — e por que não votou nas outras**. O livro registra que a transparência e o imediatismo **eliminaram as considerações políticas** endêmicas ao planejamento estratégico. E quantifica o aprendizado: **quase um terço** do que se julgava serem atributos competitivos básicos era **secundário para os clientes**; **outro terço** não fora bem articulado ou fora ignorado no despertar visual. A curva final gerou a mensagem **"A FedEx das operações cambiais corporativas: fácil, confiável, rápida e rastreável"** — e o modelo de negócios ficou mais simples de executar, não mais complexo. **Na equipe:** três a seis versões da curva, dez minutos cada, cinco adesivos por juiz, e juízes de fora — de preferência os usuários afoitos da Q4. O que não pode ser cortado é a **justificativa dos votos negativos**. ### Passo 4 — Comunicação visual A EFS distribuiu **um diagrama de uma página** com o perfil novo ao lado do anterior. Quem formulou conduziu reuniões explicando **o que devia ser eliminado, reduzido, elevado e criado**; muitos funcionários afixaram o diagrama na própria sala. **Para a Q5, a entrega é esse diagrama**: antes e depois, mesma escala, mensagem embaixo. Se precisar de duas páginas, a curva ainda não tem foco. --- ## 3. Os três exemplos, abertos ### Cirque du Soleil Setor decadente, público encolhendo, alternativas de entretenimento crescendo. Em menos de 20 anos desde a criação, atingiu um nível de receita que o Ringling Brothers and Barnum & Bailey's — campeão mundial do setor — só alcançou após mais de 100 anos. | Ação | Fatores | |---|---| | **Eliminar** | Espetáculos com animais · performance de astros circenses · vários picadeiros (os três círculos) · descontos para grupos nas vendas | | **Reduzir** | Diversão e humor — os palhaços ficaram, mas o humor mudou do pastelão para formas mais encantadoras e refinadas · emoção e perigo — acrobatas e encenações vibrantes mantidos, com papel reduzido e mais elegantes | | **Elevar** | A lona: acabamento externo mais grandioso e mais conforto interno, num momento em que muitos circos a trocavam por recintos alugados. Sumiram a serragem e os bancos duros | | **Criar** | Tema e enredo · várias produções · ambiente refinado para os espectadores · música e dança artísticas | As razões dos cortes são sempre duas — econômica **e** de percepção. Os animais eram um dos componentes mais caros (compra, treinamento, assistência médica, alojamento, alimentação, seguro, transporte) e o público estava cada vez mais incomodado com a exploração deles. Os astros eram caros e, na percepção do público, **inexpressivos em comparação com os artistas de cinema**. Os três picadeiros triplicavam o número de artistas **e** obrigavam o espectador a alternar a atenção, criando ansiedade. Os descontos para grupos geravam receita, mas os preços altos desestimulavam a compra e faziam os pais se sentirem explorados. Do circo tradicional sobraram **três fatores**: a tenda, os palhaços e as acrobacias clássicas. Os novos vieram de **outro setor**, o teatro. E o preço foi definido em comparação com o do teatro: várias vezes o do circo tradicional, mas acessível ao público adulto acostumado a preço de teatro. ⚠️ Nenhum dos cortes é funcionalidade de produto. Animais, astros e picadeiros são formato, elenco e cenografia. ### [yellow tail] A Casella Wines competia com **mais de 1.600 vinicultores** nos Estados Unidos. | Ação | Fatores | |---|---| | **Eliminar** | Terminologia enológica no rótulo · envelhecimento · prestígio e referência ao vinhedo — **não há referência alguma ao vinhedo na garrafa** · campanhas promocionais em mídia de massa | | **Reduzir** | Tanino, carvalho e complexidade do sabor · amplitude da linha, reduzida a **dois vinhos**: um chardonnay e um shiraz | | **Elevar** | Preço, acima dos vinhos de garrafão · envolvimento dos varejistas, que receberam roupas típicas do interior da Austrália e viraram embaixadores | | **Criar** | **Facilidade de beber** · **facilidade de escolher** · **diversão e aventura** | Os três fatores criados vieram de olhar **as alternativas e os não clientes** — bebedores de cerveja e de coquetéis prontos —, não os concorrentes. A descoberta: a maioria dos americanos rejeitava o vinho pela dificuldade de apreciar sua complexidade, enquanto cerveja e coquetel eram mais doces e fáceis de beber. Os efeitos no modelo de negócios são o outro lado da inovação de valor: eliminar o envelhecimento **reduziu a necessidade de capital de giro**; reduzir a variedade **maximizou o giro e minimizou estoque**; e a empresa foi a primeira a pôr tinto e branco em **garrafas do mesmo formato**, simplificando fabricação, compra e exposição. Resultados registrados no livro: em dois anos, a marca de crescimento mais rápido da história do setor vinícola australiano e americano, e o vinho mais importado pelos EUA, superando franceses e italianos; em agosto de 2003, o tinto mais vendido nos EUA, superando os rótulos californianos; média em torno de **4,5 milhões de caixas por ano**. Uma década depois, em mais de 50 países, com mais de 2,5 milhões de taças por dia. O lançamento, em julho de 2001, foi a **US$ 6,99 a garrafa — duas vezes o preço de um vinho de garrafão**; uma década depois, o preço médio nos EUA era US$ 7,49. ### Southwest Airlines | Ação | Fatores | |---|---| | **Eliminar / não investir** | Refeições · salas de espera · escolha de assentos | | **Reduzir** | Preço, ao ponto de competir com o custo de viajar de automóvel | | **Elevar** | Serviços amigáveis · velocidade · frequência de voos | | **Criar** | **Voos diretos entre cidades médias** — a Southwest foi pioneira; até então o deslocamento se dava por conexões em grandes aeroportos | A curva enfatiza **três atributos apenas**, e é isso que permite competir em preço com o automóvel. Os concorrentes investiam em **todos** os atributos do setor, o que tornava muito mais difícil replicar aqueles preços. Sobre a mensagem, uma nuance que vale preservar: o livro apresenta **"Velocidade de avião a preço de carro — sempre que você precisar"** e escreve em seguida que esse é o slogan da Southwest, **"ou pelo menos poderia ser"**. Não é peça publicitária histórica; é a demonstração de que a estratégia **admite** um slogan forte. O argumento fecha pelo contraste: mesmo as melhores agências teriam dificuldade em resumir, numa mensagem consistente, a oferta convencional de almoços, escolha de assentos, salas de espera, conexões, voos mais longos e preços mais altos. --- ## 4. Os cinco diagnósticos de curva ruim Quatro vêm da seção de leitura da matriz; o primeiro está enunciado na seção dos três critérios. | # | Sintoma no desenho | Diagnóstico | O que fazer | |---|---|---|---| | 1 | Curva **alta e plana**, investindo em muitos atributos | **Falta de foco.** Custo alto e modelo complexo de implementar e executar | Escolher os poucos fatores a enfatizar | | 2 | Curva **se confunde com a dos concorrentes** | **À deriva no oceano vermelho.** A estratégia é superar a concorrência em custo ou qualidade. Sinaliza crescimento lento, salvo por sorte se o setor crescer — e aí **o crescimento não é produto da estratégia, é da sorte** | Voltar às alternativas e aos não clientes | | 3 | Níveis **altos em todos os atributos** | **Excesso de oferta sem retorno.** A pergunta: a fatia de mercado e a rentabilidade são compatíveis com esses investimentos? Se não, fornece-se em excesso o que só agrega valor incremental | Decidir o que **eliminar e reduzir** | | 4 | Alto num fator, baixo no que o sustenta | **Contradição estratégica.** O exemplo do livro: investir na facilidade de uso do site e não corrigir a lentidão. Há também contradição entre oferta e preço — uma rede de postos descobriu que oferecia **"menos por mais"**: menos serviços que o melhor concorrente, a preços mais altos | Alinhar o fator com o que o sustenta, ou baixá-lo | | 5 | Rótulos em jargão operacional | **Foco interno.** "Megahertz" em vez de "velocidade"; "temperatura de fontes termais" em vez de "água quente". A linguagem revela se a visão é de fora para dentro ou de dentro para fora | Reescrever cada rótulo com a palavra que o usuário usou | **Acionável:** antes de fechar a curva, passe os cinco em ordem. O item 5 leva dois minutos e é o que mais aparece em entrega de equipe de computação. --- ## Fontes - **Kim, W. Chan & Mauborgne, Renée**, *A estratégia do oceano azul* (edição em português) — a matriz de avaliação de valor e o "toque de despertar"; a dificuldade de avaliação consistente, com os exemplos do gerente de refeições e do diretor de informática; as quatro ações e a observação de que raramente se elimina e reduz sistematicamente; o processo de quatro passos e o caso EFS, com os 90 minutos, as quatro semanas de campo e as 10 pessoas por gerente, as seis curvas por equipe, as 12 curvas em duas horas, os 10 minutos por ideia, as cinco notas adesivas e a justificativa dos votos, os terços de atributos secundários e mal articulados, a mensagem final e o diagrama de uma página; o alerta contra terceirizar olhos e ouvidos e o exemplo de Bloomberg; as quatro ações do Cirque du Soleil, do [yellow tail] e da Southwest, com os números citados; os três critérios; os diagnósticos de leitura da matriz. - Os procedimentos de escala para uma equipe de Projetão (subequipes, cronometragem, juízes externos) são adaptações minhas do processo descrito no livro. # Escrever a PUV — Quest #5 Abra este arquivo depois de a curva de valor estar desenhada e a matriz eliminar-reduzir-elevar-criar estar preenchida. Escrever a frase antes de ter a curva produz slogan, não proposta única de valor. O `SKILL.md` da quest dá a fórmula, os quatro testes e a distinção em relação ao pitch de alto conceito. Aqui está o raciocínio por trás de cada um, os exemplos, e o vocabulário que alimenta o eixo X da curva. --- ## 1. A definição, e por que ela mudou Maurya reescreveu a própria definição depois da primeira edição do livro: **Proposta única de valor: por que você é diferente e vale a pena conquistar atenção.** A versão anterior terminava em "vale a pena comprar", e ele riscou. O argumento: **vender é uma conversa**, e é difícil demais fazer isso com uma única frase. Mais importante — **a primeira batalha nem é vender; é conseguir a atenção do interessado.** O número que sustenta isso: visitantes de primeira viagem passam, em média, **oito segundos** numa página. O livro cita como origem o *Landing Page Handbook* da MarketingSherpa, de 2005, com a estimativa de que **até 50% dos visitantes abandonam a página nos primeiros oito segundos**. A PUV é a primeira interação da pessoa com o produto: se for boa, ela fica e vê o resto; se não, sai. ⚠️ **A leitura prática para a Q5.** A pergunta que a equipe tem de responder não é "o que o nosso produto faz de melhor?", e sim "**por que essa pessoa continuaria lendo?**". São perguntas diferentes, e a segunda é mais difícil. E a PUV é a mais difícil de acertar de todo o modelo de negócio. Maurya diz isso com todas as letras — é a caixa central e a mais dura. A boa notícia que ele acrescenta: **não precisa ficar perfeita de saída**; começa-se com o melhor palpite e itera-se, como todo o resto. --- ## 2. Funcionalidade, benefício e benefício da história terminada Todo mundo já ouviu que se deve destacar benefício em vez de funcionalidade. Maurya vai um degrau além: **benefício ainda exige que o cliente traduza a frase para a visão de mundo dele.** Uma boa PUV entra na cabeça da pessoa e foca no que ela obtém **depois** de usar o produto. O exemplo do livro, para um serviço de construção de currículos: | Nível | Frase | |---|---| | Funcionalidade | "modelos projetados profissionalmente" | | Benefício | "um currículo que chama atenção" | | **Benefício da história terminada** | **"conseguir o emprego dos seus sonhos"** | Repare no que muda de linha para linha: a primeira fala do produto, a segunda fala do resultado imediato, a terceira **fala da vida da pessoa**. O produto some. **Acionável:** escreva as três linhas para a sua solução, nessa ordem, e entregue só a terceira. Se a terceira linha for igual à segunda, a equipe ainda está falando do produto. --- ## 3. A fórmula > **Headline de clareza instantânea = resultado final que o cliente quer + prazo específico + tratamento da objeção** Maurya credita a fórmula a **Dane Maxwell**, e registra explicitamente que **os dois últimos elementos são ótimos se couberem, mas não são obrigatórios**. O exemplo clássico que junta os três é o slogan da Domino's: **"Pizza quente e fresca entregue na sua porta em 30 minutos, ou é de graça."** Decomposto: | Elemento | No exemplo | |---|---| | Resultado final que o cliente quer | pizza quente e fresca na porta | | Prazo específico | em 30 minutos | | Tratamento da objeção | ou é de graça | A objeção tratada não é "e se demorar?" — é a desconfiança de que a promessa de prazo seja vazia. Note que a objeção respondida é **a que a própria promessa cria**. Dois exemplos de PUVs que o próprio Maurya usou nos produtos dele, e que mostram o formato "frase + subtítulo": - **Lean Canvas** — "Gaste mais tempo construindo do que planejando o seu negócio." / *A maneira mais rápida e eficaz de comunicar o seu modelo de negócio* - **USERcycle** — "Transforme seus usuários em clientes apaixonados." / *Software de gestão do ciclo de vida do cliente* A frase de cima é o benefício da história terminada; a linha de baixo diz **o que é**. Maurya recomenda exatamente isso: a PUV precisa responder claramente **o quê** e **quem**; o **porquê** muitas vezes não cabe na mesma frase, e ele usa um subtítulo. --- ## 4. As três regras que antecedem a frase ### Seja diferente, mas garanta que a diferença importa A chave, segundo Maurya, é **derivar a PUV diretamente do problema número um que você resolve**. Se esse problema vale mesmo a pena ser resolvido, você já percorreu mais da metade do caminho. Isso amarra a Q5 à Q4 de forma dura: **a PUV não pode citar um problema que não esteja no topo da ordenação feita pelos usuários.** Maurya coloca a destilação como objetivo declarado do ciclo de entrevistas: > **O objetivo final é destilar o produto até um único problema *must-have* — uma única proposta única de valor.** ### Mire o usuário afoito, não o meio Muita gente de marketing mira "o meio", na esperança de alcançar o cliente de mercado de massa, e **no processo dilui a mensagem**. O produto de vocês ainda não está pronto para o mercado de massa. O trabalho é encontrar e mirar o usuário afoito — o que exige mensagem **ousada, clara e específica**. ### Foque no benefício da história terminada Já tratado na seção 2. ### E duas regras de vocabulário **Escolha poucas palavras-chave e seja dono delas.** O exemplo do livro são as marcas de automóvel de luxo, cada uma dona de uma única palavra: | Palavra | Marca | |---|---| | Desempenho | BMW | | Design | Audi | | Prestígio | Mercedes | Maurya acrescenta um efeito colateral prático: usar consistentemente umas poucas palavras-chave também ajuda o posicionamento em busca. **As palavras têm de ser as do cliente.** A instrução dele é direta: **o melhor jeito de descobrir as palavras-chave da sua PUV é ouvir atentamente como os clientes descrevem o próprio fluxo de trabalho.** Não é o momento de inventar nome bonito. E uma advertência que muda o texto da frase: **entenda de verdade as alternativas existentes dos seus usuários afoitos**, porque é contra elas que eles vão julgar a sua solução, o seu preço e o seu posicionamento. O caso que ele dá é o mais comum no Projetão: **se as alternativas existentes são todas gratuitas, o seu produto tem de prometer e entregar valor suficiente para superar o fato de que as alternativas são de graça.** **Estude PUVs boas.** Maurya recomenda visitar as páginas das marcas que você admira e desmontar como e por que a mensagem funciona; cita Apple, 37signals e FreshBooks como as que mais lhe ensinaram. --- ## 5. Os quatro testes | Teste | Como rodar | Reprovou se | |---|---|---| | **Substituição** | Troque o nome do seu produto pelo de um concorrente ou de uma alternativa existente | A frase continua verdadeira | | **Superlativo** | Risque "melhor", "mais fácil", "mais rápido", "mais completo" | Não sobra frase | | **Público** | Pergunte para quem a frase foi escrita | Serve para todo mundo | | **Palavras próprias** | Aponte as duas ou três palavras que vocês reivindicam | Não há nenhuma, ou são palavras que todo concorrente usa | ⚠️ **Nota de origem.** Os testes de **público** e de **palavras próprias** são leitura direta de duas instruções de Maurya — mirar o usuário afoito em vez do meio, e escolher poucas palavras-chave e ser dono delas. Os testes de **substituição** e de **superlativo** são formulações minhas para operacionalizar a exigência dele de que a diferença precisa importar; não estão enunciados assim no livro. Use-os como filtro, não os cite como se fossem do autor. E há um quinto teste, esse sim prescrito pelo `SKILL.md` e coerente com todo o método: **mostre a frase para cinco pessoas do público-alvo.** Se ninguém entender sem explicação, o problema é a frase — não o público. --- ## 6. Pitch de alto conceito É uma destilação no estilo de Hollywood, usada por produtores para reduzir o enredo de um filme a uma frase memorável. Maurya credita a popularização como ferramenta de pitch ao livro eletrônico *Pitching Hacks*, do Venture Hacks. Os exemplos do livro: - **YouTube:** "Flickr para vídeo" - **Aliens** (filme): "Tubarão no espaço" - **Dogster:** "Friendster para cachorros" ### Por que ele não vai na página Maurya é explícito: **o pitch de alto conceito não deve ser confundido com a PUV e não se destina à página de captação.** O motivo é concreto — **há o risco de os conceitos em que ele se apoia serem desconhecidos do seu público.** "Flickr para vídeo" só funciona com quem sabe o que é o Flickr. ### Onde ele serve No **fecho de uma entrevista**. No roteiro de entrevista de Maurya, os dois últimos minutos têm três tarefas: dar um gancho que mantenha o interesse, pedir permissão para voltar, e pedir indicações de outras pessoas. O pitch de alto conceito serve à primeira: explica a solução num nível alto **e deixa uma frase memorável que ajuda a pessoa entrevistada a espalhar a mensagem**. E há uma torção operacional no exemplo dele que vale copiar. O texto do roteiro é: *"Como falei no começo, isto não é um produto pronto, mas estamos construindo um produto que vai simplificar como os pais compartilham fotos e vídeos on-line. A melhor forma de descrever o conceito talvez seja 'o SmugMug sem precisar fazer upload'"* — **trocando "SmugMug" pelo nome do serviço que a própria pessoa entrevistada usa.** Ou seja: o pitch é **ancorado na ferramenta que o interlocutor já usa**, e muda de pessoa para pessoa. É o oposto de um slogan, que precisa ser o mesmo para todos. É por isso que os dois não se confundem. --- ## 7. O vocabulário de fontes de valor Osterwalder e Pigneur listam os elementos que podem contribuir para a criação de valor — e registram que **a lista não é exaustiva**, e que valores podem ser quantitativos (preço, velocidade de atendimento) ou qualitativos (design, experiência do cliente). Para a Q5, essa lista tem uma função específica: **é o antídoto contra um eixo X composto só de funcionalidades.** Quando a equipe travar na montagem da curva, passe pelos onze e pergunte, em cada um, "o setor compete nisso?". | Fonte de valor | O que é | Exemplo do livro | Como vira fator de competição | |---|---|---|---| | **Novidade** | Atende a um conjunto de necessidades que o cliente antes nem percebia, porque não havia oferta similar. Frequentemente, mas nem sempre, ligada a tecnologia | Telefone celular; fundos de investimento éticos, que pouco têm a ver com tecnologia nova | "Existe categoria para isso?" | | **Desempenho** | Melhorar o desempenho do produto ou serviço — via tradicional, e com limites | O setor de PC, onde máquinas mais rápidas e mais disco deixaram de produzir crescimento correspondente de demanda | Velocidade, capacidade, precisão | | **Customização** | Ajustar às necessidades específicas de um cliente ou segmento | Customização em massa e cocriação com o cliente | Grau de configuração | | **"Fazer o trabalho"** | Simplesmente ajudar o cliente a dar conta de uma tarefa | A Rolls-Royce fabrica e mantém os motores, e as companhias aéreas pagam por hora de motor em operação, podendo focar em operar a companhia | Quanto do trabalho sai das mãos do usuário | | **Design** | Importante e difícil de medir; decisivo em moda e eletrônicos de consumo | — | Aparência, acabamento | | **Marca / status** | O valor está no ato de usar e exibir a marca | Um Rolex sinaliza riqueza; skatistas usam marcas "de submundo" para sinalizar pertencimento | Prestígio, pertencimento | | **Preço** | Valor semelhante por preço menor, para segmentos sensíveis a preço | Southwest, easyJet e Ryanair desenharam modelos inteiros para viabilizar voo barato; o Tata Nano tornou o automóvel acessível a um novo segmento | O fator preço da curva — lembrando que **nota alta = preço alto** | | **Redução de custos** | Ajudar o cliente a reduzir os custos dele | A Salesforce.com vende CRM hospedado, poupando o comprador de comprar, instalar e gerir o software | Quanto o usuário deixa de gastar | | **Redução de riscos** | Reduzir o risco que o cliente assume ao comprar | Garantia de um ano no carro usado; garantia de nível de serviço na TI terceirizada | Garantia, previsibilidade | | **Acessibilidade** | Disponibilizar a quem antes não tinha acesso | A NetJets popularizou a propriedade fracionada de jatos; fundos mútuos permitiram carteira diversificada a quem tem patrimônio modesto | Quem passa a poder usar | | **Conveniência / usabilidade** | Tornar mais conveniente ou mais fácil de usar | iPod e iTunes, pela conveniência de buscar, comprar, baixar e ouvir música | Esforço para completar a tarefa | ⚠️ Note quantos desses **não são funcionalidade**: marca, preço, acessibilidade, redução de risco, "fazer o trabalho". É exatamente a correção que o `SKILL.md` faz ao material do site — e esta tabela é a lista de onde tirar os fatores que faltam. --- ## 8. Antes de fechar - [ ] A PUV deriva do **problema número um** ordenado pelos usuários, não do que a equipe sabe construir - [ ] Está no nível do **benefício da história terminada** - [ ] Usa **palavras que o usuário disse**, e há duas ou três que a equipe reivindica - [ ] Passou pelos quatro testes - [ ] Foi mostrada a **cinco pessoas do público-alvo** sem explicação prévia - [ ] Se cliente e usuário são distintos, **há uma PUV para cada**, e elas são compatíveis - [ ] O pitch de alto conceito, se existir, está guardado **para o fim das entrevistas** — e não na página --- ## Fontes - **Maurya, Ash**, *Running Lean* — a definição revista de PUV e o argumento sobre atenção antes de venda; os oito segundos, atribuídos ao *Landing Page Handbook* da MarketingSherpa (2005), com até 50% de abandono; funcionalidade, benefício e benefício da história terminada, com o exemplo do serviço de currículos; a fórmula do headline de clareza instantânea, creditada a Dane Maxwell, com o exemplo da Domino's e a nota de que os dois últimos elementos são opcionais; as regras de ser diferente com diferença que importe, mirar o usuário afoito e focar o benefício da história terminada; responder "o quê", "quem" e "por quê"; escolher e ser dono de poucas palavras, com BMW, Audi e Mercedes; ouvir as palavras que o cliente usa; entender as alternativas existentes e o caso das alternativas gratuitas; destilar até um único problema *must-have*; estudar PUVs alheias (Apple, 37signals, FreshBooks); os exemplos Lean Canvas e USERcycle; o pitch de alto conceito, creditado a *Pitching Hacks* do Venture Hacks, com YouTube, Aliens e Dogster, a advertência de não usá-lo na página e o uso no fecho da entrevista, com a substituição do serviço citado pelo entrevistado. - **Osterwalder, Alexander & Pigneur, Yves**, *Business Model Generation* — a lista não exaustiva de elementos que contribuem para a criação de valor, com os exemplos citados em cada linha. - Os testes de **substituição** e de **superlativo** são formulações minhas, sinalizadas no texto. --- # Quest #6 — MVP & Prova de Conceito > **Objetivo.** Apresentar o MVP e sua prova de conceito. | | | |---|---| | **Modo de IA** | 🟢 coprodução na construção · 🔴 sem assistência na validação com usuário | | **Milestones** | **Solução**, **Prova de conceito** e **MVP/Implementação** (os três abrem aqui) | | **Entrega** | definição do MVP + evidência de que o usuário vê valor nele | | **Erro que mais custa** | construir antes de testar o conceito | --- ## 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. | Tipo | Pergunta que responde | Caso conhecido | |---|---|---| | **Smoke test** | As pessoas demonstram intenção de agir diante da promessa, antes de existir produto? | pouco mais que um anúncio | | **Vídeo** | A proposta é entendida e desejada, quando o produto é impossível de prototipar? | Dropbox: vídeo de 3 min levou a lista de espera de 5 mil para 75 mil pessoas | | **Concierge** | Entregando **manualmente**, um cliente por vez, o que o produto precisa ter? | Food on the Table: um único cliente, uma loja, zero software, cheque de US$9,95/semana | | **Mágico de Oz** | Se resolvermos o problema técnico difícil, as pessoas usam? | Aardvark: 8 pessoas respondendo por trás da cortina, 9 meses antes de automatizar | | **Landing page** | O problema vale a pena? Quantos se inscrevem? O canal funciona? | página com sumário e capa, feita em um dia, 1.000 e-mails coletados | **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. | Bloco | Tempo | O que testa | |---|---|---| | Boas-vindas | 2 min | — | | Coletar demografia | 2 min | segmento | | Contar uma história | 2 min | contexto do problema | | **Demo** | **15 min** | a solução | | **Testar preço** | **3 min** | fontes de receita | | Fechamento — o pedido | 2 min | compromisso + indicações | | Documentar | 5 min | — | **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. | Pivô | O que muda | |---|---| | **Zoom-in** | Uma funcionalidade vira o produto inteiro | | **Zoom-out** | O produto inteiro vira uma funcionalidade de algo maior | | **Segmento de cliente** | O produto resolve problema real, mas de **outro** público | | **Necessidade do cliente** | O cliente é o certo; o problema atacado não é o que importa para ele | | **Plataforma** | De aplicação para plataforma, ou o inverso | | **Arquitetura de negócio** | Entre margem alta/volume baixo e margem baixa/volume alto | | **Captura de valor** | Como o valor gerado é monetizado | | **Motor de crescimento** | Entre viral, pegajoso e pago | | **Canal** | A mesma solução chega ao cliente por outro caminho | | **Tecnologia** | Mesmo resultado, tecnologia diferente | **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 | Arquivo | Quando | |---|---| | **Os cinco tipos de MVP — Quest #6** (neste arquivo) | Ao escolher o formato. Os cinco tipos em detalhe, com os casos | | **A entrevista de solução — Quest #6** (neste arquivo) | Antes de entrevistar. Roteiro, falas, teste de preço, critérios de saída | | **Pivotar — Quest #6** (neste arquivo) | Se o projeto não estiver funcionando. Os dez pivôs e como decidir | | **Autodiagnóstico — Quest #6** (neste arquivo) | Antes de entregar | --- ### Antes de registrar pessoas | Arquivo | Quando | |---|---| | `../../metodo/consentimento.md` | Antes de testar a prova de conceito com pessoas | --- ### Técnicas desta quest Fichas curtas de consulta rápida. Abra quando o procedimento acima mencionar a técnica. | Ficha | Para quê | |---|---| | **Brainstorm** (neste arquivo) | gerar formatos de prova de conceito | | **Brainwriting** (neste arquivo) | quando a equipe é desigual | | **Wireframe** (neste arquivo) | o esqueleto antes da estética | | **Usuário afoito (*early adopter*)** (neste arquivo) | quem testa a PoC | | **Entrevistas** (neste arquivo) | o roteiro da conversa de solução | --- ## 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 | Obra | O que ela dá para a Q6 | |---|---| | **Ries — A startup enxuta** | A definição de MVP, os tipos, aprendizado validado, os dez pivôs | | **Maurya — Running Lean** | Entrevista de solução, diretrizes da demo, redução para o Release 1.0 | | **Blank — The Four Steps to the Epiphany** | Customer validation: o portão entre descobrir e escalar | | **Brown — Change by Design** | Protótipo rápido, tosco e barato; prototipar para pensar | | **Hanington & Martin — Universal Methods of Design** | Prototipagem paralela, bodystorming, role-playing, Mágico de Oz | # Autodiagnóstico — Quest #6 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. | Nível | Significado | |---|---| | **0** | O critério ainda não aparece. | | **1** | Já aparece, mas sem clareza nem coerência. | | **2** | Falta clareza **ou** falta coerência com o resto. A resposta ainda está no terreno da insegurança. | | **3** | Coerente, mas ainda não totalmente claro. Resta uma parcela de incerteza. | | **4** | Claro e coerente com toda a proposta. A equipe responde com segurança. | | **5** | Perfeitamente alinhado ao conjunto. As respostas são sólidas. | 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** | "É um app". A categoria é a única descrição. | | **3** | Aplicativo, serviço ou produto físico está definido, mas o que o usuário faz nele ainda é vago. | | **4** | A equipe descreve o artefato, o que ele faz, para quem, e por que **essa** forma e não outra. | | **5** | O acima, mais as formas descartadas e o critério de descarte. | ### 2. Estratégia em curva de valor | | | |---|---| | **2** | A curva da Q5 foi copiada sem alteração, ou não há curva. | | **3** | Há as quatro colunas — eliminar, diminuir, aumentar, criar —, mas todas as funcionalidades caem em "criar". | | **4** | Cada item de "criar" está justificado, e a equipe sabe dizer quantas semanas ele custa. Há itens reais em "eliminar". | | **5** | O acima, com a curva do produto comparada à curva dos concorrentes da Q3, no mesmo eixo de fatores de competição. | ### 3. Mínimo necessário | | | |---|---| | **2** | A lista de funcionalidades é a lista de desejos da equipe. | | **3** | Há corte, mas o critério é esforço de implementação. | | **4** | Cada elemento está rotulado como *must-have*, *nice-to-have* ou *don't-need*, com base no que foi ouvido; os *nice-to-have* estão em backlog nomeado. | | **5** | O acima, e a equipe consegue dizer qual **promessa da PUV** cada *must-have* cumpre. | ### 4. Jornada alterada | | | |---|---| | **2** | A jornada nova é descrita como "fica mais fácil". | | **3** | Há um fluxo de telas, mas não há a jornada anterior para comparar. | | **4** | Jornada de antes e jornada de depois, passo a passo, com a persona da Q1 percorrendo as duas; fica visível onde a gambiarra desaparece. | | **5** | O acima, com os passos que **continuam ruins** depois da solução, assumidos. | --- ## Rubrica — milestone MVP/Implementação ### 5. Escolha do formato de MVP | | | |---|---| | **2** | Nenhuma escolha consciente; construiu-se o que a equipe sabia construir. | | **3** | O formato foi escolhido, mas não está ligado a uma hipótese. | | **4** | Formato escolhido **a partir da pergunta em aberto**, com a hipótese escrita de forma falseável antes de rodar. | | **5** | O acima, com o registro de por que os outros quatro formatos responderiam pior. | ### 6. Evidência com usuário | | | |---|---| | **2** | Feedback de colegas de turma e de familiares. | | **3** | Demonstração para gente do público certo, com registro de opinião. | | **4** | Entrevistas de solução com roteiro cronometrado, ficha por entrevista preenchida individualmente, e **um pedido de compromisso** feito ao final de cada uma; o número de pedidos e o de aceites está registrado. | | **5** | O acima, com um segundo lote rodado depois de ajustar a demo, e a variação entre lotes explicada. | ### 7. Preço | | | |---|---| | **2** | Não se falou de preço. | | **3** | Perguntou-se ao cliente quanto ele pagaria. | | **4** | O preço foi **dito** ao cliente e a reação foi medida, com registro de quem hesitou; há uma faixa e a âncora usada está nomeada. | | **5** | O acima, com um preço mais alto testado depois de a primeira faixa não ter gerado resistência. | ### 8. O que funciona | | | |---|---| | **2** | Telas navegáveis sem nada por trás, apresentadas como sistema. | | **3** | Parte do fluxo funciona; o restante é simulado, e isso não está declarado. | | **4** | O caminho principal funciona de ponta a ponta, e o que é simulado está **explicitamente declarado** — inclusive o que é operado à mão. | | **5** | O acima, com defeitos conhecidos listados e a decisão consciente de tolerá-los ou não, à luz do efeito deles sobre a velocidade de aprendizado. | --- ## 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. # 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: | Risco | A pergunta | |---|---| | **Risco de cliente** | Quem sente a dor? Como identificar o usuário afoito (*early adopter*)? | | **Risco de produto** | Como você resolve esses problemas? Qual o conjunto mínimo de funcionalidades para lançar? | | **Risco de mercado** | Qual o modelo de preço? O cliente paga? Que preço ele suporta? | 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. | Bloco | Tempo | O que testa | |---|---|---| | Boas-vindas — montar o palco | 2 min | — | | Coletar demografia | 2 min | segmento de cliente | | Contar uma história | 2 min | contexto do problema | | **Demo** | **15 min** | a solução | | **Testar preço** | **3 min** | fontes de receita | | Fechamento — o pedido | 2 min | compromisso e indicações | | Documentar | 5 min | — | ### 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 | Diretriz | O que significa, e o modo de falha | |---|---| | **Realizável** | Demo construída numa tecnologia que você não vai usar vende bem e cria elementos impossíveis de recriar. O resultado é o descolamento entre o que foi prometido (e vendido) e o que é entregue. | | **Parecer real** | Wireframe cru é rápido de montar, mas exige do cliente um salto de fé sobre o produto final. **Quanto mais real a demo parece, mais precisamente você testa a solução.** | | **Rápida de iterar** | Você vai receber feedback de usabilidade e precisa incorporá-lo antes da entrevista seguinte. Terceirizar a demo prejudica exatamente isso: sua velocidade passa a depender da agenda de outro. | | **Minimizar desperdício** | Comece em papel, e converta para a tecnologia final em algum ponto — o que for feito fora dela vira retrabalho. | | **Dados realistas** | Nada de *lorem ipsum*. Dados verossímeis não só posicionam a tela como sustentam a narrativa. "Design sem conteúdo não é design, é decoração" (Jeffrey Zeldman, citado por Maurya). | 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: | Princípio | O que faz | |---|---| | **Posição de prêmio** (*prizing*) | Em vez de se apresentar como quem entretém a corte, posicione-se como o prêmio. A referência é Oren Klaff, *Pitch Anything*. | | **Escassez** | "10 clientes" não era manobra: o primeiro objetivo do MVP é aprender, e 10 clientes plenamente envolvidos valem mais que 100 em cima do muro. | | **Ancoragem** | Preço é relativo. Ancorar contra as alternativas existentes parece óbvio para você, mas **o cliente não faz essa referência sozinho** — você tem de fazê-la. | | **Confiança** | Não cobrar por achar o MVP "mínimo demais" inverte a lógica: você reduziu escopo com esforço justamente para construir o produto mais simples que resolve um problema real. | ### 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 — Quest #6 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. | Pivô | O que muda | Sinal de que é o seu caso | |---|---|---| | **Zoom-in** | O que era um recurso isolado vira o produto inteiro | Nas entrevistas, todo mundo comenta a mesma tela e ignora o resto; uma funcionalidade concentra o uso | | **Zoom-out** | O que era o produto inteiro vira um recurso de algo maior | O cliente entende o valor, mas diz que não abriria "mais um app" só para isso; o valor só aparece dentro de um fluxo que já existe | | **Segmento de cliente** | O problema é real e a solução resolve — para **outro** público | A demo ressoa forte com um perfil que não era o seu alvo, e fraco com o alvo declarado | | **Necessidade do cliente** | O público está certo; o problema atacado não é o que importa para ele | Você conhece bem o cliente e percebe que o problema nº 1 dele é outro, vizinho ao seu, e que sua equipe conseguiria resolver | | **Plataforma** | De aplicativo para plataforma, ou o contrário | Terceiros começam a pedir para construir em cima do que você fez; ou, ao contrário, ninguém constrói nada e falta o aplicativo matador | | **Arquitetura de negócio** | Entre margem alta/volume baixo e margem baixa/volume alto | O ciclo de venda ficou longo e caro num produto pensado para massa; ou o contrário, o produto de massa só fecha com venda consultiva | | **Captura de valor** | Como o valor gerado é monetizado | O uso cresce e a receita não acompanha; ou o preço é o único ponto em que as entrevistas travam | | **Motor de crescimento** | Entre viral, pegajoso e pago | A aquisição empata com o abandono; o coeficiente viral não passa de 1; o custo de aquisição sobe acima do valor do cliente | | **Canal** | A mesma solução chega ao cliente por outro caminho | O cliente quer o produto e não consegue comprá-lo pelo caminho que você desenhou; requisitos do canal estão ditando preço e recursos | | **Tecnologia** | Mesmo resultado, tecnologia diferente | Segmento, problema, captura de valor e canal permanecem os mesmos; só muda preço ou desempenho da entrega | 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. | Item | A recomendação | |---|---| | **Cadência** | Uma reunião regular. Menos de algumas semanas entre elas é frequente demais; mais de alguns meses é infrequente demais. Cada equipe encontra o próprio ritmo. | | **Quem participa** | Desenvolvimento de produto **e** liderança comercial, juntos. Na IMVU, somaram-se conselheiros externos, que ajudavam a enxergar além das ideias preconcebidas e a interpretar os dados de outras maneiras. | | **O que produto leva** | Relatório completo dos resultados das iniciativas de otimização **ao longo do tempo** — não só do último período —, comparados com as expectativas, também ao longo do tempo. | | **O que a ponta comercial leva** | Relatos detalhados das conversas com clientes atuais e potenciais. | **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: | Elemento | O que mostrar | |---|---| | A hipótese anterior | O que vocês tinham afirmado, com número | | O dado que a derrubou | Quantas pessoas, o que fizeram, o que não fizeram | | O tipo de pivô | O nome do catálogo, não "mudamos de ideia" | | A nova hipótese | Escrita de forma falseável | | O novo MVP | Qual formato, o que ele mede, quando roda | 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 # 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: | Se a pergunta em aberto é… | O formato é | |---|---| | As pessoas agem diante da promessa, antes de existir produto? | Smoke test | | A proposta é entendida e desejada, mas o produto é impossível de prototipar? | Vídeo | | O que o produto precisa ter, e como o cliente realmente usa? | Concierge | | Se resolvermos o problema técnico difícil, as pessoas usam? | Mágico de Oz | | O problema vale a pena? O canal funciona? Quantos se inscrevem? | Landing page | 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 | Tipo | Responde | **Não** responde | Custo em código | Custo em horas de pessoa | |---|---|---|---|---| | Smoke test | intenção de agir | uso repetido, usabilidade | quase zero | baixo | | Vídeo | compreensão e desejo | usabilidade, retenção | zero | médio (roteiro e edição) | | Concierge | o que o produto precisa ter | efeito de rede, escala | quase zero | alto e contínuo | | Mágico de Oz | valor da solução técnica | viabilidade técnica real, custo em escala | baixo | alto durante as sessões | | Landing page | o problema vale a pena; o canal funciona | se o produto entrega o prometido | baixo | baixo, se houver canal | 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 --- # Quest #7 — Modelo de Receita > **Objetivo.** Apresentar um modelo de receita e a estratégia de atração. | | | |---|---| | **Modo de IA** | 🟡 com apoio · 🔴 sem assistência na pesquisa de preço com clientes | | **Milestones** | **Modelo de receitas**, **Estratégias de tração**, **Tração efetiva** | | **Entrega** | custos, funil ARM e preço validado com gente de verdade | | **Erro que mais custa** | subsidiar o lado errado da plataforma | --- ## O recorte **Modelo de negócio** é o esquema de como o empreendimento obtém os recursos para funcionar, atender clientes e se manter competitivo. Ele vem sendo definido ao longo das quests. Aqui o foco é apenas o **modelo de receitas**: como o produto pode ser remunerado, de forma a pelo menos cobrir seus custos. **E ele deve ser validado com os clientes** — não estimado em reunião. Uma nota estrutural que ajuda: no canvas de negócio, os custos são **resultado** dos demais blocos, não uma escolha independente. Receita, por sua vez, resulta de propostas de valor entregues com sucesso. Se o seu modelo de receita não conversa com a PUV da Q5, um dos dois está errado. --- ## Funil ARM **A**quisição → **R**etenção → **M**onetização. A ordem importa e é contraintuitiva para quem está com pressa: **retenção vem antes de monetização.** Produto que não retém não monetiza — só troca de cliente para sempre, e o custo de aquisição come a margem. > Se você não sabe dizer quantos dos seus usuários voltariam na semana seguinte, você não sabe se tem negócio. --- ## As perguntas da entrega 1. **Quais as atividades-chave do seu negócio?** 2. **Qual a estrutura de custos?** 3. **Aquisição: como os clientes vão ficar sabendo da solução?** 4. **Retenção: como manter os clientes fiéis?** 5. **Monetização: quais as possíveis fontes de financiamento e recursos?** 6. **Perguntar aos clientes** — as quatro perguntas de preço 7. **Qual o potencial de escala?** 8. **Que influências o modelo de negócios tem no MVP?** A pergunta 8 fecha o laço e é frequentemente esquecida: descobrir o modelo de receita **muda o produto**. Se o seu MVP saiu da Q6 idêntico ao que entra na Q8, você não levou a sério a pergunta de preço. --- ## Plataforma multilateral — o caso mais comum, e o erro clássico Projeto de Projetão quase sempre nasce com **quem usa não paga**. Isso tem nome: plataforma multilateral, que reúne dois ou mais grupos de clientes **distintos mas interdependentes**. A plataforma ganha valor à medida que atrai mais usuários — o efeito de rede. É comum atrair um lado com uma proposta barata ou gratuita, para depois atrair o outro. E aí moram dois problemas estruturais: **1. O dilema do ovo e da galinha.** O valor da plataforma para um grupo depende do número de usuários do outro lado. Console sem jogos não vende; ninguém faz jogo para console sem base. **2. Subsidiar o lado errado.** A dificuldade central é entender **qual lado subsidiar** e como precificar. O caso de fracasso é conhecido: um fabricante subsidiou cada console vendido esperando lucrar depois com royalties de jogos — e o plano falhou porque vendeu-se menos jogo do que o estimado. ### As quatro perguntas de teste Se o seu projeto é de dois lados, responda estas quatro na entrega: 1. Conseguimos atrair número suficiente de clientes de **cada** lado? 2. Qual lado é mais sensível a preço? 3. Esse lado pode ser atraído por uma oferta subsidiada? 4. O outro lado gera receita suficiente para **cobrir** o subsídio? --- ## Os padrões de modelo de negócio Reconhecer em qual padrão você está evita reinventar (mal) o que já tem forma conhecida. | Padrão | Mecanismo | Exemplo | |---|---|---| | **Desagregado** | Separar os três negócios que têm economias diferentes: relacionamento com cliente, inovação de produto e infraestrutura | Banco que separa a plataforma transacional e fica só com assessoria | | **Cauda longa** | Vender menos de mais: muitos nichos, cada um vendendo pouco. Exige estoque barato e plataforma forte | Editora sob demanda: o fracasso de um título é irrelevante, porque não gera custo | | **Plataforma multilateral** | Dois lados interdependentes; um subsidia o outro | Buscador que lucra com anunciantes subsidiando duas outras pontas | | **Grátis — anúncio** | Um lado atrai com conteúdo gratuito; o outro paga por espaço | Jornal gratuito distribuído em pontos de alto fluxo | | **Grátis — freemium** | Básico grátis, premium pago | Serviço em que mais de 90% dos usuários usam a versão gratuita | | **Grátis — isca-e-anzol** | Oferta inicial atraente ou gratuita que induz compras futuras | Aparelho subsidiado com assinatura; cabo barato e lâminas caras | | **Aberto** | Criar e capturar valor colaborando sistematicamente com terceiros | Programa que mirou metade das inovações vindas de parceiros externos | **Sobre freemium**, a métrica que importa é a **taxa de conversão de conta grátis para paga**. E a estrutura de custo é tripartite: custo fixo alto, custo marginal baixíssimo do gratuito, custo separado do premium. **Sobre isca-e-anzol**, o ponto crítico é o *lock-in*: sem barreira, o concorrente vende a lâmina mais barata para o seu cabo. --- ## Precificação ### Os mecanismos | Preço fixo | Preço dinâmico | |---|---| | **Lista** — preço fixo por produto | **Negociação** — depende do poder de barganha | | **Por atributo** — número ou qualidade de features | **Yield management** — depende de estoque e momento (recursos perecíveis) | | **Por segmento** — tipo de cliente | **Mercado em tempo real** — oferta e demanda | | **Por volume** — função da quantidade | **Leilão** — lances competitivos | E sete formas de gerar receita: venda de ativo, taxa de uso, assinatura, aluguel/leasing, licenciamento, corretagem e publicidade. ### A posição normativa que contraria o instinto > **Se você pretende cobrar pelo seu produto, cobre desde o primeiro dia.** — Ash Maurya Três razões: - **O preço é parte do produto.** Duas garrafas d'água indistinguíveis em teste cego, uma a 50 centavos e outra a 2 reais: o preço muda a percepção do produto. - **O preço define seus clientes.** O que você cobra sinaliza quem você quer atrair. - **Ser pago é a primeira forma de validação.** Conseguir que alguém dê dinheiro é uma das ações mais difíceis que você pode pedir. ### Ancoragem Derive o preço inicial das **alternativas existentes** que você levantou na Q3 — elas são as âncoras contra as quais a sua oferta será medida. Se as alternativas são gratuitas, seu produto precisa prometer e entregar valor suficiente para superar o "de graça". ### As quatro perguntas de preço > ⚠️ **Origem.** Estas quatro perguntas são **material próprio da disciplina** — não constam de nenhuma das obras da bibliografia. A orientação dos livros vai no sentido oposto: *diga* o preço e meça a reação, em vez de perguntar quanto a pessoa pagaria. Use as quatro para **abrir** a conversa e obter uma faixa; feche com o preço dito, como descrito acima. Não as cite como se fossem de Maurya ou de Osterwalder. Faça **aos clientes** — 🔴 sem assistência modo sem assistência, é a campo: 1. Qual o **menor preço** abaixo do qual você **duvidaria da qualidade**? 2. Qual o **maior preço** que você pagaria? 3. Qual preço **não é alto demais, mas faria você pensar duas vezes**? 4. Qual o **preço ideal** para você? O conjunto dá uma **faixa**, não um número. A pergunta 1 é a que mais surpreende: equipe de estudante tende a subprecificar por insegurança, e preço baixo demais destrói percepção de valor. **Sequência de validação:** primeiro meça o que o cliente **diz** (compromisso verbal). Depois meça o que ele **faz** (pré-reserva, sinal, lista de espera com cartão). O preço certo é aquele que o cliente aceita **com um pouco de resistência**. ### Contra o freemium prematuro Objeções ao freemium como ponto de partida, todas relevantes para um semestre: conversões de 0,5% a 5% geram ciclos de validação longos demais; o foco migra de retenção para cadastros; a razão sinal-ruído do feedback cai; e **usuário gratuito não é gratuito** — custa servidor, suporte e funcionalidade. Recomendação: comece pelo "premium do freemium", com faixa única e teste gratuito por tempo, que força a decisão. O plano grátis vem depois. --- ## Custos — as duas omissões que a banca cobra **O custo do seu próprio trabalho.** Se você não coloca salário na conta, o negócio "se paga" no papel e não se paga na vida. Use um valor-hora plausível. **O ponto de equilíbrio.** Custos ÷ margem por cliente = quantos clientes você precisa. Esse número é o teste de realidade do projeto inteiro: se dá 40 mil clientes no primeiro ano, ou o preço, ou o segmento, ou o custo está errado. --- ## Os três motores de crescimento Escolha **um**. O motor é o mecanismo pelo qual a startup alcança crescimento sustentável. | Motor | Mecanismo | Métrica-chave | Condição | |---|---|---|---| | **Pegajoso** | alta retenção, baixo abandono | taxa de abandono | aquisição > abandono | | **Viral** | indicação como efeito colateral do uso | coeficiente viral | coeficiente > 1 | | **Pago** | reinvestir parte da receita em aquisição | valor do cliente e custo de aquisição | valor > custo (regra prática: 3×) | **Por que não perseguir os três:** é importante focar num só primeiro, o de maior potencial dado o seu caminho até os clientes. A escolha certa costuma ser não óbvia, porque a maioria dos produtos exibe traços dos três. Guia rápido: viralidade **implícita no uso** → motor viral; uso recorrente → comece reduzindo abandono; produto de uso único e não viral (fotógrafo de casamento, advogado) → sua única aposta é o motor pago. E antes de qualquer motor: **valide suas métricas de valor.** Focar em escalar antes de demonstrar tração inicial é desperdício. --- ## Métrica de vaidade × métrica acionável > **Métrica acionável é a que liga ações específicas e repetíveis a resultados observados.** — Ash Maurya, a partir de Ries O oposto são as métricas de vaidade, que só documentam o estado atual sem dizer como você chegou lá nem o que fazer a seguir. **Bandeira vermelha:** quando os números não vão a lugar nenhum além de para cima, mês após mês. | Vaidade | Acionável | |---|---| | Visitas no site | Aquisição: visitante → vê a página de cadastro | | Downloads | Ativação: primeira experiência gratificante | | Total acumulado de cadastros | Retenção: uso repetido | | Contagem bruta que só sobe | Receita: eventos que fazem você ser pago | | — | Indicação: referências convertidas | Detalhe que importa: visitas e downloads não são inúteis — são **sub-funis** de uma macro-métrica. O erro é reportar o sub-funil como resultado. Os três critérios: métricas devem ser **acionáveis, acessíveis e auditáveis**. --- ## Tração — os dois milestones que a quest alimenta - **Estratégias de tração:** como a equipe se aproxima e constitui um grupo de usuários afoitos. - **Tração efetiva:** a transformação em negócio real, com divulgação e promoção. Concretamente, para um semestre: **quem são as 10 primeiras pessoas que vão usar isso, você já falou com elas, e o que elas precisam ver para experimentar?** Canal com nome e pessoa vale mais que "redes sociais". --- ## Referências desta quest | Arquivo | Quando | |---|---| | **Modelos de negócio — Quest #7** (neste arquivo) | Ao escolher o padrão. Os nove blocos, os cinco padrões, plataforma multilateral em detalhe | | **Precificação — Quest #7** (neste arquivo) | Ao definir preço. Mecanismos, ancoragem, as quatro perguntas, freemium | | **Métricas e tração — Quest #7** (neste arquivo) | Ao medir. Motores de crescimento, vaidade × acionável, o funil | | **Autodiagnóstico — Quest #7** (neste arquivo) | Antes de entregar | --- ### Técnicas desta quest Fichas curtas de consulta rápida. Abra quando o procedimento acima mencionar a técnica. | Ficha | Para quê | |---|---| | **Usuário afoito (*early adopter*)** (neste arquivo) | a base que sustenta a tração | | **Entrevistas** (neste arquivo) | como perguntar preço | | **Percepção de Valor** (neste arquivo) | por que o preço é parte do produto | --- ## Perguntas frequentes **"Nosso projeto é social / não visa lucro. Preciso desta quest?"** Sim, e ela fica mais difícil. Sustentabilidade financeira não é sinônimo de lucro: a pergunta é como a operação se paga — edital, contrapartida pública, patrocínio, cliente institucional que paga pelo usuário que não pode pagar. Projeto social sem modelo de sustentação acaba quando a disciplina acaba. **"Podemos deixar o preço para depois?"** Pode, mas você está adiando a validação da parte mais arriscada do modelo — e ficando sem o sinal mais forte que existe. Facilitar o "sim" torna o "sim" barato demais para significar algo. --- ## Bibliografia desta quest | Obra | O que ela dá para a Q7 | |---|---| | **Osterwalder & Pigneur — Business Model Generation** | Os nove blocos, os cinco padrões, mecanismos de precificação | | **Maurya — Running Lean** | Cobrar desde o dia 1, ancoragem, métricas acionáveis, motores de crescimento | | **Ries — A startup enxuta** | Os três motores, contabilidade da inovação, métricas de vaidade | | **Anderson — A cauda longa** | Economia de nicho, preço variável, o poder da gratuidade | | **Norman — O design do dia a dia** · **Krug — Não me faça pensar** | Bibliografia oficial da quest no site | # Autodiagnóstico — Quest #7 Faça este exercício **antes** de entregar. É o mesmo que o mentor vai fazer depois. --- ## Os milestones que abrem aqui A Q7 alimenta três dos 13 milestones: **Modelo de receitas**, **Estratégias de tração** e **Tração efetiva**. A aprovação exige nível 4 em todos. | Nível | Significado | |---|---| | **0** | O critério ainda não aparece. | | **1** | Já aparece, mas sem clareza nem coerência. | | **2** | Falta clareza **ou** falta coerência com o resto. A resposta ainda está no terreno da insegurança. | | **3** | Coerente, mas ainda não totalmente claro. Resta uma parcela de incerteza. | | **4** | Claro e coerente com toda a proposta. A equipe responde com segurança. | | **5** | Perfeitamente alinhado ao conjunto. As respostas são sólidas. | O salto 3 → 4 tem, aqui, um nome preciso: sair de *"nosso modelo é freemium"* para *"dissemos R$ X a doze pessoas do lado que paga, três aceitaram, uma hesitou, e o ponto de equilíbrio é de N clientes"*. --- ## Rubrica — milestone Modelo de receitas ### 1. Atividades-chave e custos | | | |---|---| | **2** | Custos listados como "hospedagem e domínio". | | **3** | Custos fixos e variáveis separados, mas sem o trabalho da equipe. | | **4** | Atividades-chave nomeadas; custos derivados delas, **incluindo horas da equipe a um valor-hora plausível**; fixos e variáveis separados. | | **5** | O acima, com a estrutura declarada como orientada a custo ou a valor, e a coerência disso com a PUV da Q5 demonstrada. | ### 2. Fontes de receita | | | |---|---| | **2** | Uma linha genérica ("anúncios"), sem base e sem preço. | | **3** | A fonte se encaixa numa das sete formas conhecidas, mas não há preço nem quem paga. | | **4** | Cada fonte tem: quem paga, por qual valor, mecanismo de preço e valor numérico; e ela nasce de um segmento específico, não do produto em geral. | | **5** | O acima, com fontes secundárias identificadas e **deliberadamente adiadas**, com o motivo do adiamento. | ### 3. Preço validado | | | |---|---| | **2** | O preço saiu de uma reunião da equipe. | | **3** | Perguntou-se aos clientes quanto pagariam, e usou-se a média. | | **4** | O preço foi **dito** ao cliente e a reação medida, com registro de hesitação por pessoa; a âncora usada está nomeada e vem das alternativas existentes da Q3. | | **5** | O acima, com uma segunda rodada em preço mais alto após ausência de resistência, e ao menos um compromisso que custou algo ao cliente. | ### 4. Padrão e plataforma | | | |---|---| | **2** | O modelo é descrito sem nome e sem estrutura. | | **3** | O padrão foi nomeado (freemium, plataforma, isca-e-anzol), mas sem as implicações. | | **4** | O padrão está nomeado **e** suas condições estão respondidas: no freemium, custo do usuário gratuito e taxa de conversão; no isca-e-anzol, a barreira que sustenta o *lock-in*; na plataforma, as **quatro perguntas** de subsídio. | | **5** | O acima, com o padrão alternativo que foi considerado e por que foi descartado. | ### 5. Ponto de equilíbrio e escala | | | |---|---| | **2** | Não há conta. | | **3** | Há uma projeção de receita de três anos, sem base. | | **4** | Custos ÷ margem por cliente, resultando num **número de clientes**, com a leitura honesta desse número diante do segmento definido na Q4. | | **5** | O acima, com a análise de qual variável — preço, custo ou segmento — teria de mudar e em quanto, se o número for inviável. | --- ## Rubrica — milestone Estratégias de tração ### 6. Aquisição | | | |---|---| | **2** | "Redes sociais e boca a boca." | | **3** | Canais listados por categoria, sem nome nem custo. | | **4** | Cada canal tem **nome próprio, pessoa de contato ou lugar concreto**, e uma estimativa de custo — inclusive o custo humano dos canais ditos gratuitos. | | **5** | O acima, com um canal já testado e o resultado numérico do teste. | ### 7. As 10 primeiras pessoas | | | |---|---| | **2** | O usuário afoito é descrito por demografia genérica. | | **3** | Há uma lista de perfis, mas ninguém foi contatado. | | **4** | Existe uma lista **nominal** de pelo menos dez pessoas, todas já contatadas, com o registro do que cada uma precisa ver para experimentar. | | **5** | O acima, com pelo menos três delas já usando ou com compromisso firmado. | ### 8. Retenção | | | |---|---| | **2** | Retenção não foi tratada, ou foi tratada como "fidelizar o cliente". | | **3** | Há ideias de retenção, sem definição do que conta como usuário ativo. | | **4** | **Usuário ativo está definido** por uma ação representativa do produto, não por login; e há um plano de como medi-la. | | **5** | O acima, com dado real de retorno de ao menos uma coorte. | ### 9. Escolha do motor de crescimento | | | |---|---| | **2** | Nenhum motor escolhido, ou os três citados juntos. | | **3** | Um motor foi escolhido, mas sem justificativa pelo padrão de uso. | | **4** | Um motor escolhido, justificado pelo **caminho do produto até os clientes**, com a métrica-chave e a condição de crescimento explícitas. | | **5** | O acima, com os outros dois analisados e descartados por razão nomeada. | --- ## Rubrica — milestone Tração efetiva ### 10. Métricas em uso | | | |---|---| | **2** | Só números brutos acumulados. | | **3** | Há funil, mas reportado por sub-funil (visitas, downloads) como se fosse resultado. | | **4** | O funil de cinco etapas está instrumentado; os números passam nos três A — a equipe sabe dizer a causa, explicar em unidades de pessoas e chegar à lista por trás do número. | | **5** | O acima, com pelo menos duas coortes comparadas e a variação entre elas explicada por uma ação datada. | ### 11. Evidência de uso real | | | |---|---| | **2** | Nenhum usuário fora da equipe. | | **3** | Usuários de teste, sem uso espontâneo. | | **4** | Pessoas de fora usaram por vontade própria, e há registro de quantas voltaram. | | **5** | O acima, com pelo menos uma transação real — pagamento, pré-reserva ou compromisso equivalente à natureza do projeto. | --- ## Checklist rápido - [ ] O trabalho da minha equipe está na conta de custos? - [ ] Sei dizer, em número, quantos clientes preciso para me pagar? - [ ] Disse o preço a alguém de fora da equipe — e anotei quem hesitou? - [ ] Se o projeto é de dois lados, respondi qual lado é mais sensível a preço, com dado? - [ ] O lado que subsidiei é o que hesita, ou o que já viria de graça? - [ ] Meu canal tem nome de pessoa ou de lugar? - [ ] Consigo listar dez pessoas pelo nome que vão usar isso? - [ ] Defini o que conta como usuário ativo, sem usar "login"? - [ ] Escolhi **um** motor de crescimento — ou estou perseguindo os três? - [ ] Algum número da minha apresentação é sub-funil apresentado como resultado? - [ ] O modelo de receita mudou alguma coisa no MVP — ou a pergunta 8 ficou em branco? **Sinal de alerta:** se o modelo de receita da Q7 não alterou nada no que vai ser construído na Q8, ou a resposta é irrelevante para o produto — o que é improvável — ou a pergunta não foi levada a sério. **Segundo sinal:** se o preço nunca encontrou resistência em nenhuma conversa, ele está baixo, e a validação ainda não aconteceu. --- ## 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 Q7, o trabalho é 🟡 com apoio e a pesquisa de preço é 🔴 sem assistência. Se algum número de custo ou de mercado veio da IA sem verificação, diga.* 2. **O que a IA gerou e você descartou — e por quê.** *Típico da Q7: a IA propõe um modelo de receita plausível e completo em segundos, quase sempre freemium ou marketplace. Esse texto é hipótese. Se vocês o trocaram depois de falar com quem paga, esse é o registro mais valioso da quest.* 3. **O que você verificou, e como.** *Típico da Q7: preços de alternativas existentes, custos de infraestrutura, tamanho de mercado. Diga em que fonte você conferiu e o que encontrou de diferente.* 4. **O que ainda não sabe.** *Exemplos honestos: "não conseguimos falar com nenhum comprador do lado que paga"; "o custo de suporte por usuário é um chute".* --- ## Como o mentor vai ler Quatro perguntas frequentes na apresentação da Q7. Se você responde às quatro, está em 4. 1. **"Quem paga, e quanto?"** Resposta fraca: "o modelo é freemium". Resposta forte: o nome do segmento pagante, o valor, e o que aconteceu quando vocês disseram esse valor a ele. 2. **"Quantos clientes vocês precisam para se pagar?"** Se não houver número, a conversa não avança. Se houver e ele for implausível, dizer isso em voz alta vale mais do que defendê-lo. 3. **"Quem são as dez primeiras pessoas?"** Nomes. "Estudantes do CIn" não é resposta. 4. **"Que número vocês olham toda semana, e o que ele fez mudar?"** É o teste que separa métrica acionável de painel decorativo. Divergência entre a sua auto-avaliação e a leitura do mentor é informação útil, não constrangimento. # Métricas e tração — Quest #7 Abra este arquivo quando for decidir **o que medir** e **como crescer**. Ele traz a distinção entre métrica de vaidade e métrica acionável, os três critérios de uma boa métrica, o funil, os três motores de crescimento e a conta que diz se o negócio fecha. **Modo de IA:** 🟡 com apoio. A IA ajuda a montar o funil, a nomear eventos e a criticar um painel. Ela não pode gerar os números, e um número que ela produziu não é medição — é ilustração. --- ## 1. Métrica de vaidade × métrica acionável > **Uma métrica acionável é aquela que liga ações específicas e repetíveis a resultados observados.** O oposto são as métricas de vaidade — visitas no site, número de downloads —, que só documentam o estado atual do produto e, **por si sós**, não dizem nem como você chegou ali nem o que fazer a seguir. **A bandeira vermelha:** quando os números não vão a lugar nenhum além de para cima, mês após mês. O detalhe que evita o exagero na interpretação: visitas e downloads **não são inúteis**. São elementos de **sub-funis** que compõem a macro-métrica que importa — aquisição, ativação. O erro não é medi-los; o erro é **reportá-los como resultado**. | Métrica de vaidade | A macro-métrica correspondente | |---|---| | Visitas no site | **Aquisição** — o visitante deixa de abandonar e chega à página de cadastro | | Downloads | **Ativação** — a primeira experiência gratificante acontece | | Total acumulado de cadastros | **Retenção** — o uso se repete | | Receita bruta acumulada | **Receita** — os eventos que fazem você ser pago | | Menções na imprensa | **Indicação** — referências que convertem | ### Por que a métrica de vaidade sobrevive tanto tempo O mecanismo, na descrição de Ries: quando os números sobem, as pessoas acham que a melhoria foi causada pelo que **elas** estavam fazendo naquele momento. É por isso que é comum a reunião em que marketing atribui a alta a uma campanha e engenharia atribui aos recursos novos. Descobrir o que de fato aconteceu é caro, e a maioria segue adiante. E há a assimetria: **quando os números afundam, a culpa é dos outros**. Cada área passa a viver num mundo em que sempre melhora as coisas e é sabotada pelas demais. O caso documentado é a própria IMVU: o gráfico de usuários cadastrados e clientes pagantes tinha o formato de taco de hóquei, ideal para apresentação de diretoria. Os mesmos dados, apresentados por coorte, mostravam que a empresa **adicionava clientes sem melhorar o rendimento de cada novo grupo**. O motor funcionava; os esforços de regulá-lo não rendiam. --- ## 2. Os três A: acionável, acessível, auditável ### Acionável Para um relatório ser acionável, ele deve **demonstrar causa e efeito claros**. Caso contrário, é vaidade. O teste que Ries aplica ao número de visitas: tivemos 40 mil visitas no mês, um recorde. De onde vieram? São 40 mil pessoas ou uma pessoa com um navegador muito ativo? É resultado de campanha ou de assessoria de imprensa? E, afinal, **o que conta como uma visita** — cada página, ou também as imagens e o conteúdo embutido? Quem já participou de reunião discutindo a unidade de medida de um relatório reconhece o problema. ### Acessível Duas coisas ao mesmo tempo: **compreensível** e **disponível**. Compreensível: relatórios devem ser tão simples quanto possível, e o caminho mais fácil é usar **unidades tangíveis e concretas**. Ninguém tem certeza do que é uma visita; todo mundo sabe o que é uma pessoa visitando um site. Por isso os **relatórios por coorte são o padrão-ouro** das métricas de aprendizagem: convertem ações complexas em relatórios sobre pessoas. Cada análise de coorte diz: entre as pessoas que usaram o produto neste período, este é o número das que exibiram cada comportamento que nos interessa. O argumento fica mais forte com números grandes: é difícil visualizar o que significa a queda de 250 mil para 200 mil visitas; a maioria das pessoas entende de imediato o que é perder 50 mil clientes — praticamente um estádio cheio de gente abandonando o produto. Disponível: na Grockit, o sistema gerava diariamente um documento com os últimos dados de cada experimento, enviado por e-mail a **todos** os funcionários, escrito em linguagem comum. Na IMVU, os relatórios eram parte do próprio produto, pertenciam à equipe de desenvolvimento e ficavam acessíveis a qualquer funcionário com senha — e viraram, na prática, o padrão para resolver discussões de produto. ### Auditável Quando alguém é informado de que o projeto predileto fracassou, a tentação é atacar o mensageiro ou os dados. Por isso é preciso **assegurar que os dados sejam confiáveis**, e que seja possível ir atrás do número até chegar às pessoas por trás dele. Maurya acrescenta que o painel ideal é metade análise de dados e metade gestão de relacionamento: em qualquer evento do sub-funil, você deve conseguir chegar à **lista de pessoas**. **Tradução para a Q7:** se a sua apresentação traz um número, você precisa saber dizer de onde ele veio, em que ferramenta, e conseguir mostrar a lista de quem está dentro dele. --- ## 3. O funil: aquisição, ativação, retenção, receita, indicação O modelo é de **Dave McClure**, das 500 Startups, e foi construído pensando em empresas de software, mas se aplica a muitos tipos de negócio. Maurya o explica com dois exemplos em paralelo — uma floricultura e um produto digital: | Etapa | O que é | Floricultura | Produto digital | |---|---|---|---| | **Aquisição** | Transformar um visitante desavisado em interessado | Fazer quem passa na calçada parar e entrar | Fazer o visitante fazer qualquer coisa além de abandonar o site — na prática, chegar à página de cadastro | | **Ativação** | A primeira experiência gratificante | A loja estar arrumada quando ele entra; caso contrário há desconexão com a promessa da vitrine | Depois do cadastro, levar o cliente ao ponto em que ele conecta a promessa da página com o produto | | **Retenção** | Uso repetido e/ou engajamento | Voltar à loja | Fazer login e usar de novo | | **Receita** | Os eventos que fazem você ser pago | Comprar flores | Assinar; podem não ocorrer na primeira visita | | **Indicação** | Clientes satisfeitos trazendo novos interessados | Falar da loja para um amigo | Compartilhamento embutido, programa de afiliados, indicação medida | **A ordem importa e é contraintuitiva para quem está com pressa: retenção antes de indicação.** Programas de viralidade e de indicação podem ser muito eficazes em espalhar a palavra sobre o produto — mas **é preciso ter um produto que valha a pena espalhar primeiro**. Duas observações operacionais de Maurya sobre o painel: - meça a taxa de ativação sobre o número de **adquiridos**, não sobre o total de visitantes. Assim você separa eficiência do fluxo de cadastro (ativação) de eficiência de marketing (aquisição), e uma onda inesperada de tráfego de imprensa não distorce a leitura; - o relatório semanal por coorte funciona como canário na mina: **se nenhum número muda de semana para semana, você está patinando**. Quando um número muda numa semana específica, você consegue amarrar o resultado às ações daquela semana. --- ## 4. Os três motores de crescimento O motor de crescimento é o mecanismo pelo qual uma iniciativa alcança **crescimento sustentável**. O objetivo do arcabouço é dar à equipe um conjunto pequeno de métricas em que concentrar energia — porque, como disse o investidor Shawn Carolan a Ries, "as startups não morrem de fome; elas se afogam". | Motor | Mecanismo | Métrica-chave | Condição de crescimento | |---|---|---|---| | **Pegajoso** | Alta retenção, baixo abandono | Taxa de abandono (*churn*) | Taxa de aquisição > taxa de abandono | | **Viral** | Indicação como efeito colateral necessário do uso normal | Coeficiente viral | Coeficiente viral > 1 | | **Pago** | Reinvestir parte da receita do cliente em aquisição | Valor do cliente ao longo da vida e custo de aquisição | Valor > custo — regra prática de David Skok: valor > 3 × custo | > ⚠️ **Nota de tradução.** A edição brasileira de Ries traduz *sticky engine* como **"motor de crescimento recorrente"**. O material da disciplina usa **"pegajoso"**. São o mesmo motor. Ao citar a edição brasileira num trabalho, use o termo dela e indique a equivalência uma vez. ### Pegajoso A regra é simples: **se a taxa de aquisição de novos clientes superar a taxa de abandono, o produto cresce.** A velocidade é dada pela taxa de composição — crescimento natural menos abandono —, que se comporta como juro composto. O caso que ilustra o diagnóstico: uma das startups que Ries acompanhou modelou seus dados e encontrou retenção de 61% (abandono de 39%) e aquisição de 39%. Aquisição e abandono se equilibravam quase perfeitamente, resultando numa **taxa de composição de 0,02% — praticamente zero**. A leitura contraintuitiva: a saída não era investir mais em vendas e marketing, e sim **melhorar a retenção** — engajar mais os clientes que já entram pela porta. ### Viral O crescimento viral não é boca a boca: depende da **transmissão de pessoa para pessoa como consequência necessária do uso normal do produto**. Os clientes não estão tentando divulgar; o crescimento acontece como efeito colateral. "Viroses não são opcionais." O caso é o **Hotmail**. Em 1996, Sabeer Bhatia e Jack Smith lançaram um serviço de e-mail gratuito na web. O crescimento inicial foi lento — sem dinheiro para campanha. Tudo mudou com um ajuste pequeno no produto: adicionaram ao final de cada e-mail enviado a frase **"P.S.: Obtenha seu e-mail grátis no Hotmail"**, com um link. Em seis meses tinham mais de 1 milhão de clientes cadastrados; cinco semanas depois, 2 milhões. Dezoito meses após o lançamento, com 12 milhões de assinantes, venderam a empresa para a Microsoft por 400 milhões de dólares. A aritmética do coeficiente viral: com coeficiente 0,1, um em cada dez clientes recruta um amigo. Cem clientes trazem dez; esses dez trazem mais um; e o ciclo desaparece. Acima de 1,0, o crescimento é exponencial, porque cada inscrito traz, em média, mais de uma pessoa. Por isso quem usa este motor deve **concentrar-se em aumentar o coeficiente viral mais do que em qualquer outra coisa**: mudanças pequenas nesse número provocam alterações dramáticas. A consequência de modelo: produtos virais frequentemente **não cobram do cliente**, dependendo de receita indireta, porque não podem tolerar atrito no cadastro. Isso torna o teste da hipótese de valor mais difícil — e é a origem da divergência com Maurya registrada em `precificacao.md`. ### Pago Duas empresas: uma ganha 1 dólar por cliente cadastrado, a outra ganha 100 mil dólares. Para saber qual cresce mais rápido, falta um dado: **quanto custa cadastrar um cliente novo**. Se a primeira gasta 80 centavos em anúncio e a segunda gasta 80 mil dólares em equipe de vendas e engenharia de implantação, **as duas crescem na mesma taxa** — as duas têm 20% da receita disponível para reinvestir em aquisição. Só há duas formas de acelerar: **aumentar a receita por cliente** ou **reduzir o custo de aquisição**. E há o modo de falha clássico: se o custo por aquisição fica em 2 dólares e o valor do cliente cai abaixo disso, o crescimento perde velocidade. A diferença pode ser compensada por capital investido ou por truques publicitários, mas nenhum dos dois é sustentável — foi o destino de várias empresas ponto-com que acreditaram que poderiam perder dinheiro em cada cliente e "ganhar no volume". O motor pago é mais amplo que publicidade: equipes de venda externa e lojas que dependem de fluxo de pedestres também o usam, e todos esses custos entram no custo por aquisição. --- ## 5. Por que focar em um só Alguns ou todos os motores podem se aplicar ao seu produto. Ainda assim, **foque num só primeiro** — o de maior potencial de impacto dado o caminho específico do seu produto até os clientes, ou seja, dados os seus canais. A escolha certa costuma ser **não óbvia**, porque a maioria dos produtos exibe traços dos três, e o motor certo pode mudar com o tempo. O roteiro de escolha: 1. **Valide primeiro as métricas de valor.** Todo produto tem de começar demonstrando e entregando uma proposta de valor básica. Escalar antes de demonstrar tração inicial é desperdício. 2. **Estude o ciclo de vida do seu cliente** e procure o padrão de uso: | Se o padrão é… | O motor é | |---|---| | Viralidade implícita no uso — usuários trazem outros usuários como efeito natural do serviço | **Viral**, e isso costuma implicar reduzir a fricção de cadastro, muitas vezes tornando o serviço gratuito para maximizar crescimento | | Uso recorrente, como um serviço por assinatura | **Pegajoso**, começando por reduzir o abandono e elevar o valor do cliente. Em algum ponto haverá um teto de retornos decrescentes, que é a deixa para trocar de motor. Nesses produtos há indicações, mas elas não se repetem além de um ou dois graus — o coeficiente viral fica abaixo de 1 | | Uso único e sem viralidade — os exemplos do livro são o fotógrafo de casamento e o advogado de divórcio | **Pago**, sem alternativa. Pode haver boca a boca e até cliente que volta, mas nenhum dos dois sustenta o crescimento | 3. **Escolha um motor para regular** e concentre os experimentos nele. --- ## 6. Todos os motores acabam parando > Todos os motores de crescimento acabam ficando sem gasolina. Cada motor está atrelado a um conjunto específico de clientes — hábitos, preferências, canais de publicidade e interconexões. Em algum momento esse conjunto se esgota. O modo de falha específico: construir o MVP sem nada além do que o usuário afoito exige destrava um motor que alcança o público-alvo — mas **a transição para os clientes convencionais exige um trabalho adicional imenso**. Em teoria, seria possível parar de desenvolver e o produto continuaria crescendo até os limites do mercado inicial; e a desaceleração pode levar **meses ou anos** para aparecer. Empresas que usam métricas de vaidade acham que estão melhorando o produto quando na verdade não estão afetando o comportamento do cliente: todo o crescimento vem do motor funcionando bem, não das melhorias. Quando o crescimento arrefece de repente, vira crise. **No Projetão** (interpretação minha): um semestre raramente é longo o bastante para esgotar um motor. O que se pode e se deve mostrar na Q7 é **qual é o tamanho do seu mercado inicial** e o que aconteceria quando ele acabasse. --- ## 7. A conta que fecha, e a tração que a Q7 pede **O ponto de equilíbrio.** Custos ÷ margem por cliente = quantos clientes você precisa. Esse número é o teste de realidade do projeto inteiro. E ele só é honesto se os custos incluírem **o valor do trabalho da própria equipe** — sem isso, o negócio se paga no papel e não se paga na vida. **Os dois milestones que a quest alimenta:** | Milestone | O que ele pede | |---|---| | **Estratégias de tração** | Como a equipe se aproxima e constitui um grupo de usuários afoitos | | **Tração efetiva** | A transformação em negócio real, com divulgação e promoção | Concretamente, para um semestre: **quem são as 10 primeiras pessoas que vão usar isso, você já falou com elas, e o que elas precisam ver para experimentar?** Canal com nome e pessoa vale mais que "redes sociais" — e isso é coerente com a orientação de Maurya sobre canais: enquanto a proposta de valor não está testada, é difícil justificar gasto em canais de empurrar mensagem, e buscar cobertura da imprensa antes disso é desperdício. A exceção explícita é a **entrevista**, que é um canal de saída cujo retorno em aprendizado supera em muito o custo de rodá-la. Duas regras que evitam o desperdício mais comum da Q7: **primeiro venda manualmente, depois automatize** — a venda direta é ineficiente como canal escalável, mas é dos mais eficazes como canal de aprendizado, porque você fica cara a cara com o cliente. E **não busque parceria estratégica cedo demais**: enquanto o produto não estiver provado, você não terá o nível de atenção necessário dentro da empresa maior. Coloque-se no lugar do vendedor dela: entre vender o que ele conhece e vender um produto não comprovado para bater a meta, o que ele escolhe? --- ## Fontes - **Ries, Eric**, *A startup enxuta* (ed. brasileira), caps. 7 e 10 — métricas de vaidade e o caso do gráfico da IMVU; a definição de métrica acionável; os três A (acionável, acessível, auditável) com o exemplo das 40 mil visitas, a coorte como padrão-ouro e os relatórios da Grockit e da IMVU; os três motores de crescimento com o caso Hotmail, a aritmética do coeficiente viral, o caso da taxa de composição de 0,02% e o exemplo das duas empresas no motor pago; quando os motores param - **Maurya, Ash**, *Running Lean*, caps. 3 e 5 e apêndice — a definição de métrica acionável e a bandeira vermelha do "sempre para cima"; sub-funil × macro-métrica; as Métricas Pirata de Dave McClure com os exemplos da floricultura e do produto digital; retenção antes de indicação; ativação medida sobre adquiridos; o relatório semanal por coorte; os três motores com as condições e a regra prática de David Skok; o roteiro de escolha do motor; canais de entrada e de saída, vender manualmente antes de automatizar, e a advertência sobre parceria prematura # Modelos de negócio — Quest #7 Abra este arquivo quando for descrever como o projeto se sustenta. Ele traz os nove blocos do canvas com a pergunta que cada um responde, a diferença em relação ao Lean Canvas, os cinco padrões e o caso mais comum no Projetão: a plataforma multilateral. **Modo de IA:** 🟡 com apoio. A IA é boa em apontar em qual padrão você provavelmente está e em listar o que falta no canvas. Ela não sabe qual lado da sua plataforma é sensível a preço — isso é campo. --- ## 1. Os nove blocos, com a pergunta central As perguntas da segunda coluna são as do livro de Osterwalder & Pigneur, traduzidas. A terceira coluna é **observação minha** sobre o que costuma dar errado em projeto de disciplina — não vem do livro. | Bloco | Pergunta central | Erro típico | |---|---|---| | **Segmentos de clientes** | Para quem estamos criando valor? Quem são nossos clientes mais importantes? | Um segmento tão largo que serve para qualquer projeto; ou usuário e cliente tratados como a mesma pessoa | | **Propostas de valor** | Que valor entregamos ao cliente? Qual problema dele estamos ajudando a resolver? Que necessidade estamos satisfazendo? | Listar funcionalidades no lugar de valor | | **Canais** | Por quais canais nossos segmentos querem ser alcançados? Como os alcançamos hoje? Quais funcionam melhor? Quais são mais eficientes em custo? | "Redes sociais" como resposta — que não é canal, é categoria | | **Relacionamento com clientes** | Que tipo de relação cada segmento espera que a gente estabeleça e mantenha? Quanto ela custa? | Assumir autosserviço porque é o mais barato de descrever | | **Fontes de receita** | Por qual valor os clientes estão realmente dispostos a pagar? Por que pagam hoje? Como pagam hoje? Como prefeririam pagar? | Uma única linha, "assinatura", sem preço nem base | | **Recursos principais** | Que recursos nossas propostas de valor exigem? E nossos canais, relacionamentos e fontes de receita? | Esquecer o recurso humano — as horas da própria equipe | | **Atividades-chave** | Que atividades nossas propostas de valor exigem? E os canais, relacionamentos e receitas? | Confundir atividade-chave com tarefa de desenvolvimento | | **Parcerias principais** | Quem são nossos parceiros e fornecedores-chave? Que recursos adquirimos deles? Que atividades eles executam? | Listar parceiro que nunca foi contatado | | **Estrutura de custos** | Quais são os custos mais importantes do modelo? Quais recursos e atividades são mais caros? | Omitir o custo do trabalho da própria equipe | **Duas notas estruturais que mudam a ordem de preenchimento.** Os custos "podem ser calculados com relativa facilidade **depois** de definir recursos principais, atividades-chave e parcerias" — ou seja, custo é resultado, não escolha independente. E, do lado da receita: se os clientes são o coração do modelo, as fontes de receita são as artérias — cada fonte nasce de um segmento específico, e não do produto em geral. **Duas classes de estrutura de custo**, úteis para se posicionar: **orientada a custo** (minimizar custo em toda parte: proposta de baixo preço, automação máxima, terceirização — o caso das companhias aéreas de baixo custo) e **orientada a valor** (foco na criação de valor, proposta premium, alto grau de serviço personalizado — o caso dos hotéis de luxo). A maioria dos modelos fica entre os dois extremos, mas dizer para qual lado o seu pende evita a incoerência de prometer atendimento dedicado com custo de autosserviço. --- ## 2. Como o Lean Canvas difere — e por quê O Lean Canvas é a **adaptação de Ash Maurya** do canvas de Osterwalder. Também tem nove blocos, mas quatro são outros. | Sai do canvas original | Entra no Lean Canvas | |---|---| | Relacionamento com clientes | **Problema** (os 1 a 3 principais, mais as alternativas existentes) | | Recursos principais | **Solução** | | Atividades-chave | **Métricas-chave** | | Parcerias principais | **Vantagem injusta** | Permanecem: segmentos de clientes, proposta única de valor, canais, fontes de receita e estrutura de custos. > ⚠️ **Cuidado ao citar.** O livro *Running Lean* apresenta o Lean Canvas como adaptação e **remete o leitor à página do autor** para a lista das diferenças; ele não enumera no texto quais blocos foram trocados nem justifica bloco a bloco. A tabela acima é a comparação entre as duas listas de nove blocos como cada livro as apresenta. Num trabalho acadêmico, apresente-a como comparação sua entre as duas fontes, não como afirmação de Maurya. O que o livro **diz** sobre a lógica do formato, e que explica a direção da troca: - o canvas serve para **decompor o modelo em nove partes que são testadas sistematicamente, da mais arriscada para a menos arriscada** — o que exige que problema e métricas apareçam como blocos próprios, porque são eles que carregam o risco no início; - a abordagem é **centrada no cliente**: mexer só no segmento de clientes muda o modelo inteiro; - a caixa da solução foi desenhada **de propósito com menos de um nono do canvas**, porque é a caixa pela qual a equipe é naturalmente apaixonada. A frase que fecha o argumento: *"Clientes não se importam com a sua solução. Eles se importam com os problemas deles"* (Dave McClure, citado por Maurya). **Qual usar no Projetão.** Nas quests iniciais, o Lean Canvas é mais próximo do que a disciplina pede, porque tem "problema" e "alternativas existentes" como blocos explícitos — que é o material das Q2 e Q3. Na Q7, os quatro blocos que só existem no canvas de Osterwalder voltam a fazer falta: as **atividades-chave** e a **estrutura de custos** são literalmente as perguntas 1 e 2 da entrega. Preencher os dois não é redundância; é o mesmo modelo visto pelo lado do risco e pelo lado da operação. Duas regras de preenchimento que valem para qualquer um dos dois: esboce em **uma sentada, em menos de 15 minutos**, e **deixe em branco o que não sabe** — um bloco em branco costuma indicar exatamente onde está o maior risco e por onde começar a testar. --- ## 3. Os cinco padrões Reconhecer em qual padrão você está evita reinventar mal o que já tem forma conhecida. Os cinco são os de Osterwalder & Pigneur, e cada um tem uma referência de origem própria. ### Desagregado **Mecanismo.** Existem três tipos fundamentalmente diferentes de negócio dentro de uma empresa — **relacionamento com clientes**, **inovação de produto** e **infraestrutura** —, com imperativos econômicos, competitivos e culturais distintos. Podem coexistir na mesma corporação, mas idealmente são separados em entidades distintas, para evitar conflitos e trocas indesejáveis. A formulação é de John Hagel e Marc Singer, "Unbundling the Corporation", *Harvard Business Review*, mar–abr 1999. **Exemplo do livro.** O *private banking* suíço era tradicionalmente integrado verticalmente, da gestão de patrimônio à corretagem e ao desenho de produtos financeiros. Do outro lado, as operadoras de telefonia móvel começaram a desagregar: fecharam acordos de compartilhamento de rede com concorrentes ou terceirizaram a operação para fabricantes de equipamento, ao perceber que o ativo principal já não era a rede, e sim a marca e o relacionamento. A Bharti Airtel terceirizou a operação de rede para Ericsson e Nokia Siemens Networks, e a infraestrutura de TI para a IBM. **Uso na Q7:** se a sua equipe está simultaneamente cuidando de relacionamento, de inovação e de infraestrutura, diga qual dos três é o seu negócio e o que você pretende terceirizar. ### Cauda longa **Mecanismo.** Vender menos de mais: muitos produtos de nicho, cada um em quantidade pequena, cuja soma iguala ou supera a receita dos campeões de venda. O conceito é de Chris Anderson (*Wired*, out. 2004; livro em 2006). Exige custos de estoque baratos e plataforma forte. **Exemplo do livro.** A Lulu.com inverteu o modelo editorial centrado no best-seller: dá a qualquer pessoa as ferramentas para criar, imprimir e distribuir a própria obra. **Quanto mais autores ela atrai, mais ela ganha, porque os autores são os clientes.** Os livros só são impressos em resposta a pedidos reais — por isso o fracasso de um título é irrelevante: ele não gera custo. **Uso na Q7:** este padrão só fecha se o custo marginal de servir mais um item for próximo de zero. Verifique isso antes de adotá-lo. ### Plataforma multilateral Detalhada na seção 4 — é o caso mais comum de projeto do Projetão. ### Grátis **Mecanismo.** Pelo menos um segmento de clientes se beneficia continuamente de uma oferta gratuita. Há três variantes, com economias distintas por trás: | Variante | Como funciona | Exemplo do livro | |---|---|---| | **Publicidade** | Um lado da plataforma atrai usuários com conteúdo grátis; o outro paga por espaço. É uma forma particular de plataforma multilateral | *Metro*, jornal diário gratuito nascido em Estocolmo em 1995, distribuído a quem circula em estações de trem e ônibus; a audiência atraiu anunciantes e o jornal ficou rentável rapidamente | | **Freemium** | Básico grátis, premium pago. Base grande de usuários gratuitos, **em geral menos de 10% assinam** o serviço pago; os pagantes subsidiam os gratuitos, o que só é possível porque o custo marginal de servir mais um gratuito é baixo | Flickr: conta gratuita com limite de armazenamento e de envios mensais; conta "pro" anual com envio e armazenamento ilimitados. Skype é a variante extrema: chamadas roteadas ponto a ponto pela internet, usando o hardware do usuário como infraestrutura | | **Isca-e-anzol** | Oferta inicial atraente, barata ou gratuita, que induz compras futuras de um item relacionado — em geral descartável e de margem alta | King C. Gillette, em 1904, vendeu cabos de barbear com desconto forte ou os deu junto com outros produtos, para criar demanda pelas lâminas descartáveis. Operadoras de celular fazem o mesmo com o aparelho subsidiado | **As métricas do freemium**, segundo o livro: (1) o custo médio de servir um usuário gratuito e (2) a taxa de conversão de gratuito para pagante. Sem as duas, o padrão é um nome, não um modelo. **O ponto crítico do isca-e-anzol** é o *lock-in*: a ligação entre o item inicial barato e o item de reposição precisa estar protegida. A Gillette garantiu isso por patentes de bloqueio, para que concorrentes não vendessem lâminas mais baratas para os cabos dela. Hoje, aparelhos de barbear estão entre os produtos de consumo mais patenteados do mundo, com mais de mil patentes cobrindo desde a fita lubrificante até o sistema de encaixe do cartucho. **Sem barreira equivalente, o seu anzol pega o peixe de outra pessoa.** ### Aberto **Mecanismo.** Criar e capturar valor colaborando sistematicamente com parceiros externos, seja **de fora para dentro** (trazer ideias, tecnologia e propriedade intelectual externas para dentro do processo de desenvolvimento) ou **de dentro para fora** (licenciar, vender ou disponibilizar ativos que estão parados dentro da empresa). O conceito é de Henry Chesbrough, *Open Business Models*, 2006. **Exemplo de fora para dentro.** Em 2000, A. G. Lafley assumiu a Procter & Gamble e, em vez de aumentar o gasto em P&D, montou a estratégia "Connect & Develop", com a meta de **criar 50% das inovações com parceiros externos**, num momento em que o número estava próximo de 15%. A empresa superou a meta em 2007; a produtividade de P&D subiu 85%, com gasto apenas modestamente maior. Para ligar seus recursos internos ao mundo, a P&G construiu três pontes: empreendedores de tecnologia, plataformas de internet e aposentados. **Exemplo de dentro para fora.** A GlaxoSmithKline colocou direitos de propriedade intelectual relevantes para doenças pouco estudadas num *patent pool* aberto a outros pesquisadores. Como as farmacêuticas concentram esforço em medicamentos de grande volume, a PI dessas doenças costuma ficar ociosa; o *pool* agrega direitos de titulares distintos e impede que o avanço fique bloqueado por um único detentor. **Uso na Q7:** se o seu projeto depende de dado, base ou tecnologia de terceiro, este é o padrão que descreve a sua relação com eles — e a pergunta que a banca fará é o que **você** oferece em troca. --- ## 4. Plataforma multilateral, em detalhe Projeto de Projetão quase sempre nasce com "quem usa não paga". Isso tem nome e tem literatura. ### A definição Plataformas multilaterais **reúnem dois ou mais grupos de clientes distintos mas interdependentes**. Elas criam valor como intermediárias, conectando esses grupos. A plataforma só tem valor para um grupo se os outros também estiverem presentes. E ela **cresce em valor à medida que atrai mais usuários** — o efeito de rede. Exemplos do livro: cartões de crédito ligam lojistas e portadores; sistemas operacionais ligam fabricantes de hardware, desenvolvedores de aplicativos e usuários; jornais ligam leitores e anunciantes; consoles ligam desenvolvedores de jogos e jogadores. **A consequência estrutural:** cada segmento tem sua própria proposta de valor e sua própria fonte de receita, e **um segmento não existe sem os outros**. ### O dilema do ovo e da galinha O valor da plataforma para um grupo depende substancialmente do número de usuários do outro lado. Um console de videogame só atrai compradores se houver jogos suficientes; desenvolvedores só fazem jogos para um console novo se já houver uma base substancial de jogadores. Daí o dilema. **Como se resolve, na prática do livro:** subsidiando um segmento. O operador arca com o custo de servir todos os grupos, mas atrai um deles com uma proposta barata ou gratuita, para depois atrair o outro lado. Três exemplos de subsídio: - o *Metro* atraiu leitores com distribuição gratuita e cobrou dos anunciantes; - a Microsoft distribuiu o kit de desenvolvimento do Windows de graça para estimular a criação de aplicativos; mais aplicativos atraíram mais usuários, o que aumentou a receita; - o Google cobra de **um** segmento — os anunciantes — enquanto subsidia dois outros: quem faz buscas e os donos de conteúdo do AdSense. Anunciantes não compram espaço diretamente: dão lances em palavras-chave, e quanto mais popular a palavra, mais o anunciante paga. ### O erro de subsidiar o lado errado > Uma dificuldade que os operadores de plataformas multilaterais enfrentam é **entender qual lado subsidiar e como precificar corretamente** para atrair clientes. O caso de fracasso registrado no livro: a Sony subsidiou cada console **PlayStation 3** vendido, na expectativa de recuperar depois com royalties de jogos. A estratégia teve desempenho ruim porque **venderam-se menos jogos do que a Sony estimara inicialmente**. O erro tem uma forma reconhecível em projeto de estudante: subsidiar o lado que já viria de graça. Se o lado A entra na plataforma porque tem interesse próprio forte e o lado B é quem hesita, dar benefício ao lado A é gastar dinheiro para comprar o que já se tinha. ### As quatro perguntas de teste Se o seu projeto é de dois lados, responda estas quatro na entrega — são as perguntas que o livro diz que o operador **deve** se fazer: 1. Conseguimos atrair um número suficiente de clientes para **cada** lado da plataforma? 2. Qual lado é mais sensível a preço? 3. Esse lado pode ser atraído por uma oferta subsidiada? 4. O outro lado da plataforma gera receita suficiente para **cobrir** os subsídios? A pergunta 2 é a única que não se responde em reunião. Ela exige o teste de preço com gente real, dos dois lados — ver `precificacao.md`. --- ## 5. O que isso obriga a mudar no MVP A última pergunta da entrega da Q7 — "que influências o modelo de negócios tem no MVP?" — é a que fecha o laço, e a mais esquecida. Três consequências concretas do que está acima: | Descoberta na Q7 | Efeito no MVP da Q8 | |---|---| | O lado que paga não é o que usa | O MVP precisa de uma interface para o lado pagante, que provavelmente não existia | | O padrão é freemium | É preciso instrumentar a **conversão** de gratuito para pago, e medir o custo de servir um gratuito | | O padrão é isca-e-anzol | É preciso desenhar a barreira que segura o cliente no seu anzol; sem ela, não há modelo | | O padrão é cauda longa | O custo marginal por item precisa ser medido, não estimado | | O padrão é aberto | A contrapartida ao parceiro entra no escopo do produto | Se o MVP saiu da Q6 idêntico ao que entra na Q8, ou o modelo de receita é irrelevante para o produto — o que é improvável — ou a pergunta 8 não foi levada a sério. --- ## Fontes - **Osterwalder, Alexander & Pigneur, Yves**, *Business Model Generation* — os nove blocos e as perguntas centrais de cada um; tipos de segmento; custo orientado a custo × orientado a valor; os cinco padrões (desagregado, cauda longa, plataforma multilateral, grátis, aberto) com os casos *private banking* suíço, Bharti Airtel, Lulu.com, Metro, Flickr, Skype, Gillette, Google, PlayStation 3, Procter & Gamble e GlaxoSmithKline; o dilema do ovo e da galinha e as quatro perguntas do operador de plataforma - **Maurya, Ash**, *Running Lean*, caps. 1 e 3 — o Lean Canvas como adaptação do canvas original, seus nove blocos, o teste em ordem de risco, a abordagem centrada no cliente e a caixa da solução propositalmente reduzida - **Hagel, John & Singer, Marc**, "Unbundling the Corporation", *Harvard Business Review*, 1999, citados por Osterwalder — os três tipos de negócio - **Anderson, Chris**, *A cauda longa*, citado por Osterwalder — a origem do conceito de cauda longa - **Chesbrough, Henry**, *Open Business Models*, 2006, citado por Osterwalder — inovação de fora para dentro e de dentro para fora # Precificação — Quest #7 Abra este arquivo quando for definir quanto cobrar, de quem e como. Ele traz os mecanismos disponíveis, o argumento para cobrar desde o primeiro dia, como ancorar, como testar com gente real e por que o freemium raramente é bom ponto de partida num semestre. **Modo de IA:** 🔴 **sem assistência** na pesquisa de preço com clientes. 🟡 com apoio para montar a faixa a testar e para criticar a sua conta de padeiro. A IA não sabe o que o seu cliente aceita pagar, e vai concordar com o número que você propuser. --- ## 1. Os mecanismos: fixos e dinâmicos Cada fonte de receita pode ter um mecanismo de preço diferente, e a escolha do mecanismo faz diferença grande na receita gerada. São dois tipos principais: | **Preço fixo** — preços predefinidos, baseados em variáveis estáticas | **Preço dinâmico** — preços mudam conforme as condições de mercado | |---|---| | **Lista** — preço fixo para produtos, serviços ou propostas de valor individuais | **Negociação** — preço negociado entre duas ou mais partes, conforme poder e habilidade de negociação | | **Por atributo do produto** — depende do número ou da qualidade das características da proposta de valor | **Gestão de rendimento** (*yield management*) — depende do estoque e do momento da compra; usado para recursos perecíveis, como quarto de hotel e assento de avião | | **Por segmento de cliente** — depende do tipo e das características do segmento | **Mercado em tempo real** — estabelecido dinamicamente por oferta e demanda | | **Por volume** — função da quantidade comprada | **Leilão** — determinado pelo resultado de lances competitivos | **Como escolher, para o Projetão:** comece por preço de lista, faixa única. Os mecanismos dinâmicos exigem volume de transações que um projeto de semestre não tem, e leilão ou gestão de rendimento sem liquidez produz preço aleatório, não preço de mercado. --- ## 2. As sete formas de gerar receita O livro separa antes as receitas em duas naturezas: **de transação**, resultantes de pagamentos únicos, e **recorrentes**, resultantes de pagamentos continuados — seja para entregar a proposta de valor, seja para dar suporte pós-venda. | Forma | Como se cobra | Exemplo do livro | |---|---|---| | **Venda de ativo** | Venda do direito de propriedade sobre um produto físico | Livros, música e eletrônicos vendidos on-line; automóveis | | **Taxa de uso** | Quanto mais o serviço é usado, mais o cliente paga | Minutos de telefonia; diárias de hotel; entrega de encomenda | | **Assinatura** | Venda de acesso contínuo a um serviço | Mensalidade de academia; assinatura mensal de jogo on-line | | **Aluguel / arrendamento** | Direito exclusivo de uso de um ativo por período fixo, mediante taxa | Aluguel de carro por hora | | **Licenciamento** | Permissão de uso de propriedade intelectual protegida, mediante taxa | Licenças de conteúdo na mídia; licenças de patente em tecnologia | | **Corretagem** | Intermediação em nome de duas ou mais partes, com percentual sobre a transação | Percentual do cartão de crédito sobre cada venda; comissão de corretor | | **Publicidade** | Taxas por anunciar um produto, serviço ou marca | Mídia e organizadores de eventos, tradicionalmente; software e serviços, cada vez mais | Uma equipe que não consegue encaixar sua receita em nenhuma das sete quase sempre está descrevendo um **desejo** de receita, e não um mecanismo. --- ## 3. Cobrar desde o dia 1 > **Se você pretende cobrar pelo seu produto, cobre desde o primeiro dia.** A objeção usual é que o MVP é, por definição, constrangedoramente mínimo — como cobrar por ele? A resposta de Maurya é que **MVP não é sinônimo de produto pela metade ou cheio de defeito**: ele deve atacar os principais problemas identificados pelos clientes e que *valem a pena resolver*. Por essa definição, ele deve entregar valor suficiente para justificar cobrança. A segunda objeção é que o preço cria fricção desnecessária e atrasa o aprendizado. É o inverso: **facilitar o "sim" atrasa a validação da parte mais arriscada do modelo**, porque fica fácil demais dizer sim, e compromisso fraco prejudica o aprendizado. Além disso, você não precisa de muitos usuários para aprender — precisa de **uns poucos bons clientes**. As três razões: | Razão | O argumento | |---|---| | **O preço é parte do produto** | Duas garrafas d'água à sua frente, uma a 50 centavos e outra a 2 dólares. Mesmo que você não as distinguisse num teste cego, você tende a acreditar — ou ao menos a se perguntar — que a mais cara é de melhor qualidade. **O preço muda a percepção do produto.** | | **O preço define seus clientes** | A garrafa que você escolhe determina o segmento a que você pertence. Existe negócio viável nos dois preços. O que você cobra sinaliza o posicionamento e **quem você quer atrair**. | | **Ser pago é a primeira forma de validação** | Conseguir que um cliente lhe dê dinheiro é uma das ações mais difíceis que você pode pedir a ele. | **A exceção registrada:** propostas de valor que se constroem ao longo do tempo — o exemplo do livro são as contas premium do LinkedIn. **A operacionalização que reduz escopo:** *cobre desde o dia 1, mas colete no dia 30*. Período de teste é padrão hoje, e adiar a coleta de dados de cartão reduz fricção de cadastro. Os dois fatos trabalham a seu favor: você não precisa de conta de recebimento, de provedor de assinatura recorrente nem de múltiplos planos para lançar. Terá 30 dias depois do lançamento para montar isso. > ⚠️ **Nota sobre a divergência entre as fontes.** Ries mostra o motor de crescimento viral funcionando **exatamente ao contrário**: produtos virais frequentemente não cobram do cliente e dependem de receita indireta, porque não podem ter nenhum atrito que atrapalhe o cadastro e o recrutamento de amigos — "se o Facebook ou o Hotmail tivessem começado a cobrar dos clientes nos primeiros dias, teria sido uma tolice". As duas posições não se contradizem: **elas dependem do motor de crescimento escolhido**. Para o Projetão, a recomendação prática é seguir Maurya — cobrar cedo —, salvo se a equipe conseguir demonstrar viralidade implícita no uso. Ver `metricas-e-tracao.md` para essa decisão. --- ## 4. Ancoragem contra as alternativas existentes A técnica para definir o preço inicial: precifique **contra a lista de alternativas existentes** levantada no bloco de problema. Elas são as referências contra as quais a sua oferta será medida. Quando não existe referência clara — mais comum em produtos corporativos que resolvem um problema inédito —, pode ser necessário escolher um preço inicial do nada e refinar dali. **O exemplo trabalhado no livro** (produto de compartilhamento de fotos e vídeos): as alternativas iam de 24 a 39 dólares por ano (Flickr, SmugMug) até 99 dólares por ano (MobileMe, que entregava bem mais que fotos e vídeos). O preço inicial escolhido foi **49 dólares por ano** — dentro da faixa, acima do piso, com folga em relação ao teto. **A armadilha da ancoragem:** o cliente **não faz a referência sozinho**. Ancorar contra as alternativas existentes parece lógico para você, mas cabe a você trazer a comparação para a conversa. No diálogo relatado em **A entrevista de solução — Quest #6** (neste arquivo), a âncora foi explícita: "100 dólares por mês é menos de duas horas de desenvolvedor". **Se a alternativa existente é gratuita:** o livro coloca a pergunta na revisão semanal das entrevistas — se a solução atual do cliente é grátis, como você entrega valor suficiente para justificar que ele pague? Não há atalho aqui. "De graça" é uma âncora dura. **Não esqueça o custo.** O objetivo é um modelo escalável, então é preciso saber quanto custa entregar a solução e garantir margem. Uma regra prática citada por Maurya, de David Skok (Matrix Partners): **o valor do cliente ao longo da vida deve superar o custo de aquisição em pelo menos três vezes.** --- ## 5. As quatro perguntas de preço A entrega da Q7 pede que vocês perguntem aos clientes: 1. Qual o **menor preço** abaixo do qual você **duvidaria da qualidade**? 2. Qual o **maior preço** que você pagaria? 3. Qual preço **não é alto demais, mas faria você pensar duas vezes**? 4. Qual o **preço ideal** para você? > ⚠️ **Origem.** Essas quatro perguntas **não aparecem em nenhuma das obras do acervo da disciplina**. Elas vêm do material da própria disciplina. Não as atribua a Maurya, a Osterwalder nem a Ries num trabalho acadêmico. Se precisar de referência bibliográfica, procure a literatura de sensibilidade a preço — não invente a citação. **Como usá-las sem contrariar o item 6 abaixo.** As quatro perguntas produzem uma **faixa**, não um número, e servem para *calibrar* qual preço você vai dizer na entrevista de solução — não para substituir o teste. A ordem correta é: usar as alternativas existentes e as quatro perguntas para chegar a uma faixa; escolher um valor **na parte alta** dela; dizer esse valor; medir a reação. A pergunta 1 é a que mais surpreende equipe de estudante. Preço baixo demais destrói a percepção de valor, e a insegurança da equipe empurra sistematicamente para baixo. O livro registra o mesmo viés: quem cria — artistas, músicos, desenvolvedores — é notoriamente ruim em precificar o próprio trabalho e tende a subvalorizá-lo. **Preço deve ser definido com o comprador em mente, não com o vendedor.** --- ## 6. A sequência: dizer, depois fazer **Não pergunte quanto o cliente pagaria — diga o preço.** Não há justificativa econômica razoável para o cliente oferecer outra coisa que não um valor baixo; e ele pode honestamente não saber, caso em que a pergunta só o deixa desconfortável. Depois de dizer, meça em duas camadas: | Camada | O que se mede | Sinal forte | |---|---|---| | **O que ele diz** | Reação verbal ao preço dito, com registro de **hesitação** | Aceitou com um pouco de resistência | | **O que ele faz** | Pré-reserva, sinal, lista de espera com dado real, pré-pagamento | Entregou algo que custa alguma coisa | > Em geral, o preço certo é o que o cliente aceita, mas **com um pouco de resistência**. A regra de iteração: **se não houve nenhuma resistência ao preço, teste um preço mais alto** na próxima leva. Não é ganância — é a constatação de que aceitação imediata significa que a faixa ainda não foi encontrada. No relato do próprio Maurya sobre suas oficinas, ele dobrou o preço a cada edição **até encontrar alguma resistência**. E não reduza a fricção de cadastro: aumente. O caso completo, com os quatro princípios em jogo — posição de prêmio, escassez, ancoragem e confiança —, está em **A entrevista de solução — Quest #6** (neste arquivo). --- ## 7. Contra o freemium prematuro O freemium — básico grátis, premium pago — foi popularizado por Fred Wilson e parece o melhor dos dois mundos: o usuário experimenta sem se preocupar com preço, e depois é convertido ao plano certo. Maurya concorda que pode ser um modelo muito eficaz, mas **não recomenda começar por ele**. Cinco razões, todas relevantes para um semestre: | Objeção | Por que pesa | |---|---| | **Conversão baixa ou nula** | Serviços erram ao dar demais no plano gratuito. E há um motivo estrutural: **você ainda não tem dados de uso suficientes** para desenhar um plano gratuito do qual o usuário naturalmente saia num momento previsível | | **Ciclo de validação longo** | Mesmo os melhores serviços freemium relatam conversões de **0,5% a 5%**. Tempo é o recurso mais valioso de uma equipe pequena, e não dá para pagar ciclos longos em algo tão crítico quanto preço | | **O foco migra para a métrica errada** | Como "grátis" é irracionalmente atraente, o freemium tende a deslocar o foco de **retenção** para **aquisição de cadastros**. Sem o produto certo, mais cadastro é desperdício | | **Razão sinal-ruído baixa** | Com muitos usuários gratuitos, fica difícil focar no feedback certo. "Dada a oportunidade, todo mundo vira crítico" | | **Usuário gratuito não é gratuito** | Além de banda e hospedagem, há custos de suporte, de funcionalidade e de aprendizado. Se o usuário gratuito não agrega valor participativo — como agrega numa rede com efeito de rede forte —, ele é despesa. Jason Cohen chega a defender contabilizá-lo como despesa de marketing, ao lado de compra de anúncio e feira | **A recomendação de por onde começar:** comece pelo **premium do freemium**. Escolha as funcionalidades e um **plano único** pelo que os clientes pagam hoje, e inscreva-os como seus primeiros clientes — é mais simples de construir e mais simples de medir. Use um **teste gratuito por tempo determinado**, que delimita o experimento de preço e **força uma decisão de conversão**, permitindo aprender e iterar mais rápido. Depois, com dados de uso na mão, você pode desenhar o plano gratuito — e aí saberá desenhá-lo de modo que o usuário o supere em um momento razoavelmente previsível. **Quando o freemium faz sentido:** depois de já ter o produto certo, como estratégia de aquisição para produtos de consumo, que tendem a ser mais movidos pelo grátis. Empresas, por outro lado, já esperam testes por tempo determinado — e a complexidade adicional de rastrear e carregar usuários gratuitos pode não se justificar. --- ## 8. Preço variável em mercado de custo marginal baixo Se o seu produto é digital e o custo de servir mais um item é próximo de zero, você está no território em que o preço fixo é uma escolha, não uma imposição. O argumento de Chris Anderson: pessoas diferentes estão dispostas a pagar preços diferentes, por razões diversas — dinheiro disponível, tempo disponível. Nos mercados tradicionais, como só há espaço para uma versão do produto, também só há espaço para um preço de cada vez. Em mercados com espaço para ampla variedade, **a precificação variável é uma técnica poderosa para maximizar o valor dos produtos e o tamanho do mercado**. Os exemplos que ele registra: - o eBay oferece leilão (em geral preços mais baixos, ao custo de mais inconveniência e incerteza) **e** compra imediata (preços mais altos); - a iTunes, que por simplicidade adotou 0,99 dólar por faixa, **cobra menos por faixa quando ela é comprada dentro de um álbum**; - a Rhapsody testou preços de 0,79 e 0,49 dólar por faixa e constatou que **reduzir o preço à metade triplicava aproximadamente as vendas**. E o diagnóstico de por que isso ainda não é regra: as gravadoras cobram um preço fixo de atacado em torno de 0,70 dólar por faixa, sobretudo para evitar conflito de canal com o CD, que ainda produzia o grosso das receitas. **A barreira ao preço variável raramente é técnica; é conflito com o canal existente.** Vale conferir se a barreira que você percebe no seu projeto é dessa natureza. > O modelo natural para música e para qualquer outra coisa em que o custo marginal de fabricação e distribuição está perto de zero é a precificação variável. --- ## 9. A conta que fecha a quest Some as entradas de receita e as de custo para chegar ao **ponto de equilíbrio**, e estime quanto tempo, dinheiro e esforço são necessários para alcançá-lo. Maurya sugere modelar de baixo para cima e no presente, em vez de projetar três ou cinco anos: quanto custa entrevistar de 30 a 50 clientes? Quanto custa construir e lançar o MVP? Qual a taxa de queima contínua, em custos fixos e variáveis? Duas omissões que a banca cobra: **O custo do próprio trabalho.** Se as horas da equipe não entram na conta, o negócio "se paga" no papel e não se paga na vida. Use um valor-hora plausível. **O número de clientes necessário.** Custos ÷ margem por cliente. Esse número é o teste de realidade do projeto inteiro. Se der dezenas de milhares de clientes no primeiro ano, ou o preço, ou o segmento, ou o custo está errado — e a conversa da Q7 vira sobre qual dos três. --- ## Fontes - **Osterwalder, Alexander & Pigneur, Yves**, *Business Model Generation* — os mecanismos de preço fixo e dinâmico; as sete formas de gerar receita; receitas de transação e recorrentes; as métricas do freemium - **Maurya, Ash**, *Running Lean*, cap. 3, 8 e apêndice "How to Set Pricing for a SaaS Product" — cobrar desde o dia 1 e as três razões; a exceção da proposta construída ao longo do tempo; cobrar no dia 1 e coletar no dia 30; ancoragem contra alternativas existentes e o exemplo de 24–39 / 99 / 49 dólares por ano; dizer o preço em vez de perguntar; o preço aceito com um pouco de resistência; testar preço mais alto na ausência de resistência; as cinco objeções ao freemium prematuro e o caminho de começar pelo premium; a regra prática de David Skok sobre valor do cliente e custo de aquisição; o ponto de equilíbrio de baixo para cima - **Ries, Eric**, *A startup enxuta*, cap. 10 — a posição contrária sobre cobrança inicial em produtos com motor viral - **Anderson, Chris**, *A cauda longa* (ed. brasileira), regra 5 — precificação variável em mercados de custo marginal próximo de zero; eBay, iTunes, Rhapsody; o conflito de canal como barreira --- # Quest #8 — Prototipação & Usabilidade > **Objetivo.** Apresentar testes de usabilidade com o protótipo de solução. | | | |---|---| | **Modo de IA** | 🟢 coprodução no protótipo · 🔴 sem assistência no teste com usuário | | **Milestone** | **Testes de usabilidade** | | **Entrega** | o que os testes revelaram e o que vai mudar por causa disso | | **Erro que mais custa** | apresentar o protótipo e anotar elogios | --- ## O protótipo nasce aqui Nenhuma quest anterior pediu protótipo. A Q6 diz literalmente *"nesta quest não precisa prototipar"* — ali o que se testa é o **conceito**, com o meio mais barato disponível. É nesta quest que o artefato testável é construído. Se a sua equipe já construiu algo na Q6, ótimo — use. Se não construiu, você não está atrasado. --- ## A entrega não é o protótipo É o **aprendizado**. Todas as perguntas da quest são sobre o que os testes revelaram, não sobre o que foi construído. Equipe que entrega um protótipo lindo e nenhuma descoberta não cumpriu a quest. Vale registrar uma coisa que a metodologia diz e é fácil esquecer: **entender uma solução para a qual não se tem referência prévia é mais difícil que o normal.** O que parece simples para quem está imerso produz percepção completamente diferente em quem tem o primeiro contato. > Você é a pior pessoa para avaliar a usabilidade do seu produto. A segunda pior é a IA que o construiu com você. --- ## O método: três usuários por rodada, uma manhã por rodada **Três participantes por rodada.** É o número ideal para teste feito pela própria equipe. A objeção óbvia — três é amostra pequena demais e não acha todos os problemas — é verdadeira **e irrelevante**, por três motivos: 1. **O propósito não é provar nada.** Provar exigiria teste quantitativo, amostra grande e análise estatística. Isto é qualitativo: você dá tarefas, observa e aprende. O resultado são **insights acionáveis, não prova**. 2. **Você não precisa achar todos os problemas** — e não adiantaria: *você acha mais problemas em meia manhã do que consegue consertar em um mês*. 3. **Mais rodadas vencem rodada mais completa.** É muito mais importante fazer mais rodadas do que espremer cada uma. > **Testar um usuário cedo no projeto é melhor que testar 50 perto do fim.** — Steve Krug **A cadência:** uma manhã por rodada, com a equipe toda. Três usuários, depois debriefing no almoço — e ao sair do almoço a equipe já decidiu o que vai consertar. Marque **dia fixo**, não amarre a etapas do cronograma: cronograma escorrega, e o teste escorrega junto. ⚠️ **Krug propõe cadência mensal; a Q8 dura uma semana.** No livro, a manhã de teste é um ritual de calendário (a terceira quinta-feira de cada mês) porque ele fala de produto em operação contínua. Aqui o ciclo é comprimido: **duas rodadas dentro da mesma semana**, uma no começo e outra depois dos consertos. A lógica é a mesma — testar cedo, pouco e de novo —, só que o "de novo" acontece em dias, não em meses. Depois da Q8, se a equipe seguir construindo até o Demoday, a cadência mensal do livro volta a ser a referência. ⚠️ **Três por rodada, não três no total.** O enunciado da quest no site dá "10 usuários afoitos" como exemplo de resposta, e os dois números não se contradizem: 3 é o tamanho da **rodada**, 10 é a ordem de grandeza de quem a equipe ouve **ao longo do projeto**. Numa semana, isso são no mínimo **duas rodadas de 3** — a segunda testando o que a primeira mandou consertar. Uma rodada só entrega uma lista de problemas; a segunda é que mostra se a correção funcionou, e é isso que a quest cobra. Se a equipe fizer 10 pessoas numa sessão única, terá gastado o dobro do tempo para aprender menos. **Infraestrutura mínima:** sala silenciosa, mesa, duas cadeiras, computador, e software de gravação de tela. --- ## Recrutar solto e corrigir na leitura Equipes gastam tempo demais tentando achar o perfil exato. Recrutar exatamente do público-alvo **não é tão importante quanto parece** — se você está começando a testar, o produto provavelmente tem falhas que travam qualquer um. > **Recrute solto, e corrija na hora de interpretar.** — Steve Krug Na prática: procure gente que reflita o seu público, mas não trave nisso. Afrouxe os requisitos e faça a compensação mental depois. Quando alguém tiver um problema, pergunte-se: > *"Os nossos usuários teriam esse problema, ou foi problema só porque essa pessoa não sabe o que eles sabem?"* E há um argumento a favor de **sempre incluir alguém de fora do público-alvo**: 1. Projetar de modo que só o público-alvo consiga usar costuma ser má ideia — parte dos próprios especialistas não entende o jargão. 2. **Somos todos iniciantes por baixo da pele.** Arranhe um especialista e você acha alguém se virando — só que num nível mais alto. 3. **Especialistas raramente se ofendem com algo que está claro o bastante para iniciantes.** Se o produto exige conhecimento de domínio, você precisa de **alguns** participantes com esse conhecimento — não de todos. --- ## O roteiro da sessão Uma hora, minuto a minuto: | Etapa | Tempo | O que acontece | |---|---|---| | Boas-vindas | 4 min | Explica como funciona, para a pessoa saber o que esperar | | Perguntas | 2 min | Sobre o participante; deixa à vontade e revela familiaridade | | Tour da tela inicial | 3 min | "Olhe e me diga o que você entende disto" — **sem clicar** | | **As tarefas** | **35 min** | O coração: executa pensando em voz alta | | Sondagem | 5 min | Perguntas sobre o que aconteceu, inclusive as da sala de observação | | Fechamento | 5 min | Agradece, paga, acompanha até a porta | **Escolha tarefas, não telas.** *"Encontre um grupo de corrida no seu bairro e entre nele"* é tarefa. *"Veja a tela de grupos"* não é. E prefira tarefas em que a pessoa escolhe parte dos detalhes — *"encontre um livro que você queira comprar"* em vez de *"encontre um livro de culinária abaixo de R$40"* — porque aumenta o investimento emocional. ### O que o facilitador PODE dizer - *"Estamos testando o site, não você. Você não pode fazer nada errado aqui."* - *"Por favor, não se preocupe em ferir os nossos sentimentos."* - Quando a pessoa silencia: *"No que você está pensando?"*, *"O que você está olhando?"*, *"O que você está fazendo agora?"* - Se pedirem ajuda: ***"O que você faria se eu não estivesse aqui?"*** - Avise que as perguntas serão respondidas **no fim** — interessa saber como as pessoas se viram sozinhas. ### O que o facilitador NÃO PODE fazer > **Não faça perguntas indutoras, e não dê nenhuma pista ou ajuda, a menos que a pessoa esteja irremediavelmente travada ou extremamente frustrada.** Guarde as perguntas investigativas para o bloco de sondagem, justamente para não enviesar durante as tarefas. E escolha como facilitador alguém paciente, calmo, empático e bom ouvinte. --- ## O debriefing — e a triagem que define a nota **Durante:** no intervalo após cada sessão, **cada observador escreve os três problemas mais sérios** que notou. Podem anotar o que quiserem, mas a lista curta é obrigatória. **Depois:** logo em seguida, com tudo fresco. ### Por que a triagem existe Problemas sérios aparecem sempre — mas não são os que acabam consertados. Ou alguém diz "essa parte vai mudar mesmo, dá pra conviver", ou, diante da escolha entre um problema grave e vários simples, a equipe escolhe os simples. **É por isso que sites grandes e bem financiados têm problemas graves.** > **Foque implacavelmente em consertar primeiro os problemas mais sérios.** ### O método, em quatro passos 1. **Lista coletiva.** Cada pessoa diz os três problemas mais sérios que observou. Escreve tudo no quadro; repetição vira um tique. **Sem discussão nesta etapa**, e só valem problemas **observados** — coisas que de fato aconteceram numa sessão. 2. **Escolher os dez mais sérios**, começando pelos mais repetidos. 3. **Ordenar de 1 a 10**, 1 sendo o pior. 4. **Lista acionável:** para cada um, de cima para baixo — como consertar no próximo mês, quem faz, que recursos exige. **Duas regras de parada:** você não precisa consertar cada problema perfeitamente; basta fazer algo — muitas vezes um ajuste — que o tire da categoria de "problema sério". E quando o tempo do mês estiver alocado, **pare**. ### As quatro armadilhas do debriefing - **Lista separada de fruta baixa.** Coisas fáceis (uma pessoa, menos de uma hora) ficam **fora** da lista principal, para não competirem com o que é grave. - **Resista ao impulso de acrescentar.** Quando o usuário não entende, o reflexo é adicionar explicação. Muitas vezes o certo é **tirar** o que está obscurecendo o sentido. - **Trate pedido de funcionalidade com ceticismo.** Peça para a pessoa descrever a funcionalidade na sondagem e ela quase sempre conclui sozinha que não usaria. **Participantes não são designers.** - **Ignore problemas de caiaque.** Desvios momentâneos em que a pessoa se recupera sozinha, rápido, sem se abalar. Se o segundo palpite dela sobre onde achar as coisas está sempre certo, está bom o bastante. **Os três tipos de problema mais frequentes:** a pessoa não entende o conceito; as palavras que ela procura não estão lá; há coisa demais acontecendo — o alvo está na página mas não é visto. --- ## Classificar o que aconteceu: deslize ou engano? Esta é a ferramenta que transforma "não conseguiu usar" em diagnóstico acionável. > **Deslizes acontecem quando o objetivo está correto, mas as ações não são executadas direito — a execução falhou. Enganos acontecem quando o objetivo ou o plano está errado.** > > — Donald Norman, *O design do dia a dia* ### Deslize (a pessoa sabia o que queria e errou a execução) | Subtipo | O que é | Como consertar | |---|---|---| | **Captura** | Uma sequência mais frequente "captura" a pretendida, porque as duas começam igual | Desenhe sequências que difiram **desde o início** | | **Semelhança de descrição** | Ação certa no objeto errado, porque a descrição interna do alvo era vaga | Diferencie visual e fisicamente controles de propósitos distintos | | **Lapso de memória** | Pula etapa, repete, esquece o resultado | Minimize passos; lembretes vívidos | | **Erro de modo** | O mesmo controle significa coisas diferentes em estados diferentes | Elimine modos, ou torne o modo óbvio. **Erro de modo é erro de design** | Propriedade contraintuitiva: **deslizes são mais frequentes em especialistas que em novatos**, porque o especialista automatiza e não presta atenção consciente. ### Engano (a pessoa executou corretamente um plano errado) Aqui o alvo do conserto é o **modelo conceitual**, o vocabulário e a informação de estado — não o botão. Distinção operacional que muda o teste: **enganos são difíceis de detectar.** Como as ações seguintes são coerentes com o objetivo errado, observar as ações não revela o erro. **Engano só aparece se a pessoa pensar em voz alta ou se você perguntar na sondagem.** Deslize aparece sozinho. --- ## Onde exatamente o usuário travou Sete fases da ação — uma de objetivo, três de execução, três de avaliação — e os dois golfos: > **Ao usar algo, as pessoas enfrentam dois golfos: o Golfo da Execução, ao tentar descobrir como aquilo funciona, e o Golfo da Avaliação, ao tentar descobrir o que aconteceu. O papel do designer é ajudar a atravessar os dois.** > > — Donald Norman Atravessa-se o **Golfo da Execução** com significantes, restrições, mapeamentos e modelo conceitual. Atravessa-se o **Golfo da Avaliação** com feedback e modelo conceitual. ### A tabela de diagnóstico | O que o participante disse ou fez | Fase travada | Golfo | O que consertar | |---|---|---|---| | "Não sei o que dá para fazer aqui" | planejar / especificar | Execução | Significantes, descoberta | | "Sei o que quero, mas não sei como" | executar | Execução | Mapeamento | | "Cliquei… aconteceu alguma coisa?" | perceber | Avaliação | Feedback imediato | | "Apareceu isso, não sei o que quer dizer" | interpretar | Avaliação | Feedback informativo, modelo conceitual | | "Acho que deu certo… deu?" | comparar | Avaliação | Confirmação explícita do estado | | Buscou o objetivo errado desde o início | objetivo | — | Modelo conceitual, vocabulário | ### Significantes, não affordances Uma correção que o próprio autor fez ao termo que ele popularizou: desenhar um círculo indicando onde tocar **não é** criar uma affordance — a affordance de tocar existe na tela inteira. Você está **sinalizando onde** o toque deve acontecer. > **Affordances determinam que ações são possíveis. Significantes comunicam onde a ação deve acontecer.** — Donald Norman, *O design do dia a dia* > > **No design, significantes são mais importantes que affordances**, porque comunicam como usar. Regra de bolso para avaliar protótipo: **toda vez que você vê um aviso escrito à mão colado num controle explicando como usá-lo, você está vendo design ruim.** ### Feedback — três exigências **Imediato** (até um décimo de segundo de atraso já desconcerta), **informativo** (bipe genérico diz que algo aconteceu, não o quê) e **priorizado**. E duas advertências: **feedback ruim pode ser pior que nenhum**, porque distrai e irrita; e **feedback demais incomoda mais que de menos**. --- ## Fidelidade: escolha pelo que quer descobrir | Fidelidade | Boa para | Cuidado | |---|---|---| | **Papel** | fluxo, nomenclatura, entendimento do conceito | não testa desempenho nem prazer de uso | | **Encenação** | serviço, atendimento, processo com pessoas | exige ensaio | | **Wireframe navegável** | arquitetura de informação, navegação | gera discussão sobre estética que não interessa agora | | **Alta fidelidade** | percepção de valor, confiança, detalhe | caro; e protótipo bonito demais inibe crítica | **Aviso específico da era da IA:** a facilidade de gerar alta fidelidade **não é razão para pular a baixa**. O protótipo de papel continua melhor para testar conceito, porque ninguém tem medo de dizer que um rabisco está errado. **Mágico de Oz** — quando o back-end não existe: um membro da equipe simula as respostas do sistema por trás da cortina enquanto o participante interage com algo que parece real. A credibilidade depende de **comportamento consistente** do "mago" quanto a tempo, padrões e lógica. Especialmente útil em produtos com IA, onde o modelo pode ser um humano na primeira rodada. --- ## Inspeção não substitui usuário | | Inspeção (heurística, percurso cognitivo) | Teste com usuário | |---|---|---| | Quem | 3 a 5 avaliadores da equipe, **independentes** | Participantes reais, 3 por rodada | | Contra o quê | Um conjunto de heurísticas acordadas | Tarefas reais, comportamento observado | | Quando | **Antes** de trazer usuários — limpa o básico | Continuamente | | Acha | Violações de princípio | O que de fato confunde e frustra | A independência antes da agregação é o que mitiga o viés de qualquer avaliador. E os dois métodos revelam **classes diferentes** de problema — use os dois, não um no lugar do outro. --- ## As perguntas da entrega 1. **As pessoas se mostraram motivadas a usar o protótipo?** 2. **O protótipo funciona corretamente?** > ⚠️ **Cuidado com a pergunta 1.** Teste de usabilidade **não mede desejabilidade** — ele mede se a pessoa **consegue** fazer, não se ela **quer**. Querer é pergunta de pesquisa com usuário, e a resposta de quem está sentado num teste é enviesada pela cortesia. > > O que fazer: responda a pergunta 1 com evidência de outra origem — o que os usuários afoitos disseram, quantos aceitaram continuar usando depois da sessão, quantos pediram acesso — e **declare de onde veio**. Responder "60% gostaram" a partir do próprio teste é medir educação, não motivação. 3. **Qual o perfil e a quantidade de usuários que testaram?** 4. **O usuário aprovou as funcionalidades?** 5. **O usuário se sentiu familiarizado, ou teve dificuldade?** Em **qual tarefa** teve mais dificuldade? 6. **O que precisa mudar?** A pergunta 5 é a que dá o milestone. Note o formato esperado: ela nomeia **a tarefa específica**. "Acharam um pouco confuso" não é resposta. --- ## Referências desta quest | Arquivo | Quando | |---|---| | **Teste de usabilidade — Quest #8** (neste arquivo) | Antes de testar. Roteiro completo, falas literais, recrutamento, o debriefing | | **Diagnóstico de erro — Quest #8** (neste arquivo) | Ao analisar. Deslize × engano, as sete fases, os golfos, feedback | | **Protótipos e inspeção — Quest #8** (neste arquivo) | Ao construir. Fidelidades, Mágico de Oz, microinterações | | **Autodiagnóstico — Quest #8** (neste arquivo) | Antes de entregar | --- ### Antes de registrar pessoas | Arquivo | Quando | |---|---| | `../../metodo/consentimento.md` | Antes do teste de usabilidade. Gravação de tela e voz, e o que não se publica | --- ### Técnicas desta quest Fichas curtas de consulta rápida. Abra quando o procedimento acima mencionar a técnica. | Ficha | Para quê | |---|---| | **Wireframe** (neste arquivo) | o que testar em cada fidelidade | | **Microinterações** (neste arquivo) | quando o usuário não percebe que algo aconteceu | | **Usuário afoito (*early adopter*)** (neste arquivo) | quem recrutar | | **Brainstorm** (neste arquivo) | gerar soluções para os problemas achados | --- ## Perguntas frequentes **"Podemos testar com colegas de turma?"** Só se forem do perfil. Colega sabe o que você está fazendo, quer te ajudar e domina tecnologia — as três coisas contaminam. Se não houver alternativa, **declare a limitação** na entrega; declarar é melhor que disfarçar. **"O gerente da equipe não sabe gerenciar."** Ninguém sabe — todos estão aprendendo. Cheque três coisas: ele **quer** o papel; ele não está ouvindo a equipe ou apenas não está fazendo o que você queria; e ele está tentando melhorar. Se há esforço de aprendizado, as coisas estão andando como deveriam. --- ## Bibliografia desta quest | Obra | O que ela dá para a Q8 | |---|---| | **Krug — Não me faça pensar** | O método de teste barato, o roteiro, o debriefing, a triagem | | **Norman — O design do dia a dia** | Deslize × engano, sete fases, golfos, significantes, feedback | | **Hanington & Martin — Universal Methods of Design** | Think-aloud, avaliação heurística, percurso cognitivo, Mágico de Oz | | **Head — Designing Interface Animation** | Microinterações com propósito | | **Maurya — Running Lean** | A entrevista de MVP, derivada do método de teste acima | | **Bigão Silva** · **Sutherland** | Bibliografia oficial da quest no site | # Autodiagnóstico — Quest #8 Faça este exercício **antes** de entregar. Ele é o mesmo que o mentor vai fazer depois. --- ## A escala O milestone da Q8 é **Testes de usabilidade**. Use a escala 0–5 da disciplina: | Nível | Significado | |---|---| | **0** | O critério ainda não aparece. | | **1** | Já aparece, mas sem clareza nem coerência. | | **2** | Falta clareza **ou** falta coerência. A resposta ainda está no terreno da insegurança. | | **3** | Coerente, mas ainda não totalmente claro. Resta uma parcela de incerteza. | | **4** | Claro e coerente com toda a proposta. Ainda cabe aperfeiçoar, mas a equipe responde com segurança. | | **5** | Perfeitamente alinhado ao conjunto. As respostas são sólidas. | O salto que trava a maioria na Q8 é o **2 → 3**, e ele quase nunca é sobre o protótipo: é sobre ter **observado** em vez de ter **apresentado**. Equipe que fez demonstração comentada com três amigos não passa de 2, por melhor que seja a tela. --- ## Rubrica por dimensão ### 1. Condução do teste | | | |---|---| | **2** | Mostramos o protótipo e perguntamos o que acharam. Quem conduziu explicou as telas durante o uso. | | **3** | Demos tarefas e observamos, mas sem roteiro escrito; o facilitador ajudou algumas vezes. | | **4** | Roteiro escrito e lido; tarefas (não telas) com investimento da pessoa; pensar em voz alta estimulado; nenhuma pergunta indutora; perguntas guardadas para a sondagem. | | **5** | O acima, com observadores em sala separada, cada um registrando os três problemas mais sérios por sessão, e gravação de tela. | ### 2. Participantes | | | |---|---| | **2** | Colegas de turma, sem relação com o perfil, que já conheciam o projeto. | | **3** | Três pessoas do perfil aproximado, mas o quanto elas se afastam do público-alvo não foi declarado. | | **4** | Três participantes, perfil descrito com precisão, **com a compensação declarada** — o que foi problema de fato e o que foi problema por desconhecimento de domínio. | | **5** | O acima, com pelo menos um participante deliberadamente de fora do público-alvo, e com o motivo dessa escolha explicado. | ### 3. Achados | | | |---|---| | **2** | "Acharam confuso", "gostaram", "sugeriram melhorias". Nenhuma tarefa nomeada. | | **3** | Problemas listados por tela, misturando o que foi observado com o que foi opinado. | | **4** | Só problemas **observados**, cada um ligado à **tarefa específica** em que apareceu e ao participante que o teve; dez priorizados e ordenados de 1 a 10. | | **5** | O acima, com cada problema classificado (deslize ou engano; fase da ação travada; golfo) e a evidência de qual sondagem revelou o engano. | ### 4. Decisão do que mudar | | | |---|---| | **2** | Lista de melhorias futuras, sem dono e sem prazo. | | **3** | Correções descritas, mas sem responsável nem estimativa, e sem ordem de prioridade. | | **4** | Lista ordenada, do pior para o menos pior, com **como consertar, quem faz e que recursos exige** — e uma lista separada de fruta baixa. | | **5** | O acima, com o ponto de parada declarado: o que **não** vai ser consertado nesta rodada e por quê. | ### 5. Honestidade metodológica | | | |---|---| | **2** | O relato sugere que o teste provou que a solução funciona. | | **3** | Limitações citadas de forma genérica ("amostra pequena"). | | **4** | A equipe declara que a rodada é qualitativa e não prova nada; declara o que o teste **não** mede (desejo, motivação) e de onde veio a evidência disso. | | **5** | O acima, com o registro do que a equipe **esperava** que acontecesse, escrito antes do teste, comparado ao que aconteceu. | --- ## Checklist rápido - [ ] Dei **tarefas**, não telas — e consigo nomear **a tarefa** em que a maior dificuldade apareceu? - [ ] Todos os problemas da minha lista **aconteceram** numa sessão, ou algum é opinião da equipe? - [ ] Alguém pediu ajuda e eu respondi *"o que você faria se eu não estivesse aqui?"*, ou eu ajudei? - [ ] Guardei as perguntas para a sondagem, ou perguntei durante a tarefa? - [ ] Sei distinguir, na minha lista, o que foi deslize e o que foi engano? - [ ] Se só há deslizes na lista, eu de fato sondei — ou não houve como detectar engano? - [ ] Ignorei os problemas de caiaque, e separei a fruta baixa para não competir com o que é grave? - [ ] Cada item da lista tem **dono e prazo**, ou é uma lista de desejos? - [ ] Declarei o que **não** vamos consertar? - [ ] O protótipo era da fidelidade certa para o que eu queria descobrir? - [ ] Se usei Mágico de Oz, declarei — e o mago se comportou de forma consistente? **Sinal de alerta:** se a entrega tem mais imagem de tela do que descrição de comportamento observado, a equipe entregou o protótipo, não o aprendizado. A quest pede o segundo. **Segundo sinal:** se nenhuma decisão de produto mudou por causa do teste, ou o produto já estava perfeito — improvável — ou o teste foi apresentação. --- ## 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 Q8 há dois modos distintos: 🟢 coprodução ao construir o protótipo, 🔴 sem assistência durante a sessão com o participante. Se a IA participou da condução ou da interpretação do que o participante fez, isso precisa estar declarado.* 2. **O que a IA gerou e você descartou — e por quê.** *Típico da Q8: a IA gera uma lista de "problemas de usabilidade prováveis" a partir das telas. Ela pode servir de insumo para a avaliação heurística, e não pode entrar na lista de achados do teste. Achado de teste é o que aconteceu com alguém.* 3. **O que você verificou, e como.** *Típico da Q8: a classificação dos erros. Diga qual episódio você reclassificou depois de olhar a gravação.* 4. **O que ainda não sabe.** --- ## Como o mentor vai ler Quatro perguntas que aparecem com regularidade na apresentação da Q8. Se você tem resposta para as quatro, está em 4: 1. **"Em qual tarefa o usuário teve mais dificuldade?"** É a pergunta 5 da entrega, e ela pede o nome de uma tarefa. "Acharam um pouco confuso" não é resposta. 2. **"O que exatamente aconteceu na tela quando ele travou?"** Se a resposta é vaga, a equipe assistiu sem registrar. Se é precisa, ela observou. 3. **"Vocês ajudaram?"** "Só um pouquinho, quando ele ficou perdido" é responder que a sessão foi contaminada. Melhor ter ajudado e declarado do que ter ajudado e omitido. 4. **"O que vocês vão consertar até a Q9, e o que não vão?"** A segunda metade da pergunta é a que separa 3 de 4. Divergência entre a sua auto-avaliação e a leitura do mentor é informação útil, não constrangimento. # Diagnóstico de erro — Quest #8 Abra este arquivo **depois** do teste, com as notas na mão, quando for preciso transformar "não conseguiu usar" em uma frase que diz o que consertar. É o vocabulário que separa uma entrega nível 2 de uma entrega nível 4 na Q8: nível 2 diz *"os usuários acharam confuso"*; nível 4 diz *"o participante 2 travou na fase de especificar a ação, por falta de significante no botão de convite — vamos rotular o ícone"*. Modo de IA: 🟡 **com apoio**. A IA é boa em ajudar a classificar um episódio já descrito — pergunte a ela por que um caso é engano e não deslize, e peça que ela aponte a evidência que falta. Ela não pode classificar o que não observou. --- ## 1. Deslize ou engano: a bifurcação Toda a classificação de erro humano usada aqui vem da divisão que Donald Norman e o psicólogo britânico James Reason estabeleceram, e que hoje é usada em estudos de acidentes industriais, de aviação e de erro médico. > **Deslizes acontecem quando o objetivo está correto, mas as ações não são executadas direito — a execução falhou. Enganos acontecem quando o objetivo ou o plano está errado.** A consequência prática vem antes de qualquer subtipo: | | Deslize | Engano | |---|---|---| | Origem | Ação subconsciente que se desviou no caminho | Deliberação consciente que partiu errado | | Quem comete mais | **Especialistas**, porque automatizam e não prestam atenção consciente | Quem está diante de situação nova ou mal classificada | | Aparece sozinho no teste? | **Sim.** Você vê acontecer | **Não.** As ações seguintes são coerentes com o objetivo errado | | Como você descobre | Observando | **Só se a pessoa pensar em voz alta, ou se você perguntar na sondagem** | | O que consertar | O controle, o layout, a sequência | O modelo conceitual, o vocabulário, a informação de estado | Norman também registra que a distinção entre detectar um e outro não é simétrica: **lapsos de memória são difíceis de detectar precisamente porque não há nada para ver** — a ação devida não foi executada, e quando nenhuma ação acontece, não há o que detectar. Só quando a ausência de ação provoca algum evento indesejado é que existe chance de perceber. > ⚠️ **Por que isso muda o seu roteiro de teste.** Se a equipe não insistir no "pensar em voz alta" e pular o bloco de sondagem, ela vai voltar do campo com uma lista só de deslizes — e vai consertar botões enquanto o problema real é que ninguém entendeu para que serve o produto. O bloco de sondagem não é sobra de tempo: é o único instrumento que detecta engano. --- ## 2. Os deslizes, subtipo por subtipo Norman divide deslizes em dois grupos: **baseados em ação** (a ação errada é executada) e **lapsos de memória** (a memória falha, e a ação pretendida não é feita, ou o resultado não é avaliado). ### Deslize de captura **O que é:** em vez da atividade pretendida, uma outra, mais frequente ou mais recente, é executada — ela *captura* a atividade. Exige que **parte das duas sequências de ação seja idêntica**, com uma delas sendo muito mais familiar. Depois da parte idêntica, a atividade mais frequente continua sozinha, e a pretendida não acontece. Norman observa que a sequência não familiar raramente, ou nunca, captura a familiar. Basta um lapso de atenção no ponto crítico em que as sequências se separam. São, portanto, erros parciais de memória. **Por que aparece em especialistas:** o experiente automatizou as ações e pode não estar prestando atenção consciente exatamente quando a ação pretendida se desvia da mais frequente. **A cura:** desenhe sequências que **difiram desde o início**. Norman é explícito ao fechar o capítulo: procedimentos devem ser projetados de modo que os passos iniciais sejam tão dissimilares quanto possível. E forneça auxílio e lembretes visíveis para procedimentos pouco frequentes que se parecem com outros muito frequentes. **Como aparece no seu protótipo:** dois fluxos que começam pelos mesmos três toques e divergem no quarto. Salvar rascunho e publicar. Convidar para o grupo e entrar no grupo. ### Deslize por semelhança de descrição **O que é:** agir sobre um item **semelhante** ao alvo, porque a descrição interna do alvo era vaga demais. Norman dá o mecanismo: se a descrição mental era algo como "um recipiente grande o bastante", tanto o cesto de roupa quanto o vaso sanitário satisfazem. Acontece mais quando a pessoa está cansada, estressada ou sobrecarregada. **A cura:** garantir que **controles e telas de propósitos diferentes sejam significativamente diferentes entre si**. Norman é enfático: uma fileira de interruptores ou mostradores de aparência idêntica é receita quase certa para esse erro. Em cabines de avião, muitos controles são codificados por forma, de modo a **parecer e se sentir diferentes** — a alavanca de flap tem o formato de um flap de asa; o controle do trem de pouso, o de uma roda. **Como aparece no seu protótipo:** três botões iguais em cinza, com rótulos parecidos, um ao lado do outro. Duas listas idênticas em telas diferentes. ### Lapso de memória **O que é:** a pessoa pula uma etapa, repete uma etapa, esquece o resultado da ação, ou esquece o objetivo no meio do caminho. **A causa imediata**, segundo Norman, é quase sempre **interrupção**: eventos que se interpõem entre o momento em que a ação foi decidida e o momento em que ela seria concluída. E boa parte da interferência vem das próprias máquinas — os muitos passos exigidos entre o início e o fim da operação sobrecarregam a memória de trabalho. **As curas, em ordem de força:** 1. **Minimizar o número de passos.** 2. **Lembretes vívidos** dos passos que ainda faltam. 3. **Função de força** — o método superior. O caixa eletrônico que exige a retirada do cartão antes de entregar o dinheiro impede o esquecimento do cartão, aproveitando o fato de que as pessoas raramente esquecem o objetivo da atividade, que aqui é o dinheiro. Norman é honesto sobre o limite: nem todo lapso de memória admite solução simples, porque muitas interrupções vêm de fora do sistema, onde o projetista não tem controle. **E um alerta que vale para todo formulário longo:** listas de verificação impressas têm uma falha grande — forçam os passos a seguir uma ordem sequencial mesmo quando isso não é necessário nem possível. Quando um item não pode ser feito na hora em que aparece, a pessoa o pula pretendendo voltar depois. Isso é uma oportunidade clara de lapso de memória. ### Erro de modo **O que é:** o dispositivo tem estados diferentes nos quais **os mesmos controles têm significados diferentes**. Esses estados são os modos. Norman é direto sobre a inevitabilidade: erros de modo são inevitáveis em qualquer coisa que tenha mais ações possíveis do que controles ou telas disponíveis — e isso é inescapável à medida que acrescentamos funções. **A tentação que os cria:** parece econômico ter dez funções e apenas dois controles, um para escolher a função e outro para ajustá-la. O resultado parece simples e fácil de usar, mas essa simplicidade aparente **mascara a complexidade de uso**: o operador precisa estar sempre completamente ciente de qual modo está ativo. A prevalência dos erros de modo mostra que essa premissa é falsa. E o problema piora quando o modo é selecionado e a pessoa é interrompida, ou quando o modo se mantém por períodos longos. **A frase que a equipe precisa decorar:** **erro de modo é, na verdade, erro de projeto.** Erros de modo são especialmente prováveis quando o equipamento **não torna o modo visível**, e se espera que o usuário se lembre de qual modo foi estabelecido — às vezes horas antes, com muitos eventos no meio. **A cura:** eliminar modos. Se não for possível, tornar **óbvio** qual modo está ativo. Norman registra a correção que a Airbus fez depois de um acidente em que os pilotos acreditavam controlar o ângulo de descida quando controlavam a velocidade vertical: passou a exibir velocidade vertical sempre com quatro dígitos e ângulo com dois, reduzindo a chance de confusão. **Como aparece no seu protótipo:** o mesmo botão "+" que cria tarefa numa aba e cria projeto em outra. O modo de edição que não se distingue do modo de leitura. --- ## 3. Os enganos, subtipo por subtipo Enganos resultam da escolha de objetivos e planos inadequados, ou de comparação falha entre resultado e objetivo. Norman classifica em três, apoiado na distinção do engenheiro dinamarquês Jens Rasmussen entre comportamento **baseado em habilidade**, **baseado em regra** e **baseado em conhecimento**. | Subtipo | O que é | Como se manifesta | Direção da cura | |---|---|---|---| | **Baseado em regra** | A situação foi diagnosticada corretamente, mas o curso de ação escolhido é errado: a regra errada foi seguida | A pessoa faz algo coerente e confiante, e está errada desde o começo | Modelo conceitual explícito; deixar o estado do sistema visível para que a classificação errada apareça | | **Baseado em conhecimento** | A situação é **mal diagnosticada**, por conhecimento errado ou incompleto; não há habilidade nem regra que se aplique | Situação nova, a pessoa raciocina em voz alta, testa hipóteses, se perde | Modelo conceitual é essencial aqui — é ele que guia o desenvolvimento do plano e a interpretação da situação | | **Lapso de memória** | Esquecimento nas fases de objetivo, plano ou avaliação | A pessoa abandona a tarefa e não retoma; ou não avalia se deu certo | **Mesma cura do lapso de memória em deslizes:** garantir que toda a informação relevante permaneça continuamente disponível. Objetivos, planos e avaliação corrente do sistema são os itens mais importantes, e são justamente os que muitos designs apagam assim que a ação é executada | **Por que enganos baseados em regra são difíceis de evitar e difíceis de detectar:** uma vez classificada a situação, escolher a regra costuma ser direto. Mas se a classificação está errada, isso é difícil de descobrir, porque normalmente há bastante evidência sustentando a classificação errada. Em situações complexas o problema é **informação demais** — informação que sustenta a decisão e informação que a contradiz. Sob pressão de tempo, é difícil saber qual considerar e qual rejeitar. E há um viés previsível: as pessoas decidem casando a situação atual com algo que aconteceu antes, e esse casamento é enviesado por **recência, regularidade e unicidade**. Diante de algo genuinamente novo, a pessoa ainda assim encontra algum casamento na memória para usar como guia. **Um exemplo que Norman dá e que serve de teste para o seu produto:** girar o termostato do forno até o máximo para ele chegar mais rápido à temperatura de cozimento é engano baseado num modelo conceitual falso do funcionamento do forno. Pergunte-se se o seu produto tem um controle que convida a esse tipo de raciocínio. **Diagnóstico duplo.** Norman analisa um caso comum de computador — fechar a janela errada e aceitar a caixa de diálogo sem ler — e conclui que houve os dois erros: emitir o comando "fechar" com a janela errada ativa é lapso de memória (deslize); decidir não ler a caixa de diálogo e aceitá-la sem salvar é engano. **Um episódio pode conter os dois.** Não force a escolha. --- ## 4. As sete fases da ação Toda ação tem duas partes — executar e avaliar; fazer e interpretar. Norman decompõe em sete fases: uma de objetivo, três de execução, três de avaliação. | # | Fase | A pergunta que a pessoa se faz | |---|---|---| | 1 | **Objetivo** (formar o objetivo) | O que eu quero realizar? | | 2 | **Planejar** (a ação) | Quais são as sequências de ação alternativas? | | 3 | **Especificar** (a sequência de ações) | Que ação eu posso fazer agora? | | 4 | **Executar** (a sequência) | Como eu faço isso? | | 5 | **Perceber** (o estado do mundo) | O que aconteceu? | | 6 | **Interpretar** (a percepção) | O que isso quer dizer? | | 7 | **Comparar** (resultado e objetivo) | Está tudo bem? Eu consegui o que queria? | Norman é claro sobre os limites do modelo: ele é **simplificado**; nem toda atividade percorre as sete fases em sequência, objetivos geram subobjetivos, e há atividades em que o objetivo é esquecido ou reformulado. Nem tudo é consciente — só quando algo novo ou um impasse rompe o fluxo é que a atenção consciente entra. E o ciclo tanto pode começar em cima, no objetivo (**comportamento dirigido a objetivo**), quanto embaixo, disparado por um evento do mundo (**dirigido a dados ou a eventos**). **Onde cada erro nasce:** enganos são erros nas fases altas — estabelecer objetivo ou plano, e comparar resultado com expectativa. Deslizes acontecem na execução do plano, ou na percepção e interpretação do resultado — as fases baixas. **Lapsos de memória podem acontecer em qualquer uma das oito transições entre fases**, e um lapso numa transição impede o ciclo de prosseguir, de modo que a ação desejada não se completa. **Uso adicional, que serve à Q2 tanto quanto à Q8:** as sete fases servem de guia para desenvolver produtos novos. Os golfos são o ponto óbvio de partida, porque cada um deles é uma oportunidade de melhoria — o truque é desenvolver a habilidade de observação para detectá-los. Ideias radicais, que criam categorias novas, vêm de **reconsiderar o objetivo**, perguntando qual é o objetivo real — o que Norman chama de análise de causa-raiz. --- ## 5. Os dois golfos, e como atravessá-los > **Ao usar algo, as pessoas enfrentam dois golfos: o Golfo da Execução, ao tentar descobrir como aquilo funciona, e o Golfo da Avaliação, ao tentar descobrir o que aconteceu. O papel do designer é ajudar a atravessar os dois.** O **Golfo da Avaliação** reflete o **esforço** que a pessoa tem de fazer para interpretar o estado físico do dispositivo e determinar quão bem as expectativas e intenções foram atendidas. Ele é pequeno quando o dispositivo oferece informação sobre o próprio estado numa forma fácil de obter, fácil de interpretar e compatível com o modo como a pessoa pensa o sistema. | Golfo | Atravessa-se com | |---|---| | **Execução** | Significantes, restrições, mapeamentos e modelo conceitual | | **Avaliação** | Feedback e modelo conceitual | Há um par de termos que organiza isso e que vale usar na apresentação da Q8: - **Feedforward** — a informação que ajuda a responder às perguntas de execução (o que dá para fazer, como faço). Vem de significantes, restrições e mapeamentos, com o modelo conceitual como base. O termo é emprestado da teoria de controle. - **Feedback** — a informação que ajuda a entender o que aconteceu. Vem de informação explícita sobre o impacto da ação, de novo com o modelo conceitual como base. Norman acrescenta a condição que quase toda equipe esquece: **os dois precisam ser apresentados numa forma que as pessoas que usam o sistema consigam interpretar.** A apresentação tem de corresponder ao modo como a pessoa vê o objetivo que persegue e às expectativas dela. **Quem deve conseguir responder às sete perguntas?** Qualquer pessoa que use o produto, sempre. Isso põe o ônus no projetista: garantir que, em cada fase, o produto forneça a informação necessária para responder. --- ## 6. A tabela de diagnóstico Use esta tabela lendo as notas do teste. A coluna da esquerda é o que você **anotou**; as outras três são o diagnóstico. | O que o participante disse ou fez | Fase travada | Golfo | O que consertar | |---|---|---|---| | "Não sei o que dá para fazer aqui" · varre a tela sem clicar | Planejar / especificar | Execução | **Significantes** e descoberta: tornar visíveis as ações possíveis | | "Sei o que eu quero, mas não sei como fazer" · encontra o botão certo e não o reconhece como certo | Executar | Execução | **Mapeamento** entre controle e efeito; rótulo; proximidade espacial | | "Cliquei… aconteceu alguma coisa?" · clica de novo no mesmo lugar | Perceber | Avaliação | **Feedback imediato** — até um décimo de segundo de atraso desconcerta | | "Apareceu isso aqui, não sei o que quer dizer" | Interpretar | Avaliação | **Feedback informativo** e modelo conceitual: dizer o que aconteceu, não que algo aconteceu | | "Acho que deu certo… deu?" · sai da tela sem confirmar | Comparar | Avaliação | **Confirmação explícita do estado**; mostrar o novo estado depois da ação | | Perseguiu o objetivo errado desde o início, com ações coerentes entre si | Objetivo | — (engano) | **Modelo conceitual** e vocabulário: a primeira tela, os nomes das coisas | | Pulou uma etapa e não voltou; ou abandonou no meio depois de uma interrupção | Transição entre fases | — (lapso) | Menos passos; lembrete vívido; função de força | | Fez a coisa certa no objeto errado, entre controles parecidos | Executar | Execução | Diferenciar visual e fisicamente os controles (semelhança de descrição) | | Fez a sequência mais frequente em vez da pretendida | Executar | Execução | Fazer as sequências divergirem desde o primeiro passo (captura) | | Fez a ação certa com o produto no estado errado | Executar | Execução | Eliminar o modo, ou torná-lo óbvio (erro de modo) | **Ação:** para cada um dos dez problemas priorizados no debriefing, preencha as quatro colunas antes de escrever o conserto. Problema que não cabe em nenhuma linha provavelmente não é problema de usabilidade — é pedido de funcionalidade disfarçado. --- ## 7. Significantes, não affordances Esta é uma correção que o próprio Norman fez ao termo que ele popularizou, e que ele explica na revisão do livro: a primeira edição focava em affordances, mas embora affordances façam sentido para objetos físicos, elas confundem quando se trata de objetos virtuais — e criaram muita confusão no mundo do design. **Affordance** é a possibilidade de interação que existe no mundo entre um agente e algo. Algumas affordances são perceptíveis, outras são invisíveis. Se uma affordance não pode ser percebida, é preciso algum meio de sinalizar que ela existe — e a esse meio Norman dá o nome de **significante**. **Significante** é qualquer marca, som ou indicador perceptível que comunique o comportamento apropriado a uma pessoa. Pode ser deliberado — a placa "EMPURRE" na porta — ou acidental: a trilha aberta na neve por quem passou antes, o número de pessoas esperando na plataforma como sinal de que o trem já passou ou não. Norman insiste que **não faz diferença se o sinal foi colocado de propósito**. A formulação dele: **affordances definem que ações são possíveis; significantes especificam como as pessoas descobrem essas possibilidades.** E a consequência para quem projeta: **no design, significantes são mais importantes que affordances**, porque são eles que comunicam **como usar**. Na maior parte do tempo, o projetista pode se concentrar nos significantes. O exemplo que fecha a discussão, num diálogo do próprio livro: desenhar um círculo indicando onde tocar na tela **não é** criar uma affordance — a affordance de tocar existe na tela inteira, e o círculo não acrescenta nada de novo. Ele **sinaliza o que fazer e onde fazer**. Chame pelo nome certo: significante. **Um cuidado:** affordances percebidas podem ser falsas. Algo pode parecer uma porta ou um lugar de empurrar sem ser. Norman chama esses de **significantes enganosos** — às vezes acidentais, às vezes propositais, como uma fileira de tubos de borracha atravessando uma estrada de serviço, que bloqueia carros aos olhos de quem passa mas deixa passar quem sabe que são de borracha. **A regra de bolso para avaliar o seu protótipo:** Toda vez que você vê um aviso escrito à mão colado numa porta, num interruptor ou num produto, explicando como usar aquilo, você está olhando para design ruim. A versão de tela é o balão de ajuda que a equipe acrescentou porque "ninguém entendia" — o pedido de socorro do significante que está faltando. --- ## 8. Feedback: três exigências e duas advertências Norman observa que, dada a importância do feedback, é espantoso quantos produtos o ignoram. **As três exigências:** 1. **Imediato.** Mesmo um atraso de um décimo de segundo já desconcerta. Se o atraso é longo demais, as pessoas frequentemente desistem e vão fazer outra coisa — o que é irritante para elas e desperdício de recurso para o sistema, que gasta tempo e esforço atendendo uma requisição cujo destinatário já não está mais lá. 2. **Informativo.** Empresas economizam usando luzes baratas e geradores de som simples. Esses flashes e bipes costumam ser mais irritantes que úteis: dizem que **algo** aconteceu, transmitem pouquíssima informação sobre **o que** aconteceu, e nada sobre o que fazer a respeito. Com som, muitas vezes não dá nem para saber qual aparelho emitiu; com luz, você perde se não estava olhando para o lugar certo na hora certa. 3. **Priorizado.** Todas as ações precisam de confirmação, mas de modo **discreto**. Informação sem importância deve ser apresentada de forma discreta; sinais importantes, de forma que capture atenção. Quando tudo sinaliza emergência, nada é ganho com a cacofonia resultante. **As duas advertências:** - **Feedback ruim pode ser pior que nenhum feedback**, porque distrai, não informa e, em muitos casos, irrita e provoca ansiedade. - **Feedback demais incomoda mais que de menos.** Norman dá o exemplo doméstico da lava-louças que apita às três da manhã para avisar que terminou, derrotando o objetivo de rodar de madrugada sem incomodar ninguém. E o risco maior: excesso de avisos faz as pessoas ignorarem todos, ou desligarem todos — e então os importantes se perdem. **Ação para a Q8:** liste as ações principais do seu protótipo numa tabela de três colunas — *ação · o que o sistema responde · em quanto tempo*. Toda linha em que a segunda coluna esteja vazia é um problema de Golfo da Avaliação esperando aparecer no teste. Toda linha em que a resposta seja genérica ("Pronto!", "Erro") é feedback não informativo. --- ## Fontes - **Norman, Donald**, *O design do dia a dia* (*The Design of Everyday Things*, edição revista) — cap. 1: affordances, significantes, a correção do autor ao próprio termo, significantes enganosos, a regra do aviso escrito à mão; cap. 2: os dois golfos, as sete fases da ação, feedforward e feedback, os sete princípios de projeto; cap. 1: as três exigências do feedback e as duas advertências; cap. 5: a classificação de erros, todos os subtipos de deslize e de engano, as curas de cada um, a dificuldade de detecção, interrupções e listas de verificação - **Reason, James** — coautor, com Norman, da classificação em deslizes e enganos, conforme o próprio Norman registra nas notas - **Rasmussen, Jens** (1983) — a distinção entre comportamento baseado em habilidade, em regra e em conhecimento, da qual vem a classificação de enganos; Norman a indica como uma das melhores introduções ao tema # Protótipos e inspeção — Quest #8 Abra este arquivo **antes** de construir, quando a equipe está decidindo o que fazer para levar ao teste — e de novo antes de trazer usuários, para limpar o básico por conta própria. Ele responde a três perguntas: qual fidelidade construir, como simular o que ainda não existe, e o que a equipe consegue descobrir sozinha sem gastar a sessão de um participante. Modo de IA: 🟢 **coprodução** ao construir o protótipo — gerar telas, variações, dados de exemplo. 🟡 **com apoio** na avaliação heurística e no percurso cognitivo: a IA aponta violações e faz perguntas, e a equipe decide o que é problema. --- ## 1. Escolha a fidelidade pelo que você quer descobrir Protótipo é a **representação tangível de artefatos em vários níveis de resolução**, para desenvolver e testar ideias dentro da equipe, com clientes e com usuários. Hanington & Martin definem protótipos pelo **nível de fidelidade**, ou grau de acabamento resolvido, e tratam baixa e alta fidelidade como as duas pontas de um contínuo — com muitas variações no meio. | Fidelidade | O que é | O que testa bem | O que não testa | Cuidado | |---|---|---|---|---| | **Baixa (esboço, storyboard, modelo de rascunho)** | Comum na ideação inicial em todas as disciplinas de design. Serve de ponto de checagem para o time | Conceito, fluxo, nomenclatura, entendimento | Desempenho, prazer de uso, estética | É "proposta para revisão construtiva", não produto — deixe isso explícito ao participante | | **Papel** | Páginas representando telas. A pessoa indica o que faria em cada página, e o pesquisador troca as páginas seguintes para simular a resposta da interface | Entendimento do conceito, nomes, sequência | Tempo de resposta, transições, sensação | Áreas de dificuldade podem ser anotadas **direto no papel**, com códigos | | **Encenação / protótipo de experiência** | Participação ativa numa experiência ao vivo, com adereços simples e representação de papéis, criando um cenário de uso realista | Serviço, atendimento, processo com pessoas, pontos de contato ao longo do tempo | Detalhe de interface | Barato, e viável quando a experiência real é arriscada ou logisticamente complicada; exige ensaio | | **Wireframe navegável** | Renderizações de tela com navegação | Arquitetura de informação, navegação | Percepção de valor | Gera discussão sobre estética que não interessa agora | | **Alta fidelidade** | Aparência de produto final em *look and feel*, às vezes com funcionalidade básica. Em software, implica protótipo interativo capaz de dar uma experiência real | Percepção de valor, confiança, detalhe de interação, estética | Conceito (a pessoa já não critica o essencial) | Caro; e protótipo bonito demais inibe crítica | **Um princípio que atravessa a tabela.** Brown registra o caso de um executivo da Steelcase que, tomando um modelo em espuma bem detalhado pelo objeto real, destruiu ao sentar-se um protótipo de 40 mil dólares da cadeira Vecta. A conclusão dele: toda a tecnologia do mundo não serve de nada se for usada para criar protótipos refinados demais, detalhados demais e cedo demais. **"Prototipagem apenas o suficiente"** significa escolher sobre o que você quer aprender e alcançar resolução suficiente só para aquilo. Quem tem experiência sabe a hora de dizer "já basta". > ⚠️ **Correção específica da era da IA.** A facilidade de gerar alta fidelidade em minutos não é razão para pular a baixa. O motivo não é ideológico: é que **protótipo bonito muda o comportamento do participante e o da própria equipe**. Ninguém tem medo de dizer que um rabisco está errado; quase todo mundo hesita em dizer que uma tela acabada está errada. E, do lado da equipe, apego a um artefato caro é o que produz aquele item de debriefing que ninguém quer priorizar. Se a IA gerou alta fidelidade em dez minutos, isso é argumento a favor de **jogar fora e refazer**, não a favor de defender o que está lá. **Prototipar o que não se pega.** As mesmas regras valem para serviço, experiência virtual ou sistema organizacional. Brown: qualquer coisa tangível que permita explorar uma ideia, avaliá-la e empurrá-la adiante é um protótipo. Ele cita dispositivos sofisticados de injeção de insulina que começaram como Lego, interfaces de software esboçadas com notas adesivas antes de existir uma linha de código, e conceitos de agência bancária encenados diante do cliente contra um cenário de papelão preso com fita. ### Prototipagem paralela Vale citar quando a equipe está travada entre duas direções. Consiste em considerar **várias ideias simultaneamente** antes de escolher e refinar uma. Aplicada antes do design iterativo, evita que a equipe fixe cedo demais numa direção e suba morro acima rumo a um resultado inferior — crítica antiga ao design puramente iterativo. O procedimento: cada pessoa cria, rápido e **de forma independente**, protótipos de baixa fidelidade; depois todos vão a teste com usuários ou a avaliação heurística. Hanington & Martin fazem uma ressalva que muda o uso: **a intenção não é escolher o "melhor" ou o "preferido"**. É levar a equipe a refletir sobre como as pessoas reagem a elementos individuais de cada design e quais deles cumprem os objetivos do projeto — para depois refinar e **fundir** as melhores qualidades num design otimizado. O efeito colateral interessa a equipes de disciplina: quando vários designs são considerados lado a lado, fica mais difícil o autor se sentir na defensiva sobre um deles. Isso desloca a crítica **da pessoa para o design** e reduz a competição interna. **Ação:** escreva numa frase o que a rodada de teste precisa descobrir. Se a frase contém "se entendem o que é", construa papel. Se contém "se conseguem completar", construa navegável. Se contém "se confiam", só aí alta fidelidade. --- ## 2. Mágico de Oz Serve quando o *back-end* não existe — e é a técnica central para produtos com IA numa disciplina de um semestre. **O que é:** os participantes são levados a acreditar que estão interagindo com um protótipo funcional, mas na verdade **um pesquisador atua como procurador do sistema, nos bastidores**. Sem ser visto, ele intercepta e molda a interação, sem que exista sistema nenhum rodando. O objetivo é permitir que a pessoa experimente o produto proposto **antes** de protótipos caros serem construídos. O nome vem do filme de 1939 em que um homem comum se esconde atrás de uma cortina e usa tecnologia para convencer todos de que é um mago onipotente. O paradigma foi cunhado por John F. Kelly, do centro de pesquisa da IBM, em 1980. **A montagem:** participante numa sala, mago em outra. O mago precisa **observar a atividade do participante** — por vídeo ou compartilhamento de tela — para conseguir preparar uma resposta apropriada e no tempo certo. **Os três papéis que o mago pode assumir:** | Papel | O que faz | |---|---| | **Controlador** | Simula a inteligência do sistema | | **Supervisor** | Corrige o rumo e sobrepõe decisões que o sistema ou o participante tomam | | **Moderador** | Simula dados sensoriais e faz a experiência imaginada parecer completa | **A condição de validade, e é uma só:** a credibilidade das simulações depende do **comportamento consistente do mago quanto a tempo, padrões e lógica do sistema**. Um mago que responde em 2 segundos numa tarefa e em 20 na seguinte, ou que aplica um critério diferente do que aplicou antes, invalida a sessão — o participante está reagindo à inconsistência, não ao produto. **A trajetória ao longo do projeto:** nas fases iniciais, o mago simula a maior parte dos comportamentos do sistema. À medida que a interface é melhorada de forma iterativa, **cada vez menos intervenção é necessária** — só o suficiente para manter o processo andando e cobrir a distância entre o que já está implementado e o sistema imaginado. **Quando usar:** sempre que for preciso avaliar como as pessoas vão se sentir com uma solução proposta, e como se sairiam usando-a, antes de investir tempo e dinheiro num protótipo de verdade. É especialmente útil em aplicações digitais que **ainda não têm padrões de design estabelecidos**. Serve tanto nas fases exploratórias e conceituais quanto nas finais. **Ação:** se o seu produto depende de um modelo, escreva antes da sessão as **regras que o mago vai seguir** — tempo de resposta, formato da resposta, o que fazer diante de entrada fora do previsto. Ensaie uma vez com alguém da equipe. Declare na entrega que a rodada foi Mágico de Oz: declarar é mais forte que disfarçar. --- ## 3. Avaliação heurística É método de **inspeção informal de usabilidade**: avaliadores checam a interface contra um conjunto acordado de boas práticas — "regras de bolso" de usabilidade. É reconhecidamente um dos métodos de usabilidade de baixo custo de Jakob Nielsen, e o benefício é duplo: os usuários ganham um produto mais usável, e a organização gasta menos e ocupa menos gente. **Quem faz:** ao contrário do teste, que exige usuários reais, a avaliação heurística **convoca membros da própria equipe** — do programador iniciante ao profissional experiente de usabilidade — para inspecionar a interface e detectar os problemas de base que devem ser corrigidos **antes** de o teste com usuários começar. **O procedimento que define a qualidade do resultado:** avaliadores duplamente especialistas — que conhecem o domínio **e** usabilidade — tendem a ser os que mais identificam problemas, mas o método foi projetado para ser usado tanto por especialistas quanto por novatos treinados nas heurísticas. Para conter o viés que qualquer avaliador traz consigo, por causa da mentalidade ou da experiência dele, recomenda-se que **três a cinco avaliadores façam a avaliação de forma independente primeiro**, e só depois agreguem os achados num relatório único. **A independência antes da agregação é o método.** Sem ela, você tem uma reunião de opinião. **O que esperar, e o que não esperar.** O método **raramente vai revelar oportunidades de ruptura no design**. O que ele faz bem é detectar elementos de diálogo críticos que estão faltando, cedo no processo. Pode ser usado a partir do meio do processo — ou mesmo assim que existam protótipos de baixa fidelidade. **Como escrever o relatório:** liste quais problemas são inconsistentes com quais heurísticas, com bastante captura de tela e marcação. E inclua **também exemplos do que está funcionando bem**. Reportar os dois lados dá equilíbrio ao documento, reconhece o trabalho já feito e serve de motivação para continuar avaliando — o que importa numa equipe de disciplina, em que a rodada seguinte depende de as pessoas quererem participar. **Um efeito de segunda ordem que vale para a Q8:** conforme a equipe assiste a mais testes com usuários, ela tende a ficar melhor em detectar problemas nas avaliações heurísticas. Os dois métodos se alimentam. --- ## 4. Percurso cognitivo Avalia se **a ordem das pistas e dos comandos** num sistema reflete o modo como as pessoas processam a tarefa cognitivamente e antecipam o "próximo passo". É método de inspeção, criado no início dos anos 1990 por Peter Polson, Clayton Lewis, John Rieman e Cathleen Wharton, no Instituto de Ciência Cognitiva da Universidade do Colorado, apoiado numa teoria de aprendizagem exploratória. **Onde ele se aplica melhor:** situações em que instrução prévia, orientação ou treinamento **não vão acontecer** — em que a pessoa precisa se engajar ativamente com a interface para saber o que fazer em seguida, em vez de recorrer a conhecimento prévio do sistema. Ele é particularmente adequado a sistemas de "chegar e usar": caixas eletrônicos, máquinas de estacionamento e de bilhete de metrô, atendimento telefônico automatizado. **A montagem:** escolha uma série de tarefas representativas, **todas escritas do ponto de vista do usuário**, e descreva cada uma como uma sequência crível de passos de ação. O método então critica cada passo e avalia se ele é o passo certo no momento certo. Cada passo é julgado como algo que aproxima ou afasta a pessoa do objetivo dela. **As quatro perguntas, feitas para cada passo da sequência:** 1. **O usuário vai querer produzir o efeito que essa ação produz?** 2. **O usuário vai ver o controle** — botão, menu, rótulo — **para essa ação?** 3. **Uma vez que o encontre, ele vai reconhecer que aquele controle produz o efeito que ele quer?** 4. **Depois de executada a ação, o usuário vai entender o feedback que recebeu**, de modo a seguir com confiança para a ação seguinte? Ao avaliar cada passo com essas quatro perguntas, a equipe consegue decidir **qual sequência cria menos obstáculos** para o usuário. **A relação com as sete fases de Norman é direta**, e vale explicitar na apresentação: a pergunta 1 é a fase de objetivo; a 2 e a 3, o Golfo da Execução; a 4, o Golfo da Avaliação. Ver `diagnostico-de-erro.md`. --- ## 5. Por que inspeção não substitui usuário | | Inspeção (heurística, percurso cognitivo) | Teste com usuário | |---|---|---| | Quem | 3 a 5 avaliadores da equipe, trabalhando **independentemente** antes de agregar | Participantes reais, três por rodada | | Contra o quê | Um conjunto de heurísticas acordadas, ou quatro perguntas por passo | Tarefas reais, comportamento observado | | Quando | **Antes** de trazer usuários — limpa o básico e torna o teste mais eficaz | Continuamente | | Acha | Violações de princípio; elementos de diálogo faltantes | O que de fato confunde e frustra | | Não acha | O que ninguém da equipe consegue deixar de saber | Violações de princípio que não apareceram nas tarefas testadas | Hanington & Martin dão os dois argumentos, e eles não se anulam: - **A favor da inspeção:** não se pode supor que haverá usuários disponíveis para testar cada passo do processo iterativo. Revisões por especialistas, como o percurso cognitivo, garantem **melhor uso do tempo dos participantes** — quando eles chegam, os problemas óbvios já foram removidos. - **A favor de usar os dois:** percursos cognitivos e testes de usabilidade tendem a revelar **classes diferentes** de problema de design e de usabilidade. Usá-los **juntos, em vez de um no lugar do outro, é sempre recomendado**. Há ainda o argumento de Krug, do outro lado: **você é a pior pessoa para avaliar a usabilidade do que construiu.** Inspeção feita pela equipe está sujeita a isso; é justamente por isso que ela vem antes e não no lugar. **Ação para a Q8:** faça a inspeção **uma semana antes** do teste, com três pessoas da equipe avaliando separado. Conserte o que couber. Leve ao usuário a versão limpa. Registre as duas listas na entrega — as violações que vocês acharam sozinhos e os problemas que só apareceram com gente de fora. A diferença entre as duas listas é uma das evidências mais fortes que a Q8 pode apresentar. --- ## 6. Microinterações com propósito Vale a seção porque toda equipe, na Q8, gasta tempo em animação, e porque animação mal calibrada aparece no teste como problema de Golfo da Avaliação. **O critério de aceitação, e é um só:** > **Nenhuma animação de interface deveria chegar ao produto final sem que se saiba qual é o propósito dela.** Val Head propõe o exercício operacional: **desafie-se a articular um propósito para cada animação**, para avaliar quão úteis elas são. O propósito pode ser tático — dar feedback — ou de marca — expressar personalidade. **Se não há propósito definível, considere eliminar ou redesenhar** a animação para que ela tenha um propósito e um objetivo sólidos. **As três regras que evitam que a animação vire problema no teste:** | Regra | O que significa | Por quê | |---|---|---| | **Não bloqueante, por padrão** | A animação aceita e responde à entrada do usuário **em qualquer ponto** da sua execução. Animação interrompível é animação não bloqueante | Animação que ignora a entrada enquanto roda impede a pessoa de usar a interface para a tarefa pretendida, e faz o produto parecer quebrado ou lento. Head compara a uma conversa: se a outra pessoa não responde ao que você disse, você para de confiar nela | | **Duração entre 200 ms e 500 ms** | Transições pequenas, com poucos elementos ou pouca mudança, ficam na faixa de 200 a 350 ms. Movimentos maiores, que cobrem muito espaço ou usam transições complexas, sobem para 400 a 500 ms | Head alerta contra as duas simplificações opostas: nem "toda animação de interface tem de ser rapidíssima", nem uma duração única fixa aplicada a tudo. Bom timing é mais arte que ciência — pense em diretriz, não em regra fixa | | **O tamanho da animação combina com o tamanho da tarefa** | Movimento exagerado só onde a tarefa é importante | Head cita o botão de salvar do CodePen, que começa a pulsar depois de cerca de um minuto sem salvar. O exagero seria excessivo em outro contexto; ali, **o volume visual do movimento corresponde à importância da tarefa** | **Uma quarta, quando a animação existe para orientar:** a direção do movimento pode guiar o olho pela hierarquia do conteúdo. Head descreve o padrão do Pinterest, em que a miniatura desliza para dentro do modal a partir da posição que ocupava na grade, e volta ao mesmo lugar ao fechar — o que ajuda a pessoa a **não perder de vista** com qual item ela está interagindo. E o encadeamento: quando a segunda animação começa exatamente onde a primeira terminou, fica mais fácil acompanhar o fluxo de informação. **Como usar isso no debriefing:** microinteração é o item típico da lista separada de fruta baixa (ver `teste-de-usabilidade.md`). Ela raramente é o problema mais grave; ela quase sempre é uma correção de menos de uma hora. Não deixe competir com o que é grave. --- ## Fontes - **Hanington, Bruce & Martin, Bella**, *Universal Methods of Design* — método 13 (Cognitive Walkthrough): origem, aplicação e as quatro perguntas por passo; método 36 (Experience Prototyping): encenação e protótipos de experiência; método 46 (Heuristic Evaluation): quem avalia, os três a cinco avaliadores independentes, o que o método acha e o que não acha, como escrever o relatório; método 58 (Parallel Prototyping): o procedimento e os efeitos sobre a equipe; método 66 (Prototyping): fidelidades, protótipo de papel, o contínuo; método 99 (Wizard of Oz): origem, montagem, os três papéis do mago, a condição de consistência - **Krug, Steve**, *Não me faça pensar* — o argumento de que quem constrói é a pior pessoa para avaliar - **Brown, Tim**, *Change by Design* — "prototipagem apenas o suficiente", o caso da cadeira Vecta, prototipar o que não se pega - **Head, Val**, *Designing Interface Animation* — cap. 3: animação bloqueante e não bloqueante, a faixa de 200–500 ms, o alerta contra a duração única; cap. 5: a direção do movimento e o pareamento entre volume da animação e tamanho da tarefa; cap. 9 e 10: a auditoria de movimento, articular o propósito de cada animação e a regra de não levar ao produto animação sem propósito conhecido - **Nielsen, Jakob** — autor das heurísticas e do conjunto de métodos de usabilidade de baixo custo, conforme atribuído por Hanington & Martin - **Kelly, John F.** (IBM, 1980) — o paradigma "Oz", conforme registrado por Hanington & Martin - **Polson, Lewis, Rieman & Wharton** (Universidade do Colorado, início dos anos 1990) — o percurso cognitivo # Teste de usabilidade — Quest #8 Abra este arquivo na semana em que a equipe vai testar: quando já existe algo a mostrar e ainda falta decidir quem chamar, o que dizer e o que fazer com o que aparecer. Ele cobre a sessão inteira, do recrutamento à decisão do que consertar. O modo de IA aqui é 🔴 **sem assistência** durante a sessão. A IA pode ajudar antes (montar o roteiro, revisar o texto das tarefas) e depois (organizar as notas do debriefing). Ela não facilita, não observa e não interpreta no lugar de quem esteve na sala. --- ## 1. O que você está montando, e o que ele custa O teste que a Q8 pede é o **teste feito pela própria equipe** — a versão barata, mensal, sem laboratório. Vale saber de onde ela vem, porque a diferença explica por que três participantes bastam. | | Teste tradicional | Teste da própria equipe | |---|---|---| | Tempo por rodada | 1–2 dias de teste, mais uma semana de relatório | **Uma manhã**: testar, almoçar, decidir | | Quando | Quando o site está quase pronto | Continuamente, durante todo o desenvolvimento | | Rodadas | Uma ou duas por projeto | **Uma por mês** | | Participantes | Oito ou mais | **Três** | | Recrutamento | Criterioso, perfil exato | **Solto, se necessário** | | Quem identifica os problemas | Quem conduziu o teste, num relatório | **A equipe inteira**, no almoço do mesmo dia | | Relatório | 25 a 50 páginas | E-mail de 1 a 2 páginas com as decisões | | Propósito | Achar o máximo de problemas e priorizá-los por severidade | **Achar os mais graves e se comprometer a consertá-los** antes da próxima rodada | Krug registra a genealogia: até 1989 um teste custava de 20 a 50 mil dólares e exigia laboratório com espelho falso. O artigo de Jakob Nielsen *Usability Engineering at a Discount* derrubou isso para 5 a 10 mil. A versão que você vai fazer custa algumas centenas de reais ou menos por rodada. > ⚠️ **Sobre a palavra "participante".** Krug é explícito: chamamos de **participante**, e não de "sujeito de teste", para deixar claro que **não estamos testando a pessoa** — estamos testando o produto. Não é preciosismo de vocabulário: a palavra que você usa entre a equipe vaza para a fala do facilitador, e o participante percebe. **Infraestrutura mínima:** uma sala silenciosa em que ninguém interrompa (uma sala de aula vazia serve), mesa, duas cadeiras, um computador com internet, mouse, teclado e microfone. Uma segunda sala para os observadores, com projetor ou monitor grande e som. Software de compartilhamento de tela para transmitir, e software de gravação de tela para registrar o que aconteceu e o que foi dito. Você pode nunca reassistir; é bom ter para conferir um detalhe ou recortar 30 segundos para a apresentação. **A cadência:** dia fixo do calendário — a terceira quinta-feira, por exemplo —, não a uma etapa do cronograma. Cronograma escorrega, e teste amarrado a cronograma escorrega junto. Sempre haverá alguma coisa para testar. **Ação:** antes de recrutar, reserve a sala e marque a data no calendário compartilhado da equipe. Data primeiro, participante depois — a ordem inversa é a que faz o teste não acontecer. --- ## 2. Recrutar solto e corrigir na leitura Equipes gastam tempo demais atrás do perfil exato — "homens contadores de 25 a 30 anos com um a três anos de experiência com computador". Recrutar exatamente do público-alvo **não é tão importante quanto parece**: se você está começando a testar, o produto provavelmente tem falhas que travam quase qualquer pessoa. A regra de Krug é curta: **recrute solto, e corrija na hora de interpretar.** Na prática: procure pessoas que reflitam o seu público, mas não trave nisso. Afrouxe os requisitos e faça a compensação depois. Quando alguém tiver um problema, a pergunta é *"os nossos usuários teriam esse problema, ou foi problema só porque essa pessoa não sabe o que eles sabem?"* **Quando você precisa de conhecimento de domínio** — um sistema para técnicos de laboratório, um app para agentes de saúde —, você precisa de **alguns** participantes com esse conhecimento. Não de todos. E há um argumento a favor de **sempre incluir alguém de fora do público-alvo**: 1. Projetar de modo que só o público-alvo consiga usar costuma ser má ideia. Se você escreve para gestores financeiros usando o jargão que acha que todo gestor financeiro entende, vai descobrir que uma parcela pequena mas não desprezível deles não entende. E na maioria dos casos você precisa atender novatos além de especialistas. 2. **Somos todos iniciantes por baixo da pele.** Arranhe um especialista e você acha alguém se virando — só que num nível mais alto. 3. **Especialistas raramente se ofendem com algo que está claro o bastante para iniciantes.** Todo mundo aprecia clareza — clareza de verdade, não simplificação. ### Onde achar participantes Krug lista: grupos de usuários, feiras e eventos do setor, classificados online, redes sociais, fóruns de clientes, um convite na própria página do produto, e até amigos e vizinhos. Traduzindo para o CIn: | Fonte | Serve para | Cuidado | |---|---|---| | O lugar onde você fez a observação da Q1 | O perfil mais próximo do real | Combine com quem te recebeu; não apareça sem avisar | | Grupos e comunidades do domínio (associações, coletivos, grupos de mensagem) | Usuários afoitos que já têm a dor | Peça a um administrador do grupo para apresentar | | Contatos de primeiro grau que se encaixam no perfil, e as indicações deles | Começar rápido | Registre o grau de proximidade na entrega | | Outros cursos do campus, funcionários, terceirizados | O "alguém de fora do público-alvo" | Não use como base inteira | | Serviços de teste remoto não moderado | Ver alguém pensando alto em uma hora | Você não interage; sem sondagem | **Incentivo.** Krug relata a faixa praticada no mercado americano: de 50 a 100 dólares por sessão de uma hora para usuários médios, e várias centenas para profissionais caros e ocupados. Ele recomenda pagar um pouco acima da praxe, porque deixa claro que você valoriza o tempo da pessoa e aumenta a chance de ela aparecer — e lembra que, mesmo numa sessão de uma hora, a pessoa normalmente gasta outra hora se deslocando. Num projeto de disciplina não há orçamento equivalente; o que existe é o reconhecimento do custo real. Ofereça o que for possível e digno (lanche, vale-transporte, crédito na entrega, acesso antecipado) e **combine antes**, não na hora. **Ação:** monte uma lista de dez nomes ou grupos concretos com forma de contato. Chame seis para conseguir três. --- ## 3. O roteiro, minuto a minuto Uma hora, dividida assim: | Etapa | Tempo | O que acontece | |---|---|---| | Boas-vindas | 4 min | Explicar como funciona, para a pessoa saber o que esperar | | Perguntas sobre a pessoa | 2 min | Deixa à vontade e revela familiaridade com tecnologia | | Tour da tela inicial | 3 min | "Olhe e me diga o que você entende disto" — **sem clicar** | | **As tarefas** | **35 min** | O coração: executar pensando em voz alta | | Sondagem | 5 min | Perguntas sobre o que aconteceu, inclusive as da sala de observação | | Fechamento | 5 min | Agradecer, pagar/entregar o combinado, acompanhar até a porta | Krug recomenda **ler as falas exatamente como escritas**, porque a redação foi escolhida com cuidado. O que segue é a tradução das falas do roteiro dele para o português; adapte os nomes, não a estrutura. ### Abertura - *"Oi, [nome]. Meu nome é [seu nome], e eu vou te acompanhar nesta sessão. Antes de começar, tenho algumas informações para você, e vou ler para ter certeza de que não esqueço nada."* - *"Você provavelmente já tem uma ideia de por que a gente te chamou aqui hoje, mas deixa eu repassar rapidinho. Estamos testando um produto em que estamos trabalhando, para ver como é usá-lo. A sessão deve levar cerca de uma hora."* - *"Quero deixar claro desde já que **estamos testando o produto, não você**. Você não pode fazer nada errado aqui. Na verdade, este é provavelmente o único lugar hoje em que você não precisa se preocupar em errar."* - *"A gente quer ouvir exatamente o que você pensa, então, por favor, não se preocupe em ferir os nossos sentimentos. A gente quer melhorar isto, então precisa saber honestamente o que você acha."* - *"Conforme a gente for andando, vou te pedir para pensar em voz alta, para me dizer o que está passando pela sua cabeça. Isso ajuda muito."* - *"Se você tiver perguntas, é só perguntar. Talvez eu não consiga responder na hora, porque a gente quer saber como as pessoas se viram quando não tem ninguém do lado para ajudar, mas eu vou tentar responder qualquer pergunta que ainda ficar no fim."* - *"E se você precisar de uma pausa em algum momento, é só falar."* - *"Você deve ter visto o microfone. Com a sua permissão, vamos gravar o que acontece na tela e o que você fala. A gravação vai ser usada só para nos ajudar a melhorar o produto, e não vai ser vista por ninguém além de quem trabalha no projeto. Também me ajuda, porque assim eu não preciso fazer tanta anotação."* - *"Também tem algumas pessoas da equipe acompanhando a sessão de outra sala. Elas não veem a gente, só a tela."* - *"Se você puder, vou te pedir para assinar um termo de autorização simples. Ele só diz que você nos autoriza a gravar, e que a gravação só será vista por quem trabalha no projeto."* - *"Você tem alguma pergunta antes de a gente começar?"* O ponto sobre as perguntas é o que mais se esquece. Krug explica por quê: **é importante avisar antes que você não vai responder na hora**, porque não responder pareceria grosseria. Você tem de deixar claro que (a) não é nada pessoal e (b) você tenta responder no fim, se a dúvida ainda existir. ### Perguntas sobre a pessoa Duas ou três, curtas: qual é a sua ocupação, o que você faz durante o dia; quantas horas por semana você passa na internet, mais ou menos; que tipo de site ou aplicativo você costuma usar. **A precisão da resposta não importa.** O objetivo é fazer a pessoa começar a falar, e mostrar que você vai escutar com atenção e que não há resposta certa ou errada. Duas atitudes que Krug recomenda aqui: **não hesite em admitir que você não conhece algo** que a pessoa mencionou — seu papel não é parecer especialista, é ser bom ouvinte —, e **não tenha medo de uma digressão curta**, desde que você volte ao assunto logo. ### Tour da tela inicial *"Primeiro, vou só pedir para você olhar para esta tela e me dizer o que você entende disto: o que te chama atenção, de quem você acha que é, o que dá para fazer aqui, para que serve. Só olhe e vá narrando um pouco. Você pode rolar a tela se quiser, mas não clique em nada ainda."* Deixe o navegador aberto em algo neutro até esse momento; abra a tela do produto na hora e passe o mouse para a pessoa. ### As tarefas **Escolha tarefas, não telas.** *"Encontre um grupo de corrida no seu bairro e entre nele"* é tarefa. *"Veja a tela de grupos"* não é. Escreva cada tarefa com cuidado, incluindo toda a informação que a pessoa vai precisar e não tem — login de conta de demonstração, por exemplo. E **prefira tarefas em que a pessoa escolha parte dos detalhes**: *"encontre um livro que você queira comprar, ou um que você comprou recentemente"* rende mais que *"encontre um livro de culinária abaixo de R$ 40"*, porque aumenta o investimento emocional e deixa a pessoa usar o conhecimento dela sobre o conteúdo. Escolha tarefas suficientes para preencher os 35 minutos, lembrando que algumas pessoas terminam mais rápido do que você espera. Deixe cada tarefa correr até que (a) a pessoa termine, (b) ela fique realmente frustrada, ou (c) você pare de aprender algo novo observando. **O que dizer quando a pessoa silencia:** *"No que você está pensando?"*. Para variar: *"O que você está olhando?"*, *"O que você está fazendo agora?"*. **O que dizer quando pedem ajuda:** *"O que você faria se eu não estivesse aqui?"*. ### Sondagem É aqui, e só aqui, que entram as perguntas investigativas: sobre o que aconteceu, por que a pessoa ignorou determinado elemento, o que ela esperava que acontecesse. Inclua as perguntas que a sala de observação mandou. Guardar essas perguntas para o fim é justamente o que impede que elas enviesem as tarefas. ### Fechamento Agradeça, entregue o combinado, acompanhe até a porta. --- ## 4. O que o facilitador pode e não pode **Quem facilita.** Quase qualquer pessoa consegue, e melhora com prática. Se você vai escolher outra pessoa, escolha alguém **paciente, calmo, empático e bom ouvinte**. Krug é direto sobre quem não escolher: quem você descreveria como "não é muito de gente" ou "o rabugento da sala". **A função principal do facilitador**, além de manter a pessoa confortável e concentrada nas tarefas, é **encorajá-la a pensar em voz alta o máximo possível**. É a combinação de ver o que ela faz com ouvir o que ela pensa enquanto faz que permite aos observadores enxergar o produto pelos olhos de outra pessoa. | Pode | Não pode | |---|---| | Ler as falas do roteiro como escritas | Improvisar a abertura | | *"No que você está pensando?"* | *"Você não achou confuso aquele botão?"* (indutora) | | *"O que você faria se eu não estivesse aqui?"* | *"Tenta clicar no menu de cima."* | | Admitir que não conhece algo que a pessoa citou | Explicar o produto durante as tarefas | | Digredir um pouco nas perguntas iniciais | Digredir durante as tarefas | | Ficar em silêncio enquanto a pessoa se vira | Preencher o silêncio | A regra dura: > **Não faça perguntas indutoras, e não dê nenhuma pista ou ajuda, a menos que a pessoa esteja irremediavelmente travada ou extremamente frustrada.** --- ## 5. A sala de observação **Quantos observadores? Quantos couberem.** Um dos efeitos mais valiosos do teste é sobre quem assiste: para muita gente é uma experiência que muda de forma dramática o modo de pensar sobre usuários — a pessoa de repente **entende** que os usuários não são todos como ela. Krug recomenda gastar o pouco dinheiro que houver em comprar comida boa para atrair gente para a sala. Na Q8 isso tem uma consequência específica: **quem escreveu o código precisa assistir.** Ler o relatório não produz o mesmo efeito. **A regra que faz o debriefing funcionar:** no intervalo depois de cada sessão, **cada observador escreve os três problemas mais sérios** que notou naquela sessão. Podem anotar o que quiserem além disso, mas a lista curta de três é obrigatória. Com três sessões, cada observador chega ao debriefing com nove problemas anotados e três para dizer em voz alta. Além disso, a sala de observação manda perguntas para o facilitador fazer no bloco de sondagem. Combine o canal antes (um grupo de mensagens serve). --- ## 6. O debriefing, em quatro passos **Quando:** logo depois, no mesmo dia, com tudo fresco. Krug faz no almoço. **Por que ele existe.** Problemas sérios aparecem sempre — mas não são os que acabam consertados. Ou alguém diz "essa parte vai mudar mesmo, dá para conviver até lá", ou, diante da escolha entre um problema grave e vários simples, a equipe escolhe os simples. É por isso que sites grandes e bem financiados continuam tendo problemas graves. > **Foque implacavelmente em consertar primeiro os problemas mais sérios.** O método: 1. **Lista coletiva.** Cada pessoa diz os três problemas mais sérios que observou. Escreva tudo num quadro. Repetição vira um tique ao lado do item. **Sem discussão nesta etapa** — você está só listando. E só valem **problemas observados**: coisas que de fato aconteceram numa das sessões. Opinião sobre o design não entra. 2. **Escolher os dez mais sérios.** Pode haver votação informal, mas normalmente basta começar pelos que receberam mais tiques. 3. **Ordenar de 1 a 10**, sendo 1 o pior. Copie para uma lista nova, com o pior no topo e espaço entre os itens. 4. **Lista acionável.** Do topo para baixo, escreva para cada um: uma ideia grosseira de **como** consertar no próximo mês, **quem** faz, e **que recursos** exige. ### As regras de parada São duas, e as duas são contraintuitivas: - **Você não precisa consertar cada problema perfeitamente nem completamente.** Basta fazer algo — muitas vezes um ajuste pequeno — que tire aquilo da categoria de "problema sério". - **Quando você tiver alocado todo o tempo e os recursos disponíveis no próximo mês, PARE.** Você já conseguiu o que veio buscar: o grupo decidiu o que precisa ser consertado e se comprometeu a consertar. Numa disciplina de um semestre, a segunda regra é a que mais importa, porque a Q9 já está chegando e o cronograma dela precisa caber no que sobrou. --- ## 7. As quatro armadilhas do debriefing | Armadilha | O que acontece | O que fazer | |---|---|---| | **Fruta baixa competindo com o que é grave** | Coisas triviais entram na lista principal e consomem a cota do mês | Mantenha uma **lista separada** de coisas fáceis. "Fácil" = uma pessoa resolve em menos de uma hora, sem precisar de autorização de ninguém que não esteja no debriefing | | **O impulso de acrescentar** | O usuário não entendeu, e o reflexo da equipe é adicionar explicação, instrução, tooltip | Muitas vezes a solução certa é **tirar** o que está obscurecendo o sentido, em vez de acrescentar mais uma distração | | **Pedido de funcionalidade levado a sério demais** | "Eu gostaria mais se ele fizesse X" vira item de backlog | Peça, na sondagem, que a pessoa descreva como a funcionalidade funcionaria. Quase sempre ela mesma conclui: "mas agora que eu penso, eu provavelmente não usaria". **Participantes não são designers.** Quando a ideia é boa de verdade, você reconhece na hora — seu primeiro pensamento é "por que não pensamos nisso?" | | **Problema de caiaque** | A equipe registra desvios momentâneos como se fossem falhas graves | Ignore quando as três condições valem: a pessoa percebe rápido que saiu do caminho, se recupera sozinha, e não se abala. Se o **segundo palpite** dela sobre onde achar as coisas está sempre certo, está bom o bastante | --- ## 8. Os três tipos de problema mais frequentes Krug lista os que aparecem com mais regularidade. Use como grade de codificação ao escrever o resultado — ela dá o vocabulário que falta quando a equipe só sabe dizer "acharam confuso". | Tipo | Sinal na sessão | Direção do conserto | |---|---|---| | **A pessoa não entende o conceito** | Olha a tela e não sabe o que fazer daquilo, ou acha que sabe e está errada | Modelo conceitual, vocabulário, primeira tela (ver `diagnostico-de-erro.md`) | | **As palavras que ela procura não estão lá** | Varre a tela procurando um termo que você não usou | Ou você não antecipou o que ela procuraria, ou as palavras que você usa não são as que ela usaria | | **Há coisa demais acontecendo** | O alvo está na tela e ela não vê | Reduzir o ruído geral, ou aumentar o volume do que precisa ser visto, para que ele salte na hierarquia visual | --- ## 9. Duas coisas que este teste não mede **Não mede desejo.** Krug é explícito: ele fica desconfortável quando ouvem falar em usar teste de usabilidade para determinar se algo é **desejável**, porque não é isso que esse teste mede. Você pode ter uma *sensação*, durante a sessão, de que a pessoa achou aquilo desejável — mas é só isso, uma sensação. Desejabilidade é pergunta de pesquisa de mercado, respondida com instrumentos de pesquisa de mercado. > ⚠️ Isso tem efeito direto na entrega da Q8. A pergunta 1 da quest — *"as pessoas se mostraram motivadas a usar o protótipo?"* — **não é respondida pelo teste de usabilidade**. Responda-a com o que você tem de outra natureza: quantas pessoas pediram para continuar usando, quantas aceitaram entrar na base de testes da Q9, quantas indicaram outra pessoa. Declarar que a evidência de motivação vem de outra fonte é mais forte que fingir que o teste mediu isso. **Não prova nada.** É método qualitativo: você dá tarefas, observa e aprende. O resultado são **insights acionáveis, não prova**. Provar exigiria teste quantitativo, amostra grande, protocolo rígido e análise. Se a banca ou o mentor perguntar "três pessoas provam alguma coisa?", a resposta correta não é defender a amostra — é dizer que a rodada não pretendia provar, e mostrar o que mudou no produto por causa dela. --- ## Fontes - **Krug, Steve**, *Não me faça pensar* (*Don't Make Me Think, Revisited*), cap. 9 — todo o método: a tabela tradicional × faça-você-mesmo, a cadência mensal, os três participantes, "recrute solto e corrija na leitura", onde achar e quanto pagar, a infraestrutura, o roteiro minuto a minuto e as falas, os três tipos de problema, o debriefing em quatro passos, as regras de parada, as quatro armadilhas; cap. 13 — o que o teste não mede - **Krug, Steve**, *Rocket Surgery Made Easy* — livro dedicado ao procedimento, citado por ele como a versão detalhada do capítulo 9; é de lá que vem a máxima sobre consertar primeiro o mais sério - **Nielsen, Jakob**, "Usability Engineering at a Discount", 1989 — a origem do teste barato, referida por Krug - **Hanington & Martin**, *Universal Methods of Design*, método 87 (Think-aloud Protocol) — as duas variantes do pensar em voz alta e o alerta de focar no *o quê* e não no *porquê* durante a tarefa --- # Quest #9 — Plano de Projeto > **Objetivo.** Apresentar o plano de implementação do MVP. | | | |---|---| | **Modo de IA** | 🟢 coprodução no cronograma · 🔴 sem assistência nas estimativas de duração e na base de testes | | **Milestone** | **Plano de projeto** | | **Entrega** | cronograma com responsáveis, caminho crítico e base de testes | | **Erro que mais custa** | estimar em horas e planejar tudo no início | --- ## Duas entregas, não uma Os preparativos e a visão panorâmica do processo de execução. É vital estimar prazos e organizar a produção para que o produto esteja pronto até o Demoday — **e** elaborar como a equipe vai estimular uma base de usuários afoitos. A segunda é a que as equipes esquecem, e é a que aparece vazia no Demoday. --- ## Por que estimar em horas falha Três argumentos encadeados: **1. O cone da incerteza.** As estimativas iniciais de trabalho variam de **400% acima** do tempo real até **25% dele** — os extremos diferem por um fator de dezesseis. Conclusão: planejar tudo no início é inútil. Refine ao longo do projeto, detalhando só o próximo incremento de valor. **2. Somos péssimos em absoluto, bons em relativo.** Humanos são terríveis em estimar valores absolutos, mas bons em **dimensionamento relativo** — comparar um tamanho a outro. **3. Quem estima tem de ser quem executa.** Uma empresa entregou a estimativa de 80 projetos multimilionários aos "melhores estimadores" e teve de abortar o experimento na metade: as estimativas eram tão erradas que se tornaram inúteis, e nada foi entregue no prazo. **Só quem faz o trabalho sabe quanto tempo e esforço ele exige.** ### Estimativa relativa O exemplo canônico usa raças de cachorro: dachshund = 1, buldogue = 3, pastor-alemão = 5, dogue alemão = 13. Ninguém sabe dizer "quantos quilos", mas todos concordam na ordem. Há uma regra operacional embutida: **se um item é grande demais, quebre-o.** O dogue alemão vira dois buldogues mais um pastor-alemão. ### Por que Fibonacci 1, 3, 5, 8, 13 — cada número é a soma dos dois anteriores. O argumento é **perceptual**: > Os números da sequência estão suficientemente distantes para que consigamos perceber a diferença. Mas a diferença entre um cinco e um seis? É sutil demais para o nosso cérebro registrar. > > — Jeff Sutherland, *Scrum* Reforço clínico: para um paciente **perceber** melhora de sintoma, ela precisa ser maior que 65%. E o fecho: Fibonacci permite estimativas que **não precisam ser 100% exatas** — o valor está em todos usarem a mesma régua e formarem consenso. --- ## Planning poker — o procedimento É o método Delphi acelerado. Delphi remove viés mas é lento demais para centenas de itens. 1. Cada pessoa tem um baralho com números de Fibonacci. 2. O item a estimar vai à mesa. 3. Todos escolhem uma carta e a põem **virada para baixo**. 4. Todos viram **ao mesmo tempo**. 5. **Se todos estão dentro de duas cartas** (ex.: um 5, dois 8 e um 13): somam, tiram a média, e passam ao próximo item. 6. **Se a distância é maior que três cartas**: quem votou o maior e quem votou o menor **explicam o raciocínio**. Só então há nova rodada. O objetivo do passo 3–4 é evitar **ancoragem** — efeito manada e efeito halo. E o valor do passo 6 é o conhecimento compartilhado: no exemplo do livro, quem votou 3 achava que havia pouca parede; quem votou 13 lembrou do tempo de fitar armários e pintar de pincel. Nova rodada: o 3 virou 8. --- ## Velocity — como prever a data **Cálculo:** rode a primeira sprint. Ao final, conte as histórias **completas**, some os pontos delas. Esse número é a velocity. **Previsão:** com a velocity, olhe quantas histórias restam e quantos pontos representam. > **Velocity × Tempo = Entrega.** — Jeff Sutherland **Consequência para a Q9:** velocity só existe **depois de ao menos uma sprint fechada**. Logo, o cronograma até o Demoday deve ser **recalculado a cada sprint** — a linha de base sem dado real é ficção. O instrumento de visualização é o gráfico de burndown: pontos levados para a sprint num eixo, dias no outro, atualizado diariamente. --- ## Caminho crítico "Atividades mais críticas" não significa "mais importantes". Significa: **as que, se atrasarem, atrasam tudo o mais.** 1. Liste as atividades e o que cada uma precisa que exista antes. 2. Estime a duração de cada uma. 3. Encontre a **sequência mais longa de dependências** até o Demoday. Essa é o caminho crítico. 4. O que está nela não tem folga. O que está fora tem — e pode ser sacrificado sem mover a data. Em projeto de semestre, o caminho crítico quase sempre passa por: a parte técnica mais arriscada, a **integração entre partes feitas por pessoas diferentes**, e a **aquisição dos primeiros usuários**. As duas últimas são subestimadas com regularidade. --- ## Tamanho de equipe e o custo da comunicação **Sete pessoas, mais ou menos duas.** Acima de nove, a velocidade **cai** — mais gente faz o time ir mais devagar. **Lei de Brooks:** acrescentar gente a um projeto atrasado o atrasa mais. Duas causas: o tempo de trazer o novato ao ritmo, e a explosão de canais de comunicação. > **Canais = n(n−1)/2.** Cinco pessoas geram 10 canais; sete geram 21; nove geram 36; dez geram 45. Dado empírico: num levantamento de 491 projetos, grupos de **3 a 7 pessoas exigiram cerca de 25% do esforço** de grupos de 9 a 20 para o mesmo trabalho. **Se a turma impõe equipe grande** — que é o caso do Projetão —, a saída não é reclamar: é **subdividir em frentes com dono**, mantendo cada frente pequena e multifuncional. Sem isso, o time se quebra socialmente em subgrupos que trabalham com propósitos cruzados, a multifuncionalidade se perde, e reuniões de minutos viram reuniões de horas. --- ## O custo real da multitarefa | Projetos simultâneos | % do tempo por projeto | Perda por troca de contexto | |---|---|---| | 1 | 100% | 0% | | 2 | 40% | **20%** | | 3 | 20% | **40%** | | 4 | 10% | **60%** | | 5 | 5% | **75%** | > A coluna de perda é desperdício puro: com cinco projetos, 75% do trabalho não vai a lugar nenhum. **O exercício que prova, e cabe em cinco minutos de aula:** escreva 1–10, I–X e A–L. Fazendo por **linhas** (trocando de contexto a cada símbolo) leva cerca de 39 segundos; fazendo por **colunas** (um bloco de cada vez), 19 — metade. E o resultado num time real: três projetos tocados ao mesmo tempo terminam no fim de julho; conduzidos **um por vez até o fim**, terminam no começo de maio. **Trabalho pela metade é igual a zero.** Se algo está pela metade no fim da sprint, você está pior do que se não tivesse começado — teria sido melhor criar algo menor que realmente funcione. --- ## O que significa "pronto" Duas definições, e elas não competem — encaixam. **A barra de engenharia.** *Pronto* é um padrão de qualidade **acordado antes**, embutido no item de trabalho, não checado no fim. Todo mundo sabe quando algo está pronto porque há critério claro. Embutir conformidade em cada item, em vez de descobrir a não-conformidade no fim, elimina boa parte do retrabalho. Exija o par **Pronto para começar** e **Pronto**: histórias verdadeiramente prontas para começar dobram a velocidade; histórias verdadeiramente prontas ao fim da sprint dobram de novo. **Só demonstre o que atende à definição de pronto.** **A barra de aprendizado.** Numa startup enxuta, **uma funcionalidade só está "pronta" quando produz aprendizado validado com clientes.** Definir assim restringe ainda mais o funil: você não trabalha em nada novo sem provar que o que acabou de sair produziu aprendizado. **Como conciliar num semestre.** Use **Pronto = padrão técnico atendido + validação qualitativa** — é o que libera o item e mantém o ritmo. A verificação quantitativa fica como estado posterior, porque leva tempo demais para caber numa sprint curta. --- ## Limite de trabalho em progresso > **Comece com um limite de trabalho em progresso igual ao número de pessoas do time.** Três pessoas, três frentes em andamento. Isso maximiza a vazão e minimiza desperdício. E conecta com a tabela da multitarefa: o limite existe para impedir a equipe de se auto-sabotar. Complementos do quadro: - **Só entram itens que entregam valor ao usuário.** O teste: *você anunciaria isso aos usuários num informe?* Se é pequeno demais para mencionar, vai para um quadro de tarefas à parte, não para o quadro principal. - **Metas no topo do quadro**, para a priorização ser óbvia a todos. - **Faixas de espera**: cada etapa se divide em "em andamento" e "concluído, aguardando ser puxado". - **Itens podem ser mortos em qualquer estágio.** --- ## Planejar num prazo que não se move A data do Demoday é fixa. Isso muda a natureza do plano: **o escopo é a variável, não o prazo.** - **Fatie por valor entregue**, não por camada técnica. "Backend pronto" não é entregável — ninguém pode usar. "O usuário consegue se cadastrar e entrar num grupo" é. - **Tenha uma versão apresentável desde cedo.** Se a partir da metade a equipe puder mostrar algo que funciona em qualquer semana, o risco de chegar ao Demoday sem nada cai muito. - **Deixe folga explícita na última semana** — não para trabalhar: para ensaiar, gravar vídeo, imprimir material e consertar o que quebrar. - **Marque o congelamento de escopo.** Uma data a partir da qual não entra funcionalidade nova. - **Integre cedo e com frequência.** Quem integra uma vez por semana descobre o erro de integração na semana; quem integra na véspera do Demoday descobre na véspera. --- ## As perguntas da entrega 1. **Quais as atividades previstas** para a implementação do MVP? 2. **Quais os prazos estimados e quais as atividades mais críticas?** 3. **Quais são as (sub)equipes e seus responsáveis?** 4. **Quem é a base de testes** — o grupo de usuários afoitos com quem a equipe vai iniciar a operação? **Dica da disciplina:** elabore um cronograma gráfico com datas e prazos por membro responsável. ### Sobre a pergunta 4 É a continuação direta do trabalho de tração da Q7, e merece o mesmo rigor: - Quem são, **nominalmente ou por grupo identificado**? - Como vocês chegam até eles? - Quantos já toparam? - O que eles ganham? (usuário afoito colabora porque tem a dor — se você não sabe qual, não achou o usuário afoito) - Quando começam a usar? "Divulgaremos nas redes sociais" não é base de testes. E há um princípio útil: **prefira 10 usuários totalmente comprometidos a 100 em cima do muro.** --- ## Onde a IA ajuda de verdade Esta é a quest mais confortavelmente 🟢 coprodução. Decomposição de atividades, detecção de dependências, geração de cronograma, checklist de riscos — a máquina é boa nisso e não há dado de usuário em jogo. **O que continua sendo seu: as estimativas de duração.** A IA não sabe quanto a sua equipe rende, quem some na semana de provas, nem que a peça de hardware demora a chegar. Estimativa gerada sem esse conhecimento parece precisa e não é — e o princípio vale aqui igual: **só quem faz o trabalho sabe quanto ele custa.** Uso que rende mais: peça à IA que **questione o seu plano** — onde ele assume que nada dá errado, o que acontece se a pessoa X sair, qual atividade não tem dono. --- ## Referências desta quest | Arquivo | Quando | |---|---| | **Estimar — Quest #9** (neste arquivo) | Ao montar o cronograma. Pontos, Fibonacci, planning poker, velocity, burndown | | **Organizar o trabalho — Quest #9** (neste arquivo) | Ao dividir. Tamanho de time, multitarefa, limite de WIP, definição de pronto | | **Base de testes — Quest #9** (neste arquivo) | Ao planejar a tração. Como constituir e manter a comunidade de usuários afoitos | | **Autodiagnóstico — Quest #9** (neste arquivo) | Antes de entregar | --- ### Antes de registrar pessoas | Arquivo | Quando | |---|---| | `../../metodo/consentimento.md` | Ao montar a base de testes. A lista de quem topou testar é uma lista de pessoas reais — o que registrar dela, e o que não | --- ### Técnicas desta quest Fichas curtas de consulta rápida. Abra quando o procedimento acima mencionar a técnica. | Ficha | Para quê | |---|---| | **Usuário afoito (*early adopter*)** (neste arquivo) | a base de testes | | **Brainstorm** (neste arquivo) | decompor o trabalho | --- ## Perguntas frequentes **"Estamos atrasados. Cortamos escopo ou estendemos?"** A data não se move — logo, corta escopo. Corte pela curva de valor da Q5: sai primeiro o que não sustenta a PUV. Cortar a PUV para caber no prazo significa entregar um produto que não é o seu; nesse caso o problema é anterior, e vale conversar com o mentor. **"Vale a pena fazer Scrum completo num semestre?"** O mínimo que costuma valer: ciclo curto, reunião regular e curta, quadro visível, limite do que cada pessoa pega ao mesmo tempo, e uma definição de pronto escrita. Cerimônia demais consome o tempo que deveria ir para o produto. --- ## Bibliografia desta quest | Obra | O que ela dá para a Q9 | |---|---| | **Sutherland — Scrum** | Estimativa relativa, Fibonacci, planning poker, velocity, tamanho de time, multitarefa, definição de pronto | | **Maurya — Running Lean** | Limite de trabalho em progresso, o que entra no quadro, pronto = aprendizado validado | | **Ries — A startup enxuta** | Lotes pequenos: por que integrar cedo revela defeito cedo | | **Bigão Silva — Gerenciamento de projetos fora da caixa** | Bibliografia oficial da quest no site | # Autodiagnóstico — Quest #9 Faça este exercício **antes** de entregar. Ele é o mesmo que o mentor vai fazer depois. --- ## A escala O milestone da Q9 é **Plano de projeto**. Use a escala 0–5 da disciplina: | Nível | Significado | |---|---| | **0** | O critério ainda não aparece. | | **1** | Já aparece, mas sem clareza nem coerência. | | **2** | Falta clareza **ou** falta coerência. A resposta ainda está no terreno da insegurança. | | **3** | Coerente, mas ainda não totalmente claro. Resta uma parcela de incerteza. | | **4** | Claro e coerente com toda a proposta. Ainda cabe aperfeiçoar, mas a equipe responde com segurança. | | **5** | Perfeitamente alinhado ao conjunto. As respostas são sólidas. | O salto que trava a maioria na Q9 é o **3 → 4**, e ele tem um sintoma específico: o cronograma é bonito e ninguém consegue dizer **de onde saiu cada duração**. Plano que a equipe não sustenta sob a pergunta "quem estimou isso?" está em 3. --- ## Rubrica por dimensão ### 1. Decomposição das atividades | | | |---|---| | **2** | Lista por camada técnica: "backend", "frontend", "banco". Itens grandes demais para estimar. | | **3** | Lista de atividades razoável, mas com itens de tamanhos muito díspares e sem critério de quebra. | | **4** | Atividades fatiadas por **valor entregue ao usuário**, nenhuma grande demais para caber numa sprint, cada uma com o que precisa existir antes dela. | | **5** | O acima, com os itens grandes visivelmente quebrados e o registro de como foram quebrados. | ### 2. Estimativa | | | |---|---| | **2** | Horas atribuídas por uma pessoa, ou geradas por IA e aceitas. | | **3** | Estimativa relativa em pontos, mas feita por parte da equipe, sem régua declarada. | | **4** | Pontos em escala de Fibonacci, estimados **por quem vai executar**, com o item de referência declarado e o registro dos itens em que houve divergência e do que a discussão revelou. | | **5** | O acima, com a **data de recálculo** declarada e o burndown da primeira sprint preparado. | ### 3. Prazos e caminho crítico | | | |---|---| | **2** | Cronograma com todas as semanas preenchidas no mesmo nível de detalhe até o Demoday. | | **3** | Cronograma com datas, mas "atividades críticas" listadas como sinônimo de "atividades importantes". | | **4** | Detalhe fino nas próximas semanas e blocos grossos depois; caminho crítico identificado como a **sequência mais longa de dependências**; folga explícita na última semana; data de congelamento de escopo. | | **5** | O acima, com integração cedo e frequente marcada no cronograma, e com o que sai primeiro se o prazo apertar já decidido pela curva de valor da Q5. | ### 4. Subequipes e responsáveis | | | |---|---| | **2** | "Todos fazem tudo", ou papéis genéricos sem nome. | | **3** | Frentes definidas, mas com pessoas em três frentes ao mesmo tempo. | | **4** | Frentes pequenas e multifuncionais, cada uma com **um dono nomeado**; ninguém em mais de duas frentes; limite de trabalho em progresso declarado. | | **5** | O acima, com o custo de coordenação entre frentes tratado explicitamente (quando as frentes se falam, e sobre o quê) e com quem estimou cada bloco sendo quem o executa. | ### 5. Definição de pronto e quadro | | | |---|---| | **2** | Não há definição de pronto escrita. | | **3** | Definição de pronto existe, mas é genérica ("funcionando e testado"). | | **4** | Definição escrita em uma frase, incluindo validação qualitativa com usuário; quadro montado com metas no topo e limite de trabalho em progresso visível. | | **5** | O acima, com par **pronto para começar** / **pronto**, e com a regra de que só se demonstra o que atende à definição. | ### 6. Base de testes | | | |---|---| | **2** | "Divulgaremos nas redes sociais" ou a descrição do público-alvo repetida da Q1. | | **3** | Grupo identificado, mas sem nomes, sem número de quem já topou e sem data de início. | | **4** | Pessoas ou grupos nomeados, com caminho até eles, número de confirmados, **o que ganham** (a dor específica), e a semana do cronograma em que começam a usar. | | **5** | O acima, com quem recusou e por quê, e com o canal e a frequência de contato definidos e com dono. | --- ## Checklist rápido - [ ] Cada duração do cronograma foi estimada por **quem vai executar** aquilo? - [ ] Estimamos em pontos relativos, ou em horas absolutas — e qual é o "3" de referência da equipe? - [ ] Alguma atividade continua grande demais para caber numa sprint? - [ ] O cronograma tem **data declarada de recálculo**, ou finge precisão até o fim do semestre? - [ ] O caminho crítico é a sequência mais longa de dependências, ou é só a lista do que achamos importante? - [ ] A integração entre as partes feitas por pessoas diferentes está no cronograma, com data? - [ ] Existe folga na última semana **que não é para trabalhar**, e data de congelamento de escopo? - [ ] Nenhuma frente tem mais de sete pessoas, e toda frente tem **um** dono com nome? - [ ] Alguém está em três frentes ao mesmo tempo? (Ver a tabela de troca de contexto.) - [ ] O limite de trabalho em progresso está escrito no quadro? - [ ] A definição de pronto cabe em uma frase e está colada em algum lugar visível? - [ ] A base de testes tem **nomes** e **data** no cronograma, ou tem um público-alvo? - [ ] Sabemos dizer, de cada pessoa da base, qual é a dor dela? **Sinal de alerta:** se o cronograma foi montado em uma sessão e ninguém discordou de nenhuma duração, não houve estimativa — houve transcrição. Discordância entre o maior e o menor palpite é o mecanismo pelo qual o conhecimento circula. **Segundo sinal:** se a resposta à pergunta 4 tem o mesmo texto do segmento de cliente da Q5, a equipe não constituiu base de testes. --- ## 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. *A Q9 é a quest mais confortavelmente 🟢 coprodução: decompor atividades, detectar dependências, gerar cronograma e listar riscos são tarefas em que a máquina rende, e não há dado de usuário em jogo. A fronteira é a duração: estimativa gerada por quem não executa é o erro documentado na literatura da própria disciplina.* 2. **O que a IA gerou e você descartou — e por quê.** *Típico da Q9: a IA devolve um cronograma completo com durações plausíveis. Descartar as durações e refazê-las em planning poker, mantendo a decomposição, é exatamente o comportamento esperado.* 3. **O que você verificou, e como.** *Típico da Q9: as dependências. Diga qual dependência a IA não viu, ou qual ela inventou.* 4. **O que ainda não sabe.** *Aqui cabe declarar a velocity: se ela ainda não existe, diga que ainda não existe.* **O uso que mais rende na Q9:** peça à IA que **questione o seu plano** — onde ele assume que nada dá errado, o que acontece se a pessoa X sair, qual atividade não tem dono, qual dependência não tem folga. Registre as respostas que mudaram o plano. --- ## Como o mentor vai ler Cinco perguntas que aparecem com regularidade na apresentação da Q9. Se você tem resposta para as cinco, está em 4: 1. **"Quem estimou isto?"** A resposta forte nomeia as pessoas, e elas são as mesmas que aparecem como responsáveis pela frente. 2. **"O que acontece com a data se esta atividade atrasar uma semana?"** Se qualquer atividade atrasa tudo, não há caminho crítico identificado — há uma lista. 3. **"O que vocês cortam se estiverem atrasados?"** A data não se move; logo, corta escopo. A resposta forte já sabe a ordem do corte, e ela vem da curva de valor da Q5. 4. **"Quem já está usando, ou já topou usar?"** Nome, ou número com data. "Estamos conversando com algumas pessoas" é nível 2. 5. **"O que significa 'pronto' para vocês?"** Se cada pessoa da equipe responder diferente, a definição não existe — está escrita, mas não acordada. Divergência entre a sua auto-avaliação e a leitura do mentor é informação útil, não constrangimento. # Base de testes — Quest #9 Abra este arquivo quando for responder à pergunta 4 da entrega: **quem é o grupo de usuários afoitos com quem a equipe vai iniciar a operação.** É a metade da Q9 que as equipes esquecem, e é a que aparece vazia no Demoday. Modo de IA: 🟡 **com apoio**. A IA ajuda a redigir a mensagem de convite e a organizar a lista. Ela não pode gerar os nomes, e um "público-alvo" descrito por ela não é base de testes. *Usuário afoito* traduz *early adopter*: quem já tem a dor e adota antes de o produto estar pronto. --- ## 1. O que conta como base de testes, e o que não conta A base de testes é a **lista de pessoas concretas que vão usar o MVP durante o semestre e devolver dado.** É diferente de três coisas com que ela costuma ser confundida: | Isto | Não é base de testes porque | |---|---| | A persona da Q1 | É um retrato, não um contato | | O segmento de cliente da Q5 | É uma categoria, não uma lista | | "Vamos divulgar nas redes" | É um canal, não um compromisso | | Os três participantes do teste da Q8 | Foram convidados para uma sessão de uma hora, não para uso continuado — a menos que você tenha pedido e eles tenham aceitado | O que a Q9 pede é a quarta coisa: nomes, ou grupos identificados, com forma de contato, com o que eles ganham, e com quando começam. **A regra que orienta o tamanho.** Maurya é direto sobre a proporção: > **Prefiro dez usuários afoitos totalmente comprometidos, a quem eu possa dar atenção integral, a cem em cima do muro, qualquer dia.** E ele explica por quê: **o primeiro objetivo com o MVP é aprender.** Cem usuários indiferentes produzem números que parecem melhores e aprendizado que não existe. Dez comprometidos produzem conversa. > ⚠️ **Isso contraria o instinto da apresentação.** A equipe quer dizer "temos 200 pessoas na lista de espera" porque soa melhor diante da banca. Mas 200 inscrições sem uso é exatamente o que Ries chama de **métrica de vaidade** — o número que dá o quadro mais cor-de-rosa possível e não sustenta pergunta. Dez pessoas nomeadas, com o que cada uma já fez com o produto, é uma resposta que a banca não derruba. --- ## 2. Como constituir a base ### Primeiro, o canal certo Maurya coloca uma preferência antes de qualquer tática: **sempre que possível, priorize achar pessoas pelo canal que você de fato vai usar para adquirir clientes no futuro.** Se você não tem ainda um caminho até o cliente, isso pode não ser possível nesta fase — mas quando for, o mesmo esforço rende duas coisas: a base de testes e o teste do canal. ### As técnicas, em ordem de esforço | Técnica | Como | Ressalva | |---|---|---| | **Contatos de primeiro grau** | Comece pelos contatos imediatos que se encaixam no perfil demográfico alvo | Há quem desconfie de feedback de contato próximo. A posição de Maurya: **falar com qualquer pessoa é melhor que não falar com ninguém** | | **Pedir apresentação** | Peça aos contatos de primeiro grau que apresentem pessoas do perfil. **Inclua um modelo de mensagem** que a pessoa possa copiar e encaminhar, para poupar o tempo dela | Duas ou três casas de distância normalmente bastam | | **Chegar até o segundo e o terceiro grau** | Use os primeiros entrevistados para chegar a outros | Serve também para praticar o roteiro e ganhar conforto | | **Contato frio** | Ligação, e-mail, redes profissionais | O segredo para conseguir que alguém, frio ou morno, aceite conversar é **acertar em cheio o problema dela**. Como isso é difícil de fazer de saída, Maurya usa as outras técnicas primeiro, roda algumas conversas, e só depois vai a frio | **O modelo de mensagem** que Maurya usa tem uma estrutura que vale copiar: um pedido curto ao amigo, seguido de um texto pronto para encaminhar, que diz o que a equipe está construindo, quanto tempo pede, e — a frase que faz a diferença — **"não estou vendendo nada, só procurando conselho"**. **A parcela que fica.** Quando Maurya lançou seu próprio produto de forma iterativa, cerca de metade das pessoas aceitou receber material inacabado a cada duas semanas; as outras preferiram esperar o produto terminado. Isso, por si, distinguiu **usuários afoitos de clientes de estágio posterior**: os afoitos se moviam pelo conteúdo e não se importavam com o empacotamento. **A recusa também é dado.** Registre-a. ### Uma prática de campo **Prefira encontro presencial.** Além de captar linguagem corporal, encontrar alguém pessoalmente cria uma proximidade que não se recria à distância — e isso é crítico para construir relação com o cliente, que é exatamente o que a base de testes é. **Ação:** monte uma planilha com colunas *nome · como chegamos até ele · perfil · já topou? · o que ganha · quando começa*. Dez linhas preenchidas valem mais que trezentos e-mails coletados. --- ## 3. O que oferecer Aqui há uma divergência entre as fontes, e ela é útil. | Fonte | Posição | Contexto | |---|---|---| | **Krug** | Pague, e um pouco acima da praxe. Torna claro que você valoriza o tempo da pessoa e melhora a chance de ela aparecer | **Teste de usabilidade**: sessão isolada de uma hora, com deslocamento | | **Maurya** | **Não pague nem ofereça outros incentivos.** "Diferentemente de teste de usabilidade, onde é aceitável oferecer incentivo, aqui o seu objetivo é achar clientes que paguem **você**, não o contrário" | **Entrevista com cliente e base de usuários**: relação continuada | **Qual usar na Q9:** a de Maurya. A base de testes não é uma sessão paga; é uma relação. Se as pessoas só participam mediante pagamento, você não achou usuários afoitos — achou participantes de pesquisa. **Então o que elas ganham?** A dor resolvida antes dos outros. Se a equipe não consegue dizer qual é a dor específica daquela pessoa, ela não achou o usuário afoito — achou alguém educado. A checagem prática de Maurya se aplica: se a pessoa declara um problema como indispensável mas **não está fazendo nada para resolvê-lo hoje**, há uma desconexão. Quem já mantém uma gambiarra para se virar tem a dor; quem não faz nada e continua se virando, não. **Os quatro princípios que fazem o convite funcionar.** Maurya analisa por que um cliente concordou em pagar cinco vezes mais do que havia proposto, e nomeia quatro mecanismos. Três deles se transportam para o convite à base de testes de um projeto de disciplina, sem pagamento envolvido: | Princípio | Como se usa no convite | |---|---| | **Escassez** | "Estamos procurando especificamente **dez** [perfil] que tenham [problema]. Vamos trabalhar de perto com essas dez pessoas para validar [PUV] em 30 a 60 dias." A escassez de Maurya **não era artifício** — era a consequência de querer dar atenção integral a cada um | | **Prêmio** (*prizing*) | Maurya cita a técnica de enquadramento de Oren Klaff, em *Pitch Anything*: na maioria das apresentações, quem apresenta faz o papel de bobo da corte entretendo a corte de clientes. Em vez de tentar impressionar, **posicione-se como o prêmio** — você está selecionando com quem vai trabalhar | | **Confiança** | A maioria reluta em cobrar, ou em convidar, porque acha o MVP "mínimo" demais e sente vergonha dele. Maurya não subscreve: **a razão de testar problemas com cuidado e reduzir escopo é construir o produto mais simples que resolve um problema real de cliente** | **Ação:** escreva o convite em três frases usando escassez explícita e número declarado. Não use "queremos o máximo de gente possível". --- ## 4. Como manter o diálogo Constituir a base é a parte fácil. Mantê-la viva por doze semanas é o que a Q9 está de fato pedindo. **1. Peça permissão para acompanhar — sempre, e na hora.** Maurya fecha toda conversa com dois pedidos, e o primeiro é este: *"Com base no que a gente conversou hoje, você toparia ver o produto quando a gente tiver alguma coisa pronta?"* O objetivo declarado é **estabelecer um ciclo contínuo de feedback**. **2. Peça indicação, na mesma hora.** O segundo pedido: *"Também estamos procurando entrevistar outras pessoas como você. Você poderia nos apresentar a outros [perfil]?"* A base cresce por dentro. **3. Deixe um gancho memorável.** Mesmo quando ainda não é hora de falar da solução em detalhe, é preciso dar um gancho que mantenha o interesse. Maurya usa o **pitch de alto conceito** para isso — a destilação em *sound bite* no formato "[referência conhecida] para/sem [torção]" —, porque ele explica a solução em alto nível **e deixa uma frase memorável que a pessoa consegue repetir para outros**. Detalhes em **Roteiro do pitch — Quest #10** (neste arquivo). **4. Documente nos cinco minutos seguintes.** Reserve os cinco minutos imediatamente depois de cada conversa para registrar o resultado enquanto está fresco. Maurya recomenda um formulário curto e fixo; e, quando duas pessoas participaram, **cada uma preenche o formulário sozinha primeiro**, e só depois há uma conversa de comparação e um registro final. Isso mantém o resultado objetivo. **5. Facilite o retorno espontâneo.** Maurya observa que, ao contrário do que se teme, você não vai ser bombardeado: boa parte dos contatos que chegam são de pessoas com **dúvidas sobre o serviço**, não com problemas de suporte. Dá para reservar uma faixa de horário no dia e redirecionar as chamadas se e quando isso virar problema de escala — o que seria um problema bom de ter. **6. Vá atrás de quem desistiu.** Este é o item que quase nenhuma equipe faz e que rende muito na apresentação: **você aprende tanto ou mais com quem não ficou do que com quem ficou.** Algumas pessoas dão retorno honesto se você fizer um pedido sincero ao fim do período de teste; outras precisam de um pequeno incentivo — Maurya sugere um vale ou uma doação a uma instituição em troca de quinze minutos. **7. Tenha um ritmo fixo de revisão.** Maurya marca **um horário toda segunda-feira** para revisar os indicadores da semana com a equipe inteira e identificar onde está vazando. Numa disciplina, isso encaixa na reunião de sprint. --- ## 5. Uma coisa que a base de testes não é Ela não é fila de espera de lançamento. Maurya faz a distinção com clareza: se você já tem uma lista grande de contatos mornos vinda de esforços anteriores — página teaser, indicações de entrevistados —, **considere esgotar essa lista primeiro, na forma de mais convites de acesso antecipado, antes de um lançamento público.** A ordem, portanto, é: conversar com quem já está na lista → convidar para usar → só então pensar em divulgação ampla. Equipe que inverte essa ordem chega ao Demoday com muita divulgação e nenhum uso. E há um alerta associado: quando o produto abre, você deixa de controlar quem entra. Além dos usuários afoitos alvo, chegam robôs, curiosos e talvez outros clientes-alvo ainda não descobertos. **Olhar só o número agregado produz um efeito de média que distorce muito quando o tráfego ainda é pouco, ou não é o tráfego certo.** Por isso é preciso **segmentar** — e por isso a base nominal importa: ela é o segmento que você sabe interpretar. --- ## 6. O que reportar na entrega A pergunta 4 da Q9 pede um grupo. Responda com esta estrutura — ela é curta e cobre o que o mentor vai perguntar: | Item | O que escrever | Resposta fraca | |---|---|---| | **Quem são** | Nominalmente, ou por grupo identificado com nome próprio ("os 8 monitores do laboratório X", "o grupo de mensagens da associação Y, 40 pessoas") | "Estudantes universitários" | | **Como chegamos até eles** | O caminho concreto: quem apresentou, por qual canal | "Redes sociais" | | **Quantos já toparam** | Um número, e a data em que cada um confirmou | "Vários demonstraram interesse" | | **O que eles ganham** | A dor específica resolvida antes dos outros. Se houver outra contrapartida, declare | "Vão ajudar a melhorar o produto" | | **Quando começam a usar** | Data no cronograma, ligada a uma sprint | "Assim que estiver pronto" | | **Como vamos manter contato** | Canal, frequência, quem da equipe é responsável | — | | **O que já sabemos deles** | O que veio das conversas da Q2 e do teste da Q8, com quantas pessoas | — | | **Quem recusou, e por quê** | A recusa também é dado, e mostra que houve convite real | — | **A conexão com a Q7 e a Q10.** A base de testes é a mesma população que vai responder ao teste de ajuste produto-mercado da Q10, se houver tempo, ou fornecer o número de retenção. Se ela não existir na Q9, não existirá número honesto na Q10 — e a única resposta possível diante da banca vai ser "ainda não medimos". Ver **Tração e números — Quest #10** (neste arquivo). **Ação:** entregue a planilha de dez linhas junto com o cronograma, e marque no cronograma a semana em que a base começa a usar. Base de testes sem data no cronograma é intenção, não plano. --- ## Fontes - **Maurya, Ash**, *Running Lean* — cap. 6: as técnicas para achar pessoas (contatos de primeiro grau, pedir apresentação com modelo de mensagem, contato frio e a condição de acertar o problema), a preferência pelo canal real de aquisição, a recomendação de encontro presencial, a orientação de não pagar nem incentivar prospects, a documentação em cinco minutos com preenchimento independente; cap. 7: o fechamento com pedido de permissão para acompanhar e pedido de indicação, e o uso do pitch de alto conceito como gancho; cap. 8: os quatro princípios do convite (prêmio, escassez, ancoragem, confiança) e a frase sobre dez comprometidos contra cem em cima do muro; cap. 10 e 12: esgotar a lista morna antes do lançamento público, a segmentação contra o efeito de média, o retorno espontâneo dos usuários e o incentivo para conversar com quem desistiu; cap. 2: o caso da própria publicação iterativa e a metade que preferiu esperar o produto pronto - **Krug, Steve**, *Não me faça pensar*, cap. 9 — a posição oposta sobre incentivo, no contexto de sessão isolada de teste - **Ries, Eric**, *A startup enxuta*, cap. 7 — métricas de vaidade e o "teatro do sucesso": por que número bruto de cadastros não sustenta pergunta - **Klaff, Oren**, *Pitch Anything* — a técnica de enquadramento como prêmio, conforme citada por Maurya # Estimar — Quest #9 Abra este arquivo no dia em que a equipe for transformar a lista de atividades em datas. Ele responde a uma pergunta só, em várias camadas: **como dizer quando algo fica pronto sem inventar.** Modo de IA: 🟢 **coprodução** na decomposição e na montagem do cronograma. 🔴 **sem assistência** no valor das estimativas — quem estima tem de ser quem executa, e a IA não executa. --- ## 1. O cone da incerteza, e o que ele proíbe Sutherland apresenta o gráfico com os números: **as estimativas iniciais de trabalho variam de 400% acima do tempo efetivamente gasto até 25% dele.** Os extremos, portanto, diferem por um **fator de dezesseis**. Conforme o projeto avança e mais coisas se assentam, as estimativas se aproximam da realidade, até que não há mais estimativa — só realidade. A conclusão que ele tira é dura e é a que interessa à Q9: **planejar tudo no início não funciona.** No caso que ele narra, uma empresa passou meses planejando o que o produto seria e quanto tempo levaria, e mesmo depois de todos esses meses a pesquisa indica que eles provavelmente errariam por um fator de quatro, para mais ou para menos. O que fazer no lugar: **refinar o plano ao longo do projeto, em vez de fazê-lo todo no início** — planejando em detalhe apenas o suficiente para entregar o próximo incremento de valor, e estimando o resto em blocos maiores. E o que sustenta esse refinamento: ao fim de cada iteração existe **algo de valor que dá para ver, tocar e mostrar** para quem vai usar. Aí você pergunta: é isso que você quer? Isso resolve pelo menos parte do seu problema? Estamos indo na direção certa? Se a resposta for não, o plano muda. > ⚠️ **Consequência para o cronograma da Q9.** A quest pede um cronograma até o Demoday, e é preciso entregar um. Mas um cronograma detalhado semana a semana até o fim do semestre, feito na semana da Q9, é exatamente o artefato que o cone da incerteza diz ser inútil. A forma defensável de entregar: **detalhe fino nas próximas duas ou três semanas, blocos grossos depois**, e uma **data declarada de recálculo** — "este cronograma será refeito ao fim de cada sprint, com a velocity medida". Declarar isso vale mais do que fingir precisão de segunda casa em maio. --- ## 2. Somos péssimos em absoluto, bons em relativo O segundo argumento encadeado: humanos são **absolutamente terríveis** em estimar valores absolutos, mas bons em **dimensionamento relativo** — comparar um tamanho a outro. Distinguir camisetas P, M e G, por exemplo. ### O exemplo das raças de cachorro Mike Cohn, tendo sido proibido pela esposa de ter cachorro, começou a perguntar às equipes de que **tamanho de cachorro** era cada pedaço do projeto. Ele listava raças — labrador, terrier, dogue alemão, poodle, dachshund, pastor-alemão, setter irlandês, buldogue — e perguntava: este problema aqui é um dachshund ou um dogue alemão? E se aquele é um dachshund, este aqui deve ser mais ou menos do tamanho de um labrador, certo? Depois vinha a conversão em número: **dachshund = 1, dogue alemão = 13.** Isso faria um **labrador = 5** e um **buldogue = 3**. Sutherland aplica ao exemplo do casamento, e o passo a passo serve de modelo para a Q9: | Item | Raciocínio | Ponto | |---|---|---| | Achar o local | Exige pesquisa, orçamento, visitar lugares. É envolvido | Pastor-alemão = **5** | | Noivos | Só precisam aparecer. Um telefonema | Dachshund = **1** | | Convites | Fazer a lista, pegar a lista da mãe dele, a da mãe dela, escolher o papel, imprimir, endereçar à mão | Dogue alemão = **13**, ou talvez dois | E aí entra a regra operacional embutida no exercício: **se um item é grande demais, quebre-o em pedaços administráveis.** Os convites viram dois projetos — juntar os nomes (buldogue, **3**) e lidar com a gráfica (buldogue, **3**) —, e endereçar vira um pastor-alemão (**5**). **Ação:** faça o exercício com a lista de atividades da Q9 antes de qualquer conversa sobre datas. Escolha **um item de referência** que todo mundo entende — algo já feito na Q6 ou Q8 — e chame de 3. Estime todo o resto em relação a ele. --- ## 3. Por que Fibonacci 1, 3, 5, 8, 13 — cada número é a soma dos dois anteriores. Sutherland dá o contexto matemático (a sequência aparece na concha do náutilo, nos galhos de árvore, na couve-flor, na curva da folha de samambaia, na forma das galáxias; é a razão áurea), mas o argumento que sustenta o uso é **perceptual**: > Os números da sequência estão suficientemente distantes para que consigamos perceber a diferença. Mas a diferença entre um cinco e um seis? É sutil demais para o nosso cérebro registrar. Se uma pessoa estima algo como cinco e outra como oito, dá para ver intuitivamente a diferença. Entre cinco e seis, não. **O reforço clínico** que ele traz: é razoavelmente conhecido em medicina que, para um paciente **relatar que percebe** melhora em um sintoma, a melhora precisa ter sido **maior que 65%**. Nossas mentes não funcionam em incrementos suaves; somos melhores em perceber saltos de um estado para outro — e saltos irregulares, não suaves. **O fecho, e é o ponto que mais se perde:** usar Fibonacci permite estimativas que **não precisam ser 100% exatas**. Nada é exatamente um cinco, um oito ou um treze. O que os números dão é uma forma de coletar opiniões sobre o tamanho de uma tarefa em que **todo mundo usa mais ou menos a mesma régua** — e é assim que se forma consenso. Estimar em grupo dessa maneira dá uma estimativa muito mais acurada do que qualquer pessoa sozinha produziria. --- ## 4. Planning poker, passo a passo ### De onde vem É o **método Delphi acelerado**. Sutherland conta a origem: nos anos 1950 a Rand Corporation foi chamada a responder perguntas da Guerra Fria. Norman Dalkey e Olaf Helmer publicaram em 1963 o método, invocando o oráculo de Delfos, com a intenção de fazer perguntas **sem que a opinião de uma pessoa afetasse a das outras**. Reuniram quatro economistas, um especialista em vulnerabilidade física, um analista de sistemas e um engenheiro elétrico, e conduziram uma série de pesquisas anônimas: ninguém sabia quem eram os outros; a cada rodada, as respostas e os dados usados voltavam ao grupo, com qualquer marca de identificação removida. Os números da convergência: na primeira rodada, a faixa ia de **50 a 5.000**. Depois de perguntarem quais fatores os especialistas haviam usado e devolverem essa informação ao grupo, a faixa caiu para **89 a 800**. Repetindo, chegou-se a **167 a 360**. **O problema do Delphi**, para o uso em projeto: é lento demais. Sutherland precisava de centenas de itens estimados em horas, não em dias ou semanas. ### Os dois vieses que ele existe para combater | Viés | O que é | Exemplo do livro | |---|---|---| | **Efeito manada** (*bandwagon*, ou cascata informacional) | Alguém propõe uma ideia, o grupo embarca, e mesmo quem discordava inicialmente vai junto. Depois, ao serem sondadas, quase todas as pessoas tinham reservas — e não as verbalizaram porque supuseram que a própria reserva era boba ou mal informada. Sutherland insiste: **isso não é falha individual, é falha humana** | Um artigo rejeitado pelo primeiro periódico tem mais chance de ser rejeitado pelo segundo, que sabe da primeira rejeição — e ainda mais pelo terceiro | | **Efeito halo** | Uma característica de algo influencia a percepção de outras características, não relacionadas | Thorndike, 1920, "A Constant Error in Psychological Ratings": oficiais militares classificaram soldados por qualidades físicas, intelectuais, de liderança e de personalidade, e as notas correlacionaram demais — quem tinha bom físico era avaliado como bom líder, inteligente e de bom caráter | ### O procedimento 1. Cada pessoa tem um baralho com os números de Fibonacci — 1, 3, 5, 8, 13, e assim por diante. 2. O item a estimar vai à mesa. 3. Cada um puxa a carta que representa o esforço que julga correto e a coloca **virada para baixo**. 4. Todos viram **ao mesmo tempo**. 5. **Se todos estão dentro de duas cartas** — por exemplo um 5, dois 8 e um 13 —, a equipe soma tudo, tira a média (nesse caso 6,6) e passa ao item seguinte. São estimativas, não cronogramas de ferro, e sobre pedaços pequenos do projeto. 6. **Se as cartas estão a mais de três de distância**, quem votou o maior e quem votou o menor **explicam o raciocínio**. Só então há nova rodada. Fora isso, a equipe simplesmente tira a média — que aproxima o que os estatísticos da Rand obtiveram. ### O exemplo que mostra o valor do passo 6 Pintar o interior de uma casa: sala, cozinha e dois quartos, com uma equipe que já pintou junta antes. - Os dois quartos: todo mundo estima **3**. Sem discordância — já fizeram, é direto. - A sala: cômodo grande mas simples. Estimativas de **5 a 13**, com média **6**. Sem necessidade de discussão. - A cozinha: um **3**, um **8**, um **13** e um **5** na mesa. Quem pôs 3 argumenta que o cômodo é pequeno e tem menos parede que os quartos. Quem pôs 13 responde que o consumo real de tempo é **fitar armários e bancadas**, e que pintar todas aquelas áreas pequenas vai ter de ser com pincel, não com rolo. Nova rodada: **o 3 vira 8**, os outros ficam. Perto o bastante — somam, tiram a média e seguem. **O que o passo 6 produz não é a estimativa: é o conhecimento compartilhado.** Todo mundo na equipe passou a saber que existe trabalho de fitar armários. **Ação:** o baralho pode ser papel cortado. O que não pode faltar é o passo 3 e 4 — todos escolhem antes de ver a escolha alheia. Sem isso, o método vira reunião de opinião, e você reintroduz exatamente os dois vieses que ele existe para remover. --- ## 5. Quem estima tem de ser quem executa Sutherland é explícito: **é crucial que quem estima seja a equipe que vai de fato fazer o trabalho, não estimadores "ideais" especialistas.** O caso que ele narra: a GSI Commerce, empresa que projetava lojas online para grandes marcas, teve a ideia — que parecia boa — de tirar a estimativa das equipes e entregá-la aos **melhores estimadores da empresa**, os que mais entendiam de projeto e tecnologia. O plano era entregar estimativas de **oitenta projetos multimilionários** aos clientes e às equipes que fariam o trabalho. O resultado: **o experimento foi interrompido pela metade, com quarenta projetos feitos.** Sutherland compara a estudos de medicamento interrompidos porque a droga está matando os pacientes. As estimativas eram tão erradas que se tornaram inúteis; nada foi entregue no prazo; os clientes ficaram insatisfeitos; as equipes, desmoralizadas. Os gestores voltaram a fazer as equipes que executam estimarem, e as estimativas voltaram a bater com a realidade. A lição que ele extrai: **só quem faz o trabalho sabe quanto tempo e esforço ele exige.** Talvez a equipe seja muito boa numa coisa e péssima em outra; talvez tenha um especialista útil numa área e ninguém que conheça outra. Equipes são individuais e únicas, cada uma com o próprio ritmo. Forçá-las em processos de molde único é receita de desastre. > ⚠️ **Onde isso morde na Q9.** Duas violações são comuns numa equipe de disciplina. A primeira: o gerente estima sozinho e distribui. A segunda: a IA gera o cronograma completo, com durações, e a equipe aceita. As duas são a mesma violação — estimador que não executa. A IA não sabe quanto a sua equipe rende, quem some na semana de provas, nem que a peça de hardware demora a chegar. **Use a IA para decompor e para questionar; não para atribuir duração.** --- ## 6. Velocity: como a data deixa de ser chute **O cálculo.** Você tem as histórias e já as estimou — esta é um oito, aquela é um três. Rode a primeira sprint. Ao fim dela, **conte as histórias completas**, some os pontos delas. Esse número é a **velocity** da equipe. **A previsão.** Com a velocity, olhe quantas histórias restam e quantos pontos elas representam — e você sabe quando vai terminar. > **Velocity × Tempo = Entrega.** **O segundo uso, que Sutherland considera o mais importante:** uma vez que você tem velocity, dá para perguntar **o que está impedindo a equipe de ir mais rápido**. É assim que se verifica se o desperdício está de fato sendo removido — e não apenas declarado removido. **O caso, com os números:** depois de três sprints medindo velocity, as equipes tinham acelerado de **20 para 60 pontos por sprint**. Com essa velocity, no começo de março, a conta dava mais dezenove sprints de duas semanas: entrega em **1º de dezembro**. A gestão recebeu então uma lista de **doze impedimentos** — de falta de autonomia para decidir a requisitos técnicos onerosos, de gente que não aparecia em reunião a coisas simples como não ter todo mundo da equipe na mesma sala. Cada impedimento com o nome de um gestor ao lado. Todos foram removidos entre a segunda e a quinta-feira. **Ao fim da sprint seguinte, a velocity subiu 50%**, e a data foi para 1º de setembro — ainda três meses atrasada, mesmo tendo a equipe acelerado de 20 para 90 pontos por sprint, mais de 400%. **As três perguntas que ele fez quando a data ainda não fechava** — e que valem para uma equipe de disciplina em apuros: 1. **Há algo que possamos fazer diferente para acelerar?** (Foi assim que descobriram que a segurança de TI havia fechado uma porta e travado equipes inteiras.) 2. **Dá para transferir itens do backlog? Há coisa que outras equipes possam fazer?** 3. **Há coisa que possamos não fazer? Dá para reduzir o escopo?** A resposta inicial foi que já haviam cortado até o osso. Passaram a tarde inteira raspando: **cada tarefa teve de lutar pela própria vida.** Ganharam mais um mês. **Consequência direta para a Q9:** velocity **só existe depois de pelo menos uma sprint fechada**. Se a Q9 acontece antes da primeira sprint, a linha de base do cronograma não tem dado real por trás. Diga isso, e marque a data do primeiro recálculo. --- ## 7. Burndown O instrumento de visualização. Num eixo, **o número de pontos que a equipe levou para a sprint**; no outro, **os dias**. Todo dia alguém soma os pontos concluídos e marca no gráfico. Idealmente, há uma **inclinação acentuada para baixo**, chegando a zero ponto restante no último dia da sprint. O valor não é o desenho: é que o desvio aparece **no dia três**, não na véspera. Uma linha que não desce nos primeiros dias é a informação de que a equipe começou muitas coisas e não terminou nenhuma — que é exatamente o diagnóstico de trabalho em progresso excessivo tratado em `organizar-o-trabalho.md`. Sutherland lista o burndown ao lado do quadro de três colunas — **A fazer, Fazendo, Feito** — como as duas formas padrão de **tornar o trabalho visível**. **Ação para a Q9:** entregue o burndown em branco, com o eixo de pontos preenchido pela estimativa da primeira sprint e os dias marcados. Um burndown planejado é entregável; um burndown inventado retroativamente não é. --- ## 8. O que a Q9 precisa mostrar sobre estimativa | Pergunta da entrega | O que a estimativa fornece | |---|---| | Quais as atividades previstas? | A lista quebrada até o ponto em que nenhum item é um dogue alemão solto | | Quais os prazos estimados? | Pontos por item, com a régua declarada (qual item é o 3 de referência) e a data de recálculo | | Quais as atividades mais críticas? | Ver caminho crítico no `SKILL.md`: a sequência mais longa de dependências. Grande ≠ crítica | | Quais as subequipes e responsáveis? | Quem estimou cada bloco é quem executa cada bloco — a coerência entre as duas listas é verificável | **Uma frase para a apresentação, se a banca ou o mentor perguntar de onde vieram as datas:** "estimamos em pontos, por comparação relativa, com quem vai executar; a data sai da velocity, e a velocity só existe depois da primeira sprint — por isso o cronograma tem data de recálculo". Isso é mais forte do que um Gantt com precisão fictícia. --- ## Fontes - **Sutherland, Jeff**, *Scrum: a arte de fazer o dobro do trabalho na metade do tempo* — cap. 6 inteiro: o cone da incerteza e os números de 400% e 25%; o refinamento incremental do plano; dimensionamento relativo e os pontos de cachorro de Mike Cohn; a sequência de Fibonacci e o argumento perceptual, incluindo o dado dos 65% de melhora percebida; o método Delphi da Rand (Dalkey & Helmer, 1963) e as faixas de convergência; efeito manada e cascata informacional; efeito halo (Thorndike, 1920); o procedimento do planning poker e o exemplo da pintura; o caso da GSI Commerce e a conclusão sobre quem estima; velocity, a fórmula, os doze impedimentos e as três perguntas; o apêndice do livro, com o burndown e o quadro de três colunas - **Cohn, Mike** — autor do exercício dos pontos de cachorro, conforme creditado por Sutherland - **Weinberg, Gerald**, *Quality Software Management* — origem da tabela de multitarefa usada em `organizar-o-trabalho.md`, do mesmo capítulo # Organizar o trabalho — Quest #9 Abra este arquivo quando a equipe for dividir gente por frente e decidir como o trabalho anda de semana em semana. Ele trata de quatro decisões que uma equipe grande de disciplina costuma tomar por omissão: **quantas pessoas por frente, quantas coisas ao mesmo tempo, o que significa "pronto", e o que entra no quadro.** Modo de IA: 🟢 **coprodução** — decompor, detectar dependências, montar o quadro. A IA não decide quem faz o quê, e não sabe quem some na semana de provas. --- ## 1. Tamanho de time, e por que a Q9 esbarra nisso A formulação clássica é **sete pessoas, mais ou menos duas** — Sutherland registra ter visto times de três funcionando em alto nível. O dado que interessa: **se você tem mais de nove pessoas num time, a velocity de fato cai.** Mais recurso faz o time ir mais devagar. **Lei de Brooks**, cunhada por Fred Brooks em 1975, em *The Mythical Man-Month*: **acrescentar gente a um projeto de software atrasado o atrasa mais.** Isso foi confirmado em estudo após estudo. **O dado empírico.** Lawrence Putnam dedicou a carreira a estudar quanto tempo as coisas levam para ser feitas e por quê. O trabalho dele mostrava, repetidamente, que projetos com vinte ou mais pessoas consumiam mais esforço do que projetos com cinco ou menos — não um pouco mais: **um time grande gastava cerca de cinco vezes o número de horas de um time pequeno.** Em meados dos anos 1990 ele fez um levantamento amplo para determinar o tamanho certo: **491 projetos de médio porte, em centenas de empresas diferentes**, todos exigindo produtos ou funcionalidades novas — não reaproveitamento de versões antigas. Dividindo por tamanho de time, notou de imediato que, **acima de oito pessoas, os times demoravam dramaticamente mais**. E o número que se cita: **grupos de três a sete pessoas exigiram cerca de 25% do esforço de grupos de nove a vinte para fazer a mesma quantidade de trabalho.** O resultado se repetiu ao longo de centenas e centenas de projetos. ### As duas causas Brooks encontrou duas razões para adicionar gente atrasar o projeto: 1. **O tempo de trazer a pessoa nova ao ritmo.** Como se espera, colocar alguém a par atrasa todo mundo. 2. **A explosão de canais de comunicação**, contra o limite do cérebro. **A fórmula:** número de pessoas, multiplicado por esse número menos um, dividido por dois. > **Canais = n(n−1)/2** | Pessoas | Canais | |---|---| | 5 | 10 | | 6 | 15 | | 7 | 21 | | 8 | 28 | | 9 | 36 | | 10 | 45 | **Por que isso é limite duro e não preguiça.** Sutherland traz o contexto cognitivo: o estudo clássico de George Miller, de 1956, dizia que o máximo de itens retidos na memória de curto prazo é sete. Pesquisa posterior corrigiu o número: em 2001, Nelson Cowan, da Universidade do Missouri, revisou a literatura nova sobre o tema e concluiu que **o número não é sete, é quatro**. As pessoas costumam achar que memorizam mais usando mnemônicos ou concentração, mas a evidência é razoavelmente clara: retemos cerca de quatro "blocos" de informação. O exemplo canônico é a sequência de doze letras **fbicbsibmirs** — quase ninguém retém mais que quatro letras, a menos que perceba que elas se agrupam em siglas conhecidas: FBI, CBS, IBM, IRS. Ligando ao que já está na memória de longo prazo, cabe mais. Mas a parte da mente que foca — a consciente — segura cerca de quatro itens distintos por vez. E a exigência que isso contraria: num time de Scrum, como num time de forças especiais, **todo mundo tem de saber o que todo mundo está fazendo**. Todo o trabalho em curso, os obstáculos, o progresso, tem de ser transparente para os demais. Se o time cresce demais, a capacidade de todos se comunicarem com clareza com todos, o tempo todo, se embaralha. > ⚠️ **A Q9 impõe equipe grande — e a saída não é reclamar.** A turma monta equipes acima do tamanho ótimo. A resposta operacional é **subdividir em frentes com dono**, mantendo cada frente pequena e multifuncional, e aceitando o custo de coordenação entre frentes como custo explícito, com hora marcada. O que não funciona é deixar a equipe grande operar como time único e esperar que ela se organize: sem estrutura, ela se quebra socialmente em subgrupos que trabalham com propósitos cruzados, a multifuncionalidade se perde, e reuniões de minutos viram reuniões de horas. **Ação:** na tabela de subequipes que a Q9 pede, nenhuma frente deve ter mais de sete pessoas, e cada frente deve ter **um nome de dono**. Some os canais internos de cada frente e escreva o número ao lado — é a justificativa da divisão que você escolheu. --- ## 2. O custo real da multitarefa A tabela abaixo aparece em *Quality Software Management*, de Gerald Weinberg, e é reproduzida por Sutherland: | Projetos simultâneos | % do tempo disponível por projeto | Perda por troca de contexto | |---|---|---| | 1 | 100% | 0% | | 2 | 40% | **20%** | | 3 | 20% | **40%** | | 4 | 10% | **60%** | | 5 | 5% | **75%** | **A coluna da direita é desperdício puro.** Com cinco projetos, 75% do trabalho não vai a lugar nenhum — três quartos do dia jogados fora. ### O exercício que cabe em cinco minutos Sutherland usa em treinamento, e ele funciona porque a pessoa mede o próprio tempo. A tarefa: escrever os algarismos de **1 a 10**, os algarismos romanos de **I a X**, e as letras de **A a L**. O mais rápido possível. - **Primeira rodada, por linhas.** Escreva o algarismo, o romano, a letra; depois a linha seguinte. Você troca de contexto a cada símbolo. Sutherland cronometrou: **39 segundos**. - **Segunda rodada, por colunas.** Todos os algarismos, depois todos os romanos, depois todas as letras. **19 segundos** — metade. **Por que isso não é só sobre listinhas.** A explicação vem de Harold Pashler, que no início dos anos 1990 demonstrou o que chamou de **interferência de tarefa dupla**. Um grupo fazia algo muito simples — apertar um botão quando uma luz acendia. Outro grupo fazia isso mais outra tarefa simples: apertar um botão diferente conforme a cor da luz. **Assim que a segunda tarefa era acrescentada, por mais simples que fosse, o tempo dobrava.** Pashler teorizou um gargalo de processamento: as pessoas realmente só conseguem pensar em uma coisa por vez. Há um custo em "empacotar" um processo, buscar outro na memória e rodá-lo — e esse custo se paga a cada troca. ### O resultado num time real Um time decide fazer três projetos no ano — A, B e C — e planeja o ano alternando entre eles. **Fazendo tudo ao mesmo tempo, que é a estratégia clássica, terminam no fim de julho. Levando cada projeto até o fim, um por vez, terminam no começo de maio.** O projeto não muda de tamanho nem de conteúdo; só a ordem muda. E o tempo cai para pouco mais da metade. **O custo escondido, e o que ele significa para código.** Quando você trabalha em algo complicado — escrever um relatório, montar uma apresentação, desenvolver software —, você está segurando na cabeça um objeto muito complexo: dezenas de fatores, o que já foi feito, para onde se vai, quais são os impedimentos. Se você é interrompido ou tem de trocar de projeto, mesmo por um instante, **essa arquitetura mental construída com cuidado desmorona** — e pode levar horas de trabalho só para voltar ao mesmo estado de consciência. **Ação:** blocos. Junte numa mesma janela de tempo as tarefas que exigem o mesmo tipo de concentração, e proteja o bloco. Na Q9, isso significa cronograma por **blocos de foco**, não por "um pouquinho de cada coisa toda semana". --- ## 3. Trabalho pela metade é igual a zero A ideia vem do conceito de **trabalho em processo**, ou estoque, na manufatura enxuta: é desperdício ter um monte de coisa parada que não está sendo usada para construir nada. Uma montadora que só tem carros pela metade gastou muito dinheiro e esforço e **não criou nada de valor real**. Sutherland traz o exemplo doméstico. Uma lista de tarefas da semana com dez a vinte itens: repintar o banheiro, comprar ração, pagar a conta, juntar as folhas. O maior erro é tentar fazer cinco ao mesmo tempo. Imagine cinco tarefas parcialmente feitas: **uma parede do banheiro pintada, a ração ainda no porta-malas, o cheque escrito mas não enviado, as folhas amontoadas mas não ensacadas.** Esforço gasto, valor zero. O valor chega quando a lona e as latas saem do banheiro, o cachorro come, o banco recebe e o quintal está limpo. **Fazer metade de algo é, essencialmente, não fazer nada.** Em sprint, o mesmo: **se algo está pela metade no fim da sprint, você está pior do que se não tivesse começado.** Você gastou recurso, esforço e tempo e não levou nada a um estado entregável. Você tem um carro pela metade. **Teria sido melhor criar algo menor que realmente funcione.** > ⚠️ **A tradução para o Demoday.** Cinco funcionalidades a 80% não são apresentáveis. Duas funcionalidades a 100% são. Quando a equipe estiver decidindo o que cortar na última sprint, esse é o critério — e ele é o oposto do impulso natural, que é acabar tudo um pouquinho mais. --- ## 4. O que significa "pronto" Há duas definições no acervo, e elas não competem — encaixam uma na outra. ### A barra de engenharia Sutherland conta como a definição nasceu no projeto que ele descreve: em cada nota adesiva, a equipe escrevia não só **o que precisava ser criado**, mas também **como saberiam que aquilo estava pronto**. Foi assim que requisitos de conformidade regulatória, garantia de qualidade e relatórios de processo entraram no trabalho. Para a tarefa estar pronta, ela tinha de atender àqueles critérios. O ponto é o momento em que a conformidade entra: **embutida em cada item de trabalho, e não verificada no fim.** Assim, todo mundo do time — não só o pessoal de conformidade — tinha de atingir aquele nível de qualidade antes de passar ao item seguinte. **A quantidade de retrabalho que isso remove é enorme.** A definição: *pronto* é um **padrão que precisa ser atendido**, acordado antes, de modo que todo mundo saiba quando algo está pronto ou não, porque há critérios claros para qualquer peça de trabalho. **O par que dobra a velocidade duas vezes.** Para cada história deve haver uma **definição de Pronto para começar** e uma **definição de Pronto**: | | Pergunta | Efeito medido | |---|---|---| | **Pronto para começar** | Ela atende aos critérios INVEST? Há informação suficiente para completar o item? É pequeno o bastante para estimar? Existe definição de pronto? Gera valor visível? | Quando as histórias estão de fato prontas para começar, **o time dobra a velocidade de implementação** | | **Pronto** | Que condições precisam ser atendidas, que testes precisam passar, para chamar de encerrado? | Quando as histórias estão de fato prontas ao fim da sprint, **dobra de novo** | Os critérios **INVEST** que Sutherland lista para "pronto para começar": *Independente* (dá para completar sem depender de outra), *Negociável*, *Valiosa* (entrega valor a um cliente, usuário ou interessado), *Estimável* (dá para dimensionar), *Pequena* (se for grande demais, reescreva ou quebre) e *Testável* (tem um teste que precisa passar para estar completa — escreva o teste antes de fazer a história). **A regra da demonstração:** o time só demonstra o que atende à definição de pronto — **o que está total e completamente terminado e pode ser entregue sem mais nenhum trabalho.** Pode não ser um produto completo, mas deve ser uma funcionalidade completa de um. ### A barra de aprendizado Numa startup enxuta, a barra sobe: uma história só está completa quando alcança **aprendizagem validada**. O caso que Ries narra é o da Grockit, que aplicou o princípio kanban de restrição de capacidade à priorização de produto. As histórias passaram a ser catalogadas em **quatro estados**: | Estado | Significado | |---|---| | No backlog de produto | Ainda não começou | | Em desenvolvimento | Em curso | | **Concluída** | Recurso completo **do ponto de vista tecnológico** | | **Validada** | Sabe-se se a história era uma boa ideia | Validação vinha em geral na forma de teste comparativo mostrando mudança de comportamento do cliente, mas também podia ser entrevista ou sondagem. **Cada cesto aceita poucas histórias**; quando enche, não aceita mais. E o ponto que amarra: **só quando uma história foi validada é que ela pode sair do quadro**. Se a validação fracassa e a história se revela má ideia, **o recurso é removido do produto**. O efeito sobre a equipe: as equipes que trabalham nesse sistema começam a **medir a própria produtividade por aprendizagem validada, e não por produção de novos recursos**. ### Como conciliar num semestre O problema prático: verificação quantitativa leva tempo demais para caber numa sprint curta. Maurya resolve isso com **validação em duas fases**, e é essa a formulação a adotar na Q9: **Só a validação qualitativa declara a funcionalidade "pronta".** Isso libera a trava de trabalho em progresso, permitindo que outras funcionalidades comecem **enquanto mais dados são coletados**. A verificação quantitativa continua acontecendo, como estado posterior, comparando as coortes da semana em que a funcionalidade entrou no ar com a semana anterior. Traduzindo para a definição que a Q9 deve escrever: > **Pronto = padrão técnico acordado atendido + validação qualitativa com pelo menos um usuário da base de testes. A verificação quantitativa é um estado posterior, e não trava a sprint.** **Ação:** escreva a definição de pronto em uma frase, cole no quadro, e não a mude no meio do semestre. Uma definição de pronto escrita e estável vale mais para a nota do que uma cerimônia de Scrum completa e mal feita. --- ## 5. O limite de trabalho em progresso O princípio de kanban que restringe a fila de trabalho: **estabelecer limites para quantas funcionalidades podem estar em progresso ao mesmo tempo.** Isso maximiza a vazão e minimiza o desperdício. A recomendação de Maurya é operacional: **comece com um limite de trabalho em progresso igual ao número de fundadores ou de membros da equipe, e ajuste depois se precisar.** Três pessoas, três funcionalidades em andamento. Em times maiores é comum limitar também cada subestado — protótipo, demo, código —, mas Maurya considera isso exagero em equipe pequena. **A conexão com a seção 2 é o argumento inteiro:** o limite existe para impedir a equipe de se auto-sabotar com a tabela de troca de contexto. Não é burocracia; é a implementação da tabela. --- ## 6. O que entra no quadro Nem tudo. Maurya distingue **funcionalidade mínima comercializável** (MMF, do inglês *minimum marketable feature*) de funcionalidades menores e correções de defeito. O termo foi definido por Mark Denne e Jane Cleland-Huang em *Software by Numbers*: **a menor porção de trabalho que entrega valor ao cliente.** **O teste, e ele é uma pergunta:** *Você anunciaria isso aos seus clientes num post ou num informe?* **Se é pequeno demais para mencionar, não é uma MMF.** Uma MMF é normalmente composta de itens de trabalho menores. Maurya rastreia **só MMFs no quadro principal**, e usa uma ferramenta mais leve de quadro de tarefas para funcionalidades pequenas, correções e itens de trabalho. ### Os quatro complementos do quadro | Elemento | O que é | Por que existe | |---|---|---| | **Metas no topo** | Liste os objetivos e prioridades imediatas no alto do quadro | Mantém todo mundo na mesma página ao priorizar o backlog. Com limite de trabalho em progresso finito, a fila do backlog **precisa** ser priorizada contra as metas imediatas | | **Limite de trabalho em progresso visível** | Escrito na linha de cabeçalho | O limite que ninguém vê não é limite | | **Faixas de espera** | Cada etapa se divide em duas: a parte de cima para o que está "sob trabalho", a de baixo (o *buffer*) para o que foi **concluído e aguarda ser puxado** para a etapa seguinte | Torna visível o acúmulo entre etapas — o estoque em processo da seção 3 | | **Itens podem ser mortos em qualquer estágio** | Múltiplas etapas de validação com cliente estão embutidas no ciclo de vida. Se falha a validação, o item volta à etapa anterior para retrabalho **ou é morto**. Itens marcados para morrer aparecem em vermelho | Impede que uma ideia ruim atravesse o quadro só porque já entrou | **Ação:** monte o quadro na semana da Q9, ainda que vazio, com as metas escritas no topo e o número do limite no cabeçalho. Fotografe e coloque na entrega. Quadro é evidência verificável de organização; texto sobre metodologia não é. --- ## Fontes - **Sutherland, Jeff**, *Scrum* — cap. 3: tamanho de time (sete mais ou menos dois), Lei de Brooks (Fred Brooks, *The Mythical Man-Month*, 1975), o levantamento de Lawrence Putnam com 491 projetos e o dado dos 25% de esforço, a fórmula de canais n(n−1)/2 com a tabela, Miller (1956) e a correção de Cowan (2001), a exigência de transparência total no time; cap. 5: a tabela de multitarefa de Gerald Weinberg (*Quality Software Management*), o exercício das linhas e colunas com 39 e 19 segundos, a interferência de tarefa dupla de Harold Pashler, os três projetos que terminam em maio em vez de julho, o custo de reconstruir a arquitetura mental, "trabalho pela metade é igual a zero"; cap. 6 e apêndice: a definição de pronto, os critérios INVEST, o par pronto-para-começar e pronto e o duplo ganho de velocidade, a regra de só demonstrar o que está pronto - **Maurya, Ash**, *Running Lean*, cap. 13 — o limite de trabalho em progresso igual ao número de membros da equipe, o princípio de kanban de restrição de fila, MMF e o teste do informe (definição original de Denne & Cleland-Huang, *Software by Numbers*), metas no topo do quadro, faixas de espera, itens que podem ser mortos em qualquer estágio, e a validação em duas fases que declara "pronto" pela validação qualitativa - **Ries, Eric**, *A startup enxuta*, cap. 7 — o caso da Grockit: os quatro estados da história, "validada" como condição para sair do quadro, a remoção do recurso quando a validação fracassa, e a mudança da medida de produtividade para aprendizagem validada --- # Quest #10 — Preparação para o Demoday > **Objetivo.** Organização do evento de lançamento e apresentação do projeto desenvolvido. | | | |---|---| | **Modo de IA** | 🟡 com apoio no roteiro · 🟢 coprodução no material do evento — quem apresenta e defende é você | | **Milestone** | **Pitch** | | **Entrega** | roteiro de 8 minutos, plano de demonstração e material do evento | | **Erro que mais custa** | começar pela equipe e pela tecnologia | --- ## O que se prepara Planejar como apresentar, demonstrar e **provocar impacto** no público, no primeiro contato dele com a solução. O objetivo é captar interesse e, possivelmente, futuros investidores. A banca é composta por profissionais de atuação reconhecida no mercado — pessoas que **não acompanharam o projeto** e que vão formar juízo em 8 minutos. --- ## O roteiro: siga a ordem das quests A dica da própria disciplina, e ela é boa porque a metodologia já é um argumento: > Quem é seu usuário/cliente? Qual o problema que o incomoda? Por que esse problema é relevante? Por que os concorrentes não o trataram adequadamente? Qual é a sua proposta única de valor? Como ela vai concretamente entregar esse valor? Traduzido em minutos: | Tempo | O quê | Vem da | |---|---|---| | 0:00–0:45 | **A pessoa e a cena.** Concreta, nomeada | Q1, Q4 | | 0:45–1:45 | O problema e por que é relevante — **com evidência**, e a qual ODS ele responde | Q1, Q2 | | 1:45–2:30 | Por que o que existe hoje não resolve | Q3 | | 2:30–3:15 | A proposta única de valor, **em uma frase** | Q5 | | 3:15–5:30 | **A demonstração** | Q6, Q8 | | 5:30–6:30 | Que o negócio se paga: preço, custo, tração | Q7 | | 6:30–7:15 | O que já funciona, o que não, e o que vem | Q8, Q9 | | 7:15–8:00 | Pedido claro e fechamento | — | A demonstração é o maior bloco. É ela que a banca lembra. **A ordem que não funciona:** começar pela equipe e pela stack. Ninguém se importa com a sua tecnologia antes de se importar com o problema. --- ## O que faz uma boa história de projeto Cinco atributos, e eles viram checklist dos 8 minutos: 1. **Uma necessidade satisfeita no centro** — a narrativa central é sobre como uma ideia atende a uma necessidade de forma poderosa. 2. **Cada personagem com propósito**, e a história se desenrola envolvendo cada participante na ação. 3. **Convincente sem detalhe desnecessário.** 4. **Detalhe suficiente** para ancorar numa realidade plausível. 5. **Prova de que este time consegue realizar** — a plateia não pode ficar em dúvida sobre isso. > O designer é um contador de histórias, e sua habilidade se mede pela capacidade de construir uma narrativa convincente, consistente e crível. > > — Tim Brown, *Change by Design* **Dois momentos críticos: o começo e o fim.** No começo — a narrativa deve ter sido tecida ao longo do projeto, não montada na véspera. No fim — a história ganha tração quando a plateia a adota e a leva adiante. E um argumento útil para enquadrar "o que ainda não funciona": a narrativa de design não é um arco fechado com começo, meio e fim arrumadinhos, mas uma **narrativa aberta** que engaja as pessoas e as encoraja a escrever a própria conclusão. **Final aberto é o formato correto, não uma desculpa.** ### Estruturas narrativas que funcionam num pitch - **Jornada do usuário** — as etapas pelas quais alguém passa, do início ao fim da experiência. No caso clássico do trem de alta velocidade, a jornada tinha dez etapas e o passageiro só sentava no trem na oitava: sete oportunidades de valor teriam sido invisíveis se o time olhasse só a poltrona. **Coloque a jornada de antes e a de depois lado a lado** — é o slide mais eficiente do pitch. - **Storyboard** — a sequência quadro a quadro, para garantir que a história se sustenta antes do trabalho de detalhe. - **Cenário** — situação futura descrita com palavras e imagens, com um personagem plausível. Num caso conhecido, um vídeo curto seguindo um time fictício foi **muito mais eficaz para explicar o conceito a investidores** do que um documento técnico ou um deck. --- ## As perguntas da entrega 1. **Como é o elevator pitch da solução?** 2. **Qual o nome comercial e o slogan?** 3. **Como e quanto o usuário pagará, e de que forma?** 4. **O que ainda não está implementado ou funcionando?** 5. **Como a solução será experimentada pelo público no Demoday?** 6. **O que a equipe precisará preparar para o evento?** **A pergunta 4 parece perigosa e é o contrário.** Declarar o que não funciona é o que dá credibilidade ao que funciona. Banca experiente identifica o buraco sozinha; a diferença é se você o apresentou ou foi pego. --- ## Falar de tração sem inventar número A banca vai perguntar se alguém usa. Duas maneiras honestas de responder. ### O teste de product-market fit Uma pergunta, aplicada à sua base de usuários: > **"Como você se sentiria se não pudesse mais usar [produto]?"** > — Muito decepcionado > — Um pouco decepcionado > — Não decepcionado (não é tão útil assim) > — N/A — não uso mais **O limiar:** se mais de **40%** respondem "muito decepcionado", há boa chance de se construir crescimento sustentável em cima de um produto que é *must-have*. O número saiu da comparação de resultados entre centenas de startups: acima de 40% conseguem escalar de forma sustentável; significativamente abaixo, sempre parecem sofrer. **Duas ressalvas honestas**, que valem dizer à banca: a redação pode precisar de ajuste em contexto corporativo; e o teste pede amostra e segmentação — ele é melhor aplicado quando já se está perto do ajuste produto-mercado. **Ele ajuda a determinar se há tração inicial; não ajuda a conquistá-la.** ### Quando não dá para rodar a pesquisa Use **retenção**: há tração inicial quando você retém 40% dos usuários ativados, mês após mês. E a ordem que importa: **receita é a primeira forma de validação; retenção é a forma definitiva.** --- ## Pitch de alto conceito Destilação num *sound bite* memorável, no formato **"[referência conhecida] para/sem [torção]"**: *"Flickr para vídeo"*, *"Tubarão no espaço"*. **Não é a PUV, e não vai na landing page** — há o risco de a referência ser desconhecida do público. Onde serve: como gancho memorável que ajuda quem ouviu a espalhar a ideia. **A torção operacional:** ancore na ferramenta que **o interlocutor** já usa. Num Demoday, isso significa ancorar no que a banca conhece. --- ## A apresentação Da orientação da disciplina: - **Escolha alguém que se sinta seguro e confiante.** Não é rodízio democrático. - **Treine a fala para caber nos 8 minutos** — cronometrada, em voz alta, mais de uma vez. Quase toda equipe estoura no primeiro ensaio. - **Slides bonitos, claros, limpos, sem excesso de texto.** - **Prepare-se para demonstrar** ao público presente. E o que os pitches gravados de edições anteriores mostram com regularidade: **quem lê o slide perde a banca; quem conta a história de uma pessoa concreta prende.** O ensaio que vale é o que tem alguém de fora assistindo — de preferência alguém que não sabe nada do projeto, para dizer em que minuto se perdeu. --- ## A demonstração ao vivo O maior risco do dia. Quatro regras: 1. **Tenha um plano B gravado.** Vídeo de 60 segundos da solução funcionando, pronto para rodar. Wi-fi de evento cai. 2. **Ensaie no ambiente**, se possível: luz, som, mesa, tomada, distância do público. 3. **Demonstre o caminho feliz.** Não é hora do caso extremo — é hora do valor sendo entregue. 4. **Defina quem faz o quê.** Uma pessoa fala, outra opera. As duas ao mesmo tempo dá errado. E as diretrizes de demo que valem também aqui: precisa **parecer real** e usar **dados verossímeis**. Nada de *lorem ipsum* — dado plausível sustenta a narrativa. --- ## Autodiagnóstico — milestone *Pitch* Mede a clareza e o entendimento próprio sobre o que se apresenta: a comunicação será clara para quem não passou meses no projeto? Os alunos compreendem isso? Quanto esforço para tornar compreensível no primeiro contato? - [ ] Alguém de fora assistiu ao ensaio e entendeu, **sem eu explicar depois**? - [ ] Cabe em 8 minutos **cronometrados**? - [ ] A demonstração tem plano B gravado? - [ ] Digo claramente o que **não** está pronto? - [ ] Existe um **pedido explícito** no final? - [ ] O primeiro minuto fala de uma pessoa, ou da equipe e da tecnologia? - [ ] Se me perguntarem "de onde veio esse número?", eu tenho a fonte? Nível 2 típico: slides prontos, sem ensaio cronometrado, demo dependendo de wi-fi. Nível 4: roteiro na ordem das quests, ensaiado com plateia externa, demo com plano B, limitações declaradas, pedido claro. --- ## Referências desta quest | Arquivo | Quando | |---|---| | **Roteiro do pitch — Quest #10** (neste arquivo) | Ao montar. Estrutura minuto a minuto, o que vai em cada bloco, os erros de ordem | | **Tração e números — Quest #10** (neste arquivo) | Ao falar de resultado. O teste de PMF, retenção, o que dizer quando não há número | | **A demonstração — Quest #10** (neste arquivo) | Ao preparar a demo. Regras, plano B, ensaio, montagem do espaço | | **Autodiagnóstico — Quest #10** (neste arquivo) | Antes do evento | --- ### Antes de registrar pessoas | Arquivo | Quando | |---|---| | `../../metodo/consentimento.md` | Antes do Demoday. O que não vai para o slide, e o que fazer se você for cadastrar visitantes no evento | --- ### Técnicas desta quest Fichas curtas de consulta rápida. Abra quando o procedimento acima mencionar a técnica. | Ficha | Para quê | |---|---| | **Jornada do Usuário** (neste arquivo) | o slide antes-e-depois | | **Brainstorm** (neste arquivo) | gerar aberturas para o pitch | --- ## Perguntas frequentes **"E se o projeto não estiver pronto?"** Apresente o que está, diga com precisão o que falta e por quê, e mostre o que aprendeu. Projeto incompleto apresentado com honestidade vai melhor com a banca do que projeto incompleto apresentado como se estivesse pronto — porque a segunda opção destrói a confiança em tudo o mais que você disse. **"Podemos usar IA para gerar os slides e o roteiro?"** Para estruturar e criticar, sim. Mas o pitch é o milestone que mede se **você** entende o que construiu. Roteiro que você não escreveu é roteiro que você não defende na pergunta da banca — e a pergunta vem. **"Quanto tempo de ensaio?"** No mínimo três passagens cronometradas, sendo a última com plateia externa. E ensaie a **transição** entre quem fala e quem opera a demo — é onde as apresentações quebram. --- ## Referências de pitch da disciplina Há dois pitches de edições anteriores usados como referência — **Blun** (Demoday CIn 2019.1) e **Potlatch** (Demoday CIn 2019.2), ambos com transcrição no material da disciplina. Assista aos dois com o roteiro acima na mão, marcando em que minuto cada bloco acontece. --- ## Bibliografia desta quest | Obra | O que ela dá para a Q10 | |---|---| | **Maurya — Running Lean** | Teste de product-market fit, retenção, pitch de alto conceito, regras da demo | | **Brown — Change by Design** | Storytelling de projeto, jornada, storyboard, cenário, os dois momentos críticos | | **Ries — A startup enxuta** | O que reportar como progresso: aprendizado, não funcionalidades | # Autodiagnóstico — Quest #10 Faça este exercício **antes** do evento, depois do primeiro ensaio cronometrado e antes do último. Ele é o mesmo que o mentor vai fazer depois — e boa parte dele é o que a banca vai fazer no dia. --- ## A escala O milestone da Q10 é **Pitch**. Ele mede a clareza e o entendimento próprio sobre o que se apresenta: a comunicação será clara para quem não passou meses no projeto? Os alunos compreendem isso? Quanto esforço é preciso para tornar aquilo compreensível no primeiro contato? | Nível | Significado | |---|---| | **0** | O critério ainda não aparece. | | **1** | Já aparece, mas sem clareza nem coerência. | | **2** | Falta clareza **ou** falta coerência. A resposta ainda está no terreno da insegurança. | | **3** | Coerente, mas ainda não totalmente claro. Resta uma parcela de incerteza. | | **4** | Claro e coerente com toda a proposta. Ainda cabe aperfeiçoar, mas a equipe responde com segurança. | | **5** | Perfeitamente alinhado ao conjunto. As respostas são sólidas. | **Nível 2 típico:** slides prontos, sem ensaio cronometrado, demo dependendo do Wi-fi do evento. **Nível 4:** roteiro na ordem das quests, ensaiado com plateia externa, demo com plano B gravado, limitações declaradas, pedido claro. O salto que trava a maioria na Q10 é o **2 → 3**, e ele quase nunca é sobre design de slide: é sobre a equipe não ter descoberto ainda que **ninguém na banca sabe do que se trata**. Entender uma solução para a qual não se tem referência prévia é mais difícil que o normal — o que parece óbvio para quem está imerso produz percepção completamente diferente em quem tem o primeiro contato. --- ## Rubrica por dimensão ### 1. Estrutura do roteiro | | | |---|---| | **2** | Começa pela equipe e pela stack; a solução aparece antes do problema. | | **3** | Ordem correta, mas os blocos não têm tempo atribuído e o roteiro não foi cronometrado por bloco. | | **4** | Ordem das quests, com tempo por bloco, e a demonstração como maior bloco. Cada bloco tem um propósito declarado. | | **5** | O acima, com a jornada de antes e a de depois lado a lado, e com o retorno explícito à pessoa do minuto zero no fechamento. | ### 2. A pessoa e a evidência | | | |---|---| | **2** | Abertura com dado de mercado ou com adjetivo ("problema gigantesco"). | | **3** | Há uma pessoa citada, mas genérica ("o estudante brasileiro"). | | **4** | Pessoa concreta, com nome e cena, vinda da observação de campo; **um** dado externo com fonte, ano e link, aberto e conferido. | | **5** | O acima, com o reconhecimento explícito de onde o dado não cobre o que a equipe observou. | ### 3. Demonstração | | | |---|---| | **2** | Demo ao vivo, sem ensaio no ambiente, dependendo da rede do evento. Dados de teste na tela. | | **3** | Demo ensaiada, mas sem plano B, ou com plano B que ninguém testou. | | **4** | Caminho feliz, dados verossímeis, conta já povoada e logada, **plano B gravado em arquivo local**, uma pessoa fala e outra opera. | | **5** | O acima, com uma passagem de ensaio inteira feita pelo plano B, e com o ambiente de demonstração congelado na semana do evento. | ### 4. Números | | | |---|---| | **2** | Percentual sem base, ou número de cadastros apresentado como tração. | | **3** | Números corretos, mas sem definição de "usuário ativo" nem período. | | **4** | Todo número com base, período, definição e origem; o instrumento nomeado (teste de Sean Ellis ou retenção) e suas limitações declaradas. | | **5** | O acima, e a equipe responde a "de onde veio esse número?" sem consultar nada. | ### 5. Honestidade sobre o que falta | | | |---|---| | **2** | Nada é dito, ou o que falta aparece só quando a banca pergunta. | | **3** | "Ainda estamos ajustando algumas coisas." | | **4** | Bloco próprio, com o que está pronto, o que não está, **por quê**, e o que vem em seguida com data. | | **5** | O acima, enquadrado como narrativa aberta: o que a banca ou um parceiro poderia fazer para levar aquilo adiante. | ### 6. Entrega e material do evento | | | |---|---| | **2** | Nome comercial e slogan improvisados na véspera; nada preparado além dos slides. | | **3** | Material feito, mas sem definição de quem faz o quê no dia. | | **4** | Nome, slogan, elevator pitch, forma de cobrança e plano de como o público vai experimentar a solução, com papéis do dia distribuídos. | | **5** | O acima, com a mesa desenhada, o que fica com o visitante definido, e **como os contatos coletados serão registrados**. | --- ## Checklist rápido - [ ] O primeiro minuto fala de uma pessoa, ou da equipe e da tecnologia? - [ ] A solução aparece só depois de o problema estar estabelecido? - [ ] Cabe em 8 minutos **cronometrados**, em voz alta? - [ ] A demonstração é o maior bloco? - [ ] Existe um **pedido explícito** no final, e ele é específico? - [ ] Existe plano B gravado, **em arquivo local**, e alguém já ensaiou a passagem inteira com ele? - [ ] Os dados na tela são verossímeis, ou são "Teste 1" e *lorem ipsum*? - [ ] A conta já está logada e povoada, ou vamos cadastrar na frente da banca? - [ ] Uma pessoa fala e outra opera, e as duas ensaiaram juntas? - [ ] Se me perguntarem "de onde veio esse número?", eu tenho a fonte — para **cada** número na tela? - [ ] Todo percentual tem a base absoluta ao lado, e "usuário ativo" está definido? - [ ] Algum número no slide é métrica de vaidade — total de cadastros, total de acessos? - [ ] Digo claramente o que **não** está pronto, **por quê**, e o que vem depois? - [ ] Alguém de fora assistiu e entendeu, **sem eu explicar depois** — e disse em que minuto se perdeu? - [ ] Ensaiamos a transição entre quem fala e quem opera, e as três perguntas duras? **Sinal de alerta:** se a equipe precisa explicar o pitch depois de apresentá-lo a alguém de fora, o pitch ainda não está pronto — a explicação posterior é o conteúdo que faltava dentro dos 8 minutos. **Segundo sinal:** se o roteiro foi escrito na semana do evento, do zero, a narrativa não foi tecida ao longo do projeto. Ela pode ainda ser boa; mas confira se cada afirmação dela tem uma quest anterior por trás. A que não tiver é a que a banca vai perguntar. --- ## 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. *A Q10 é 🟡 com apoio. Para estruturar e criticar o roteiro, a IA rende. Mas o pitch é o milestone que mede se você entende o que construiu: roteiro que você não escreveu é roteiro que você não defende na pergunta da banca — e a pergunta vem.* 2. **O que a IA gerou e você descartou — e por quê.** *Típico da Q10: a IA devolve um roteiro com adjetivos de marketing e uma projeção de mercado. Descartar a projeção e trocar o adjetivo por um comportamento observado é o comportamento esperado.* 3. **O que você verificou, e como.** *Típico da Q10: o dado externo do bloco de relevância. Diga qual afirmação você foi conferir na fonte primária, e o que encontrou.* 4. **O que ainda não sabe.** --- ## Como o mentor e a banca vão ler Cinco perguntas que aparecem com regularidade. Se você tem resposta para as cinco, está em 4: 1. **"Para quem é isso, exatamente?"** Se a resposta cresce enquanto você fala, o segmento não está fechado. 2. **"De onde veio esse número?"** Vale para o dado de relevância e para o de tração. Se a resposta for "vi numa matéria", a pergunta seguinte é qual matéria, e a seguinte é qual a fonte dela. 3. **"O que não funciona?"** Você já respondeu no bloco de 6:30 — então a resposta é "como eu disse". Se a banca precisou perguntar, o bloco não existiu ou não foi claro. 4. **"Por que a pessoa não continua fazendo do jeito que faz hoje?"** É a Q3 voltando: a alternativa existente, inclusive a gambiarra, e por que ela falha para esta pessoa. 5. **"Quem já usou?"** Nome, número e período. Ver `tracao-e-numeros.md` para o que dizer quando ainda não há. **Uma nota sobre projeto incompleto.** Apresentar o que está pronto, dizer com precisão o que falta e por quê, e mostrar o que foi aprendido vai melhor com a banca do que apresentar um projeto incompleto como se estivesse pronto — porque a segunda opção destrói a confiança em tudo o mais que você disse. Divergência entre a sua auto-avaliação e a leitura do mentor é informação útil, não constrangimento. # A demonstração — Quest #10 Abra este arquivo na semana anterior ao Demoday. A demonstração é o maior bloco do pitch e o maior risco do dia: é o que a banca lembra, e é a única parte que pode falhar ao vivo diante de todo mundo. Modo de IA: 🟢 **coprodução** na preparação — gerar os dados verossímeis do ambiente de demonstração, montar o roteiro de operação, escrever o texto do vídeo de plano B. 🔴 **sem assistência** na execução: quem opera é uma pessoa da equipe, que ensaiou. --- ## 1. As quatro regras | Regra | O que significa | O que dá errado sem ela | |---|---|---| | **1. Tenha um plano B gravado** | Um vídeo curto, de cerca de 60 segundos, da solução funcionando, já aberto num arquivo local, pronto para rodar | Wi-fi de evento cai, e a equipe passa dois dos oito minutos tentando reconectar | | **2. Ensaie no ambiente** | Luz, som, mesa, tomada, distância do público, resolução do projetor | A tela fica ilegível a cinco metros, ou o áudio do vídeo não sai | | **3. Demonstre o caminho feliz** | O fluxo em que o valor é entregue à pessoa do minuto zero do pitch | A equipe mostra o caso extremo para "provar robustez", gasta o tempo e a banca não vê o produto funcionando | | **4. Defina quem faz o quê** | Uma pessoa fala, outra opera. As duas coisas ao mesmo tempo dá errado | A narração para toda vez que é preciso clicar, e o ritmo se perde | **Sobre a regra 1, um argumento a favor do vídeo que vem da literatura, não do medo.** Brown registra três casos em que **o cenário em vídeo foi mais eficaz que a alternativa**: a Vocera mostrou o crachá de comunicação por voz seguindo uma equipe fictícia de suporte, num filme curto que foi muito mais eficaz para explicar o conceito a potenciais investidores do que um documento técnico ou um conjunto de slides; a Sony fez o mesmo com adolescentes em Tóquio; a Intel produziu a série "Future Vision", realizada em poucas semanas, por uma fração do custo de um anúncio convencional. **Vídeo não é o consolo de quem não conseguiu demonstrar ao vivo.** Em contextos em que o produto ainda não existe por inteiro, ele é frequentemente o formato superior. > ⚠️ **Uma correção à ordem de preparo usual.** A maioria das equipes grava o vídeo na véspera, se sobrar tempo — e não sobra. Inverta: **grave o vídeo primeiro**, quando o produto atinge o estado apresentável, na semana da penúltima sprint. Ele passa a servir de três coisas ao mesmo tempo: plano B, material do evento, e ensaio do roteiro da demonstração. E se a demo ao vivo funcionar no dia, você tem o vídeo sobrando; o inverso não é verdade. --- ## 2. As diretrizes de demo Maurya lista cinco diretrizes para qualquer demo — no contexto dele, uma demo de entrevista com cliente, mas as cinco valem inteiras para o Demoday. | Diretriz | O que ela diz | Aplicação na Q10 | |---|---|---| | **Precisa ser realizável** | Ele conta que conhece estúdios de design com times dedicados a construir demos iniciais, muito eficazes na venda, mas apoiadas em tecnologias que **não são aquelas em que o produto final é construído** — com elementos vistosos às vezes impossíveis de recriar. O resultado é uma desconexão entre o que foi prometido e vendido e o que é entregue | Não demonstre nada que a equipe não sabe construir. A banca é de mercado e pergunta | | **Precisa parecer real** | Ele também rejeita o extremo oposto: apoiar-se em wireframes ou esboços crus, mais rápidos de montar, mas que **exigem do cliente um salto de fé** sobre o produto final. **Quanto mais real a demo parecer, mais precisamente você consegue testar a solução** | O Demoday não é o momento do protótipo de papel. Esse momento foi a Q8 | | **Precisa ser rápida de iterar** | Você vai receber retorno de usabilidade valioso que precisa ser incorporado e testado nas conversas seguintes. Terceirizar a demo prejudica isso, porque a sua capacidade de iterar passa a depender da agenda de outra pessoa | Quem opera a demo tem de conseguir mexer nela | | **Precisa minimizar desperdício** | Criar uma simulação em qualquer coisa que não seja a tecnologia final gera algum desperdício. Maurya começa com esboço em papel e ferramentas de desenho, mas em algum momento converte para a tecnologia real | Na Q10, a demo deve ser o produto, ou o mais perto disso que der | | **Precisa usar dados verossímeis** | Em vez de dados fictícios genéricos — *lorem ipsum* —, invente dados que **pareçam reais**. Eles não só ajudam a diagramar a tela como **sustentam a narrativa da sua solução** | Este é o item que mais rende por hora investida. Ver seção 3 | E a frase que Maurya cita para fechar o argumento, de Jeffrey Zeldman: **conteúdo precede design; design na ausência de conteúdo não é design, é decoração.** --- ## 3. Os dados da demonstração É a parte mais barata de fazer certo, e a que mais separa uma demo que convence de uma que não. **O princípio:** os dados na tela precisam ser os dados **da pessoa do minuto zero do pitch**. Se a abertura falou de dona Marlene, agente comunitária de saúde no bairro X, a tela não pode mostrar "Usuário 1", "Teste", "aaa" e "João Silva". Ela mostra o bairro, os nomes plausíveis, a quantidade de casos que uma agente de fato acompanha, os horários em que ela de fato trabalha. | Faça | Não faça | |---|---| | Nomes, lugares e datas do domínio real do projeto | *Lorem ipsum*, "Teste 1", "asdf" | | Volume plausível de registros (nem 3, nem 10.000) | Uma lista com um item só, ou uma lista visivelmente gerada | | Estados variados: um item pendente, um concluído, um com problema | Tudo verde, tudo no estado feliz | | Valores que fazem sentido junto (data, quantidade, preço coerentes entre si) | Números aleatórios que não se somam | | Uma conta já povoada, com histórico | Cadastro do zero na frente da banca | **A regra de tempo que decorre disso:** **nunca demonstre cadastro e configuração.** Chegue com a conta pronta, logada, na tela em que o valor acontece. Configuração consome minuto e não mostra valor. Se o cadastro é o produto — se a PUV é justamente que cadastrar é fácil —, aí sim demonstre, e só ele. **Ação:** monte o ambiente de demonstração como um artefato próprio, com nome ("conta demo"), e congele-o. Não deixe ninguém rodar teste nele na semana do evento. --- ## 4. O ensaio Da orientação da disciplina e da prática das edições anteriores: - **No mínimo três passagens cronometradas**, em voz alta. Ensaio em silêncio mede outra coisa. - **A última passagem com plateia externa**, de preferência alguém que não sabe nada do projeto. A pergunta que se faz a essa pessoa não é "gostou?" — é **"em que minuto você se perdeu?"**. - **Ensaie a transição** entre quem fala e quem opera. É onde as apresentações quebram: a fala para, a mão procura o mouse, e três segundos de silêncio viram trinta. - **Ensaie a falha.** Uma passagem inteira em que, no minuto 3:15, o Wi-fi "cai" e a equipe tem de partir para o vídeo. Se a transição para o plano B nunca foi ensaiada, ela vai levar um minuto no dia. - **Ensaie as perguntas.** Peça a alguém de fora que faça três perguntas duras ao fim — de onde veio o número, o que não funciona, e por que não usar a alternativa existente da Q3. A meta do ensaio não é decorar; é **descobrir onde o roteiro estoura**. Quase toda equipe estoura o tempo na primeira passagem, e o bloco que estoura raramente é o que a equipe imagina. --- ## 5. A montagem do espaço Aqui vale um argumento que Brown desenvolve sobre prototipagem de experiência, porque ele muda o modo de pensar o estande ou a mesa do Demoday: **a experiência que se desenrola no tempo e envolve o participante é ela mesma um protótipo.** Ele descreve equipes que alugaram um galpão e construíram, em papelão, a réplica em tamanho real do lobby e de uma suíte de hotel — não para mostrar qualidade estética, mas para servir de **palco em que designers, clientes e "hóspedes" pudessem encenar diferentes experiências de serviço** e explorar, em espaço e tempo reais, o que parecia certo. Todos os visitantes eram convidados a colar notas adesivas no protótipo e sugerir mudanças. A tradução para uma mesa de Demoday, se o evento tiver esse formato além do pitch: | Elemento | Decisão a tomar antes | |---|---| | **O que a pessoa vê ao chegar** | Qual tela está aberta, e o que ela comunica sem ninguém falar | | **O que a pessoa faz** | Ela opera, ou vocês operam? Se ela opera, qual é a **uma** tarefa que vocês pedem | | **Quanto tempo dura** | Uma interação de estande dura de 60 a 120 segundos. O que cabe | | **Quem fala com quem** | Alguém recebe, alguém demonstra, alguém anota. Rodízio combinado | | **O que fica com a pessoa** | Cartão, QR para a página, formulário de contato — e quem digita o que foi coletado | | **Como vocês registram** | Se dez pessoas passarem e nada for registrado, o evento não gerou dado. Uma folha com riscos já resolve | **Ação:** desenhe a mesa numa folha antes do dia, com onde fica cada pessoa e cada objeto. Cinco minutos de desenho eliminam a maior parte da improvisação do dia. --- ## 6. Divisão de papéis no dia | Papel | Faz | Não faz | |---|---|---| | **Quem apresenta** | Narra os 8 minutos. Uma pessoa, escolhida por se sentir segura e confiante, não por rodízio | Não opera o computador | | **Quem opera** | Conduz a demonstração no ritmo da narração; dispara o plano B se preciso | Não fala, exceto se combinado | | **Quem cuida da infraestrutura** | Cabo, tomada, adaptador, áudio, brilho, notificações desligadas, bateria; testa 30 minutos antes | Não é a mesma pessoa que apresenta | | **Quem responde a perguntas** | Pode ser mais de uma pessoa, mas **acorde antes quem responde o quê** — técnico, negócio, usuário | Não responde três ao mesmo tempo | | **Quem registra** | Anota as perguntas feitas pela banca e os contatos coletados | — | **A regra que resolve a maior parte dos acidentes:** as duas primeiras funções são de **duas pessoas diferentes**, e elas ensaiaram juntas. --- ## 7. Checagem final Coisas de custo quase zero que salvam a apresentação, e que se esquecem na semana da entrega: - Vídeo de plano B **no disco local**, não na nuvem, e já aberto num programa que funciona sem rede. - Notificações e mensagens desligadas em todas as telas que forem projetadas. - Ambiente de demonstração congelado, com dados verossímeis, conta já logada. - Adaptador de vídeo próprio, e um segundo cabo. - Bateria carregada e carregador na tomada, porque o slot pode atrasar. - Uma versão dos slides em PDF, num segundo dispositivo. - Modo avião no celular de quem apresenta; celular de outra pessoa com o cronômetro. - Alguém com a resposta pronta para "de onde veio esse número?" de cada número na tela. Ver `tracao-e-numeros.md`. **A última:** o que **não** está pronto, dito com precisão, no bloco de 6:30 do roteiro. Declarar é o que dá credibilidade ao que funciona; banca experiente identifica o buraco sozinha, e a diferença é se você o apresentou ou foi pego. --- ## Fontes - **Maurya, Ash**, *Running Lean*, cap. 8 — as cinco diretrizes da demo (realizável, parecer real, rápida de iterar, minimizar desperdício, dados verossímeis), a rejeição tanto da demo tecnologicamente descolada quanto do wireframe cru, e a citação de Jeffrey Zeldman sobre conteúdo preceder design - **Brown, Tim**, *Change by Design*, cap. 4 — os cenários em vídeo da Vocera, da Sony e da Intel e a comparação com documento técnico e conjunto de slides; a encenação como protótipo, o galpão com a réplica em papelão do lobby e da suíte, e o convite ao visitante para intervir no protótipo - **Material da disciplina** — a orientação sobre quem apresenta, o tempo de 8 minutos, a preparação para demonstrar ao público presente, e a pergunta 4 da entrega sobre o que ainda não está implementado # Roteiro do pitch — Quest #10 Abra este arquivo ao montar os 8 minutos, e de novo depois do primeiro ensaio cronometrado, quando for preciso cortar. Ele trata do que vai em cada bloco, dos erros de ordem, e das três estruturas narrativas que funcionam num pitch de projeto. Modo de IA: 🟡 **com apoio**. A IA critica o roteiro, cronometra a leitura, aponta o bloco inchado e faz as perguntas que a banca faria. Ela não escreve o roteiro — o pitch é o milestone que mede se **você** entende o que construiu, e roteiro que você não escreveu é roteiro que você não defende na pergunta. --- ## 1. A estrutura, bloco a bloco A ordem vem da própria metodologia da disciplina: quem é o usuário, qual o problema, por que ele é relevante, por que os concorrentes não o trataram, qual é a proposta única de valor, e como ela entrega esse valor concretamente. A metodologia já é um argumento — seguir a ordem das quests mostra que houve método, sem que ninguém precise dizer isso. | Tempo | Bloco | Vem da | O que **entra** | O que **não entra** | |---|---|---|---|---| | 0:00–0:45 | **A pessoa e a cena** | Q1, Q4 | Uma pessoa concreta, com nome e situação. Onde ela está, o que está tentando fazer, o que dá errado. Uma frase de observação de campo | Estatística de abertura. Nome da equipe. Agradecimento | | 0:45–1:45 | **O problema e por que é relevante** | Q2 | A dor descrita como comportamento observado, e **um** dado externo com fonte que dimensiona | Três dados. Adjetivos ("gigantesco", "alarmante") | | 1:45–2:30 | **Por que o que existe hoje não resolve** | Q3 | As alternativas existentes, inclusive a gambiarra que as pessoas usam. Por que elas falham para **esta** pessoa | Tabela comparativa de funcionalidades com sinais de certo e errado | | 2:30–3:15 | **A proposta única de valor** | Q5 | Uma frase. A PUV, dita e mostrada na tela | A lista de funcionalidades | | 3:15–5:30 | **A demonstração** | Q6, Q8 | O caminho feliz, com dados verossímeis, resolvendo o problema da pessoa do minuto zero. Ver `demonstracao.md` | Configuração, login demorado, tela de administração | | 5:30–6:30 | **Que o negócio se paga** | Q7 | Preço, como se cobra, custo principal, e o número de tração que existir. Ver `tracao-e-numeros.md` | Projeção de cinco anos. Tamanho de mercado sem caminho até ele | | 6:30–7:15 | **O que já funciona, o que não, e o que vem** | Q8, Q9 | O que está pronto, o que não está, o que foi aprendido no teste com usuários, e a próxima etapa com data | Roadmap de doze meses | | 7:15–8:00 | **Pedido e fechamento** | — | Um pedido explícito e específico, e o retorno à pessoa do minuto zero | "Obrigado, perguntas?" | **A demonstração é o maior bloco.** É ela que a banca lembra. Se ao cortar o roteiro você cortar a demonstração para caber, cortou a coisa errada. **Uma observação sobre o primeiro bloco.** Vale lembrar o que a Q8 registra: entender uma solução para a qual não se tem referência prévia é mais difícil que o normal. A banca é composta de profissionais que **não acompanharam o projeto** e vão formar juízo em 8 minutos. Os primeiros 45 segundos existem para dar a eles a âncora — uma pessoa e uma cena — a partir da qual tudo o mais faz sentido. --- ## 2. Os erros de ordem Não são erros de conteúdo. O material está todo lá; está na sequência errada, e a sequência errada custa a atenção da banca antes do minuto três. | Erro | O que acontece | A correção | |---|---|---| | **Começar pela equipe** | "Somos cinco alunos do CIn e temos paixão por tecnologia." Ninguém se importa com quem você é antes de se importar com o problema | A equipe entra no bloco de 6:30, como parte da prova de que dá para realizar | | **Começar pela tecnologia** | A stack, a arquitetura, o modelo usado. Ninguém se importa com a sua tecnologia antes de se importar com o problema | A tecnologia entra na demonstração, implícita, ou no bloco de 6:30 se for diferencial real | | **Solução antes do problema** | A banca vê a tela sem saber o que ela resolve, e passa os minutos seguintes tentando reconstruir a pergunta | Nunca mostre tela antes do minuto 2:30 | | **Mercado antes da pessoa** | "O mercado de X movimenta R$ Y bilhões." Número grande sem ninguém dentro | O dado de mercado, quando entra, entra depois da cena, para dimensionar o que já foi descrito | | **Guardar o que não funciona para o fim** | Vira confissão de última hora, sob pressão de tempo, com a banca já em modo de julgamento | Bloco próprio, em 6:30, dito com calma | | **Deixar o pedido de fora** | O pitch termina em "obrigado" e a banca não sabe o que fazer com o que ouviu | Um pedido específico, dito em voz alta, nos últimos 45 segundos | --- ## 3. Os cinco atributos de uma boa história de projeto Brown descreve o que está no centro de qualquer boa história, e a descrição vira checklist dos 8 minutos: 1. **Uma necessidade satisfeita, no centro.** No coração de qualquer boa história está uma narrativa central sobre **o modo como uma ideia atende a uma necessidade de forma poderosa**. Os exemplos que ele dá são todos concretos e pequenos: combinar um jantar com amigos que estão em pontas opostas da cidade; aplicar insulina discretamente durante uma reunião de trabalho; migrar de um carro a gasolina para um elétrico. 2. **Cada personagem com propósito.** Conforme a história se desenrola, ela dá a **cada personagem representado nela um senso de propósito**, e se desenrola de um modo que **envolve cada participante na ação**. Num pitch: se você citou o gestor, o operador e o usuário final, os três precisam ter função na cena — não podem ser figurantes de slide. 3. **Convincente, sem detalhe desnecessário.** Ela convence sem nos sobrecarregar com detalhe que não serve. 4. **Detalhe suficiente para ancorar.** E, ao mesmo tempo, inclui **bastante detalhe para ancorá-la numa realidade plausível**. Os dois critérios são um par, não uma contradição: corte o detalhe que não ancora; mantenha o que ancora. 5. **Prova de que este time consegue realizar.** A história **não pode deixar a plateia em dúvida** de que quem a narra tem o que é preciso para torná-la real. O quinto atributo é o que a equipe costuma tentar cumprir no lugar errado — na abertura, apresentando currículos. Ele se cumpre melhor na demonstração que funciona, no teste com usuários que de fato aconteceu, e no plano com datas da Q9. > O designer é um contador de histórias, e a habilidade dele se mede pela capacidade de construir uma narrativa convincente, consistente e crível. **Um alerta de calibragem.** Brown conta o caso de uma apresentação para executivos de uma fabricante de ferramentas, em que a equipe transformou uma oficina abandonada num percurso narrativo — carros nas cores da marca na porta, sala com artefatos inspiracionais, vídeos de mecânicos reais falando da marca, e por fim uma sala escura em que se acendem as luzes sobre os protótipos. A vice-presidente de marketing chorou. E ele conclui com a ressalva que interessa: **nem sempre é necessário fazer a plateia chorar, mas uma boa história bem contada deve entregar um golpe emocional.** Num Demoday isso raramente é produção; é a pessoa do minuto zero sendo real. --- ## 4. As três estruturas narrativas ### A jornada É a estrutura de cenário mais simples e mais útil para serviço: ela **mapeia as etapas pelas quais um cliente imaginado passa, do começo ao fim da experiência**. O ponto de partida pode ser imaginário ou vir direto de observação. O valor de descrevê-la é que ela **deixa claro onde o cliente e o serviço se encontram** — e cada um desses pontos de contato é uma oportunidade de entregar valor, ou de perder a pessoa de vez. **O caso, com os números.** A Amtrak estudava um serviço de trem de alta velocidade na costa leste dos Estados Unidos. Quando a IDEO foi chamada para o projeto que virou o Acela, o foco já havia se estreitado aos trens e, na prática, ao **desenho das poltronas**. Depois de passar dias andando de trem com passageiros, a equipe montou uma jornada simples que descrevia o processo inteiro de viagem. Para a maioria dos clientes ela tinha **dez etapas**, incluindo chegar à estação, achar estacionamento, comprar passagem, localizar a plataforma. E o achado: **os passageiros só se sentavam no trem na etapa oito.** A maior parte da experiência de viajar de trem, portanto, não envolvia o trem. A conclusão da equipe: cada uma das etapas anteriores era uma oportunidade de criar uma interação positiva — oportunidades que teriam passado despercebidas se o time tivesse olhado só para a poltrona. Brown reconhece que isso tornou o projeto muito mais complexo, e observa que essa é a passagem típica do design para o pensamento de design. E o fecho: **a jornada do cliente foi o primeiro protótipo do processo.** **Como usar no pitch:** coloque **a jornada de antes e a jornada de depois lado a lado**, num slide só. É o slide mais eficiente que um pitch de projeto pode ter, porque ele mostra problema, solução e escopo ao mesmo tempo, sem texto. ### O storyboard A origem está no cinema. Quando o filme era pouco mais que teatro gravado, dava para ir do roteiro direto à filmagem. Conforme os diretores ficaram mais ambiciosos, com múltiplas câmeras e efeitos, **o storyboard surgiu como forma de mapear o filme antes de rodá-lo**, para garantir que todas as cenas estivessem pensadas e que o diretor não descobrisse na ilha de edição que faltava um ângulo essencial. Com a animação, ele ganhou papel ainda maior: virou **ferramenta de prototipagem que permitia aos animadores se certificarem de que a história se sustentava antes de começar o trabalho de detalhe**. **Como usar no pitch:** desenhe os 8 minutos em oito quadros antes de abrir o editor de slides. Se a história não se sustenta em oito quadros de rabisco, ela não vai se sustentar com transições bonitas. Val Head faz a mesma recomendação para animação de interface: o storyboard é mais útil quando cobre **a frase inteira de interação**, e não trechos soltos. ### O cenário É uma forma de narrativa em que **uma situação futura possível é descrita com palavras e imagens**. Brown descreve o método: inventar um personagem que se encaixe num conjunto de características que interessam — ele dá o exemplo de uma profissional divorciada com duas crianças pequenas — e desenvolver ao redor dela uma rotina diária crível, para "observar" como ela usaria o produto. **Os casos, e o que eles mostram sobre plateia.** Quando a comunicação por Wi-Fi ainda engatinhava, a Vocera fez um cenário em vídeo mostrando como funcionários poderiam usar um crachá de comunicação por voz para se manterem conectados. O filme curto seguia a rotina de uma equipe fictícia de suporte de TI, e foi **muito mais eficaz para explicar o conceito a potenciais investidores do que um documento técnico ou um conjunto de slides**. A Sony usou a mesma técnica no início dos anos 1990, criando cenários sobre a vida de adolescentes em Tóquio para mostrar como eles usariam novos tipos de casa de jogos on-line. E a Intel, querendo mostrar como seria a vida num mundo de computação ultramóvel, produziu uma série de cenários em filme — o "Future Vision" — que uma equipe de design realizou em poucas semanas, por uma fração do custo de um anúncio convencional. O terceiro valor do cenário, e é o que ele faz por você durante o preparo: **ele obriga a manter as pessoas no centro da ideia**, impedindo que a equipe se perca em detalhe mecânico ou estético. **Como usar no pitch:** o cenário é o plano B da demonstração. Um vídeo curto seguindo uma pessoa plausível resolve o problema de mostrar o que ainda não existe, e resolve o problema do Wi-Fi do evento. Ver `demonstracao.md`. --- ## 5. Os dois momentos críticos Brown é específico: a narrativa eficaz, como parte de um programa maior, **depende de dois momentos críticos — o começo e o fim.** **No começo.** É essencial que a narrativa **comece cedo na vida do projeto e seja tecida em cada aspecto do esforço**. Ele observa a mudança de prática: era comum trazer quem escreve só no fim, para documentar um projeto concluído; cada vez mais as equipes incorporam essa pessoa **desde o primeiro dia**, para mover a história em tempo real. > ⚠️ **É por isso que o pitch não se monta na véspera.** Uma equipe que registrou o que aprendeu em cada quest chega à Q10 com a narrativa quase pronta — a pessoa do minuto zero é alguém que ela observou na Q1, a evidência é a que ela levantou na Q2, o que não funciona é o que apareceu no teste da Q8. Uma equipe que não registrou vai ter de inventar, e a banca percebe. O material da Q10 não é criação: é **seleção** do que já foi produzido. **No fim.** A história **ganha tração quando é adotada pela plateia**, que se sente motivada a levá-la adiante muito depois de a equipe ter se dispersado. E daí decorre o argumento que resolve o problema mais delicado da Q10 — o que dizer sobre o que ainda não funciona. Brown propõe que a narrativa do design não seja pensada no sentido de um **começo, meio e fim arrumadinhos**, mas como uma **narrativa contínua e aberta, que engaja as pessoas e as encoraja a levá-la adiante e escrever a própria conclusão**. Ele cita o filme de Al Gore como exemplo: ao final, o autor apresenta a evidência e **desafia os espectadores a tornarem aquilo deles**. Brown chama de mais um exemplo de pensamento de design em ação **deixar que o cliente escreva o último capítulo da história**. **Final aberto é o formato correto, não uma desculpa.** Mas há uma condição: final aberto exige que **você diga com precisão onde a história parou.** Ambiguidade sobre o que está pronto não é final aberto; é confusão. --- ## 6. O pitch de alto conceito Serve como gancho memorável, não como abertura. **O que é:** a destilação da ideia num *sound bite* memorável. Maurya registra a origem — produtores de Hollywood usam para condensar o enredo geral de um filme — e o formato **"[referência conhecida] para/sem [torção]"**. Os exemplos que ele dá: *"Flickr para vídeo"*, *"Tubarão no espaço"*, *"Friendster para cachorros"*. **O que ele não é:** ele **não deve ser confundido com a PUV, e não se destina à página inicial do produto**. Há um risco real de os conceitos em que ele se apoia serem **desconhecidos do público**. Por isso ele é mais eficaz quando usado para passar a ideia rápido e **torná-la fácil de espalhar** — por exemplo, ao fim de uma conversa com um cliente. **A torção operacional:** ancore na ferramenta que **o interlocutor** já usa. Maurya faz isso literalmente: no exemplo dele, a instrução é substituir o nome do serviço de referência pelo nome do serviço que aquela pessoa específica usa. Num Demoday, isso significa ancorar no que **a banca** conhece — e a banca é de mercado, não de academia. **Onde ele cabe nos 8 minutos:** não no minuto zero. Ele cabe como a frase de fechamento do bloco da PUV, ou como a última frase antes do pedido — porque a função dele é ser o que a pessoa da banca repete para alguém depois do evento. --- ## 7. Preparar a fala Da orientação da disciplina, com o que a prática acrescenta: - **Escolha quem se sente seguro e confiante.** Não é rodízio democrático. A pessoa que apresenta e a que opera a demo podem ser duas — devem ser duas. - **Cronometre em voz alta, mais de uma vez.** Quase toda equipe estoura no primeiro ensaio. Ensaio em silêncio, lendo com os olhos, mede outra coisa. - **Slides limpos, sem excesso de texto.** Quem lê o slide perde a banca. O slide existe para mostrar o que não dá para dizer: a cena, a jornada antes e depois, o número, a tela. - **Ensaie com alguém de fora**, de preferência quem não sabe nada do projeto, e peça que essa pessoa diga **em que minuto se perdeu**. É a única medida útil de clareza que você consegue antes do dia. - **Ensaie a transição** entre quem fala e quem opera a demo. É onde as apresentações quebram. **Ação:** faça o storyboard de oito quadros antes de abrir o editor de slides. Depois cronometre a leitura de cada bloco separadamente e anote o tempo real ao lado da tabela da seção 1. O bloco que estoura sempre é o mesmo, e não é a demonstração. --- ## Fontes - **Brown, Tim**, *Change by Design* — cap. 4: cenários, o storyboard vindo do cinema e da animação, a jornada do cliente, o caso do Acela com as dez etapas e a etapa oito, os cenários em vídeo da Vocera, da Sony e da Intel, e o argumento de que o cenário mantém as pessoas no centro; cap. 7: os cinco atributos da boa história, o designer como contador de histórias, o caso da apresentação da fabricante de ferramentas e o golpe emocional, os dois momentos críticos (começo e fim), a narrativa aberta e o exemplo de Al Gore, deixar o cliente escrever o último capítulo - **Maurya, Ash**, *Running Lean*, cap. 3 e 7 — o pitch de alto conceito: origem em Hollywood, o formato, os exemplos, a advertência de não confundir com a PUV nem usar na página inicial, e a instrução de ancorar na referência que o interlocutor usa - **Head, Val**, *Designing Interface Animation*, cap. 10 — o storyboard cobrindo a frase inteira de interação, e não trechos soltos - **Krug, Steve**, *Não me faça pensar* — o argumento de que entender algo sem referência prévia é mais difícil do que parece para quem está imerso - **Material da disciplina** — a ordem das quests como estrutura do pitch, a orientação sobre quem apresenta, o tempo de 8 minutos e a composição da banca # Tração e números — Quest #10 Abra este arquivo ao preparar o bloco de 5:30 do pitch, e antes de escrever qualquer número num slide. A banca vai perguntar se alguém usa. Há duas maneiras honestas de responder, e uma terceira para quando não há número nenhum. Modo de IA: 🟡 **com apoio**. Peça à IA que faça as perguntas que a banca faria sobre cada número do seu slide — de onde veio, sobre qual base, em que período. 🔴 **sem assistência** na produção de números: nenhum número que a equipe não mediu entra na apresentação. --- ## 1. O teste de ajuste produto-mercado ### A origem O termo *product/market fit* — ajuste produto-mercado — foi cunhado por Andy Rachleff, cofundador da firma de capital de risco Benchmark Capital, e popularizado por um texto de Marc Andreessen. Maurya observa que esse texto **terminou com mais perguntas do que respostas** e não ofereceu orientação sobre como alcançar ou medir o ajuste. Quem tornou o conceito menos abstrato foi **Sean Ellis**, que dirigia a consultoria 12in6, especializada em ajudar startups na transição para crescimento. **Como condição para aceitar um cliente**, ele conduzia uma pesquisa qualitativa com uma amostra dos usuários da empresa, para determinar se o produto tinha tração inicial — o que era um bom indicador de que a empresa estava no caminho certo. ### A pergunta, exatamente como se aplica > **"Como você se sentiria se não pudesse mais usar [produto]?"** > > — Muito decepcionado > — Um pouco decepcionado > — Não decepcionado (não é tão útil assim) > — N/A — não uso mais Quatro opções. Não são cinco, não há escala de 1 a 10, e a redação da pergunta é feita no negativo — pela retirada, não pela satisfação. ### O limiar **Se mais de 40% dos usuários respondem "muito decepcionado"**, há boa chance de se construir crescimento de aquisição de clientes sustentável e escalável em cima de um produto que é *must-have* — indispensável. **De onde vem o número:** Maurya é explícito sobre a origem, e vale citar assim se perguntarem. O parâmetro de 40% foi determinado **comparando resultados entre centenas de startups**: as que ficavam acima de 40% geralmente conseguiam escalar o negócio de forma sustentável; as que ficavam significativamente abaixo **sempre pareciam sofrer**. --- ## 2. O que o teste mede, e o que ele não mede Maurya faz três ressalvas ao teste que ele mesmo recomenda. Todas as três valem dizer à banca — dizê-las é o que transforma um número emprestado em raciocínio próprio. | Ressalva | O que significa | O que fazer na Q10 | |---|---|---| | **A redação pode precisar de ajuste** | Maurya considera que a formulação exata poderia ser levemente ajustada conforme o mercado. Em contexto corporativo, por exemplo, insinuar que se vai retirar o produto pode não cair bem com clientes iniciais que estão investindo tempo nele. Fora isso, ele considera a premissa do teste sólida | Se você ajustou a redação, **mostre a redação que usou** | | **Pesquisa verifica, não ensina** | O desafio maior de aplicar o teste é o mesmo de qualquer pesquisa com cliente: **pesquisas são mais eficazes para verificação do que para aprendizado** | Não use o resultado para descobrir o que fazer. Use conversa para isso | | **Ele exige amostra e segmentação** | Para o resultado ser estatisticamente significativo, é preciso amostra grande o suficiente, considerar segmentação de clientes e considerar motivação do usuário. Por isso **o teste é melhor aplicado quando já se está perto do ajuste produto-mercado** — que é também o que o próprio Sean Ellis recomenda | Se a base tem 12 pessoas, **diga que tem 12** e trate o resultado como sinal, não como medida | E a limitação que resume as três: **O teste ajuda a determinar se há tração inicial; ele não ajuda a conquistá-la.** > ⚠️ **O erro mais provável na Q10.** Uma equipe roda a pergunta com os oito colegas que testaram, obtém 50%, e escreve "atingimos ajuste produto-mercado". Isso é errado por três motivos ao mesmo tempo: a amostra não sustenta, quem respondeu não é usuário real de uso continuado, e o teste é para quem **já está perto** do ajuste. A formulação defensável é: *"aplicamos o teste de Sean Ellis com as N pessoas da nossa base de testes; X responderam 'muito decepcionado'. A amostra não permite conclusão, e o teste pressupõe estar perto do ajuste — reportamos como sinal inicial."* Essa frase é mais forte diante da banca do que a afirmação, porque mostra que você sabe o que o instrumento faz. --- ## 3. A alternativa por retenção Quando não dá para rodar a pesquisa — e numa disciplina de um semestre normalmente não dá —, Maurya oferece um caminho pelos indicadores do ciclo de vida do cliente. **A distinção que orienta a escolha do indicador.** Alguns produtos capturam **valor de uma vez só**: fotógrafo de casamento, advogado de divórcio, livro, DVD. Outros capturam **valor recorrente por uso repetido**: software como serviço, redes sociais, restaurante, revista. | Tipo de produto | Indicador que mede "construiu algo que as pessoas querem" | |---|---| | Valor de uma vez | **Ativação** — a qualidade da experiência do serviço | | Valor recorrente | **Retenção** — a ativação continua importando, porque um bom primeiro contato ainda é necessário, mas o sucesso vem do uso repetido | Os dois juntos formam o que Maurya chama de **indicadores de valor**. **O argumento que permite transportar o limiar:** dá para sustentar que uso repetido de um produto por um período longo o bastante correlaciona de perto o suficiente com as respostas à pergunta do "muito decepcionado" de Sean Ellis. Isso torna possível aplicar **o mesmo limiar de 40%** à determinação de tração inicial. Maurya registra que consultou Sean Ellis sobre isso e que ele concordou. O critério, na formulação de Maurya: **você tem tração inicial quando está retendo 40% dos seus usuários ativados, mês após mês.** **Duas definições que precisam estar escritas antes de você medir:** 1. **O que conta como atividade.** Retenção mede atividade repetida ao longo de um período — então o primeiro passo é definir o que é atividade. 2. **O que conta como atividade *representativa*.** Uma definição mais fiel, para fins de ajuste produto-mercado, **não mede só uso, mas uso representativo**. Todo produto tem um conjunto central de ações que indicam uso contínuo real — escrever posts, no caso de uma plataforma de blog. E uma advertência que muda a conta: **a ação-chave da ativação pode não ser a mesma da retenção.** A taxa de retenção é calculada **sobre o número de usuários ativados** — não sobre o total de cadastros. **Ação para a Q10:** escreva as duas definições numa linha cada, antes de olhar qualquer dado. "Usuário ativado = quem completou X. Usuário retido = quem fez Y pelo menos uma vez no mês." Sem essas duas linhas, o percentual que você apresentar não significa nada, e a banca vai perguntar exatamente isso. --- ## 4. Receita e retenção não são a mesma validação Maurya defende cobrar desde o primeiro dia e considera o preço parte do produto. Mesmo assim, ele é explícito sobre o limite da receita como prova: **Receita é apenas a primeira forma de validação e, usada sozinha, pode ser um falso positivo como teste de ajuste produto-mercado.** Ele relata casos com os próprios produtos em que **clientes continuavam pagando por um produto que não usavam — nem esporadicamente**. Às vezes porque outra pessoa pagava (a empresa deles); às vezes porque simplesmente esqueceram de cancelar. E há a distração oposta: startups perseguindo o tipo errado de receita — acordos pontuais de licenciamento ou desenvolvimento sob medida. A ordem, que vale como frase de apresentação: > **Receita é a primeira forma de validação; retenção é a forma definitiva.** E o fecho prático: se você oferece um produto de compra única, cobra o valor apropriado e tem boa ativação, **a receita se resolve sozinha**. Se você oferece assinatura, cobra desde o primeiro dia e tem boa retenção, **a receita também se resolve sozinha**. **Como isso entra no bloco de 5:30 do pitch:** o slide de receita da Q7 não fecha o argumento de tração. Ele mostra que o modelo se sustenta. Quem fecha o argumento é o número de retenção — ou a declaração honesta de que ele ainda não existe. ### A ordem de trabalho, se houver tempo até o Demoday Maurya descreve a sequência de iteração rumo à tração inicial, e ela cabe nas últimas semanas do semestre: 1. **Revise os indicadores semanalmente** com a equipe inteira, num horário fixo. Identifique primeiro onde está vazando mais. 2. **Priorize as metas e o backlog** contra o que vazou. 3. **Formule hipóteses ousadas.** Nesta fase, evite experimentos de micro-otimização; formule hipóteses grandes, mas **construa a menor coisa possível** para testá-las. 4. **Acrescente ou mate funcionalidades** ao longo do ciclo de vida delas, conforme o impacto. 5. **Acompanhe as coortes de retenção.** O objetivo é ver movimento consistente para cima; do contrário, você está girando em falso. 6. **Quando a retenção se aproximar de 40%, considere rodar o teste de Sean Ellis.** Note que o teste é o **último** passo, não o primeiro. --- ## 5. O que dizer quando não há número É a situação mais comum na Q10, e ela tem resposta boa. A resposta não é inventar; é **mudar a unidade de progresso**. **A unidade que substitui.** Ries propõe a **aprendizagem validada**: não é racionalização depois do fato, nem boa história elaborada para ocultar fracasso. É um método rigoroso para demonstrar progresso quando se está no terreno de extrema incerteza — o **processo de demonstrar empiricamente que uma equipe descobriu verdades valiosas sobre as perspectivas de negócio presentes e futuras**. Ele a defende como mais concreta, mais exata e mais rápida do que prognóstico de mercado ou planejamento empresarial clássico, e como o antídoto principal contra "executar com sucesso um plano que não leva a lugar nenhum". E o modo correto de pensar produtividade numa startup, segundo ele: **não em termos de quanta coisa está sendo desenvolvida, mas de quanta aprendizagem validada se obtém a partir do esforço.** **O que evitar, e o nome que a coisa tem.** Ries chama de **métricas de vaidade** os números tradicionais usados para julgar startups: total de usuários cadastrados, total de clientes pagantes, receita bruta. O motivo do nome: eles **dão o quadro mais cor-de-rosa possível**. Você vê um gráfico em forma de taco de hóquei e conclui que há grande progresso. E ele nomeia também o comportamento associado: **teatro do sucesso** — o trabalho realizado para parecer bem-sucedido. Compra de anúncio de última hora, sobrecarga de canal de distribuição, **demonstrações impressionantes**, numa tentativa desesperada de fazer os números brutos parecerem melhores. A energia investida em teatro do sucesso é energia que poderia ter ajudado a desenvolver o negócio. O teste que ele aplica para separar uma coisa da outra: um número que não permite dizer **de onde ele veio e o que o causou** é métrica de vaidade. O exemplo dele: 40 mil visitas no mês, um recorde. São 40 mil pessoas novas ou uma pessoa com um navegador muito ativo? Vieram de uma campanha ou de uma nota na imprensa? O que conta como uma visita? > ⚠️ **A tradução direta para o Demoday.** "Tivemos 300 acessos" é métrica de vaidade. "Doze pessoas da nossa base usaram; oito voltaram na segunda semana; conseguimos falar com as quatro que não voltaram, e três disseram o mesmo motivo" é aprendizagem validada. O segundo enunciado tem números menores e sustenta muito mais pergunta. ### O roteiro de 60 segundos, quando não há tração Quatro frases, nesta ordem: 1. **Quantos usaram, nominalmente ou por grupo, e por quanto tempo.** Número pequeno dito com precisão. 2. **O que vocês aprenderam com eles que mudou o produto.** Uma mudança concreta, com o antes e o depois. 3. **Qual é o número que vocês vão medir, e a definição dele.** "Retenção = usuário ativado que faz X pelo menos uma vez no mês." 4. **Quando vocês vão medir.** Uma data. E a frase que enquadra tudo: *"ainda não temos volume suficiente para afirmar tração; temos aprendizado validado, e este é o instrumento com que vamos medir."* Isso é o oposto de fraqueza diante de uma banca de mercado — é a resposta que uma pessoa de mercado reconhece. --- ## 6. Regras para qualquer número no slide | Regra | Por quê | |---|---| | **Todo número tem base declarada** | "40% de 12 pessoas" é honesto; "40%" sozinho não é | | **Todo número tem período declarado** | Retenção sem janela de tempo não é retenção | | **Todo número tem definição declarada** | Sobretudo "usuário ativo" e "usuário ativado" | | **Todo número externo tem fonte, ano e link conferido** | E você **abriu** a fonte | | **Nenhum número que a equipe não mediu entra** | Se a pergunta "de onde veio esse número?" não tem resposta, tire o número | | **Percentual pequeno com base pequena vira número absoluto** | "3 de 12" comunica melhor e é mais difícil de contestar do que "25%" | **Ação:** antes do ensaio final, passe por cada slide e escreva, num papel à parte, a resposta à pergunta *"de onde veio esse número?"* para cada número exibido. Todo número sem resposta sai do slide. É o exercício de 15 minutos que mais protege a apresentação. --- ## Fontes - **Maurya, Ash**, *Running Lean*, cap. 14 — a origem do termo ajuste produto-mercado (Andy Rachleff; o texto de Marc Andreessen sem orientação de medida), Sean Ellis e a consultoria 12in6, a pergunta exata e as quatro alternativas, o limiar de 40% e sua derivação da comparação entre centenas de startups, as três ressalvas (redação, pesquisa como verificação e não aprendizado, exigência de amostra e segmentação), a limitação de determinar mas não conquistar tração, a distinção entre valor de uma vez e valor recorrente, a transposição do limiar de 40% para retenção com a concordância de Sean Ellis, a relação entre receita e retenção, e a sequência de iteração rumo à tração inicial; apêndice — como definir atividade e atividade representativa, e a base de cálculo da retenção sobre usuários ativados - **Ries, Eric**, *A startup enxuta*, cap. 3 e 7 — aprendizagem validada como unidade de progresso, produtividade medida por aprendizado e não por produção, métricas de vaidade, teatro do sucesso, e o teste das 40 mil visitas