Moovit
Diagnóstico y propuesta de producto (Coderhouse, módulo PM)
Moovit perdía usuarios
Analicé Moovit, la app de transporte público que uso en CDMX, como caso real para mi módulo de Product Manager en Coderhouse. Con evidencia real de reseñas encontré que el 45% de las quejas venían de un anuncio que bloquea la pantalla durante la navegación activa. Propuse eliminarlo de ese momento y sumar un indicador de confiabilidad en tiempo real, validado contra una North Star Metric propia. También definí el modelo de negocio y el roadmap para sostener la propuesta sin sacrificar ingresos.
Año:
2026
Duración
3 meses
Herramientas:
FigJam, Notion, Figma, Claude
Categoría:
Producto (Product Management)
Overview
Problema
No partí de una hipótesis mía. Fui a reseñas reales de App Store, Google Play y Trustpilot (2024-2025) y clasifiqué los dolores por frecuencia: - Crítico (45% de las reseñas): un anuncio de video intersticial bloquea toda la pantalla durante la navegación activa —justo cuando el usuario necesita ver por dónde va su camión. - Alto (30%): el tiempo real es inconsistente. El caso típico que aparece una y otra vez: "indica 9 min y al minuto dice 1 o que ya pasó". - Medio: el home inicial es denso y no orienta bien a un usuario nuevo.
Propuesta
La corazonada fácil era "quitar los ads". La descarté como única solución porque el modelo de negocio de Moovit depende de publicidad, y Google Maps ya ofrece navegación gratis sin ads — quitarlos sin más no es diferenciación, es copiar a tu competencia más grande. En vez de eso, planteé la hipótesis así: quitar los anuncios durante la navegación activa + agregar un indicador de confiabilidad del tiempo en tiempo real, para reducir el abandono en la etapa de uso. La medí contra una Matriz F-O-I (Factibilidad-Oportunidad-Impacto) frente a otras dos opciones (simplificar el home, rediseñar el onboarding), y esta combinación ganó por márgen claro.
Solución
El entregable final fue un paquete de producto completo: journey map, historias de usuario con criterios Gherkin, contratos de API a nivel de arquitectura, roadmap a 6 meses, y wireframes en Figma mostrando el antes/después real —capturas reales de los ads invasivos de Moovit CDMX vs. la propuesta con un badge de confiabilidad por estación y mapa limpio.
Impacto
El impacto esperado que definí y que serviría para validar la hipótesis: mejora de 15-20% en Retención D7, medible en un experimento post-lanzamiento del MVP. Un PM no diseña la pantalla ni escribe el código: define el problema correcto y prioriza la solución correcta para que el equipo construya lo que importa, en el orden que importa.
