Escreva o Pitch #

Agora temos os elementos de uma solução e mitigamos os riscos do nosso conceito ao ponto de estarmos confiantes de que é uma boa opção para entregar a uma equipe. Mas o conceito ainda está em nossas cabeças ou em alguns desenhos difíceis de decifrar no quadro branco ou no nosso caderno. Agora precisamos colocar o conceito em uma forma que outras pessoas possam entender, digerir e responder.

É aqui que dizemos “Ok, isso está pronto para ser redigido como um pitch”. Neste capítulo, vamos passar pelos ingredientes de um pitch e mostrar alguns exemplos completos de projetos reais no Basecamp.

O propósito do pitch é apresentar uma boa aposta potencial. É basicamente uma apresentação. Os ingredientes são todas as coisas que precisamos para capturar o trabalho feito até agora e apresentá-lo de uma forma que permita às pessoas que priorizam os projetos fazer uma aposta informada.

Existem cinco ingredientes que sempre queremos incluir em um pitch:

1.Problema — A ideia bruta, um caso de uso ou algo que vimos que nos motiva a trabalhar nisso.

2.Apetite — Quanto tempo queremos gastar e como isso limita a solução.

3.Solução — Os elementos principais que elaboramos, apresentados de uma forma que seja fácil para as pessoas entenderem imediatamente.

4.Armadilhas — Detalhes sobre a solução que vale a pena serem destacados para evitar problemas.

5.Limitações — Qualquer coisa especificamente excluída do conceito: funcionalidade ou casos de uso que intencionalmente não estamos cobrindo para adequar ao prazo ou tornar o problema manejável.

Ingrediente 1. Problema #

É crucial sempre apresentar um problema e uma solução juntos. Parece um ponto óbvio, mas é surpreendente com que frequência as equipes, incluindo a nossa, pulam para uma solução assumindo que é óbvio por que é uma boa ideia construir essa coisa.

Mergulhar diretamente no “o que construir” — a solução — é perigoso. Você não estabelece nenhuma base para discutir se essa solução é boa ou ruim sem um problema. “Adicionar abas ao aplicativo para iPad” pode ser atraente para designers de interface, mas o que impede que a discussão se transforme em um longo debate sobre diferentes abordagens de interface? Sem um problema específico, não há um teste de adequação para julgar se uma solução é melhor do que a outra.

Estabelecer o problema também nos permite ter uma conversa mais clara mais tarde, quando for a hora de apresentar a ideia ou apostar nela. A solução pode ser perfeita, mas e se o problema ocorrer apenas com clientes que não são adequados ao produto? Poderíamos gastar seis semanas em uma solução engenhosa que só beneficia uma pequena porcentagem de clientes conhecidos por ter baixa retenção. Queremos ser capazes de separar essa discussão sobre a demanda para não gastarmos tempo em uma boa solução que não beneficia as pessoas certas.

Até onde você precisa ir para expor o problema depende de quanto contexto você compartilha com as pessoas que estão lendo a proposta. A melhor definição de problema consiste em uma única história específica que mostra por que o status quo não funciona. Isso lhe dá uma base para testar a adequação. As pessoas poderão comparar a solução com esse problema específico — ou outras soluções, se surgir um debate — e julgar se essa história tem um resultado melhor com a nova solução.

Ingrediente 2. Apetite #

Você pode pensar no apetite como outra parte da definição do problema. Não só queremos resolver esse caso de uso, como também queremos encontrar uma maneira de fazê-lo em seis semanas, não em três meses, ou — no caso de um projeto menor — em duas semanas, não nas seis semanas inteiras.

Declarar o apetite no Pitch previne conversas improdutivas. Sempre há uma solução melhor. A questão é: se só estamos dispostos a gastar duas semanas nisso agora, como essa solução específica se apresenta?

