Caso Rappi: ¿cómo se rediseña un producto?

Paso a paso de cómo mi equipo rediseñó la aplicación Rappi Restaurant. Desde la perspectiva de un Product Manager. Desde cuando me pregunte «¿Cómo se rediseña un producto como este? hasta el exitoso resultado final.

Por Cesar Hoshi, artículo original aquí.

Acerca de este caso de como se rediseña un producto

TL; DR de los resultados finales:

Mi equipo y yo rediseñamos la aplicación Rappi Restaurant (la que usan los restaurantes para recibir los pedidos de comida de los usuarios para la entrega), e inmediatamente mejoramos en un 30% nuestra métrica principal “pedidos cancelados por falla del restaurante”.

Suponga cualquier cambio en “X” en ese número inicial de pedidos cancelados, multiplique eso por los cientos de miles de pedidos de alimentos que Rappi hace por día en América Latina, y esa mejora es el impacto que logramos, mientras construimos lo que consideramos un mejor producto para nuestros usuarios. En esta publicación, intentaré describir paso a paso el proceso que llevamos desde el descubrimiento hasta la ejecución del como se rediseña un producto.

El caso gira en torno a una aplicación de restaurante en el contexto de la entrega de alimentos, pero esta publicación será interesante y reveladora para las personas de Producto / Diseño / Tecnología y los equipos de resolución de problemas en general.

Antecedentes de Rappi:

Rappi es uno de los pocos “Unicornios” latinoamericanos (TechCrunch 2019: “Softbank hace una gran apuesta en América Latina”), es una startup de entregas bajo demanda con ambiciones impresionantes de ser la super-aplicación número 1 en la región.

Entre todos sus verticales (supermercados, banca, comercio electrónico, etc), el de Restaurante es uno de los más importantes. Los cientos de miles de pedidos de comida al día que hacen los clientes finales, tienen que pasar por la app de restaurante que analizaremos en este post.

Experiencia personal:

Considerando que mi último producto y emprendimiento fue una App de citas (puedes ver aquí mis 6 lecciones sinceras de una Startup fallida en Latam), y considerando el hecho de que NO tenía experiencia previa en la industria de restaurantes, el desafío de optimizar “RappiAliado” (La llamaré “la aplicación del restaurante” de ahora en adelante), una aplicación que ya recibía cientos de miles de pedidos de comida al día, sonaba más que interesante.

Tuve que cambiar mi mente de encontrar un producto adecuado al mercado usuarios finales (activación, participación, retención), a optimizar salvajemente las métricas operativas para el negocio.

Problema a resolver… ¿cómo se rediseña un producto?:

El objetivo principal era reducir lo que llamamos “pedidos cancelados por falla del restaurante” (número de pedidos cancelados por motivos de atribución del restaurante), estos son los que perjudican al usuario final que no recibirá su comida (afectando la experiencia del cliente final, retención de usuarios en la aplicación Rappi y afecta directamente las ventas de los restaurantes). Algunos ejemplos: el restaurante …

• Se perdió de aceptar un nuevo pedido de un cliente.
• Aceptó un nuevo pedido pero se olvidó de prepararlo.
• Se mantuvo esperando demasiado tiempo al repartidor por una entrada falsa en el tiempo de cocción.
• Arruinó el pedido colocando un producto que el cliente no pidió, o dándole un pedido al repartidor incorrecto.
• Etc.

El desafío era reducir estas cancelaciones desde la perspectiva del producto.

Proceso para comprender el negocio, la situación actual y los problemas del usuario

¿cómo se rediseña un producto en otras compañías?… Benchmarking

Era obvio comenzar a hacer revisiones comparativas para ver lo que ya estaba haciendo la industria alimentaria. Me llamó la atención que los principales actores de la región (UberEats, iFood y Rappi) tuvieran casi un copy-paste del producto.

Si todas las demás empresas están haciendo esto (lado izquierdo: lista de pedidos activos; lado derecho: detalle del pedido), debe ser la mejor solución, ¿verdad? Llegaremos a eso.

Fuente

Este fue el estándar para las aplicaciones de restaurantes (2019).

La fuente de ideas (cliente vs usuario)

Desde el primer día, recibí una gran cantidad de “ideas increíbles para mejorar la aplicación” del equipo de operaciones de Rappi.

