SaveFamily
Este rol es responsable de la hoja de ruta de producto de la app y los relojes de SaveFamily, impulsa las mejoras de UX y convierte el feedback de los usuarios —hoy disperso entre country managers, soporte/ATC y reseñas de las tiendas de apps— en un backlog estructurado. Trabaja de cerca con Ingeniería para priorizar y lanzar, y con Marketing/Category Management en cómo las funcionalidades cobran vida comercialmente.
Se han facilitado dos extractos y cinco preguntas:
Datos de toda la compañía, en todos los mercados.
| Métrica | Abr | May | Jun | Jul | Ago | Sep |
|---|
Las cinco preguntas del caso.
Revisa el Feedback inbox. ¿Cómo agruparías y priorizarías estos ítems? Explícanos tu marco de trabajo, no solo el orden final.
Ver respuesta ↓Mira los Usability KPIs. ¿Qué historia cuentan los números? ¿Cuál es tu hipótesis sobre lo que impulsa las tendencias que ves?
Ver respuesta ↓Combina lo que has visto en ambas pestañas y esboza una hoja de ruta a 6 meses. ¿Qué abordarías primero, después y más adelante, y con qué criterio?
Ver respuesta ↓¿Qué ítems de tu hoja de ruta son transversales? ¿Quién más tiene que estar en la mesa y cómo organizarías y secuenciarías esa colaboración durante los 6 meses?
Ver respuesta ↓¿Qué seguirías midiendo por el camino para saber que tu hoja de ruta funciona, y qué te haría cambiarla a mitad de camino?
Ver respuesta ↓Para agrupar los feedbacks, en principio, simplemente los organizo por el problema del que nos hablan.
Un cliente potencial no firma si el colgante no se empareja por QR, algo que los relojes ya hacen. Es una sola petición, pero puede ser un trato grande.
¿Cuántas unidades hay detrás y cuánto cuesta reutilizar el QR de los relojes?
Los tickets de «Los contactos no se sincronizan de la app al reloj» son repetidos y muestran cómo el usuario (en este caso los padres) tiene que buscar soluciones alternativas, y muy poco eficientes, para configurar los contactos. Esto es una fricción grande para una feature básica del reloj.
¿Es un fallo o una limitación del reloj? ¿Pasa en todos los modelos?
Aquí juntamos dos feedbacks diferentes: por un lado, una tabla de referencia para límites de contactos, SOS y agenda; por otro, una comparativa sencilla de batería y funciones por modelo. Los tickets no son por un problema en el producto, sino por falta de información accesible.
¿La información ya existe o hay que crearla? ¿Dónde la buscaría cada uno?
El reloj no avisa de forma satisfactoria. Que haya dispositivos que pasan meses sin actualizarse significa que funcionan peor.
¿Quién ve hoy el aviso: el niño o el padre?
Si no completan el onboarding, abandonan más. No hay ningún recordatorio.
¿En qué paso se quedan? ¿Es falta de tiempo o se atascan?
Reinstalar apps como Spotify o WhatsApp es un proceso manual de varios pasos que el usuario no conoce. Si el proceso es eficiente, es un problema de comunicación; si no lo es, de usabilidad.
¿Cuántos hacen un reset y por qué?
Desde Ingeniería nos dicen que la falta de traducciones del firmware puede bloquear el lanzamiento. Desde Dirección marcan una fecha y señalan que falta un plan coordinado de lanzamiento. Ambos feedbacks son parte del mismo problema.
¿Qué idiomas faltan? ¿Quién lidera el plan de lanzamiento?
Con el feedback recibido hemos encontrado 6 o 7 posibles problemas diferentes. Algunos más urgentes o críticos y otros que igual podemos investigar más adelante, pero antes de decidir cuál atacamos prefiero analizar el resto de la información disponible.
Todo va a peor, mes a mes y sin grandes saltos. No parece que sea un fallo puntual.
Menos gente acaba el onboarding; el resto son consecuencias en cadena.
No hay aviso ni recordatorio (extraído del Feedback Inbox).
Geofencing y modo escolar.
Por ejemplo, contactos que no aparecen en el reloj.
+14 en los últimos seis meses.
Impacta negativamente en la percepción del producto.
Vamos a utilizar el marco que propone SaveFamily en la oferta del puesto, pero con un matiz.
A continuación hago una tabla con una estimación. Vamos a asumir que hemos hablado con Desarrollo, con Marketing… y nos han dado su impresión sobre el esfuerzo que supondría cada uno. Para ello formulamos los problemas como soluciones: así hablamos de cuánto cuesta crear esa solución.
| # | Problema | Solución | Alcance | Impacto | Confianza | Esfuerzo | Puntuación |
|---|
Escala del 1 al 5. Puntuación = alcance × impacto × confianza ÷ esfuerzo (máximo posible: 125). Son estimaciones, a calibrar con el equipo.
El lanzamiento del Iconic+3 no entra en la tabla. Tiene una fecha comprometida (Q1 2027) y lo más probable es que parta de una decisión de Dirección, con un plan que lleva otra persona y otro departamento. En ese caso no lo priorizamos nosotros: adaptamos nuestro cronograma a ese plan, que tendría máxima prioridad.
El RICE se apoya en supuestos. Estas son las respuestas a las preguntas abiertas que reordenarían la lista.
El cliente del colgante es muy grande, o hay más clientes pidiendo lo mismo.
Sube. Se decide como trato comercial, no con el RICE.
Para que los contactos se sincronicen hay que configurar algo al empezar (un permiso, un paso) y la gente se lo salta.
Se une al problema padre Onboarding y sube con él.
En el onboarding se atascan en un paso concreto: no es que les falte tiempo.
El recordatorio no basta: hay que arreglar ese paso. El esfuerzo sube.
Hay muchos relojes sin actualizar y el aviso solo lo ve el niño.
El firmware sube, sobre todo con el firmware del Iconic+3 en camino.
Los resets son frecuentes porque el reloj falla.
La reinstalación es un síntoma: el problema real es otro, y sube.
La información de los modelos no existe y hay que crearla.
La documentación deja de ser un quick win.
Tres fases de dos meses y dos puertas. Cada puerta es una condición para pasar a la fase siguiente. Si no se cumple, se revisa la hipótesis antes de seguir.
Frenar la caída antes de la puerta 1 y, en marzo, estar cerca de los niveles de abril: onboarding por encima del 72% y tickets por debajo de 32 por cada 1.000 dispositivos. Es una referencia de partida: se ajusta en cuanto tengamos datos reales.
Onboarding, documentación y responder las preguntas abiertas.
Contactos, firmware y reinstalación; cerrar traducciones.
Iconic+3 en Q1 2027 y repuntuar el RICE con los datos nuevos.
En el test A/B, quienes reciben el recordatorio terminan más el onboarding en su primera semana, y tenemos respuesta a las preguntas abiertas. Con ellas se repuntúa el RICE. Si no hay diferencia, se revisa el embudo antes de seguir.
El nuevo aviso de firmware funciona antes del Iconic+3 y nuestras entregas para el lanzamiento (traducciones, documentación y formación) están a tiempo. Si algo se retrasa, lo escalamos a quien lidera el lanzamiento y ajustamos nuestro cronograma a su plan.
Puntúa bajo (6), pero en Q1 2027 sale el firmware del Iconic+3. Si el aviso de actualización no funciona, el lanzamiento nace cojo. Por eso lo adelantamos a la fase 2, alineado con el plan de lanzamiento.
En las primeras dos o tres semanas preguntamos cuántas unidades hay detrás. Si el trato es grande, sube.
Así estaría el tablero a mitad de octubre, en pleno primer sprint. La mayoría de problemas empieza en descubrimiento, no en desarrollo.
Una iniciativa no se mueve de columna hasta convertirse en tarea: se descompone en piezas más pequeñas. Un ejemplo con el onboarding.
Mejorar la activación de los clientes nuevos.
Recordatorio de onboarding.
«Como padre que dejó la configuración a medias, quiero que me recuerden lo que me falta, para que el reloj funcione del todo.»
La prioridad del sprint no se decide solo en Producto. Cada dos semanas se sientan los departamentos que tienen algo en juego y cierran juntos qué va fijo, qué debería ir, qué estaría bien y qué no entra.
Los ítems transversales de la hoja de ruta son tres: la documentación (Soporte, Marketing y Category), el lanzamiento del Iconic+3 (Ingeniería, Marketing, Category y quien lo lidera) y el colgante (country managers e Ingeniería).
Aviso de onboarding: diseño y primer envío. Producto · Ingeniería
Medir el embudo del onboarding por pasos. Ingeniería
Tabla de límites por modelo y comparativa de batería y funciones. Soporte · Marketing · Category
Traducciones del firmware del Iconic+3. Ingeniería · plan de lanzamiento
Colgante: tamaño del trato. Country managers
Entrevistas con padres que no terminaron el onboarding. Producto · UX
Contactos: averiguar si es un fallo o una limitación. Ingeniería
Firmware: cuántos relojes están sin actualizar. Ingeniería · Soporte
Resets: cuántos hay y por qué. Soporte
Desarrollar la sincronización de contactos: hasta saber qué falla. Ingeniería
Desarrollar el QR del colgante: hasta conocer el trato. Ingeniería
Medimos cada mes los KPIs que menciona la oferta del puesto y los del caso, y cada uno lleva definida de antemano la señal que nos haría cambiar de rumbo.
| Qué medimos | Para qué | Cuándo cambiamos el plan |
|---|---|---|
| Successful Onboarding Rate, con el embudo por pasos | Comprobar que el recordatorio funciona y ver en qué paso se quedan | Si vemos que no sube tras los recordatorios, es que el problema era otro. Revisamos el embudo antes de seguir. |
| Activation Rate | Ver si quien termina la configuración llega a usar el producto | Nos evita cantar victoria antes de tiempo. Si el onboarding mejora pero la gente no usa el producto, eran dos problemas diferentes y toca buscar otra hipótesis. |
| Abandono (churn): quien completó el onboarding frente a quien no | Nos llegó el feedback de que quien no completa el onboarding abandona más. Esta es la forma de comprobarlo y ponerlo en números. | Si los dos grupos abandonan igual, el onboarding no explica las bajas y revisamos la hipótesis. |
| Device Pairing Success Rate | Medimos el pairing en el colgante y en los relojes. | Si el emparejamiento falla más en el colgante, ya no es el capricho de un cliente puntual. |
| Tickets por 1.000 dispositivos, por categoría | Ver qué categorías pitan más y si suben o bajan. | Miramos si son de configuración o de otra cosa. Si bajan los de onboarding pero suben los de contactos, repriorizamos. |
| NPS y rating de App Store | La percepción del cliente. Llegan más tarde que los cambios. | Se mira la tendencia y no un solo mes |
| Firmware actualizado y tiempo al primer GPS | Comprobar si el firmware explica el GPS más lento | Si no hay relación, el GPS lento tiene otra causa; el aviso sigue, por el Iconic+3 |
| Todas las anteriores, por modelo, desde el lanzamiento del Iconic+3 | Que el lanzamiento no se confunda con el efecto de lo que hemos hecho | Si algo se mueve solo en el Iconic+3, es cosa del lanzamiento y no de nuestras soluciones. |
| Nuestras entregas para el lanzamiento | Llegar a tiempo con traducciones, documentación y formación | Si se retrasan, se escala a quien lidera el lanzamiento |