En Thiga Academy, uno de los pilares fundamentales es el desarrollo de producto, donde se observa el proceso desde la idea hasta el MVP y sus posteriores iteraciones. Por eso, queremos que formes parte de ese "mindset".
Imagina ser el Product Manager de Thilivery, la app de comida a domicilio de Thiga. Ahora mismo, te encuentras en un periodo de refinamiento y, gracias a la máquina de estados que tú y tu equipo implementasteis, has detectado una problemática que supone una gran oportunidad para mejorar la experiencia del usuario.
Acompáñanos en este paso a paso de la idea a la creación y del problema a la solución en este caso de uso.
Análisis de la Idea
Identifico una oportunidad
THILIVERY es un marketplace de comida de entrega a domicilio que funciona a través de app móvil y que tiene presencia internacional. En la plataforma se pueden diferenciar tres tipos de uso:
1. Como usuario final, tienes la oportunidad de pedir comida a restaurantes que se encuentren cerca de ti y de recibirla en el lugar que desees.
2. Como restaurante, tienes la oportunidad de darte de alta como proveedor para ofrecer los productos que desees de tu carta (comida y bebida).
3. Como repartidor, tienes la oportunidad de ofrecer tus servicios para realizar la recogida de los productos y envío a su destino final.
Como Product Managers centradas en mejorar la experiencia del usuario del mercado español que hace un pedido a través de la app, hace dos meses detectamos una problemática gracias a la máquina de estados implementada en ThiLivery para controlar el proceso end-to-end, desde la solicitud de un pedido hasta su recepción:
1 de cada 3 pedidos que se empezaban, permanecían en estado "iniciado" (desde el momento en el que se selecciona un producto de un restaurante hasta que se pasa al estado de "en proceso de pago"), alrededor de cuatro veces más del tiempo que habíamos establecido como "normal": 3 minutos.
Por esta razón, decidimos abordar esos casos especiales donde los usuarios tardan un promedio de 12 minutos desde el inicio de un pedido hasta su realización. Hicimos una encuesta a los usuarios que habían iniciado dichos pedidos, con el fin de obtener información sobre las razones que los llevaban a demorarse en la elección de los productos del pedido. Como resultado, identificamos un motivo recurrente en la mayoría de las respuestas: la intención de realizar un pedido conjunto para dos o más personas (pareja, compañeros de trabajo, amigos, familiares) que no están en el mismo lugar al momento de hacer el pedido, pero que desean o necesitan compartir una comida juntos
Dicho esto, ¿cuál es nuestro objetivo clave? Mejorar la satisfacción de nuestros clientes dando respuesta a sus necesidades a través de la app, favoreciendo la retención.
Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy
Identifico a mi usuario
En este caso, nuestro usuario objetivo es aquel que hace un pedido de comida a través de la app móvil y, además, presenta estas características:
- Hombre o mujer entre 18 y 45 años
- De clase media, media/alta y alta
- Perfil digitalizado
- Vive en pueblo y/o ciudad de más de 10.000 habitantes
- En algún momento necesita hacer un pedido conjunto para dos o más personas (pareja, compañeros de trabajo, amigos, familiares) que no se encuentran en el mismo lugar en el momento de hacer el pedido, pero que quieren o necesitan comer juntos.
Después de analizar los datos de los usuarios de ThiLivery en España, que incluyen edad, género, número de productos en el pedido y dirección de entrega, hemos concluido que el perfil de usuario descrito representa aproximadamente el 72% de los 3,6 millones de usuarios totales.
Creo una hipótesis
Si los usuarios tuvieran la posibilidad de realizar pedidos de manera colaborativa, donde dos o más personas pudieran acceder directamente al mismo pedido en la aplicación y seleccionar juntos los platos para su próxima comida con pareja, amigos, familiares o colegas; se agilizaría el proceso de pedido al evitar llamadas o mensajes para averiguar las preferencias de cada uno. Esta funcionalidad no solo reduciría la dependencia de herramientas externas, sino que también minimizaría posibles errores en el pedido final. En definitiva, esta característica contribuiría a aumentar la satisfacción de los usuarios y, en consecuencia, su retención como clientes de ThiLivery.
Estudio la propuesta de valor
Para estudiar nuestra propuesta de valor utilizamos el modelo "Value Proposition Canvas". Una herramienta centrada en el usuario, ideal para ahondar en los dolores, ganancias y tareas del usuario del producto.
Value Proposition Canvas - Thilivery
De este modo, visualizamos en una misma pantalla la alineación entre el producto (lado izquierdo) y el cliente objetivo (lado derecho).
¿Qué observaciones hacemos de nuestros usuarios?
- Customer jobs (tareas diarias de tus usuarios en contacto con el producto): Ingresar a la aplicación móvil y agregar, junto a otros usuarios, los artículos deseados a un único pedido.
- Pains (problemas que enfrentan los usuarios): Tardar mucho tiempo, tener que usar varias herramientas y cometer errores al hacer un pedido para más de una persona.
- Gains (que esperan y desean del producto): Poder hacer un pedido entre varias personas que se reúnen para comer juntas.
¿Qué observaciones hacemos de la propuesta de valor que queremos dar nuestro producto?
- Product & Services (productos y servicios relacionados con la propuesta de valor): Creación de un pedido conjunto entre múltiples usuarios a través de la aplicación.
- Gain creator (ventajas del usuario al usar el producto): Mejora de la experiencia al reducir el tiempo de gestión y prevenir errores en pedidos en grupo.
- Pain relievers ("dolores" del usuario que solucionamos al usar el producto): Ahorro de tiempo y de malentendidos.
TheoryShot
Hay una fórmula clave a considerar al prepararse para obtener la certificación de PMP (Project Management Professional), la cual se enfoca en el cálculo de los canales de comunicación, conocida como la "Communication Channels Formula PMP".
Communication Channels: 
siendo n el número de Stakeholders afectado por alguna parte del proyecto.
Esta fórmula considera la posibilidad de que cualquier parte interesada pueda comunicarse hipotéticamente con cualquier otra parte interesada. Esto puede hacer que el número de posibles canales de comunicación aumente rápidamente a medida que incrementa el número de partes interesadas. Con tantos canales de comunicación posibles, también aumenta la probabilidad de que se produzca un error de comunicación en algún lugar.
Pensando en el caso que estamos analizando de crear un pedido conjunto, podemos hacer el símil sobre:
- el ‘proyecto’ es hacer un pedido.
- los ‘stakeholders’ son las personas que piden algún producto.
Por lo tanto, con cuántas más personas haya que comunicarse para conocer sus necesidades sobre un mismo pedido, mayor será el tiempo invertido en hacer el pedido, y además, aumentará la posibilidad de que se produzca un error.
Considerando todo lo anterior, al habilitar en nuestra aplicación la opción de realizar un pedido conjunto entre dos o más personas, eficientaríamos el proceso, reduciendo el tiempo de comunicación y minimizando los errores, ya que cada individuo podría seleccionar personalmente lo que desea pedir.
Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy
Validación de la Idea
Validación Interna
Recordemos que como Product Managers siempre tenemos que tener en mente la escalabilidad del producto que estamos desarrollando. En el caso de ThiLivery, además de España, país en el que se centra nuestro análisis, operamos en 24 países.
1. Departamento Legal
Nos aseguramos de que la idea presentada cumple con todos los requerimientos legales vigentes en España.
En este sentido, tendremos que cumplir con la Ley de Protección de Datos (Ley Orgánica 15/1999 de 13 de diciembre de Protección de Datos de Carácter Personal) que lleva activa desde el año 2000, y se fundamenta en el artículo 18 de la constitución española sobre el derecho a la intimidad familiar y personal y el secreto de las comunicaciones. Entre los requerimientos de esta Ley a tener en cuenta al desarrollar la nueva funcionalidad propuesta, cabe destacar los siguientes puntos:
- Hay que especificar qué datos van a ser recogidos y con qué fin van a usarse.
- Los datos que se recojan han de ser sólo los necesarios para cumplir con dicho fin.
- Es importante informar al usuario que brinda sus datos, sobre su derecho a modificar o eliminarlos, y proporcionarle un medio de contacto para ello. Asimismo, se debe especificar claramente quién es responsable de la gestión de dichos datos.
- La persona que proporciona los datos debe dar su consentimiento y saber que éste puede ser revocado con una causa justificada.
2. Departamento Tech y Diseño
Para ofrecer la posibilidad de crear un pedido compartido mediante la app por parte de varios usuario, debemos tener en cuenta diferentes tareas:
- Cada vez que un usuario inicie un pedido, se debe generar un link para poderlo compartir con otro usuario.
- Crear un botón que realice la función de compartir ese link.
- Si el usuario dispone de la app Thilivery, y está logueado (sino, solicitar el log in), se le debe permitir que acceda directamente a través del enlace al pedido que se está personalizando, y añadir el/los producto/s que deseados.
- Si el usuario no dispone de la app Thilivery, se le debe permitir acceder a haciendo click en el link y que, posteriormente, pueda introducir un email como “guest” para ir al pedido que se está realizando, y añadir el/los producto/s que deseados.
- Identificar dentro del pedido quién (con nombre y apellido) ha añadido qué.
- El usuario que inicia el pedido debe poder pueda finalizar el pedido, es decir, pagar y solicitar el envío de todos los productos en el momento y destino deseado.
Validación Externa
1. Usuarios
Con la ayuda de la analítica de datos que hemos integrado en nuestra aplicación a través de Amplitude, podemos monitorizar datos de uso de las diferentes funcionalidades. En este análisis nos enfocamos en la funcionalidad de compartir menús que implementamos hace un mes a través de un primer MVP llamado MVP de aprendizaje. Este MVP permitía compartir el menú de un restaurante específico con otras personas.
- MVP aprendizaje (MVP 1): Compartir menú
Descripción: Se trata del primer MPV que hemos lanzado, y del cual hemos obtenido datos y validado la propuesta. El MVP se ha basado en implementar la opción de compartir el menú de un restaurante con otro usuario a través de un link.
Métrica objetivo: Lograr que al menos 2 de cada 3 usuarios que finalizan un pedido de 3 o más productos hayan utilizado la nueva funcionalidad.
Métricas de uso (Análisis de datos): Observamos que 2 de cada 3 WAU (Weekly Active Users) usa la funcionalidad de compartir menú y hace un pedido de 3 o más productos. Esto nos indica que nuestros usuarios tienen la necesidad de hacer pedidos para múltiples personas, incluso si no están juntas en el mismo lugar al momento de realizar el pedido.
Teniendo en cuenta los resultados de esta validación externa, concluimos que el desarrollo de una nueva funcionalidad que facilite a nuestros usuarios crear pedidos conjuntos, puede aportar un valor añadido a la plataforma, ya que ayuda a nuestros usuarios a resolver un problema habitual.
2. Benchmark
Las plataformas de comida a domicilio son bastante parecidas entre sí, a diferencia de algunas que ofrecen funcionalidades aplicadas a cubrir necesidades más específicas sobre sus usuarios.
Analizando las aplicaciones de las principales empresas de comida a domicilio en cuanto a la existencia o no de una funcionalidad para tratar el caso de uso arriba explicado (realizar un pedido en conjunto), vemos que:
- ThiJust [Just Eat]: te permite realizar pedidos de un catálogo de restaurantes. El pedido solo puede hacerse de manera individual, y no permite compartir con otro usuario el menú del restaurante donde se quiere realizar el pedido.
- ThiEats [Uber Eats]: ofrece una opción para realizar pedidos en grupo, permitiendo incluso elegir si el pago se realiza de manera conjunta o individual, y el administrador puede establecer el límite máximo de pedido por persona.
- ThiFastFood [Telepizza, Domino´s & Burger King]: con estas aplicaciones puedes hacer pedidos de comida de un restaurante en concreto, no de varios. El pedido solo se puede realizar de forma individual por cuenta de usuario, y en ellos no te permite compartir menús o el pedido para que otros usuarios puedan añadir sus preferencias. En el caso de querer hacerlo, será el usuario principal el que añada dichas preferencias y realice el pago completo.
Al analizar a la competencia, podemos ver que hay un competidor que ya permite la opción de realizar pedidos en conjunto. Esto refuerza la idea de que integrar la funcionalidad de "pedido conjunto" es esencial para nuestra aplicación móvil.
Validamos dentro del flujo del producto
User Journey
Usamos la herramienta User Journey para revisar cómo es el camino actual de una persona que quiere hacer un pedido conjunto, y cuáles son los pain points que se generan y por tanto, definir aquellos que podríamos atacar con la nueva solución:
- User Journey actual -
- 👩 🏠 María se encuentra en casa y quiere invitar a dos amigos a cenar. Decide hacer un pedido en ThiLivery ⬇️
- 📱María accede a ThiLivery a través de la app móvil y decide el restaurante al que quiere hacer el pedido.
- 😔 Pain Point 1: tiene que usar otra app para preguntar
- 💬 María quiere saber qué les gustaría comer para poder incluirlo en el pedido. Les escribe por Whatsapp y les comparte el menú del restaurante a través de la app.
- ➡️ 👱♀️ Ana responde que quiere sushi uramaki, maki y nigiri.
- ➡️ 👱♂️ Juan responde que quiere sashimi, ensalda de algas y cerveza japonesa.
- ➡️ 📱María vuelve a acceder a ThiLivery para añadir los pedidos de todos pero olvida incluir uno de los platos que Ana ha pedido. Indica la dirección de envío y paga el pedido.
- 😔 Pain Point 2: se produce un error en el pedido.
- ➡️ 🚲 🏠 👩 👱♀️👱♂️ El pedido llega a casa de María. ➡️ Ana se da cuenta de que no tiene uno de sus platos y María, de su error al hacer el pedido.
Después de analizar detenidamente el user journey actual, confirmamos que nuestra propuesta resolvería los puntos de dolor encontrados por el usuario. Nuestra solución permitiría al usuario realizar un pedido conjunto sin necesidad de recurrir a otras aplicaciones, lo que significa un ahorro de tiempo, evitando errores de comunicación y eliminando la posibilidad de cometer errores manuales al realizar los pedidos. Esto, a su vez, reduce la frustración que los usuarios suelen experimentar.
- User Journey implementando las mejoras -
Si implementamos la solución planteada (funcionalidad de "pedido conjunto") el user journey quedaría de la siguiente manera:
- 👩📱 María decide hacer un pedido conjunto en la plataforma de ThiLivery ➡️ accede a la app y elige un restaurante.
- Una vez dentro del restaurante, María selecciona el botón "pedido conjunto" ➡️ añade a tantas personas como necesita indicando su nombre y apellido, y comparte el pedido (email, whatsapp, en la propia app etc.) ⬇️
- 👱♀️👱♂️ Ana y Juan reciben el link al pedido ➡️ añaden los productos que desean
- María recibe la información de que los usuarios 2 y 3 han completado la información ➡️ añade la dirección de envío y hace el pago.
- 👩👱♀️👱♂️🏠 María, Ana y Juan reciben el pedido en la dirección indicada y disfrutan juntos de la comida. 😄
Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy
De la Idea al Producto
Definimos MVP e Iteraciones
Una vez validada la propuesta, continuamos con la estrategia planteada basada en MVPs & Iteraciones mediante la creación de un Roadmap donde movemos números de negocio. Una nueva iteración no se llevará a cabo si la anterior no ha cumplido con las métricas objetivo. Así, ajustamos el producto a las necesidades reales (ya probadas) de los usuarios.
MVP 2: Pedido asociado a un grupo de personas
Descripción: El usuario podrá realizar un pedido que esté vinculado a un grupo específico de personas. Para ello, elegirá el restaurante, iniciará el pedido a través del botón "pedido asociado a un grupo" y creará un grupo con los nombres y apellidos de las personas para las que se hará el pedido. A continuación les compartirá un link con el que accederán a ver la carta del menú del restaurante. Una vez seleccionados los productos deseados, los usuarios comunicarán al iniciador del pedido a través de otro medio, para que este pueda agregar en la aplicación los productos elegidos por cada uno junto a su nombre y apellido. De este modo, facilitaremos al usuario mantener un seguimiento claro de quién aún no ha comunicado sus preferencias y de quién ha seleccionado cada producto, lo que simplificará el proceso a la hora de realizar el pago y dividir los gastos.
Métrica objetivo: 70% de los usuarios que usan la funcionalidad de compartir menú y hace un pedido de 3 o más artículos, usan esta opción de ‘pedido asociado a un grupo de personas’ reduciendo el tiempo medio de creación y gestión del pedido de 12 min a 10min.
- Iteración 1: Pedido conjunto
Descripción: todas las personas involucradas en el pedido pueden seleccionar personalmente los productos que desean y realizar el pedido de forma conjunta. Para comenzar, el usuario que inicia el pedido elegirá el restaurante, iniciará el pedido pulsando el botón "pedido conjunto", formará un grupo con los nombres y apellidos de las personas para las que se realizará el pedido y les enviará un enlace a través de whatsapp o email. Mediante ese link, cada persona accederá a ver la carta del restaurante, seleccionará su nombre y apellido y añadirá los productos que desee. El cliente que inició el pedido podrá ver las actualizaciones en el pedido al acceder a él, además de poder ingresar la dirección de envío y completar el pago. Una vez realizado, el pedido estará listo para ser enviado.
Métrica objetivo: un 80% de los usuarios que utilizan la función de compartir menú y realizan un pedido de 3 o más productos, prefieren la opción de "pedido conjunto", logrando reducir el tiempo promedio de creación y gestión del pedido de 10 minutos a solo 3 minutos. - Iteración 2: Notificaciones
- Sobre modificaciones en el pedido al usuario iniciador del pedido
Descripción: Incluir la opción de recibir notificaciones por parte del usuario iniciador del pedido:- Cada vez que algún miembro haya completado su parte del pedido.
- Cuando todos los miembros del grupo hayan terminado de incluir sus productos, para proceder a añadir los datos de envío y pagarlo.
- Sobre modificaciones en el pedido a los demás usuarios del pedido
Descripción: Incluir opción de activar notificaciones sobre el cambio del estado del pedido a todos los miembros del pedido en conjunto sobre:- Información del estado del envío del pedido a partir del estado "listo para envío".
- Recordatorio de que has recibido un link para unirte a un pedido, pero todavía no has añadido tus productos.
- Sobre modificaciones en el pedido al usuario iniciador del pedido
- Iteración 3: Pago fraccionado del pedido
Descripción: Incluir la opción de hacer el pago fraccionado entre los usuarios del pedido. El usuario que inicia el pedido será quien seleccione el tipo de forma de pago antes de su envío, lo cual accionará el cobro del importe correspondiente a todos los participantes.- Opción de realizar el pago a medias entre todas las partes.
- Opción de que cada uno pague su parte del pedido.
Métrica objetivo: 50% de usuarios activan la opción de notificaciones sobre estatus del pedido.
Cronograma MVP e Iteraciones
Organizamos Liturgias & Métricas
Una vez definido el roadmap, ya podemos pasar al desarrollo del producto. Para organizar y gestionar el trabajo conjunto con el equipo de desarrollo, será de ayuda tener estandarizados una serie de procesos y ceremonias:
- Podemos trabajar en scrum con sprints de 2 semanas.
- Implementaremos las ceremonias:
- Sprint planning ➡️ al inicio del sprint
- Daily ➡️ de lunes a viernes 15 minutos
- Backlog refinement ➡️ 1 la semana (por ejemplo viernes y lunes siguiente)
- Sprint review y sprint retrospective ➡️ ambas al final del sprint
- Trabajaremos nuestro backlog priorizando con el framework RICE.
Conclusión
En este viaje como Product Manager de Thilivery, hemos identificado y abordado una problemática clave que afecta la experiencia de nuestros usuarios al realizar pedidos conjuntos. A través de un análisis detallado y la implementación de hipótesis basadas en datos, hemos propuesto soluciones innovadoras que no solo mejoran la satisfacción del cliente, sino que también optimizan el proceso de pedido.
La introducción de funcionalidades como el pedido conjunto y la posibilidad de compartir menús directamente en la app, permiten a nuestros usuarios hacer pedidos de manera colaborativa, eliminando la necesidad de herramientas externas y reduciendo errores. Esta solución no solo mejora la eficiencia del proceso de pedido, sino que también fomenta una mayor retención de clientes al satisfacer una necesidad frecuente de nuestro mercado objetivo.
Al validar nuestra propuesta tanto interna como externamente, y al realizar un benchmarking con otras plataformas de comida a domicilio, hemos confirmado que nuestra dirección es la correcta. La implementación de MVPs y iteraciones cuidadosas asegura que nuestras soluciones sean escalables y se ajusten continuamente a las necesidades reales de los usuarios.
Con un roadmap claro y métricas de éxito bien definidas, estamos preparados para desarrollar y lanzar estas mejoras. Nuestro enfoque en la colaboración y la mejora continua, utilizando metodologías ágiles como Scrum, garantiza que nuestro equipo esté alineado y enfocado en entregar valor constantemente.
En resumen, la capacidad de realizar pedidos conjuntos a través de Thilivery no solo resolverá problemas actuales, sino que también fortalecerá nuestra propuesta de valor, posicionándonos como líderes en el mercado de comida a domicilio. Este caso de uso destaca la importancia de la escucha activa, la adaptación rápida y el enfoque centrado en el usuario para el desarrollo exitoso de productos.
Fórmate con profesionales top en el Curso de Product Manager de Thiga Academy
