Cómo encontrar y validar tu próxima idea de app

La parte más difícil de hacer una app no es el código ni la infraestructura, ni siquiera el marketing. Es conseguir hacer una app que la gente realmente quiera o necesite. Que algo pueda ser útil para ti no significa necesariamente que vaya a serlo para el mercado.

Mientras esperamos a que la burocracia de Google termine de sacar Kleos Music a producción, nos hemos estado preguntando: ¿cuál debería ser nuestra próxima app? Puede parecer una pregunta bastante sencilla, pero esconde una complejidad que solo tú y yo, compañeros desarrolladores, entendemos. ¿Será realmente útil? ¿La querrá la gente? ¿El problema es lo suficientemente importante? ¿Vamos a pasarnos meses construyendo algo que acabarán usando cinco personas?

Así que decidí compartir el "framework" de kleosvic para plantearse una idea. No es nada revolucionario, ni mucho menos una fórmula garantizada para crear una app exitosa, pero sirve para pensar en una idea antes de abrir el IDE y pasarte los siguientes tres meses construyéndola.

Algunas cosas que deberíamos aclarar antes de empezar

Haz apps alrededor de una idea que ya existe

No todas las ideas tienen que ser únicas. Puedes ser único en la forma en la que conviertes esa idea en una app. Como estamos acostumbrados a escuchar, Amazon no fue la primera librería, Facebook no fue la primera red social y Google no fue el primer buscador. Ser el primero no hace automáticamente que tu producto sea el que la gente vaya a elegir.

Ya existen miles de apps que solucionan miles de problemas, y eso en realidad es algo bueno. Si la gente ya está utilizando algo para solucionar un problema, al menos tienes cierta evidencia de que ese problema existe. En lugar de intentar inventar siempre una categoría completamente nueva, mira lo que ya existe y pregúntate qué podría hacerse mejor.

Quizás las soluciones existentes sean demasiado complicadas, demasiado caras, demasiado lentas, estén mal diseñadas o simplemente no funcionen bien para un determinado tipo de usuario. No necesitas inventar algo que nadie haya visto antes. A veces simplemente necesitas coger una idea que ya existe y ejecutarla de una forma que tenga más sentido para las personas a las que quieres ayudar.

Huye de las ideas demasiado grandes

No estoy diciendo que tengas que dejar de ser ambicioso. Digo que deberías encontrar un problema pequeño que solucionar y construir alrededor de él, en lugar de intentar crear directamente el próximo SaaS gigantesco, la próxima red social o la próxima empresa de IA.

Empezar pequeño hace que todo sea más fácil. Un problema pequeño es más fácil de entender, más fácil de validar y mucho más fácil de construir. Puedes poner algo delante de la gente, ver qué piensa, cambiarlo y repetir el proceso sin tener que pasar seis meses construyendo algo que nadie te ha pedido.

Y si a la gente realmente le importa, siempre puedes hacerlo más grande después. No necesitas saber cómo será la empresa dentro de cinco años antes de escribir la primera línea de código. De hecho, intentar decidirlo de antemano probablemente hará que construyas cosas que luego ni siquiera necesitas.

Toca césped

En serio. Muchas ideas no aparecen cuando estás sentado delante del ordenador intentando pensar en ideas. Aparecen cuando realmente estás viviendo tu vida. Ve a la universidad, al trabajo, viaja, juega, habla con gente, utiliza las apps de otras personas y presta atención cuando alguien se queje de algo.

Los desarrolladores tendemos a fijarnos en problemas de desarrolladores porque son los problemas que nosotros mismos experimentamos. Eso es útil, pero también puede hacer que pensemos que todo el mundo tiene los mismos problemas que nosotros. Y no es así. A veces la mejor idea es algo completamente ajeno a la tecnología que descubres porque estabas allí cuando alguien tuvo problemas con algo.

No necesitas sentarte una tarde entera a hacer brainstorming de ideas para startups. Simplemente vive con normalidad y presta atención a las cosas que parecen innecesariamente complicadas. Puede que encuentres algo mucho más interesante de esa manera.

El framework

El framework se puede resumir en cuatro fases: Pain → Solution → Filter → MVP. La idea es pasar por ellas en orden, pero no tratarlas como una metodología estricta. Son simplemente cuatro preguntas que te ayudan a decidir si una idea merece tu tiempo.

Pain

Deberías empezar con un problema, no con una app. Presta atención a las cosas que molestan, a las que tardan más de lo que deberían, a las tareas que la gente tiene que hacer manualmente o a esas situaciones en las que piensas que tiene que haber una forma mejor de hacer algo.

No tiene por qué ser un problema enorme. De hecho, un problema pequeño puede ser un punto de partida mucho mejor, especialmente si puedes entenderlo claramente. Lo importante es que el problema exista realmente y que sea lo suficientemente relevante como para que alguien quiera solucionarlo.