Me dieron un backlog basado en los deseos de los propietarios de restaurantes y las solicitudes del equipo de operaciones de Rappi. Eso debe haber facilitado mi trabajo, ¿verdad? Bueno, en realidad fue todo lo contrario, instantáneamente me recordó la publicación clásica de Marty Cagan “Por qué fallan los productos”:

“La fuente de las ideas: este modelo conduce a ofertas especiales impulsadas por las ventas y productos impulsados ​​por las partes interesadas (…) pero, por ahora, permítanme decirles que esta no es la fuente de nuestras mejores ideas de productos”.

Marty Cagan: Producto fail (2015)

Analicemos esas fuentes de ideas:

• Ofertas especiales impulsadas por las ventas: las solicitudes de productos fueron realizadas por los clientes (PROPIETARIOS de restaurantes). Tiene sentido escucharlos, ellos son los que le pagan a Rappi por el servicio, y cuanto más felices son, más acuerdos cierra Rappi. Pero me preocupaba que ellos no sean los usuarios reales. Los usuarios reales de mi aplicación son los CAJEROS y OPERADORES de la cocina, y tienen una mentalidad completamente diferente a la de los propietarios.
• Producto impulsado por las partes interesadas: el producto se creó de acuerdo con nuestros deseos internos (como empresa). Cada una de las solicitudes del equipo de operaciones de Rappi fue inteligente y bien analizada con datos. Pero aún así, era lo que quería nuestro equipo de operaciones, no lo que necesitaban los usuarios.

Decidí ignorar la mayor parte de mi participación

Utilizando para una comprensión clara del usuario y sus problemas).

Roles en la cocina

Pasé gran parte de mis primeras semanas haciendo investigación de campo:

• Ir a diferentes tipos de restaurantes (pequeños, grandes cadenas, cocinas oscuras, alto volumen o peores infractores).
• Observando cómo operaban los cajeros.
• Descubriendo sus luchas operativas.
• Hacer preguntas y respuestas informales con los operadores de restaurantes.
• Intentar comprender todo el proceso (desde la aceptación de un pedido hasta el envío al repartidor).
• Evitar hablar con propietarios y administradores (esto fue clave en el proceso de descubrimiento).

Fuente

Información clara: la mayor parte de la magia ocurre “sin conexión”, la aplicación del restaurante solo es necesaria en ciertas partes del proceso.

Inicialmente, cada visita me dio una nueva percepción. Pero después de más de 25 viajes de campo informales (en muchos de ellos también invité a mis desarrolladores), comencé a sentirme confiado en la información que recopilé independientemente del tipo de restaurantes. Éstos son algunos de ellos:

• # 1: Claramente hay tres roles de usuario para cada orden de entrega. Cajeros (aceptan el pedido, lo digitalizan en su sistema interno y / o imprimen el ticket); Envasadores (los que preparan / sellan el pedido con los productos correctos); Despachadores (los responsables de dar el pedido correcto al repartidor correcto).
• # 2: Durante la mayor parte del proceso, nadie está mirando la aplicación. Una vez que el cajero transcribió el pedido en su propio sistema y / o imprimió el ticket de pedido, podría operar ignorando por completo la aplicación.
• # 3: La distribución del restaurante es clave. Cada cocina es diferente, algunas solo tienen una computadora, otras tienen 2 tabletas (en el mostrador y en la zona de despacho), incluso otras tienen varias personas manipulando el mismo dispositivo.
• # 4: Para aplicaciones operativas como esta, los operadores se acostumbran a ellas sin importar cuán confuso sea el producto. Una vez que un operador se acostumbre a una herramienta, repetirá el proceso de una manera realmente eficiente. Cuando preguntamos a 10 cajeros diferentes: “¿cómo funciona el producto actual?”, Pudimos obtener hasta 6 respuestas diferentes. Eso me preocupaba desde el punto de vista del producto, pero aprendí a entender a los operadores.

Mitos de nuestro producto y usuarios

Estos fueron algunos de los “mitos” y creencias que se utilizaron para crear nuestras funciones antes del rediseño:

