Cómo diseñar productos de hardware

De qué va esta clase

Hosain Rahman es el CEO de Jawbone, una compañía pionera en lo que hoy se llama Internet de las Cosas: auriculares inteligentes, altavoces Bluetooth y pulseras de seguimiento de actividad como el Up. Rahman lleva más de una década construyendo hardware conectado, un terreno mucho más lento y arriesgado que el software puro, donde un error de diseño se paga con meses de retraso y decenas de miles de dólares en herramientas de fabricación. Su charla en la clase de Sam Altman en Stanford aborda un problema que casi nadie más en el curso trata: cómo se diseña, valida y lanza un producto físico cuando además ese producto tiene que hablar con una aplicación, generar datos y conectarse a una nube.

Lo interesante de Rahman no es solo que haya construido varios productos de éxito, como el altavoz Jambox o la pulsera Up, sino que ha tenido que resolver la friccion cultural entre equipos de hardware, que trabajan con ciclos de meses y herramientas que tardan dieciséis semanas en fabricarse, y equipos de software, acostumbrados a iterar en días y lanzar tests A/B sin fin. Esa tensión entre velocidades de iteración muy distintas es el hilo conductor de buena parte de la clase, junto con su marco de los WHYS, la pregunta que usa para mantener la disciplina creativa del equipo.

La clase importa para cualquier fundador que trabaje con producto físico, wearables, IoT o cualquier experiencia que combine varias capas tecnológicas, porque explica un proceso de creación de producto completo, desde la ideación más libre hasta el lanzamiento y la iteración posterior, con ejemplos concretos de cifras de mercado y decisiones de diseño.

Apuntes

El full stack: hardware, software y datos como tres patas iguales

Rahman defiende que para construir productos de este tipo hay que ser bueno en tres disciplinas a la vez, lo que llama el full stack. Primero, el hardware: dispositivos que la gente lleva encima 24 horas al día, porque si no se lleva puesto, todo el valor añadido de sensores y contexto se desmorona. Segundo, el software de aplicación, con un nivel de exigencia comparable al de Instagram o WhatsApp en cuanto a engagement. Tercero, los datos: saber qué hacer con el volumen masivo de información que generan los sensores, cómo procesarla y devolverla al usuario de forma útil. Ninguna de las tres patas basta por sí sola; el valor aparece cuando las tres funcionan juntas y se refuerzan.

Esta combinación no es habitual. Los equipos de hardware suelen dominar ingeniería mecánica y eléctrica pero no construir servicios digitales, y viceversa. Cuando Jawbone unió ambos mundos, generó fricción real: el equipo de software estaba acostumbrado a moverse rápido e iterar sobre la marcha, mientras que hardware necesitaba tiempos de decisión mucho más largos por los ciclos de fabricación. El resultado con el tiempo fue positivo en ambas direcciones: hardware aprendió a acelerar, y software aprendió a pensar más las decisiones antes de lanzar, en lugar de lanzar y testear después.

El contexto engine: por qué los wearables importan

Rahman explica la tesis de fondo de Jawbone sobre por qué apostar por dispositivos que se llevan puestos. Su argumento es que un dispositivo que está contigo permanentemente, a diferencia del móvil que a menudo se queda en la chaqueta o cargando, se convierte en un motor de contexto: sabe si tienes el pulso alto, si respiras rápido, si has dormido poco. Con esa información puede decirle a un termostato inteligente si tienes calor, a un coche si te estás quedando dormido, o a un altavoz qué canción poner según tu estado de ánimo. La visión de Rahman es que el ecosistema de dispositivos conectados en el hogar y alrededor del usuario, desde neveras hasta coches, necesita un elemento central que aporte ese contexto humano, y los wearables son ese elemento.

El proceso de creación de producto: de la exploración al lanzamiento

Jawbone estructura la creación de producto en fases claras, cada una con un propietario distinto dentro de la organización:

