Checklist pré-roadmap: 12 perguntas que todo fundador deve responder
Use este checklist para alinhar problema, público, métricas, riscos e responsabilidades antes de iniciar um projeto com um laboratório de startups.
Conheça o processo da Tresete
Neste artigo8 seções
- Por que fazer um checklist pré-roadmap antes do kickoff
- As 12 perguntas do checklist pré-roadmap
- Quais documentos e dados reunir antes de contratar um parceiro
- Exemplo prático: de serviço local a hipótese de assinatura
- Como transformar respostas em responsabilidades e critérios de aceitação
- Métricas, amostra e riscos: o que precisa estar definido antes do primeiro ciclo
- Como conduzir o kickoff e quais erros evitar no roadmap
- Próximos passos depois de responder às 12 perguntas
Por que fazer um checklist pré-roadmap antes do kickoff
Um checklist pré-roadmap ajuda o fundador a transformar uma ideia ampla em um conjunto de decisões verificáveis. Antes de discutir funcionalidades, prazos ou tecnologia, você precisa saber qual problema será investigado, para quem ele existe e que evidência justificará continuar, ajustar ou interromper o projeto.
Um roadmap criado cedo demais costuma virar uma lista de entregas. O time passa a medir progresso pelo número de telas desenvolvidas, e não pela redução de incertezas sobre demanda, uso ou monetização. Para uma startup em estágio inicial, essa troca pode consumir semanas de engenharia sem responder à pergunta central: alguém realmente precisa e usará esta solução?
Na Tresete, o briefing inicial é organizado em um workshop de aproximadamente 90 minutos. O objetivo não é sair com todas as funcionalidades definidas, mas registrar hipóteses, restrições, sinais de sucesso e decisões pendentes que orientarão ciclos de experimentação de duas semanas.
Esse trabalho se conecta à lógica de startup enxuta e validação contínua, na qual cada lançamento deve produzir aprendizado observável. O roadmap passa a funcionar como um plano de investigação, com entregáveis técnicos subordinados a perguntas de negócio.
Como referência para a etapa de descoberta, o guia do Sebrae sobre modelo de negócio mostra por que proposta de valor, clientes e canais precisam ser tratados de forma integrada. No contexto de um laboratório, essas informações ajudam a definir quais hipóteses merecem um teste rápido antes de qualquer construção mais complexa.
As 12 perguntas do checklist pré-roadmap
- 1
Qual problema específico estamos tentando resolver?
Descreva a situação observável, e não apenas a solução imaginada. Uma boa resposta indica quem enfrenta o problema, quando ele ocorre, como é resolvido hoje e qual custo existe na alternativa atual.
- 2
Quem é o primeiro público que deve ser validado?
Escolha um segmento inicial com características e comportamento relativamente claros. Para um negócio local, pode ser um grupo de clientes recorrentes, profissionais de uma categoria ou usuários de uma determinada região de atuação, sem tentar atender todo o mercado de uma vez.
- 3
Que evidência já temos sobre essa dor?
Separe fatos de opiniões. Registre entrevistas, pedidos recebidos, dados de atendimento, vendas, cancelamentos, pesquisas e comportamentos observados, identificando a data e a fonte de cada evidência.
- 4
Qual hipótese tem maior risco para o negócio?
Pergunte o que precisaria ser verdadeiro para o projeto funcionar. Pode ser a frequência do problema, a disposição de pagar, a capacidade de entregar o serviço ou a possibilidade de adquirir clientes por um custo sustentável.
- 5
Qual é a menor experiência capaz de testar essa hipótese?
Nem todo teste exige um aplicativo completo. Uma página de links com marca própria, um formulário, uma operação manual ou um protótipo navegável podem revelar intenção e comportamento antes do investimento em arquitetura definitiva.
- 6
Qual comportamento indicará interesse real?
Defina uma ação observável, como agendar, pagar, deixar um depósito, concluir um fluxo ou voltar a usar a solução. Curtidas e elogios podem ajudar na descoberta, mas raramente bastam como critério de validação.
- 7
Qual métrica será acompanhada no primeiro ciclo?
Escolha uma métrica principal ligada à hipótese, além de poucos indicadores de apoio. Conversão, ativação, retenção inicial, tempo até o primeiro valor e receita por usuário são opções possíveis, dependendo do modelo.
- 8
Qual amostra e qual prazo tornam o teste útil?
Estime quantas pessoas precisam ser expostas ao experimento e por quanto tempo. O número deve considerar o tipo de decisão, o canal de aquisição e a variação esperada, não uma preferência arbitrária do time.
- 9
Quais recursos o fundador consegue disponibilizar?
Liste orçamento, horas semanais, acesso a clientes, dados, materiais de marca e capacidade operacional. Um roadmap realista depende tanto da disponibilidade do fundador quanto da capacidade técnica do laboratório.
- 10
Quais riscos legais, operacionais e técnicos existem?
Verifique dados pessoais, consentimento, pagamentos, dependência de terceiros, regras setoriais, suporte ao usuário e integrações críticas. Riscos conhecidos devem aparecer no planejamento, e não surgir como surpresa durante o lançamento.
- 11
Quem decide e quem executa cada parte?
Defina responsáveis por produto, engenharia, marketing, atendimento, aprovação de conteúdo e decisão de continuidade. Uma matriz RACI simples evita que duas pessoas façam a mesma tarefa ou que uma decisão importante fique sem dono.
- 12
O que faremos com cada resultado possível?
Estabeleça previamente os limiares de decisão. Um resultado forte pode liberar o próximo ciclo, um resultado intermediário pode exigir ajuste de público ou oferta, e um resultado fraco pode indicar pausa, mudança de hipótese ou encerramento.
Quais documentos e dados reunir antes de contratar um parceiro
O laboratório não precisa receber um plano de negócio perfeito. Precisa receber informação suficiente para distinguir o que já foi observado do que ainda é uma suposição. Um briefing de duas a cinco páginas, com anexos objetivos, costuma ser mais útil do que uma apresentação extensa sem fonte para as afirmações.
Reúna uma descrição do produto ou serviço, perfil do público, histórico de vendas, canais atuais, registros de atendimento, pesquisas, protótipos, identidade visual e integrações já existentes. Se houver dados de usuários, documente sua origem, finalidade de uso, base legal presumida e nível de acesso disponível.
Inclua também as restrições que podem alterar o roadmap: orçamento máximo, prazo de lançamento, dependências técnicas, fornecedores, sazonalidade, capacidade de atendimento e compromissos com clientes. Um fundador que omite uma limitação operacional pode receber um plano teoricamente bom, mas impossível de executar.
Para dados pessoais, consulte a orientação da ANPD sobre agentes de tratamento e encarregado e avalie com assessoria jurídica quando houver dúvida. A Lei Geral de Proteção de Dados não deve ser tratada como uma etapa burocrática posterior, especialmente quando o MVP coleta contatos, localização, informações de saúde, pagamentos ou dados de comportamento.
Também vale separar métricas históricas de metas futuras. Por exemplo, "temos 800 contatos" é um dado; "vamos converter 10%" é uma hipótese. Essa distinção torna a conversa com o laboratório mais honesta e reduz a chance de o roadmap ser construído sobre projeções apresentadas como fatos.
Se você ainda não tem um MVP, use o checklist de documentos e riscos antes da validação para verificar lacunas. O objetivo não é eliminar toda incerteza antes do kickoff, e sim garantir que as incertezas mais perigosas estejam visíveis.
Exemplo prático: de serviço local a hipótese de assinatura
Imagine um salão que percebe muitos clientes retornando a cada quatro ou cinco semanas. A ideia inicial é criar um aplicativo de assinatura para reservar horários, pagar mensalidade e receber benefícios. Embora pareça uma demanda de tecnologia, a primeira dúvida pode ser comercial: clientes aceitariam comprometer pagamento recorrente em troca de previsibilidade e vantagens?
No briefing pré-roadmap, o fundador poderia responder que o público inicial são 30 clientes que já retornaram pelo menos três vezes nos últimos seis meses. A hipótese seria: pelo menos 20% desse grupo aceitará uma oferta de assinatura mensal com dois serviços definidos e fará o primeiro pagamento em até 14 dias.
O primeiro experimento não precisa começar com aplicativo. O salão pode apresentar três planos em uma página de marca própria, captar interesse, conversar com os clientes e processar os primeiros pagamentos com operação assistida. O objetivo é testar proposta, preço e compromisso, não simular toda a experiência futura.
O critério de aceitação precisa ser combinado antes do teste. Por exemplo, 6 pagamentos em 14 dias podem liberar um ciclo para automatizar agendamento; muitos cliques sem pagamento podem indicar interesse superficial, preço inadequado ou baixa clareza da oferta. A decisão depende do comportamento observado e das entrevistas realizadas após a ação.
Esse exemplo mostra por que um roadmap de produto não começa necessariamente com a funcionalidade mais desejada pelo fundador. Começa pela incerteza que pode comprometer o modelo de negócio. Depois, as tarefas de design e engenharia são escolhidas para reduzir essa incerteza com o menor custo e o menor tempo razoáveis.
Como transformar respostas em responsabilidades e critérios de aceitação
- ✓Fundador ou responsável pelo negócio: fornece contexto, acesso a clientes, decisões comerciais, materiais existentes e aprovação dos experimentos. Também deve estar disponível para revisar resultados, não apenas para aprovar telas.
- ✓Laboratório ou squad de produto: transforma hipóteses em experimentos, define o desenho do teste, estima esforço, implementa o necessário e documenta aprendizados. A responsabilidade não é apenas entregar software, mas tornar o resultado interpretável.
- ✓Responsável por engenharia: avalia arquitetura, integrações, segurança, manutenção e alternativas técnicas. Em um MVP, deve proteger a velocidade sem criar riscos desnecessários para a próxima etapa.
- ✓Responsável por marketing e aquisição: define canal, mensagem, público da campanha e orçamento de teste. Sem aquisição minimamente controlada, uma baixa conversão pode refletir tráfego inadequado, e não rejeição da proposta.
- ✓Responsável por atendimento e operação: verifica se a promessa pode ser cumprida após o lançamento. Um experimento que gera demanda sem capacidade de atendimento pode produzir uma falsa leitura sobre retenção e satisfação.
- ✓Critério de aceitação do ciclo: cada sprint de duas semanas deve terminar com uma evidência revisável, como entrevistas concluídas, usuários ativados, pagamentos recebidos, conversão medida ou uma decisão documentada de mudança de hipótese.
- ✓Critério de qualidade: o experimento precisa ser funcional o suficiente para gerar comportamento real, ter rastreamento mínimo das métricas e permitir que o usuário entenda a oferta. Perfeição visual não é requisito, mas confusão do usuário é um problema.
- ✓Critério de decisão: o time deve registrar o que acontece acima, dentro e abaixo do limiar definido. Essa regra reduz decisões emocionais e facilita explicar por que o próximo ciclo continuará, ajustará ou interromperá a iniciativa.
Métricas, amostra e riscos: o que precisa estar definido antes do primeiro ciclo
Uma métrica inicial deve responder à pergunta do experimento. Se a hipótese é que uma oferta desperta intenção de compra, conversão para pagamento ou depósito é mais informativa do que tráfego bruto. Se a hipótese é de uso recorrente, ativação e retorno em um período definido podem ser mais adequados do que o número de cadastros.
Evite criar um painel com dezenas de indicadores antes de saber qual decisão será tomada. Escolha uma métrica principal, de duas a quatro métricas de apoio e um indicador de proteção, como cancelamentos, reclamações, tempo operacional ou custo de aquisição. O artigo sobre métricas para acompanhar no primeiro MVP ajuda a estruturar essa seleção.
A amostra também precisa ser coerente com a decisão. Para entrevistas exploratórias, a qualidade e a diversidade dos participantes podem ser mais importantes que uma grande quantidade. Para medir conversão, você precisará considerar volume de exposição, origem do tráfego e intervalo de confiança, em vez de tirar conclusões de três cliques.
O guia sobre tamanho de amostra para experimentos de mercado pode apoiar esse cálculo. Ainda assim, números não substituem julgamento: uma amostra pequena com compradores reais pode ensinar mais sobre disposição de pagar do que uma audiência ampla que apenas declara interesse.
Riscos operacionais merecem o mesmo espaço que riscos de produto. Pergunte quem responderá aos usuários, como cancelamentos serão tratados, o que acontece quando uma integração falha e quais dados precisam ser apagados. Também defina um plano de contingência para pausar campanhas ou retirar uma oferta que não possa ser entregue.
Quando o experimento envolve dados pessoais, registre a finalidade da coleta, limite os dados ao necessário e estabeleça quem terá acesso. A Lei Geral de Proteção de Dados no portal oficial do Planalto é uma referência primária para revisar obrigações e conceitos, mas não substitui aconselhamento jurídico específico.
Como conduzir o kickoff e quais erros evitar no roadmap
O kickoff deve começar pela leitura conjunta do briefing, não pela apresentação de um cronograma fechado. Reserve tempo para questionar premissas, alinhar definições e identificar decisões que dependem de informação ainda não disponível. Se o parceiro já chega prometendo todas as funcionalidades, pode estar tratando o roadmap como escopo de desenvolvimento, e não como instrumento de aprendizado.
Outra falha recorrente é colocar o fundador como aprovador distante. Em projetos iniciais, entrevistas, acesso a clientes e decisões de oferta não podem ser totalmente terceirizados. O laboratório acelera método, produto e engenharia, mas o conhecimento sobre operação, reputação e relacionamento com o mercado precisa circular diariamente.
Também evite confundir velocidade com pressa. Um ciclo de duas semanas é útil quando termina com evidência e decisão; se o time apenas acumula tarefas incompletas, o intervalo curto cria ansiedade, não aprendizado. Para organizar a sequência entre hipóteses e implementação, consulte o material sobre transformar hipóteses em sprints de engenharia.
Antes de assinar ou iniciar o trabalho, documente entregáveis, canais de comunicação, prazos de resposta, propriedade dos ativos, acesso a dados, critérios de aceite e regras para mudança de prioridade. Um acordo claro protege o fundador e o parceiro, especialmente quando uma hipótese muda no meio do caminho.
Por fim, não esconda resultados negativos. Um experimento que mostra baixa disposição de pagar pode economizar meses e revelar um ajuste de público ou oferta. A função do roadmap é reduzir risco com decisões sucessivas, e não justificar uma solução escolhida antes da investigação.
Próximos passos depois de responder às 12 perguntas
- 1
Consolide o briefing em uma página de decisão
Resuma problema, público, evidências, hipótese principal, experimento, métrica, amostra, prazo e critério de aceitação. Mantenha links ou anexos para os dados que sustentam cada afirmação.
- 2
Classifique as hipóteses por risco e dependência
Comece pelas suposições que podem invalidar o negócio e que podem ser testadas rapidamente. Adie decisões de arquitetura, automação e escala quando elas não forem necessárias para obter a primeira evidência.
- 3
Faça uma reunião de alinhamento com os decisores
Inclua quem conhece o cliente, quem executará a operação, quem aprovará investimento e quem responderá pela tecnologia. A reunião deve terminar com responsáveis, datas e perguntas ainda abertas.
- 4
Escolha o formato de parceria adequado
Dependendo da lacuna, você pode precisar de descoberta, design, engenharia, aquisição ou uma combinação dessas frentes. A estrutura de um lançamento rápido com laboratório ajuda a visualizar papéis e marcos antes do início.
- 5
Agende a primeira revisão de aprendizado
Não espere o fim do projeto para revisar resultados. Marque desde o início uma conversa para analisar dados, registrar aprendizados e decidir se o próximo ciclo mantém, ajusta ou abandona a hipótese.
Perguntas Frequentes
Quais documentos devo enviar a um laboratório antes de criar um roadmap?▼
Envie um briefing com problema, público, proposta atual, evidências, métricas disponíveis e objetivo do projeto. Acrescente protótipos, dados de vendas, registros de atendimento, pesquisas, restrições de orçamento, integrações e riscos conhecidos. Se houver dados pessoais, explique a origem, a finalidade e as permissões de acesso. O material não precisa ser perfeito, mas deve separar fatos observados de hipóteses.
Quem deve participar do kickoff do roadmap pelo lado do fundador?▼
O fundador ou responsável pela decisão de negócio deve participar diretamente, junto de alguém que conheça clientes e operação. Se o produto já tiver desenvolvimento, marketing ou atendimento, inclua representantes dessas áreas. O laboratório normalmente envolve produto, design, engenharia e, conforme o experimento, aquisição ou análise de dados. O grupo precisa ser pequeno o suficiente para decidir e amplo o suficiente para revelar restrições.
Como definir métricas antes de contratar um laboratório de startups?▼
Comece pela decisão que o experimento precisa orientar e escolha uma métrica diretamente ligada a ela. Para uma oferta paga, pagamento, depósito ou conversão qualificada costuma ser mais útil que alcance; para uso recorrente, ativação e retorno podem ser mais adequados. Defina também período de medição, fonte dos dados e limiar de sucesso. Evite metas baseadas apenas em vaidade, como downloads sem uso.
Preciso ter 12 hipóteses para começar um roadmap?▼
Não. As 12 perguntas do checklist organizam a preparação do fundador, mas não exigem que você tenha 12 hipóteses independentes. Uma hipótese principal bem descrita e algumas hipóteses de apoio podem sustentar vários ciclos de validação. O mais importante é conhecer a incerteza prioritária, o teste possível e a decisão associada ao resultado.
Como saber se já tenho informação suficiente para começar o roadmap?▼
Você provavelmente está pronto quando consegue explicar qual problema será testado, quem participará, que comportamento será observado e o que acontecerá em cada faixa de resultado. Ainda haverá incerteza, e isso é esperado em um projeto inicial. O que não pode faltar é acesso mínimo ao público, capacidade de executar o experimento e disponibilidade para tomar decisões com base nos dados.
Quais riscos legais devo revisar antes de trabalhar com um laboratório?▼
Revise coleta e compartilhamento de dados pessoais, consentimento, pagamentos, propriedade intelectual, confidencialidade, uso de ferramentas de terceiros e regras específicas do seu setor. Também defina no contrato quem responde por segurança, suporte, incidentes, ativos de código e encerramento do projeto. A revisão deve ser proporcional ao risco, mas não deve ser deixada para depois do lançamento. Quando houver dados sensíveis ou obrigações regulatórias, procure orientação jurídica especializada.
O laboratório deve entregar um roadmap fechado antes de começar a validação?▼
Em geral, um roadmap inicial deve ser suficientemente claro para orientar o primeiro ciclo, mas aberto a mudanças baseadas em evidências. Fechar funcionalidades, datas e arquitetura antes de testar as hipóteses pode transformar suposições em compromissos caros. Prefira marcos de aprendizado, critérios de aceitação e pontos formais de decisão. Assim, o plano mantém direção sem impedir ajustes necessários.
Como funciona a matriz RACI em um projeto de MVP com um parceiro?▼
A matriz RACI identifica quem é responsável pela execução, quem aprova, quem precisa ser consultado e quem apenas deve ser informado em cada atividade. Ela pode ser aplicada a entrevistas, campanhas, decisões de preço, aprovação de telas, implantação, atendimento e análise de resultados. O documento evita ambiguidades, mas não substitui reuniões curtas e decisões registradas. Revise a matriz quando o escopo ou a hipótese principal mudar.