Playbook de Desenvolvimento de Produto IoT de Ponta a Ponta – Etapa 0 – Conceito e Viabilidade
Clique para o capítulo anterior: Introdução
“Espera — devemos sequer construir esta coisa?”
A maioria dos produtos IoT falhados perdeu-se antes de o primeiro esquema ser desenhado: ninguém verificou se a ideia valia a pena ser construída. A Etapa 0 existe para responder a essa pergunta com evidência em vez de entusiasmo. Imagine-se à beira de uma selva densa, machete na mão. Consegue ouvir que pode haver tesouro para lá das lianas — rumores de clientes agradecidos, slide decks de investidores entusiasmados, talvez até a mítica Série B. Mas também consegue pressentir os poços de lama e os bugs famintos à espera de roer a sua runway. Um sprint disciplinado de Conceito e Viabilidade diz-lhe se a caça ao tesouro justifica sequer abrir um caminho. Equipas com pressa saltam frequentemente este passo (“Vamos simplesmente começar a sprintar!”). Não o faça. Alguns dias focados aqui poupam meses de retrabalho, dissipam a névoa do pensamento ilusório e dão à equipa um grito de guerra que sobrevive às longas noites de depuração de firmware às 2 da manhã.
0.1 Porque é que este capítulo importa tanto?
Porque cada barra de Gantt, ticket do Jira e ordem de compra a jusante herda a sua razão de existir da decisão que toma aqui. Se se lançar na captura de esquemas ou no wireframing da aplicação móvel sem um “Porquê” claro e baseado em evidência, está a alugar um bulldozer antes de saber se precisa de um canteiro de flores ou de um arranha-céus. As equipas que saltam a viabilidade também acabam a apresentar sonhos difusos aos stakeholders: “É como um Fitbit, mas para gatos, e também mina criptomoeda!” Divertido — até as Finanças perguntarem o custo de Bluetooth mesh numa coleira que o Fofinho adora roer.
0.2 As quatro conversas que tem de ter
1. Entrevista sobre o ponto de dor
Encontre um humano real (ou vários) que experiencie o problema diariamente. Ouça mais do que fala. Se não usarem linguagem azeda ou suspirarem pesadamente ao descrever a dor, o problema provavelmente não é agudo o suficiente para justificar o burn rate de uma start-up de hardware.
Exemplo: Um gestor de instalações confessa que perde milhares de euros por mês porque ninguém repara quando o congelador industrial ultrapassa os –15 °C às 3 da manhã.
2. Declaração de visão
Destile o que ouviu numa frase que caiba numa caneca de café. “Damos aos gestores de instalações um aviso antecipado de falhas de equipamento — antes de o gelado derreter.” Se a frase parecer flácida ou tentar agradar a todos, continue a apará-la.
3. Jornada de utilizador de alto nível
Desenhe um storyboard simples: o gestor recebe uma notificação push, toca para abrir um gráfico de tendência, despacha a manutenção e desfruta de um pastel de canela tranquilo porque a catástrofe foi evitada. Ainda sem pixel-pushing de UI — pense em banda desenhada, não em mock-ups de alta fidelidade.
4. Verificação de sanidade do mercado
Abra uma folha de cálculo (sim, essa temida grelha em branco) e responda: Com que frequência ocorre esta dor? Quantas pessoas a têm? Quanto pagaria cada uma pelo alívio? Relatórios da indústria, preços de SKUs de concorrentes na Digi-Key e uma contagem rápida no LinkedIn de títulos de emprego “Facilities Manager” na sua região-alvo vão colocá-lo dentro de uma precisão respeitável. Os PMs novatos preocupam-se com casas decimais; os veteranos preocupam-se com ordens de grandeza.
0.3 Experiências de viabilidade em fogo rápido
O desenvolvimento de hardware pode parecer glacial, mas ainda consegue gerar evidência convincente em dias:
- Teste de fumo de alcance – Pegue num dev-kit BLE pronto a usar, cole-o dentro de um congelador de aço inoxidável, faça-lhe um ping do corredor, meça o RSSI. Se o sinal morre aos dois metros, acabou de evitar um erro de conectividade antes de encomendar PCBs personalizadas.
- Verificação da verdade do sensor – Peça emprestada uma sonda de temperatura calibrada, prenda-a ao lado do seu sensor digital candidato e registe 12 horas de dados. O sensor barato desvia 3 °C sempre que o compressor arranca? Descarte-o cedo.
- Demo a stakeholders – Canalize os dados do dev-kit para um dashboard cloud gratuito (ThingSpeak, Adafruit IO) e mostre ao seu gestor de instalações. Se ele perguntar “Posso comprar isto amanhã?”, está no bom caminho. Se encolher os ombros, refine ou pivo.
0.4 Artefactos a levar consigo (nada de fancy)
- One-pager de visão – Elevator pitch, utilizador-alvo, dor visceral, resultado proposto.
- Storyboard de três quadros – Identifique gatilho, ação e resultado. Esboçado serve; fotos de telemóvel a sticky notes contam.
- Tabela TAM/SAM/SOM – Estimativas de mercado Total, Servível e Obtível. Dez linhas chegam. Inclua a sua pontuação de confiança e links de citação.
- Memorando do sprint de viabilidade – Uma página: Hipótese → Experiência → Dados → Veredito → Próximo passo. Legível em três minutos pelo seu VP.
Estes artefactos não são cerimónia por si só. Atuam como faróis de alinhamento: quando o marketing quer perseguir outra persona, ou a engenharia propõe um rádio mmWave exótico, pode agitar o one-pager e perguntar: “Isto serve a nossa história do gestor de instalações que salva congeladores?”
0.5 Custo de saltar
Ainda tentado a declarar “constrói e eles virão”? Um conto de cautela de guardanapo: uma equipa que mentorei gastou €60 000 em rotações de PCB antes de perceber que os hospitais — o seu mercado-alvo — não permitem rádios de 2,4 GHz em salas de ressonância magnética. Um teste de fumo de viabilidade de duas horas com um analisador de espetro emprestado teria poupado oito meses e a demissão de um engenheiro.
0.6 Construir o ritual Go/No-Go
Os humanos — especialmente engenheiros alimentados pela emoção de LEDs a piscar — odeiam dizer “Não.” Institucionalize-o. Marque um convite de calendário para uma Revisão de Viabilidade exatamente duas semanas após o kickoff do projeto. Convide uma pessoa de cada área: negócio, engenharia, qualidade e customer success. Apresente os seus quatro artefactos, demonstre quaisquer protótipos rápidos e termine a reunião com uma votação forçada: Go ou No-Go (pivotar conta como No-Go). A maioria decide. Registe a decisão na sua wiki com timestamp e lista de participantes. O eu-do-futuro agradecerá ao eu-do-passado quando auditores ou investidores perguntarem: “Porque apostaram a quinta em LoRa em vez de NB-IoT?”
0.7 Armadilhas comuns de novatos e como as evitar
| Armadilha | Porque dói | Antídoto |
|---|---|---|
| Solução primeiro, problema depois – Apaixonar-se por tecnologia gira | Acaba a caçar um mercado | Escreva a sua declaração de dor antes de tocar no firmware do dev-kit |
| Paralisia de análise – Semanas de folhas de cálculo | O momento morre, a moral cai | Faça time-box de cada tarefa de investigação em dias; partilhe números imperfeitos abertamente |
| Perguntas tendenciosas – “Não adoraria uma cloud de congeladores?” | Os utilizadores dizem sim por educação → Validação falsa | Pergunte sobre o custo do workaround de hoje; observe emoção real |
| Ignorar restrições escondidas – Proibições regulamentares, códigos de construção | Redesigns surpresa custam milhões | Telefone a um veterano da indústria; pergunte “O que te apanhou de surpresa da última vez?” |
0.8 Mini estudo de caso: O Sprint de Uma Semana do Congelador Inteligente
Segunda-feira: Dois PMs entrevistam três gestores de instalações, confirmam que a deterioração de congelados custa €10 mil por incidente.
Terça-feira: O lead de hardware monta um sensor de temperatura I²C de $12 numa placa de desenvolvimento Wio-Link, transmite JSON para o Adafruit IO.
Quarta-feira: O estagiário de cloud constrói um painel Grafana e um alerta SMS via Twilio.
Quinta-feira: Os PMs enviam um vídeo de demo aos stakeholders; o CFO solta: “Se isto funcionar, poupamos €1 milhão por ano em todos os sites.”
Sexta-feira: A Revisão de Viabilidade vota Go, mas exige a verificação do backhaul celular onde o Wi-Fi é fraco.
Gasto total: €300 em peças e pizza. Clareza ganha: não tem preço.
0.9 A Checklist do Capítulo 0 (imprima, anote, cole acima do monitor)
- Declaração do problema capturada numa frase brutalmente curta.
- Pelo menos uma entrevista com um sofredor do problema, citações registadas verbatim.
- Declaração de visão partilhada no Slack, reações recolhidas (se ninguém reagir, reescreva).
- Dois a três esboços de jornada de utilizador fotografados e carregados.
- Números iniciais de sanidade de mercado numa folha de cálculo, etiquetados com links de fontes.
- Uma experiência de viabilidade executada, dados grafados.
- Bloqueio de calendário para a revisão Go/No-Go feito; árbitro neutro convidado.
- Decisão registada, link colado na raiz do repositório do projeto.
- Se Go → riscos de alto nível e dono do próximo capítulo atribuídos.
- Se No-Go → nota de agradecimento enviada à equipa; lições aprendidas documentadas.
Cole esta checklist na tampa do seu portátil. Da próxima vez que for tentado a sprintar à frente porque “a casa de PCBs tem uma promoção que acaba hoje à noite”, olhe para a caixa n.º 1. Se não conseguir recitar a declaração do problema em cinco segundos, não está pronto para encomendar cobre.
0.10 Para concluir
Conceito e Viabilidade é o capítulo mais pequeno em tempo de calendário — mas o maior em impacto. Trate-o como o prólogo de um bom romance: salte-o e o resto do enredo parece confuso e oco. Invista aqui uma explosão focada de energia, e cada capítulo subsequente encaixa no lugar. Os seus engenheiros vão agradecer-lhe, os seus investidores vão acenar perante uma articulação nítida de valor, e os seus utilizadores vão eventualmente receber um produto que genuinamente lhes salva a pele (ou o gelado).
Depois avance para o Capítulo 1, onde transformamos aspirações difusas em Requisitos de Sistema bem definidos — tão claros que até o seu futuro auditor de conformidade vai esboçar um sorriso.