Feedback vs. features: la eterna batalla desarrollando una app

[08/53] Este post trata de una lucha en la que me vi envuelto el año pasado y no supe ganar, por mucho que capeara los temporales y aparentemente todo fuera saliendo adelante. Además, aunque creo que es algo que compartirán la mayoría de responsables de producto o personas encargadas del desarrollo del mismo, no tiene una solución para todos, sino que es algo muy diferente según cada aplicación, su público y las posibilidades reales de cada startup.

Pongámonos en la situación que sois un equipo reducido por motivos obvios y tenéis una primera versión de vuestro producto o aplicación. Es funcional en lo básico pero muy mejorable en casi todos los aspectos. Tienes unas decenas de early adopters que ya te están dando feedback de lo que les gustaría poder hacer y de momento no pueden. Cada persona es un mundo, con lo que eso conllevará en el futuro. ¿Cuáles son los tres muros que seguro que te vas a encontrar?

1. La plataforma en sí. Nuestra primera versión de la app fue en Android. La decisión fue clara ya que era lo que más conocíamos, la que más posibilidades técnicas nos daba y la que mayor cuota de mercado con mucha diferencia tiene en España. Sinceramente, envidio a las startups que pueden empezar en iOS porque su mercado está ahí, y es que todo es mucho más cuadriculado a la hora de desarrollar y sobre todo hacer pruebas. Con Android nos encontramos infinitos problemas en teléfonos de gama media/baja, errores incomprensibles, feedback irreproducible y echando muchas más horas de las deseables caminando hacia atrás que hacia delante. Es lo que tiene innovar, sí, pero es un precio grande cuando sólo dispones de un (excelente) desarrollador.

2. La featuritis. Llega un momento en que esa aplicación básica puede ir creciendo y puedes ir haciendo caso a esas peticiones de tus primeros usuarios así como a todos esos esquemas y dibujos que has ido haciendo en cuadernos, pizarras o sueños. ¿Qué añadir? ¿Qué no añadir? Ante todo no pierdas el norte. Lo mejor es que tu producto haga excelentemente una cosa, su objetivo principal, lo que vendes como visión de la empresa. Mantenlo simple y sé fiel a ello. Di ‘No’ todas las veces que sea necesario. Yo aprendí a decirlo el año pasado, pero no lo suficiente. Reconozco que fuimos convirtiendo nuestra app en un pequeño monstruo lleno de posibilidades geniales, pero sin asegurarnos que lo básico estaba bien pulido. Cuida al máximo tu funcionalidad principal, mide, testea, y vuelve a empezar. Y, después, ve añadiendo lo que sea estrictamente necesario.

3. Las expectativas alrededor de tu trabajo. Los desarrolladores necesitarán tiempo para asegurarse que esa nueva funcionalidad está correctamente programada y hace lo que se espera que haga. Desde comunicación querrán tener hasta el último detalle de todo lo que está pasando (sea bueno o malo) con la aplicación para responder a la comunidad. Desde marketing necesitarán fechas para planificar una acción especial o enviar una serie de correos a personas específicas. Desde encima tuyo querrán ver cómo lo que estás haciendo os acerca un poco más a los objetivos globales de la empresa que, con casi toda seguridad, son facturar. Y los usuarios querrán el producto funcionando al 200% en cada momento y sintiendo que la comunidad es escuchada. ¿Cómo manejar todo esto? Principalmente haciendo partícipes a todos de la realidad, con mucha comunicación y sinceridad (igual que a la hora de manejar a tu propio equipo). Y, sobre todo, teniendo claras tus prioridades y un calendario de ejecución racional y viable.

No hay una solución mágica a todos los problemas que van a ir surgiendo más allá del trabajo diario. Pero si puedes ir sobre aviso de que ciertas cosas van a pasarte sí o sí, es mejor tener ya un plan trazado para que no te pillen con el pie cambiado.

Sobre cómo priorizar un montón de features y feedback recibido, escribí hace meses un post en el blog de GPMESS que reproduzco a continuación. Como lectura teórica me sigue pareciendo 100% válida, pero a la hora de llevarla día a día de tu empresa es donde está el reto y donde hay que ser estricto con uno mismo.

Esta semana vamos a salirnos un poco del plano detallado del desarrollo de GPMESS y nos vamos a ir a uno algo más abstracto: el de la toma de decisiones a la hora de elegir qué y cómo va a ser lo siguiente que se va a implementar tanto en la aplicación, como en el backend. Y es que en una startup es muy necesario saber qué pasos se van a dar, ya que al caminar durante mucho tiempo en una especie de cuerda floja, cualquier fallo puede aparejar un gran problema.

En el libro Designing for emotion de Aarron Walter encontré una traslación de la famosa Pirámide de Maslow –que trata sobre la jerarquía de las necesidades humanas– a las necesidades de los usuarios, y creo que es una manera perfecta de mostrar la base en la que se tienen que sostener todas las decisiones: primero tenemos que tener un producto funcional, segundo hay que garantizar que sea fiable, después hay que cuidar que sea utilizable, y finalmente que sea agradable y deleite al usuario.

El orden es este y tiene su lógica: por muy bonito que sea tu producto, por muy cuidada que esté la experiencia de usuario, si no ofrece una funcionalidad que la gente necesite, o si se estropea o se bloquea cada dos por tres, estás muerto. Y es por esto por lo que el trabajo de estrategia y priorización se tiene que imponer a las ganas de ejecutar, de picar código y de ver todas esas brillantes ideas que creemos tener en nuestra mano.

Las estrategias con bastante claras, tanto para nosotros como para la gran mayoría destartups tecnológicas: captación y retención de usuarios, generar ruido e imagen de marca y demostrar la viabilidad del plan de negocio. Con un millón de ramificaciones dentro de cada una, pero son una base común. Hay que tenerlas siempre en mente y focalizar el trabajo en ellas, y cualquier cosa que se salga de ahí probablemente nos esté despistando del objetivo final.

A la hora de priorizar, aquí tampoco estamos reinventando la rueda. De hecho, recomiendo encarecidamente a cualquiera que tenga interés el pasarse por Quora y leer las respuestas a What are the best ways to prioritize a list of product features? donde hay un montón de información útil sobre el tema. Personalmente estoy de acuerdo con la priorización en base a cuatro elementos: funcionalidades que consiguen las métricas, las que son peticiones de los usuarios, las que deleitan al usuario y las que son estratégicas.

Una vez que tenemos una serie de funcionalidades en mente que se alinean con nuestra estrategia y que pueden ser integradas en una de las cuatro categorías, hay que intentar balancear el listado para ordenarlo. Y ojo, aquí es igual de importante valorar previamente el coste en trabajo de cada funcionalidad tanto en backend como en frontend, así como la contribución a los objetivos globales de la empresa a corto, medio y largo plazo. No hay una fórmula matemática mágica que nos indique el camino a seguir, pero sí que cuanta más información podamos tener de cada paso que queremos dar, nos ayudará a que estos vayan en el camino correcto.

La conclusión final es que antes de lanzarte a añadir una nueva funcionalidad, “porque lleva poco tiempo implementarla” o “que podemos hacer opcional” o “porque la cuñada de mi hermano dijo que…” plantéate si vale para cumplir con las estrategias de la empresa a corto y largo plazo, si es prioritaria entre las tareas que hay entre manos (¿es para el deleite pero la aplicación no es fiable?) y si es ejecutable por los equipos de desarrollo en un plazo razonable. Y una vez que traces el camino a seguir, no des demasiados bandazos o perderás demasiado tiempo por el camino.