por Michael Goitein* – Product Coalition
Cómo un pequeño cambio de mentalidad puede transformar el desarrollo de su producto.
«Sé que es lo que pedí, pero lo odio».
Fue como un puñetazo en las tripas para mí y para todo nuestro equipo.
Acabábamos de terminar nuestra demostración final después de pasar las últimas 18 semanas creando un mercado complejo, móvil y de múltiples caras para una marca de renombre nacional. Esta marca había estado apoyando a un canal desatendido con un enorme Mercado Total Abordable («TAM»).
Cuando empezamos con el producto, nos sorprendió que una marca de su tamaño gestionara todo este grupo de usuarios mediante una combinación de sistemas heredados y formularios en papel. El cliente sabía que necesitaba nuestra ayuda.
Tuve la suerte de dirigir un equipo sólido con líderes experimentados en arquitectura técnica, ingeniería móvil y experiencia de usuario («UX»).
Tras la puesta en marcha inicial, nos dijeron que toda la comunicación pasaría por nuestro único punto de contacto, el responsable del canal. Nuestro interlocutor nos aseguró que sabía exactamente lo que cada uno de los diferentes usuarios necesitaría de la aplicación móvil.
Puesta en marcha
Trabajamos a partir de la exitosa presentación de ventas en PowerPoint que establecía la funcionalidad básica y los conceptos iniciales de pantalla móvil.
Como la mayoría de las consultorías, empezamos a trabajar en una serie de entregas.
Una vez que nuestra parte interesada dio el visto bueno a nuestra arquitectura técnica, pasamos por una serie de aprobaciones y traspasos antes de que nuestro jefe técnico empezara a reunir a los ingenieros para iniciar el desarrollo.
Las aprobaciones solo llegaron tras varias horas de presentaciones y discusiones y muchas rondas de revisión. En cada fase, pedimos con educación, pero con firmeza a los stakeholders que dieran su visto bueno.
Sobrepasar los límites
Debido a nuestra trayectoria en el sector móvil para marcas internacionales, nuestra parte interesada presionó a nuestro equipo de UX para que diseñara interfaces «más chulas».
Los diseños aprobados resultaron ser mucho más difíciles de codificar para nuestros ingenieros de móviles de lo que habíamos calculado. El equipo hizo un esfuerzo extra para codificar todo según los «requisitos» deseados.
Y nuestros controles semanales con los clientes garantizaron que no hubiera sorpresas.
Nuestro equipo también se convirtió en experto en cada uno de los flujos del recorrido del usuario de los múltiples personajes a medida que realizaban sus tareas en la aplicación.
Preparar el lanzamiento
Tras cuatro meses de trasnochar, el cliente se descargó una aplicación móvil bonita y totalmente funcional, impulsada por una plataforma de servicios móviles.
Y entonces llegaron las malas noticias. Nuestro stakeholder la odiaba.
A pesar de las frecuentes revisiones y de incorporar múltiples rondas de comentarios, nuestro interesado estaba enfadado con nosotros y consigo mismo.
Y eso no era culpa del cliente, sino nuestra.
Sin garantías
Si hubiera sabido entonces lo que sé ahora, nos habríamos enfrentado a las señales de alarma desde el principio.
Probablemente, la mayor señal de alarma fue que toda la comunicación pasaba por la única parte interesada. Tenían todo el poder y el control, y nadie con quien intercambiar ideas o comprobar su forma de pensar. Todo el destino del producto estaba en sus manos.
En segundo lugar, nos tomábamos al pie de la letra todo lo que nos decían y nunca comprobábamos las hipótesis ni recopilábamos datos cualitativos y cuantitativos significativos.
La segunda vida
Afortunadamente, a pesar de las preocupaciones iniciales de los stakeholders, la empresa comercializó la aplicación mediante llamativos comunicados de prensa y redes sociales antes de lanzarla a las tiendas de aplicaciones.
En cuanto los usuarios reales empezaron a utilizarla, surgieron pequeños problemas. Imagínense.
Pero después de recibir algunos comentarios positivos de los usuarios finales y de realizar algunas rondas de correcciones y cambios, la aplicación ganó algo de tracción e incluso le valió un ascenso a nuestro interesado.
¿Te sientes afortunado?
Mi experiencia no fue única, aunque sí extrema.
Lo cierto es que todo lo que planeamos es una suposición, una apuesta, basada en suposiciones sobre lo que esperamos que funcione.
No importa si diseñas la aplicación más bonita, si la codificas con el framework móvil más moderno o si utilizas los últimos pipelines DevOps para mover ese código.
La única prueba es cuando «la goma se encuentra con la carretera», es decir, lo que ocurre cuando tu aplicación entra en contacto con usuarios reales.
Hasta que eso ocurra, no tendremos ni idea de cuáles de nuestras muchas suposiciones son ciertas y cuáles son sencillamente erróneas.
Admitir que no sabemos
¿Un buen primer paso? Empezar con un poco de humildad sobre nuestra capacidad para adivinar lo que quieren nuestros usuarios.
Lo hacemos fatal.
En cambio, sí tenemos la capacidad de colaborar con los stakeholders y co-crear mejores productos con los usuarios adecuados.
No todos los usuarios son igual de importantes para tu producto
Dada la agresividad de los plazos, crear un producto que satisficiera las necesidades de todos los usuarios posibles era una mala idea.
Como todo en la vida, todo se reduce al 80/20. Como confirman los datos de seguimiento de aplicaciones, sólo el 20% de los usuarios aporta el 80% del tráfico y los ingresos de cualquier aplicación.
Centrarnos en estos «super» usuarios y atender sus necesidades habría facilitado enormemente el proceso de diseño y desarrollo del producto y habría creado una aplicación mejor.
Una estrategia diferente
El resultado final podría no haber sido exactamente la imagen que nuestra parte interesada tenía en la cabeza.
Pero nos habría permitido crear la aplicación adecuada para los usuarios más importantes, pasar de los formularios en papel a una aplicación móvil que se anticipase a sus necesidades y les facilitase la vida.
La única forma de conseguirlo habría sido utilizar una estrategia muy distinta a la de construir servilmente lo que nos dijera la parte interesada.
Hablar con la gente
Mientras intentábamos satisfacer las expectativas de nuestros interlocutores, teníamos otras dos opciones:
- Identificar al «superusuario» y hablar con algunos usuarios finales reales.
- Si por alguna razón no hubiéramos podido hablar con los usuarios finales, lo mejor habría sido hablar con el equipo de atención al cliente, las personas que se pasan el día escuchando los problemas de los usuarios. En mi experiencia, me he dado cuenta de que son excelentes a la hora de identificar clases de problemas («problemas con el inicio de sesión»), así como a la hora de establecer prioridades («este es uno de los cinco principales problemas de los usuarios»).
Contar con los stakeholders en estas discusiones, junto con los departamentos técnicos y de UX, habría permitido a todos pasar de «crear una aplicación» a resolver los problemas reales de las personas a través de la aplicación.
Descubrimiento
Entonces, ¿cómo podemos nosotros y nuestros stakeholders cambiar nuestra forma de pensar para comprender mejor el problema que realmente estamos tratando de resolver?
Una oportunidad podría haber sido animar a nuestros stakeholders a moderar su microgestión en el espacio de la «solución» (la aplicación tiene este aspecto, estos 12 botones, y hace exactamente estas 15 cosas), y cambiar al espacio del «problema» haciendo este tipo de preguntas:
«Cuando tengas la aplicación móvil, ¿qué pasará?
«¿Qué haría diferente la persona A?
«¿Y cómo les ayudaría tu empresa a realizar esas tareas si necesitaran ayuda?».
Nuestro objetivo es tomar esa información y utilizar la experiencia combinada de nuestro equipo en Producto, UX y Tecnología para innovar y crear mejores productos.
El mayor riesgo es construir exactamente lo que nos dicen que construyamos cuando se conoce la menor información.
Porque los clientes no saben lo que quieren.
E incluso cuando afirman que lo saben, no tienen ni idea de lo que el equipo adecuado puede hacer con las tecnologías adecuadas para resolver el problema.
Esta noche en el menú, tenemos…
Una excelente forma de pensar sobre el equilibrio entre servir y dirigir es la analogía de Jeff Patton entre «camarero» y «médico».
Los camareros reciben instrucciones y actúan.
Se centran en ofrecerte lo que has pedido, rápida y cortésmente.
Aunque es adecuada para algunas empresas de servicios, es una mentalidad que impide pensar en el «producto» y nuestra capacidad para innovar y ofrecer valor por encima de lo que se nos pide.
Estamos tan centrados en «servir» a quien creemos que es nuestro «cliente» que nos olvidamos de las necesidades de nuestro cliente real.
[El éxito llega] «cuando los equipos de producto no confunden a su director general o a los stakeholders de la empresa con clientes». Y lo mismo ocurre cuando los stakeholders de la empresa no se confunden a sí mismas con clientes».
Jeff Patton
¿Hay un médico en casa?
Los médicos, en cambio, son profesionales experimentados que escuchan y dedican mucho tiempo a escuchar y diagnosticar problemas con precisión.
Luego deciden cómo utilizar sus conocimientos para resolverlos de la mejor manera que consideran adecuada, dada la situación única.
La atención se centra en el logro: Crear resultados saludables para sus pacientes.
La mayoría de los negocios de consultoría se basan en la idea de intentar ser el mejor «camarero» posible.
Hay unas pocas consultorías de primera categoría y respetadas que cobran mucho dinero y pueden tomar un problema y resolverlo de forma integral.
Pero la realidad es que nunca se trata de recibir órdenes y ejecutarlas, ni de hacer diagnósticos brillantes.
Es un abanico
Es fundamental comprender que el cambio de mentalidad de camarero a médico no es un interruptor binario de encendido/apagado, sino que se trata más bien de distintos grados en una escala:
Dependiendo del cliente, la dinámica o el compromiso, podemos caer en un patrón que no es adecuado para la situación.
La clave está en hacer dos cambios:
- Cómo enmarcamos nuestro problema
- Cómo definimos el éxito
Veamos el papel que desempeña cada cambio.
Identificar el problema
Los camareros o los médicos tienen formas muy distintas de definir el problema que hay que resolver.
- Los «camareros» definen el problema como «Mi parte interesada quiere que construya una nueva función como la del competidor X. Hacer lo que mi parte interesada me dice que haga es mi misión».
- Los «doctores» definen el problema como: «Después de hablar con algunas personas y revisar los datos, muchos quieren seguir adelante y construir X. Pero me parece que el verdadero problema es que demasiadas ventas son ventas puntuales. La mercancía se agota con frecuencia y el envío tarda demasiado, así que cuando los clientes por fin reciben su mercancía, no quieren volver a comprar.»
Mientras que el «camarero» toma al pie de la letra las órdenes de las partes interesadas y se lanza a «ejecutar» una solución a medias, el «médico» trabaja para comprender mejor y exponer con mayor claridad el problema centrado en el cliente que constituye la base para lograr resultados significativos para el cliente y la empresa.
Definir el éxito
Este cambio mental nos permite cambiar nuestra definición de éxito:
- La definición de éxito de un camarero sería: Entregar una aplicación, a tiempo y dentro del presupuesto. (También conocido como «resultado»).
- La definición de éxito de un médico sería: Acelerar el envío de 2 semanas a 3 días. Permitir que nuestro grupo de clientes objetivo publique un 20% más de productos en el sistema y elimine la fricción de interactuar con más compradores potenciales, vendiendo así un 20% más de negocio repetido y aumentando sus propios ingresos (y los nuestros) en un 10%. (Esto representaría «resultados» tanto para el usuario como para la empresa).
Desde la perspectiva del médico, estamos respondiendo a la pregunta:
«¿Cómo podemos cambiar el comportamiento de esta persona usuaria de forma medible que les ayude a conseguir el éxito para ellos mismos, así como para nuestro negocio?».
Trabajando hacia atrás desde nuestro problema y teniendo una nueva definición de éxito, empezamos a pasar por el Descubrimiento Continuo, cuyo núcleo es la entrevista con el cliente.
Un nuevo nivel de colaboración
Cuando pasamos al modo de médico profesional de confianza, una vez que hemos redefinido el problema y lo que significa el éxito, podemos compartir esa información con los stakeholders.
Podemos invitarles a colaborar con nosotros para descubrir mejores soluciones, hablando con los usuarios finales y participando en el descubrimiento continuo.
Solo cuando cambiemos la dinámica subyacente al desarrollo de nuestros productos podremos abrir la puerta a la creación colaborativa de productos realmente excelentes.
Resumen y conclusiones
En nuestro trabajo, siempre hay stakeholders y un usuario final.
No cometas el error de confundirlos o acabarás con tu capacidad de aportar valor a las personas que más lo necesitan.
Recuerda que siempre tenemos la opción de quedarnos con la cabeza gacha y limitarnos a «ejecutar» lo que se nos dice que hagamos, o dar un paso atrás y trabajar para alcanzar un mayor nivel de logro comprendiendo mejor el problema.
Tomar conciencia de la dinámica entre «camarero» y «médico» puede ayudarnos a elegir intencionadamente qué papel queremos desempeñar y qué es lo mejor para cada situación.
Las dos claves residen en el cambio:
- Cómo enmarcamos nuestro problema
- Cómo definimos el éxito
Una vez hecho esto, hablar con clientes finales reales y participar en el Descubrimiento Continuo son las claves para construir mejores productos que consigan resultados para el cliente y la empresa.