• Mito # 1 – Debemos priorizar las necesidades de los propietarios: FALSO. El propietario o administrador del restaurante tiene sus propios problemas. Los cajeros y operadores tienen problemas totalmente diferentes en la cocina, debemos optimizar para ellos, no para los propietarios.
• Mito n. ° 2: es importante mostrar toda la información del pedido en todo momento en la aplicación: FALSO. La mayor parte de la magia de la orden ocurre SIN CONEXIÓN. La aplicación se usa principalmente solo para aceptar el pedido. Los cajeros casi no tienen necesidad de volver a ver un pedido una vez que lo aceptan.
• Mito n. ° 3: hay un usuario que usa la aplicación de restaurante: FALSO. Incluso si técnicamente solo puede haber una persona operando (especialmente en pequeños restaurantes), hay tres roles muy diferentes en diferentes etapas de los pedidos: los que aceptan el pedido; los que los empacan y los que se lo envían al repartidor. Incluso en algunos restaurantes (más grandes), físicamente hay tres dispositivos diferentes en el diseño con nuestra aplicación abierta al mismo tiempo (uno para cada función).
• Mito n. ° 4: el restaurante tiene una persona dedicada que opera la aplicación del restaurante: FALSO. El operador que acepta nuestros pedidos es el mismo que está tomando los pedidos in-situ para los clientes de mesa, cobrando a los clientes que quieren pagar, administrando el inventario, resolviendo un caos en la cocina, todo a la vez.

Ahora si, ¿cómo se rediseña un producto?…Proceso para diseñar una nueva solución

Después de comprender cómo funcionan las cocinas, me sentí totalmente seguro de señalar los errores del modelo actual (para nosotros Rappi y para UberEats o iFood):

Fuente

El modelo clásico tenía serios problemas para seguir el flujo natural de la cocina.

En lugar de pensar en optimizaciones incrementales para la aplicación anterior, decidí comenzar desde cero, basándome en los 3 roles de usuario. Intenté diseñar una propuesta que tuviera sentido incluso en un enfoque narrativo:

• El pedido debe ser aceptado.
• El pedido debe estar preparado.
• El pedido debe enviarse al repartidor.

Estas son algunas de mis maquetas originales, las llamamos “modelo Kanban” (como en un kanban tradicional):

Fuente

Fuente

Primeras maquetas del nuevo concepto de 3 columnas.

Volví a los restaurantes para mostrar mis primeras maquetas (y luego los primeros prototipos). Aprendí dos cosas:

• Primera reacción = Resistencia al cambio. Tan pronto como vieron algo nuevo, la mayoría de los cajeros odiaron la idea de un nuevo producto. La retroalimentación generalizada fue algo como “por favor, no cambie la forma en que ya operamos, odiamos cuando tenemos que aprender cosas nuevas o presionar nuevos botones”.
• Segunda reacción = Fácil de explicar a los demás. Luego de la resistencia inicial, una vez que vieron un flujo completo de un pedido, la retroalimentación generalizada fue algo así como “esto tiene sentido absoluto, aquí aceptas los pedidos, aquí los rastreas y aquí encuentras cuándo despachar”.

Fuente

Resultados

Los resultados fueron inmediatos para la reducción de “pedidos cancelados por fallas en restaurantes”, aquí hay una comparación de los primeros 14 días en que la prueba A / B fue 50/50 (modelo antiguo vs kanban). En promedio, mejoramos en un 30% nuestra métrica principal (y ahorramos toneladas de dólares a Rappi y los restaurantes) simplemente cambiando la visualización de las características principales del producto. Este es un número que nos hubiera costado mucho más tiempo y varias optimizaciones si hubiéramos mantenido el modelo tradicional y solo mejoras incrementales.

Fuente

De manera consistente, durante todo el proceso de prueba A / B, la versión Kanban se desempeñó un 30% mejor en la reducción de “pedidos cancelados por fallas del restaurante”.

Para ser justos con el caso, permitimos a los operadores “optar por no participar” de la nueva versión, sabiendo que la mayoría de los operadores tendrían una fuerte “resistencia al cambio” de mentalidad. Pero los resultados fueron tan consistentes que decidimos seguir lanzando la nueva versión.

Además de los buenos números, lo que nos enorgulleció como equipo fue que el nuevo producto era realmente fácil de explicar:

Fuente

Aplicación Rappi Restaurant – Antes vs Después

