Oportunidade Escolhida & Organização da Equipe

Guia da quest

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 referencias/decidir-sob-incerteza.md.

Depois, ranqueie as oportunidades — nesta ordem

Coloque as 2–3 oportunidades lado a lado. A ordem de peso, da maior para a menor:

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 referencias/decidir-sob-incerteza.md 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

Técnicas desta quest

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

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

Decidir sob incerteza

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”.

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

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.

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.

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:

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.

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

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.

Equipe

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.

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ê”

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:

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:

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

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

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.

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 (../../q02-oportunidades/referencias/quem-entrevistar.md), 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.

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:

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.

Autodiagnóstico

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

Rubrica — Problema

Rubrica — Similares

Rubrica — Escolha e equipe

A régua

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:

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.