Es muy fácil crear una solución y después intentar convencerte de que tiene que existir algún problema que justifique esa solución. Puede que una idea te parezca muy buena, pero eso no significa que nadie la necesite. Una de las señales más interesantes es cuando la gente ya está intentando solucionar el problema por su cuenta.

Puede que utilicen una hoja de cálculo, un montón de notas, un grupo de WhatsApp, varias aplicaciones distintas o algún proceso manual completamente absurdo. No importa que su solución actual te parezca extraña; lo importante es que están invirtiendo tiempo y esfuerzo en hacer que el problema sea manejable. Ya han decidido que el problema merece ser solucionado, simplemente todavía no tienen una buena solución.

También deberías fijarte en la frecuencia con la que aparece el problema. Algo que molesta a alguien una vez cada dos años probablemente no sea una razón demasiado buena para crear una app entera alrededor de ello. Algo que ocurre todos los días, en cambio, da a la gente una razón mucho más natural para seguir utilizando tu producto.

Y si tú mismo experimentas el problema, mejor todavía. Ya entiendes qué es lo que lo hace molesto y no tienes que empezar intentando adivinar qué quiere el usuario. Eso no significa que debas asumir que todo el mundo tiene el mismo problema, pero al menos tienes un punto de partida.

Solution

Una vez tienes un problema, puedes empezar a pensar en cómo solucionarlo. Aquí es donde creo que los desarrolladores solemos hacer las cosas al revés: empezamos con una idea para una app y después intentamos encontrar una razón para que esa app exista. Es mucho más fácil hacerlo al contrario. Empieza por el problema y pregúntate qué podría hacerlo más fácil.

La primera solución no tiene que ser complicada. No necesita un asistente de IA, diez integraciones, una red social, un sistema de recomendaciones y un dashboard precioso. Solo necesita solucionar el problema. Si puedes eliminar el problema con algo increíblemente sencillo, normalmente es mucho más interesante que necesitar construir un sistema enorme para que la idea funcione.

También deberías mirar cómo está solucionando la gente el problema actualmente. Si ya existen apps que hacen algo parecido, úsalas. Mira qué hacen bien y, sobre todo, de qué se quejan sus usuarios. Lee sus reseñas, habla con usuarios si puedes y presta atención a esas pequeñas cosas que hacen que la experiencia sea frustrante.

Que existan soluciones no es necesariamente una razón para abandonar una idea. De hecho, pueden ser una de las cosas más útiles que tienes al empezar. Si la gente ya está pagando por una solución pero se queja constantemente de ella, has aprendido dos cosas importantes: existe un problema y hay gente dispuesta a pagar por solucionarlo.

Puede que el mercado no necesite otra app. Puede que necesite una versión mejor de una que ya existe. Y eso está perfectamente bien. No necesitas crear una categoría completamente nueva para crear algo que la gente quiera.

Filter

En este punto tienes un problema y una posible solución, pero eso todavía no significa que debas construirla. Aquí es donde tienes que ser un poco crítico con tu propia idea, porque es muy fácil encariñarte con algo en lo que has estado pensando durante mucho tiempo.

Primero, pregúntate si el problema realmente importa. Hay una diferencia entre algo que estaría bien tener y algo que la gente realmente quiere solucionar. Después fíjate en la frecuencia con la que ocurre. Si el problema aparece todos los días, existe una razón natural para que alguien siga utilizando tu producto. Si ocurre una vez al año, será mucho más difícil justificar una app entera alrededor de él.

También deberías preguntarte si la gente ya está haciendo algo para solucionarlo. Si no están haciendo absolutamente nada, eso no tiene por qué ser malo, pero debería hacerte preguntarte por qué. Puede que hayas encontrado un problema que nadie había detectado todavía, o puede que a nadie le importe lo suficiente como para hacer nada al respecto.

Otro filtro interesante puede venir de algo que comentamos en nuestro último post sobre el Google Play Closed Testing. Si estás desarrollando una app para Android, la fase de closed testing puede darte información bastante útil sobre si a la gente realmente le importa lo que has construido. Si tus testers abandonan repetidamente antes de que puedas terminar el proceso, o dejan de utilizar la app poco después de que les digas que ya has cumplido los requisitos de testing, puede ser una señal a la que merece la pena prestar atención.

Por supuesto, no deberías tratarlo como una prueba absoluta de que la idea es mala. Los testers pueden tener sus propios motivos para irse y un grupo pequeño de testers no tiene por qué representar a tu público objetivo. Pero si tienes que convencer constantemente a la gente para que siga probando la app y, en cuanto saben que ya ha pasado el proceso, dejan de tener motivos para volver, al menos deberías preguntarte si realmente estás solucionando un problema que les importa.

