Semana 6
07/09 - 11/09

💡 DON'T BUILD THIS (Validação)

Chegamos no momento do "choque de realidade". Depois de uma semana intensa gerando ideias e priorizando o que parecia mais relevante, agora vamos descobrir se o que vocês planejaram sobrevive ao mundo real.

Esta etapa é o que separa um projeto acadêmico de uma solução que realmente impacta a vida das pessoas. Vamos falar de Validação.

POR QUE VALIDAR?

No mundo da inovação, o erro mais caro que você pode cometer é construir algo perfeitamente funcional que ninguém quer usar. Validar não é sobre provar que você está certo, mas sobre ter a coragem de descobrir onde você está errado antes de escrever a primeira linha de código ou desenhar o primeiro protótipo de alta fidelidade.

Viabilidade vs. Desejabilidade

Nesta fase, equilibramos três pilares:

Desejabilidade: As pessoas realmente têm esse problema? Elas pagariam/usariam essa solução?
Viabilidade Técnica: Temos tecnologia e tempo para construir isso neste semestre?
Viabilidade de Negócio: Isso se sustenta a longo prazo ou é apenas um "fogo de palha"?

Dica de mestre: Validar cedo poupa meses de trabalho jogado fora. Se a ideia falhar agora, o custo é zero. Se falhar depois de pronta, o custo é o seu semestre ✌️.

Don’t Build This

Para esta missão, usaremos o Don’t Build This. Esta é uma plataforma de análise crítica que utiliza IA para "moer" a sua ideia, encontrando furos na lógica, concorrentes ocultos e problemas de mercado que vocês talvez não tenham visto.

O Desafio: Vocês devem detalhar a ideia escolhida na Matriz de Priorização da semana passada e submetê-la. O objetivo é alcançar uma nota mínima de 80/100. Se a nota for baixa, leiam o feedback, ajustem a proposta e tentem novamente.

Como submeter uma ideia campeã (80+)

Para convencer a IA (e os avaliadores reais), não basta ser vago. Você precisa de:

Contexto Claro: Quem é o usuário específico? (Ex: "Estudantes de CC" é melhor que "Jovens").
O Problema Real: Qual é a dor aguda que você resolve?
O Diferencial: Por que o que já existe no mercado não é suficiente?
O "Como": Explique brevemente a mecânica da solução.

Dicas de mestre:

As vezes, o Don’t Build This implica com a construção do artefato com Arduino, visto que existem outras plataformas mais baratas (mas mais difíceis de usar ou trabalhar), então voce pode deixar claro que o Arduino está sendo usado para o protótipo, ou que ele será substituído por outro microcontrolador.
Escreva a ideia em inglês. Ele pode trocar os termos durante a tradução e interpretar sua ideia de forma equivocada.

EXEMPLOS: O QUE FAZ UMA IDEIA SER BOA OU RUIM?

A diferença entre um 40 e um 90 no Don't Build This está nos detalhes. Veja a comparação:

Ideia Ruim

Definição: "Um app de entrega de comida"

Público: "Todo mundo que come"

Problema: "As pessoas têm fome"

Diferencial: "É mais rápido que os outros"

Ideia Boa

Definição: "Uma plataforma de logística para pequenos produtores de orgânicos locais entregarem cestas direto ao consumidor final via assinatura"

Público: "Consumidores conscientes de centros urbanos que não têm tempo de ir a feiras, mas priorizam alimentos sem agrotóxicos"

Problema: "A dificuldade de pequenos produtores em competir com grandes mercados devido ao custo de frete fracionado"

Diferencial: "Algoritmo de rotas otimizadas para múltiplos produtores na mesma região, reduzindo o custo de entrega em 30%"

CRITÉRIOS DE ENTREGA

Print do Score

O print da tela final do Don't Build This mostrando a nota (mínimo 80).

Análise Crítica

Um pequeno parágrafo no site do grupo explicando: "O que a ferramenta apontou como maior risco e como pretendemos mitigar isso?"

Refinamento

A descrição final da ideia após os ajustes sugeridos pela validação.

No Final

Uma ideia sólida, testada logicamente e que o grupo sinta confiança total de que vale a pena ser desenvolvida.

Page updated

Report abuse

Semana 607/09 - 11/09