Seguimos incluyendo algunas features o características menores en las próximas semanas a principios de 2020 (escuchando los comentarios iniciales del cajero o notando cosas que se perdieron de la versión anterior), agregando algunos detalles visuales agradables y actualmente seguimos optimizando el producto, pero el rediseño del modelo Kanban llegó para quedarse, desaprobamos la versión anterior algunas semanas después.

Conclusiones

Comencé el proyecto sabiendo que estábamos siguiendo los estándares de referencia y con una enorme acumulación de aportaciones de los deseos de los propietarios (clientes) e ideas clave de las partes interesadas (necesidades internas); pero la parte clave de este proceso de «¿cómo se rediseña un producto?» para mí fue comprender primero la realidad del usuario final y, solo entonces, comenzar a sugerir mejoras en el producto.

Para cerrar el artículo, estoy resumiendo las principales conclusiones que me dejó este proceso de rediseño de productos.

Principales conclusiones para la pregunta… ¿cómo se rediseña un producto?

1. Diferenciar a su cliente frente a su usuario

• Muchas veces son iguales, pero fue clave en este proceso empezar a escuchar al usuario (CAJEROS), y dejar de escuchar a los clientes (DUEÑOS). A veces pueden tener opiniones opuestas.
• Creemos que al dar un mejor producto al usuario final, el cliente también tendrá un camino más fácil para lograr sus objetivos.

2. No tiene que copiar los estándares de la industria

• Incluso si los jugadores más importantes tienden a resolver el problema de la misma manera, eso no significa que no haya una forma completamente nueva de resolver un problema. El “modelo Kanban” (la propuesta de 3 columnas) ahora nos suena obvio (y para los restaurantes que lo utilizan), pero hubo un proceso completo para llegar allí.

3. Nunca saltes a crear funciones antes de comprender al usuario (además, no hagsa literalmente lo que le piden que haga, ellos no saben cómo crear productos, ese es su trabajo)

• Incluso si suena cliché comenzar a escuchar al usuario, no todos los equipos de productos comienzan con los dolores de cabeza de los usuarios. Muchos equipos que conozco saltan directamente a la parte de ejecución. Una vez que tenga una comprensión clara del usuario y el problema, la creación de funciones es un proceso mucho más fácil y directo de hacer.

4. Tenga una definición clara de las métricas que atacará

• Para una aplicación operativa, las métricas clásicas del producto como Activación, Retención o Compromiso no son tan relevantes. Me ayudó a tener una métrica operativa clara para atacar (“pedidos cancelados por falla del restaurante”).

5. Lleve a los desarrolladores a su proceso de descubrimiento

• Personalmente, me gusta equilibrar mi trabajo (como Product Manager) en un 90% de tiempo de descubrimiento y un 10% de tiempo de ejecución. De la misma manera, me gusta invitar a los Desarrolladores al proceso de Descubrimiento (deben hacer el 90% del tiempo de Ejecución y el 10% del Descubrimiento). Créame, si los desarrolladores también comprenden al usuario y ven el propósito de su solución, se verán más comprometidos para construir el producto final. También son una gran fuente de ideas para posibles soluciones, son los expertos en cosas de construcción.

6. No tenga miedo de los comentarios de “resistencia al cambio”

• Para una aplicación operativa, este no es un punto menor. La gente se acostumbra a repetir procesos, incluso si son confusos. Entonces, por supuesto, los usuarios odiarán el cambio. Pero nuestro trabajo como gerentes de producto es crear una mejor solución, para que no se pierdan las versiones anteriores.

Esta publicación personal se basa en mi experiencia, mi voluntad de compartir los aprendizajes del producto y el punto de vista sobre cómo abordé el problema. Esta no es una publicación oficial de Rappi.

Agradecimientos: A mi increíble equipo de desarrollo creyó en el que asumimos este reto y nos preguntabamos siempre ¿cómo se rediseña un producto? y creo que nos divertimos mucho en el proceso. Mis principales stakeholders internos, a pesar de que mi equipo tenía muchas otras prioridades de la compañía, apoyaron el rediseño tan pronto como vieron cómo estábamos haciendo el proceso de descubrimiento.

¿Cómo puedo empezar a aprender sobre Product Management? ¿cómo se rediseña un producto con las mejores prácticas?

En Kurios hemos co-creado el curso de Digital Product Management con expertos de Amazon, Uber, Dropbox, Microsoft y Oracle, para que puedas acelerar tu carrera construyendo productos que los clientes amen.

‍