La misma idea se puede aplicar fuera del closed testing. Si alguien prueba tu producto una vez porque se lo has pedido y después nunca vuelve a abrirlo, eso es información. Si sigue volviendo sin que tengas que recordárselo, también es información. El engagement por sí solo no demuestra que tengas un gran producto, pero su ausencia puede ser una señal útil cuando la combinas con todo lo demás que estás observando.

También tienes que considerar si puedes construir la solución de forma realista. Una idea puede ser fantástica en teoría, pero depender de datos a los que no tienes acceso, de una infraestructura que no puedes pagar o de una tecnología que simplemente no está disponible para ti. Eso no significa necesariamente que debas abandonar la idea; a veces simplemente tienes que reducir el alcance.

Lo importante es no confundir el tamaño de la idea con la cantidad que necesitas construir inicialmente. No necesitas construirlo todo para descubrir si algo es útil. Solo necesitas construir lo suficiente para probar la hipótesis que estás planteando.

MVP

Aquí es donde finalmente puedes empezar a programar. El MVP debería ser la versión más pequeña de tu idea que te permita comprobar si tu solución realmente funciona. Creo que aquí es donde el término MVP se malinterpreta bastante: no significa necesariamente construir una versión horrible del producto final.

Significa construir únicamente lo necesario para responder a la pregunta que tienes ahora mismo. Si estás haciendo una app de productividad, quizá no necesites una app móvil, una aplicación de escritorio, una extensión para el navegador y un asistente de IA. Quizá solo necesites la funcionalidad principal que resuelve el problema.

Lo mismo se aplica prácticamente a cualquier otra cosa. Si estás haciendo una red social, probablemente no necesitas todas las funcionalidades sociales que se te ocurran. Si estás construyendo un marketplace, tampoco necesitas todos los métodos de pago, tipos de cuenta y sistemas de recomendación desde el primer día.

Cuanto menos construyas, antes podrás ponerlo delante de alguien. Y eso es importante porque realmente no sabes si tus suposiciones son correctas hasta que alguien utiliza el producto. Puedes pasarte semanas discutiendo cómo debería funcionar algo, pero un usuario real puede enseñarte más en cinco minutos.

Luego escucha

Una vez tengas el MVP, dáselo a la gente. Probablemente sea la parte más importante de todo el proceso porque ahora ya no estás haciendo suposiciones. Tienes algo real con lo que la gente puede interactuar, y eso te proporciona información que simplemente no puedes obtener pensando en la idea por tu cuenta.

Fíjate en lo que la gente realmente hace con la app, no solo en lo que te dicen sobre ella. Que alguien te diga que tu idea está muy bien es agradable, pero no te dice demasiado. Que alguien la utilice todos los días te dice bastante más. Lo mismo ocurre con las críticas: si alguien te dice que algo es confuso o que echa de menos una funcionalidad, no lo descartes inmediatamente solo porque no formaba parte de tu plan original.

A veces descubrirás que la gente utiliza tu app de una forma completamente diferente a la que esperabas. Puede que ignoren la funcionalidad que tú considerabas más importante y pasen todo el tiempo utilizando otra. Puede que pidan algo que nunca habías considerado. No son necesariamente problemas; son piezas de información que pueden ayudarte a entender en qué debería convertirse realmente tu producto.

El objetivo no es demostrar que tu idea original era correcta. El objetivo es descubrir qué es realmente útil. Tu idea original es simplemente una hipótesis y el producto es la forma de comprobarla.

Build, learn, repeat

Y ese es básicamente todo el framework: Pain → Solution → Filter → MVP. Encuentra algo que realmente sea molesto, piensa en una forma de solucionarlo, asegúrate de que el problema merece la pena y de que la solución es realista, y después construye la versión más pequeña que puedas.

A partir de ahí, aprendes de lo que ocurre y vas iterando. Puede que la idea funcione y puedas seguir ampliándola. Puede que el problema sea real pero que tu solución no sea suficientemente buena. Puede que descubras un problema completamente diferente mientras la construyes. O puede que a nadie le importe.

Y tampoco pasa nada. Descubrirlo después de dos semanas es mucho mejor que descubrirlo después de seis meses. El objetivo del MVP no es demostrar que tu idea se va a convertir en una gran empresa, sino descubrir si realmente hay algo que merece la pena seguir construyendo.

Lo importante es no enamorarte de la idea en sí. No estás intentando demostrar que eres muy listo por haberla pensado. Estás intentando construir algo que sea útil para alguien, y a veces eso significa cambiar la idea con la que empezaste.

Probablemente haya miles de problemas a tu alrededor que podrían convertirse en apps. Solo tienes que darte cuenta de ellos. Así que antes de abrir tu IDE y empezar a construir la próxima gran cosa, sal un rato, habla con gente, utiliza cosas, enfádate con cosas y, sobre todo, vive tu vida.

Puede que vuelvas con una idea mejor.