Exploración: fase de imaginación pura, liderada por el equipo de Desarrollo Estratégico (una especie de I+D). Se trabaja con inspiración, intuición y creatividad sin restricciones. Culmina en demo Fridays y hackatones donde el equipo muestra ideas al resto de la empresa. El criterio de paso a la siguiente fase es sencillo: ¿le daría a esta persona 50.000 dólares para que siga explorando la idea, como si fuera un inversor ángel? La decisión final la toma el CTO.

Validación temprana: aquí las ideas se someten a un proceso casi de tesis doctoral, con datos empíricos que sustenten por qué la idea puede funcionar. Empieza a participar el equipo de diseño industrial para pensar cómo la idea se convierte en algo físico, y se plantean preguntas de viabilidad: ¿hace falta esperar a que mejore la tecnología de baterías?, ¿hay presupuesto?, ¿hay negocio?

Concepto: la responsabilidad pasa del equipo de I+D al equipo de Experiencia de Producto, que en Jawbone integra diseño industrial, diseño de software, diseño de sonido y narrativa, todo bajo un mismo paraguas. Aquí se definen las Hero Experiences, es decir, los problemas más importantes que el producto va a resolver, y se empieza a perfilar el roadmap a largo plazo.

Planificación y desarrollo: la responsabilidad pasa a Product Management, que define el plan de negocio, el calendario de lanzamiento al retail y el ciclo de software, y empieza a tomar las decisiones de compromiso inevitables entre lo que se quiere construir y lo que la física y el presupuesto permiten. Finalmente entra ingeniería para comprometerse con fechas y construir de verdad.

Rahman menciona también la posibilidad de saltarse fases cuando conviene: con el Jambox decidieron pasar directamente a desarrollo sin completar todas las etapas intermedias, para llegar antes al mercado y testear con usuarios reales.

Los WHYS: la disciplina que evita la creatividad sin rumbo

El marco más citable de la charla son los WHYS. Es una pregunta que Rahman obliga a responder antes de construir nada: ¿cuál es el problema del usuario que este producto resuelve? La respuesta debe ser tan potente que, una vez resuelto el problema, la gente no pueda vivir sin el producto, ya sea porque tenían una necesidad latente evidente o porque ni siquiera sabían que la tenían hasta que apareció la solución.

El ejemplo que da es el del Jambox, el altavoz Bluetooth portátil de Jawbone. Cuando lo lanzaron en el otoño de 2010, el mercado de altavoces inalámbricos sobre el total del mercado de altavoces era del cero por ciento. Para la Navidad de 2013, esa cuota había subido al 78 por ciento. Si Rahman hubiese preguntado directamente a la gente si querían pagar 199 dólares por un altavoz para el móvil, según él mismo, el cero por ciento habría dicho que sí. El WHYS no se valida preguntando directamente por el producto, sino entendiendo el problema de fondo: que todo el contenido y los medios se habían trasladado al móvil y la gente necesitaba una forma portátil y de calidad de disfrutarlos en cualquier lugar, de forma fluida en el tiempo y el espacio.

Los WHYS también incluyen una pregunta de negocio: por qué le conviene a la empresa, no solo al usuario, resolver ese problema. En el caso del Jambox, los altavoces eran la entrada de Jawbone al hogar conectado, un punto de apoyo para vender millones de unidades y construir después servicios de software alrededor.

Track, understand, act: el marco para el Up24

Para la pulsera de actividad Up24, Rahman desarrolla otro marco memorable: track, understand, act (rastrear, entender, actuar). La idea de partida es que sabemos muchísimo sobre el mundo exterior gracias a internet, pero muy poco sobre nosotros mismos: por qué un día duermes ocho horas y te sientes mal, y otro duermes tres y te sientes genial.

El marco funciona en tres capas. Primero, rastrear: el hardware tiene que capturar datos fiables del cuerpo de forma casi invisible, lo que exige decisiones de diseño sobre baterías, materiales y comodidad para que el usuario mantenga el hábito de llevarlo puesto. Segundo, entender: los datos en bruto no significan nada por sí solos. Rahman pone el ejemplo de que si te dice que tu pulso es 75, no sabes si es bueno o malo sin contexto: depende de qué estabas haciendo y de quién eres. Tercero, actuar: convertir esa comprensión en una recomendación concreta, como recibir un recordatorio a las cuatro de la tarde para hacer ejercicio porque el sistema ha aprendido que entonces duermes mejor por la noche.