Qualquer um pode sugerir soluções caras e complicadas. É necessário trabalho e perspicácia de design para chegar a uma ideia simples que se encaixe em um período de tempo reduzido. Declarar o apetite e abraçá-lo como uma restrição transforma todos em parceiros nesse processo.

Ingrediente 3. Solução #

Assim como soluções sem problemas, às vezes as empresas apostam em problemas sem solução. “Precisamos realmente facilitar a localização de coisas na seção de mensagens. Os clientes estão reclamando disso.”

Isso não está pronto para ser apresentado ou apostado. Um problema sem solução é trabalho não planejado ou modelado. Entregá-lo a uma equipe significa empurrar a pesquisa e a exploração para o nível errado, onde as habilidades, o limite de tempo e o perfil de risco (cauda fina vs. cauda pesada) estão todos desalinhados.

Se a solução não estiver presente, alguém deve voltar e fazer o trabalho de modelagem na trilha de Shaping. Só está pronto para ser apostado quando problema, apetite e solução se unem. Então você pode examinar a adequação entre problema e solução e julgar se é uma boa aposta ou não.

Ajude-os a enxergar #

Durante a fase de elaboração dos elementos, foi crucial esboçar ideias no nível certo de abstração para não desacelerar ou perder nenhuma das ideias que surgiam nos cantos de nossas mentes e nas pontas de nossas línguas.

Também precisamos desenhar no nível certo de detalhe quando escrevemos o Pitch. Aqui o desafio é um pouco diferente. Temos tempo para desacelerar e preparar uma apresentação adequada. Precisamos manter um nível alto, mas adicionar um pouco mais de concretude do que quando trabalhamos sozinhos ou com um parceiro. As pessoas que lerem o pitch e olharem os desenhos sem muito contexto precisam “captar” a ideia.

Precisamos de mais concretude, mas não queremos especificar demais o design com wireframes ou maquetes de alta fidelidade. Isso poderia limitar os designers que farão o trabalho posteriormente. Também corremos o risco de desviar a discussão para tópicos como cor, proporções ou layout, que não têm nada a ver com o trabalho de planejamento que fizemos.

Ao mesmo tempo, os diagramas feitos à mão têm uma qualidade de "você tinha que estar lá". Para pessoas que não acompanharam o desenvolvimento do diagrama passo a passo, pode parecer uma sopa de palavras e setas.

Portanto, precisamos de algumas técnicas para ajudar as pessoas a entenderem a ideia sem entrar em detalhes irrelevantes.

Esboços incorporados #

Suponha que seu breadboard da sessão de planejamento tenha ficado assim:

As pessoas podem ter dificuldade em visualizar onde esses novos recursos vão no Dashboard. Podemos esboçar uma nova caixa no Dashboard para tornar isso mais claro:

Mas ainda estamos pedindo que as pessoas imaginem demais. Vale a pena o trade-off de descer um nível de detalhes com o marcador grosso aqui.

Isso facilita ver quais são os elementos e avaliar quão claramente a funcionalidade se apresenta no dashboard. O lado negativo é que entramos em algumas decisões de layout que teria sido bom evitar. Os designers devem se sentir livres para encontrar um design diferente da caixa dividida com uma linha vertical. Adicionaríamos uma ressalva aqui no pitch que lembra os designers da liberdade que devem ter.

Este é um exemplo de como entrar seletivamente em mais detalhes visuais porque precisamos disso para vender o conceito. Felizmente, não precisaremos tomar tantas decisões visuais em outras partes do conceito. Esta foi uma parte "pivô" do design que todos precisavam ver concretamente para "entender".

Anotações nos esboços de marcador grosso #

Às vezes, as ideias são inerentemente visuais ou um pouco complicadas demais para serem expressas em um esquema de breadboard. Esboços com marcadores grossos podem ser muito eficazes em um pitch; você só precisa ter mais cuidado ao rotulá-los de forma clara.

Redesenhar o esboço em um iPad—ainda com um tamanho de pincel grosso—funciona bem. Você pode usar cores diferentes para separar os rótulos das partes materiais do esboço.

