Playbook de desarrollo de productos IoT de extremo a extremo – Etapa 0 – Concepto y viabilidad
Clic para el capítulo anterior: Introducción
«Espera… ¿deberíamos siquiera construir esto?»
La mayoría de los productos IoT fallidos se perdieron antes de dibujar el primer esquemático: nadie comprobó si la idea valía la pena. La Etapa 0 existe para responder esa pregunta con evidencia en lugar de entusiasmo. Imagínate al borde de una jungla densa, machete en mano. Puedes oír que podría haber un tesoro tras las enredaderas: rumores de clientes agradecidos, presentaciones brillantes para inversores, quizá incluso la mítica Serie B. Pero también percibes los lodazales y los insectos hambrientos esperando mordisquear tu runway. Un sprint disciplinado de Concepto y viabilidad te dice si la búsqueda del tesoro justifica abrirse camino a machetazos. Los equipos con prisa suelen saltarse este paso («¡Empecemos a sprintar ya!»). No lo hagas. Unos pocos días de trabajo enfocado aquí ahorran meses de rehacer, disipan la niebla de los deseos y dan al equipo un grito de guerra que sobrevive a las largas noches depurando firmware a las 2 de la madrugada.
0.1 ¿Por qué importa tanto este capítulo?
Porque cada barra de Gantt, ticket de Jira y orden de compra posterior hereda su razón de existir de la decisión que tomas aquí. Si te lanzas a capturar esquemáticos o a dibujar wireframes de la app móvil sin un «por qué» claro y basado en evidencia, estás alquilando una excavadora antes de saber si necesitas un parterre o un rascacielos. Los equipos que se saltan la viabilidad acaban vendiendo sueños difusos a los stakeholders: «¡Es como un Fitbit, pero para gatos, y además mina criptomonedas!». Divertido, hasta que Finanzas pregunta cuánto cuesta el Bluetooth mesh en un collar que a Pelusa le encanta morder.
0.2 Las cuatro conversaciones que debes tener
1. Entrevista sobre el problema
Encuentra una persona real (o varias) que sufra el problema a diario. Escucha más de lo que hablas. Si no sueltan algún taco ni suspiran hondo al describir el problema, probablemente no es lo bastante agudo como para justificar el burn rate de una startup de hardware.
Ejemplo: un responsable de instalaciones confiesa que pierde miles de euros al mes porque nadie se entera cuando el congelador industrial sube de –15 °C a las 3 de la madrugada.
2. Declaración de visión
Destila lo que oíste en una frase que quepa en una taza de café. «Avisamos a los responsables de instalaciones de los fallos de equipo antes de que se derrita el helado.» Si la frase resulta blanda o intenta contentar a todo el mundo, sigue recortando.
3. User journey de alto nivel
Traza un storyboard sencillo: el responsable recibe una notificación push, toca para abrir una gráfica de tendencia, avisa a mantenimiento y se toma tranquilo un bollo de canela porque la catástrofe se evitó. Todavía nada de empujar píxeles de UI: piensa en una tira cómica, no en mock-ups de alta fidelidad.
4. Comprobación de cordura del mercado
Abre una hoja de cálculo (sí, esa temida cuadrícula en blanco) y responde: ¿Con qué frecuencia ocurre este problema? ¿Cuánta gente lo tiene? ¿Cuánto pagaría cada uno por aliviarlo? Los informes sectoriales, los precios de SKU de la competencia en Digi-Key y una búsqueda rápida en LinkedIn de puestos de «responsable de instalaciones» en tu región objetivo te darán una precisión respetable. Los PM novatos se preocupan por los decimales; los veteranos, por los órdenes de magnitud.
0.3 Experimentos rápidos de viabilidad
El desarrollo de hardware puede parecer glacial, pero aún puedes generar evidencia convincente en días:
- Prueba de humo de alcance: coge un dev-kit BLE comercial, mételo en un congelador de acero inoxidable, hazle ping desde el pasillo y mide el RSSI. Si la señal muere a dos metros, acabas de evitar un error de conectividad antes de encargar PCBs a medida.
- Prueba de verdad del sensor: consigue una sonda de temperatura calibrada, pégala junto a tu sensor digital candidato y registra 12 horas de datos. ¿El sensor barato deriva 3 °C cada vez que arranca el compresor? Descártalo pronto.
- Demo para stakeholders: envía los datos del dev-kit a un dashboard gratuito en la nube (ThingSpeak, Adafruit IO) y enséñaselo a tu responsable de instalaciones. Si pregunta «¿Puedo comprar esto mañana?», vas por buen camino. Si se encoge de hombros, refina o pivota.
0.4 Artefactos que llevarte (nada sofisticado)
- One-pager de visión: elevator pitch, usuario objetivo, problema visceral, resultado propuesto.
- Storyboard de tres viñetas: identifica disparador, acción y resultado. Vale un boceto; cuentan las fotos de notas adhesivas hechas con el móvil.
- Tabla TAM/SAM/SOM: estimaciones de mercado total, servible y alcanzable. Diez filas son suficientes. Incluye tu nivel de confianza y los enlaces a las fuentes.
- Memo del sprint de viabilidad: una página: Hipótesis → Experimento → Datos → Veredicto → Siguiente paso. Legible en tres minutos por tu VP.
Estos artefactos no son ceremonia por la ceremonia. Actúan como balizas de alineación: cuando marketing quiera perseguir otra persona, o ingeniería proponga una exótica radio mmWave, puedes agitar el one-pager y preguntar: «¿Esto sirve a nuestra historia del responsable de instalaciones que salva congeladores?».
0.5 El coste de saltárselo
¿Todavía te tienta declarar «constrúyelo y vendrán»? Un cuento preventivo de servilleta: un equipo al que mentoricé gastó 60 000 € en tiradas de PCB antes de darse cuenta de que los hospitales —su mercado objetivo— no permiten radios de 2,4 GHz en las salas de resonancia magnética. Una prueba de humo de viabilidad de dos horas con un analizador de espectro prestado habría ahorrado ocho meses y la dimisión de un ingeniero.
0.6 Construyendo el ritual Go/No-Go
Los humanos —especialmente los ingenieros alimentados por la emoción de los LEDs parpadeantes— odian decir «No». Institucionalízalo. Pon una invitación de calendario para una Revisión de viabilidad exactamente dos semanas después del arranque del proyecto. Invita a una persona de negocio, ingeniería, calidad y éxito de cliente. Presenta tus cuatro artefactos, haz la demo de los prototipos rápidos y cierra la reunión con una votación forzada: Go o No-Go (pivotar cuenta como No-Go). Gana la mayoría. Registra la decisión en tu wiki con timestamp y lista de asistentes. Tu yo futuro agradecerá a tu yo pasado cuando auditores o inversores pregunten: «¿Por qué apostasteis la granja por LoRa en lugar de NB-IoT?».
0.7 Errores típicos de novato y cómo esquivarlos
| Trampa | Por qué duele | Antídoto |
|---|---|---|
| Primero la solución, luego el problema: enamorarse de tecnología chula | Acabas buscando un mercado | Escribe tu declaración del problema antes de tocar el firmware del dev-kit |
| Parálisis por análisis: semanas de hojas de cálculo | El impulso muere, la moral cae | Limita cada tarea de investigación a días; comparte los números imperfectos abiertamente |
| Hacer preguntas capciosas: «¿No te encantaría una nube para congeladores?» | Los usuarios dicen que sí por cortesía → validación falsa | Pregunta por el coste del apaño de hoy; busca emoción real |
| Ignorar restricciones ocultas: prohibiciones regulatorias, códigos de edificación | Los rediseños sorpresa cuestan millones | Llama a un veterano del sector; pregunta «¿Qué te pilló por sorpresa la última vez?» |
0.8 Mini caso de estudio: el sprint de una semana del congelador inteligente
Lunes: dos PMs entrevistan a tres responsables de instalaciones y confirman que el deterioro de congelados cuesta 10 k€ por incidente.
Martes: el líder de hardware monta un sensor de temperatura I²C de 12 $ en una placa de desarrollo Wio-Link y transmite JSON a Adafruit IO.
Miércoles: el becario de cloud construye un panel de Grafana y una alerta por SMS vía Twilio.
Jueves: los PMs envían un vídeo de demo a los stakeholders; el CFO suelta: «Si esto funciona, ahorraremos 1 M€ al año en todos los sitios».
Viernes: la Revisión de viabilidad vota Go, pero exige verificar el back-haul celular donde el Wi-Fi es flojo.
Gasto total: 300 € en piezas y pizza. Claridad ganada: no tiene precio.
0.9 La checklist del Capítulo 0 (imprime, anota, pega sobre tu monitor)
- Declaración del problema capturada en una frase brutalmente corta.
- Al menos una entrevista con alguien que sufre el problema, con citas registradas literalmente.
- Declaración de visión compartida en Slack, reacciones recogidas (si nadie reacciona, reescribe).
- Dos o tres bocetos del user journey fotografiados y subidos.
- Números iniciales de cordura del mercado en una hoja de cálculo, etiquetados con enlaces a las fuentes.
- Un experimento de viabilidad ejecutado, datos graficados.
- Bloqueo de calendario para la revisión Go/No-Go hecho; árbitro neutral invitado.
- Decisión registrada, enlace pegado en la raíz del repositorio del proyecto.
- Si Go → riesgos de alto nivel y responsable del siguiente capítulo asignados.
- Si No-Go → nota de agradecimiento enviada al equipo; lecciones aprendidas documentadas.
Pega esta checklist en la tapa de tu portátil. La próxima vez que te tiente salir corriendo porque «la casa de PCBs tiene una oferta que acaba esta noche», mira la casilla n.º 1. Si no puedes recitar la declaración del problema en cinco segundos, no estás listo para encargar cobre.
0.10 Para cerrar
Concepto y viabilidad es el capítulo más pequeño en tiempo de calendario, pero el mayor en impacto. Trátalo como el prólogo de una buena novela: sáltatelo y el resto de la trama resulta confusa y hueca. Invierte aquí una ráfaga concentrada de energía y cada capítulo posterior encajará en su sitio. Tus ingenieros te lo agradecerán, tus inversores asentirán ante una articulación nítida del valor, y tus usuarios acabarán recibiendo un producto que de verdad les salva el tocino (o el helado).
Después pasa al Capítulo 1, donde convertimos aspiraciones difusas en Requisitos de sistema bien definidos, tan claros que hasta tu futuro auditor de cumplimiento esbozará una sonrisa.