Cómo investigar usuarios sin preguntarles qué comprarían

Ante la pregunta de Sam Altman sobre cómo se puede saber que alguien pagaría 200 dólares por un altavoz si nunca lo pediría directamente, Rahman da una de las ideas más prácticas de la charla: no se trata de preguntar "¿quieres esta función?" sino de preguntar sobre comportamientos y hábitos. En lugar de preguntar si alguien quiere un reproductor de música portátil, la pregunta correcta es algo parecido a lo que hizo el iPod: "si pudieras llevar mil canciones en el bolsillo a cualquier parte, ¿te interesaría?". Las preguntas de investigación de usuarios sirven para refinar tu tesis, no para que el usuario te diga qué construir; esa decisión, dice Rahman, es responsabilidad del fundador.

Pensar en sistema, no en piezas sueltas

Varias preguntas del público giran sobre cómo evitar que cada equipo optimice su parte sin pensar en el conjunto. Rahman insiste en que un sistema es sobre todo una forma de pensar: cuando el equipo es pequeño, la coordinación ocurre de forma natural porque todos están en la misma sala. Cuando la empresa crece, hay que forzar esa comunicación con reuniones donde cada función expone sus restricciones, de modo que decisiones de un equipo, como reducir el tamaño de la batería, se entiendan en su efecto sobre otro equipo, como la calidad del sonido. Este ejercicio de trade-offs compartidos, según Rahman, es la esencia de construir productos complejos donde hardware, software y datos tienen que encajar.

Marcos y reglas prácticas

Errores habituales que señala el ponente

• Separar el diseño de hardware, software y datos como si fueran proyectos independientes en lugar de un único sistema.
• Preguntar directamente al usuario si compraría el producto o la función, en vez de investigar su comportamiento real.
• Dejar que la creatividad avance sin la disciplina de los WHYS, lo que produce productos sin un problema claro que resolver.
• No anticipar la fricción entre equipos de hardware, que necesitan ciclos largos, y equipos de software, acostumbrados a iterar rápido.
• Optimizar una pieza del sistema sin visibilidad sobre cómo ese cambio afecta a las demás piezas.
• Ignorar los detalles pequeños de la experiencia, como sonidos, animaciones o materiales, que son los que generan conexión emocional con el producto.

Preguntas para aplicarlo a tu proyecto

• ¿Puedes explicar en una frase el WHYS de tu producto: qué problema del usuario resuelve y por qué te interesa a ti resolverlo?
• Si tu producto combina distintas capas tecnológicas, ¿tienes claro quién es responsable de cada fase del proceso, desde la exploración hasta el lanzamiento?
• ¿Estás preguntando a tus usuarios si comprarían tu producto, o estás investigando cómo se comportan hoy sin él?
• ¿Qué pequeños detalles de tu experiencia, aunque parezcan menores, podrían generar una conexión emocional memorable?
• Cuando dos partes de tu equipo tienen restricciones opuestas, ¿tienes un espacio real donde se resuelvan esos trade-offs con visibilidad de todo el sistema?
• ¿Sabrías dar una cifra concreta, como Rahman con el paso del 0 al 78 por ciento de cuota de mercado, que demuestre el cambio de categoría que persigues?

Citas

• "El sistema de todo esto es que es una empresa de experiencias, no una empresa de hardware ni de software ni de datos" (Hosain Rahman, sobre cómo piensa Jawbone su identidad de producto).
• "Nadie te va a decir qué construir; si lo hicieran, deberían construirlo ellos y no tú" (Hosain Rahman, sobre el límite de la investigación de usuarios).
• "En el otoño de 2010 el mercado de altavoces inalámbricos era del cero por ciento; en la Navidad de 2013 era el 78 por ciento" (Hosain Rahman, sobre el impacto del Jambox).
• "Los sistemas complejos exigen que todos compartan sus restricciones en la misma sala" (Hosain Rahman, sobre coordinación entre equipos a medida que la empresa crece).

Recursos y lecturas de esta clase

Material original del curso, en inglés.