Ou você pode adicionar algumas anotações para permitir a discussão de elementos específicos.

Ingrediente 4. Armadilhas #

Às vezes, abordar uma armadilha requer apenas algumas linhas de texto. Por exemplo, no projeto do Formulário de Pagamento mencionado acima, os planejadores queriam destacar uma solução específica para como criar URLs. As URLs nunca estariam em domínios personalizados na versão 1 do projeto. Esse tipo de detalhe não é central para o conceito, mas explicá-lo evita uma possível armadilha.

Ingrediente 5. Proibições #

Por fim, se houver algo que não faremos neste conceito, é bom mencionar aqui. No caso do projeto do Formulário de Pagamento, a equipe decidiu desde o início que não permitiria nenhum tipo de edição WYSIWYG do formulário. Os usuários só poderiam fornecer um logotipo e personalizar o texto do cabeçalho em uma página de "personalização" separada. O WYSIWYG pode ser melhor aos olhos de algumas pessoas, mas dado o apetite, era importante marcar isso como uma limitação.

Exemplos #

Aqui estão dois exemplos de pitches reais.

Este pitch para agrupar tarefas começa mostrando uma solução alternativa que as pessoas estão usando no design atual. Em seguida, esboça todas as principais ideias para permitir agrupamentos opcionais de tarefas.

Duas capturas de tela demonstram o problema. Esboços com marcadores grossos descrevem a solução. Algumas armadilhas motivaram alguns dos esboços.

Este pitch para mudar como as notificações funcionam começa com dois vídeos para demonstrar o problema. As caixas pretas no final são uma visualização dos dados de comportamento do usuário que apoiam uma decisão no pitch.

Dois vídeos mostram o problema. Um esboço com marcador grosso e um breadboard descrevem a solução. As caixas pretas contêm visualizações de dados que suportam as compensações na solução.

Pronto para apresentar #

O próximo passo será defender que este pitch descreve uma aposta que vale a pena ser feita. Isso pode acontecer de algumas maneiras.

Preferimos a comunicação assíncrona por padrão e escalamos para o tempo real apenas quando necessário. Isso dá a todos a máxima quantidade de tempo sob seu próprio controle para fazer o trabalho real. Isso significa que o primeiro passo para apresentar um pitch é postar o documento com todos os ingredientes acima em algum lugar que os stakeholders possam ler no seu próprio tempo. Isso mantém a mesa de apostas curta e produtiva. Em condições ideais, todos têm tempo para ler os Pitches com antecedência. E, se isso não for possível em alguns casos, o pitch está pronto para ser apresentado rapidamente ao vivo.

Como fazemos no Basecamp #

Postamos pitches como Mensagens no Basecamp. Criamos uma Categoria de Mensagens chamada Pitch para encontrá-los facilmente. Os pitches são postados em uma Equipe chamada Estratégia de Produto, que pode ser acessada pelas pessoas na mesa de apostas.

Pitches no Quadro de Mensagens da equipe de Estratégia de Produto no Basecamp.

Um pitch como Mensagem. Note o apetite de uma semana. Este foi um projeto de Pequeno Porte.

Quando precisamos incluir um esboço com marcador grosso em um pitch, desenhamos no iPad (com Notability) e tiramos uma captura de tela. O editor de texto do Basecamp facilita a inserção de imagens e a adição de legendas para que façam sentido no fluxo do pitch.

Um esboço desenhado em um iPad no meio de um pitch.

As pessoas comentam no pitch de forma assíncrona. Não para dizer sim ou não — isso acontece na mesa de apostas — mas para apontar falhas ou contribuir com informações faltantes.

Nosso CTO responde com pensamentos técnicos sobre o pitch.

No próximo capítulo, vamos examinar o processo de apostas em mais detalhes para ver para onde os pitches vão e como os transformamos em projetos agendados.