¿Dónde está mi usuario?

Hoy en día está de moda la importancia del usuario y del concepto Customer Centric. Empresas como Mercadona popularizaron el lema “el cliente es el jefe” y es algo que queremos llevar a nuestras compañías.

¿Es el usuario la persona más importante a la hora de desarrollar un software? ¿Puede afectar una aplicación a terceros? Si alguien me paga por desarrollar una aplicación… ¿Importa más el que me paga o el usuario de mi aplicación?

En mi experiencia acompañando equipos y enseñando Agile&Scrum siempre hablamos de la entrega continua de valor al usuario final. Cómo decía mi compañera Ana Gómez, el valor es valor cuando se pone delante del usuario, antes es humo.

Perfecto, y aquí viene la pregunta ¿Dónde está realmente mi usuario? ¿Y mi cliente? ¿Pueden ser la misma cosa?. Vamos a analizar algunos escenarios para ver que no siempre es tan evidente.

Si pensamos en ejemplos sencillos como la venta de software en caja como el Microsoft Office o el FIFA18 el usuario está claro, quien nos compra, y además coincide con el cliente que paga por lo que es evidente donde hay que poner el foco. Este caso es sencillo, el usuario paga por el software directo.  

Otro ejemplo bastante sencillo pero con matices pueden ser muchas de las apps actuales como Spotify donde el usuario es quien instala la App. Sin embargo, aquí tenemos dos tipos de usuario: el premium que paga y el freemium que no lo hace pero que es rentable como me decía mi compañero Aday (porque los anuncios hacen que lo sea). ¿Hay que considerarlos de la misma manera? Si tratas bien al freemium podrás convencerlo de que se haga premium pero hay que tratar de retener a los que son abonados actualmente¿Cómo encaja eso en la priorización de nuevas funcionalidades?

Un ejemplo mixto podemos ver en juegos como Clash Royale. Te regalan el software y te cobran por microtransacciones o por ciertas ventajas en el videojuego. De esta manera mi usuario es cualquiera que utiliza la aplicación, pero trato de ver cómo hacer que me pague. Por lo que, a la hora de priorizar, tengo que añadir nuevas opciones para mantener mi masa de usuarios y por otro lado ser atractivo para que compren. ¿Nos centramos demasiado en la venta o tratamos de que la experiencia sea la mejor posible?

El siguiente ejemplo lo leí en el libro “Lead with a story”. En él nos contaban la historia de una persona que acudía a un mostrador de alquiler de coches y tenía que esperar 10 minutos para que le atendieran porque los oficinistas estaban ocupados terminando de completar un alta que no se podía parar. El autor hacía la reflexión de que el software estaba pensando para optimizar el trabajo de los oficinistas pero no tenía en cuenta la satisfacción del verdadero usuario. ¿Quién es aquí mi usuario? Podemos pensar que la persona que opera detrás del mostrador, es quien usa el software, pero cómo se defina ese software afecta a los clientes. ¿Tenemos en cuenta a esos usuarios que no tocan el ordenador? Mi compañero Benjamín Garrido hablaba de usuarios directos e indirectos. Nuestro compañero Aday Guerra los dividía entre primario, secundario y terciario. ¿Invertimos tiempo en estas categorizaciones o nos centramos solo en el usuario directo?

Tuve la oportunidad de acompañar a un equipo que desarrollaba una aplicación para una Universidad privada. En ella nos contaron lo siguiente “para nosotros el cliente es el alumno, y no sus padres que son los que pagan”. Podemos decir que para ellos el usuario sería el alumno y las herramientas que desarrollan están pensadas para él, aunque realmente pague otra persona. En este caso tiene más peso el alumno que no paga que el padre que si lo hace. ¿Hacemos eso en nuestras aplicaciones?

Otro caso a tener en cuenta es cuando hacemos una aplicación con muchos usuarios diferentes. Tuvimos la oportunidad de desarrollar un backoffice para una gran cadena de supermercados y antes de empezar facilitamos un inception. En esta dinámica siempre se pide que vengan muchos usuarios de diferentes tipologías para alinear objetivos. Por ejemplo, podía venir un manager que quisiera un informe de las llamadas del call center mientras que las operarias querían un software que les ayudará a ser eficientes en las respuestas. ¿Quién es más importante? Muchas veces en estas situaciones anteponemos los intereses del usuario que patrocina el software (Sponsor) que al de los demás a pesar de que otros usuarios sean más relevantes porque tienen contacto directo con el cliente final.

Si miramos Paypal veremos un ejemplo curioso. Un comercio podría contratar paypal para implantar un botón de pago en una web. Tenemos por un lado al usuario de PayPal que paga a PayPal por sus servicios, que a su vez tiene sus propios usuarios que pagan al comercio. Ahora imaginad que desarrolláis Paypal, ¿Tendríais en cuenta la experiencia del usuario de vuestro usuario? Al final ambos usan la aplicación por lo que es esencial la experiencia de ambos.

La manera en la que le aportamos valor a un usuario también hay que estudiarlo porque a veces pensamos muy a corto y no en la estrategia. Colaboré con un equipo que desarrollaba para una operadora lowcost de telefonía en la que decidieron añadir una funcionalidad que sería poco usada. Lo sabían, pero lo hicieron porque se alineaba con su imagen de marca y preferían mirar al valor global aportado. ¿Hacemos eso con nuestros usuarios? ¿Solo habría que darles funcionalidad que realmente vayan a usar?

Google o Facebook representan otro escenario distinto. Son aplicaciones donde se busca la retención y la experiencia del usuario que no paga para utilizar sus datos para clientes que si lo hacen ¿Quién es el centro de mi software? ¿El que compra datos o el que los genera? ¿De qué manera afecta a la prioridad de nuestras decisiones?

También podemos ver algo parecido en las transformaciones culturales o Agile. Centramos muchas veces el tiro en los equipos y les enseñamos Scrum pero quizás el usuario que debe cambiar sea la dirección. Pero la dirección es la que nos contrató, es nuestro sponsor. ¿Por qué no tratamos de cambiar al sponsor  directamente? ¿Miedo a su reacción? Si tenemos miedo a la reacción del que paga difícilmente podemos enseñar Scrum que se basa en escuchar a tu usuario constantemente.

Otra de las situaciones más peculiares que he visto es cuando el Product Owner es usuario de la aplicación que construye. Siempre me pareció una gran manera de empatizar con el usuario. Sin embargo, he visto a Product Owners definir su propia aplicación a su gusto sin pensar en el resto de usuarios. Esto puede dar como resultado aplicaciones desastrosas. ¿Cómo hacemos para evitar un PO actúe pensando en sí mismo?

Por último… ¿Debemos de dar diferente servicio en función del usuario? Estuve trabajando para una aseguradora donde nos contaban que para usuarios jóvenes interesaba poner pocas cláusulas para definir una póliza, sin embargo, para personas de más edad había que poner mucha letra porque estaba demostrado que se lo leían. ¿Tenemos bien definidos nuestra tipología de usuario?

Como conclusión quiero que penséis que Agile habla de entregar valor. A veces ponemos mucho foco en hacer software y poco en cuestiones cómo ¿Para quién? O ¿A quién beneficia esto? O ¿Realmente se quién es mi usuario? ¿Puede afectar mi software a otras personas que no tocan un dispositivo digital? Hablaremos más adelante de técnicas de definición de usuarios pero los productos digitales que triunfan saben conocer a quién está al otro lado.

PD: quiero mandar un agradecimiento a las personas que participaron en la mesa redonda del Agility360 que tuvimos la suerte de pasar una hora muy agradable compartiendo y me ayudaron a terminar este artículo.