Com trobar i validar la teva pròxima idea d'app

La part més difícil de fer una app no és el codi ni la infraestructura, ni tan sols el màrqueting. És aconseguir fer una app que la gent realment vulgui o necessiti. Que una cosa pugui ser útil per a tu no vol dir necessàriament que ho sigui per al mercat.

Mentre esperem que la burocràcia de Google acabi de treure Kleos Music a producció, ens hem estat preguntant: quina hauria de ser la nostra pròxima app? Pot semblar una pregunta bastant senzilla, però amaga una complexitat que només tu i jo, companys desenvolupadors, entenem. Serà realment útil? La voldrà la gent? El problema és prou important? Ens passarem mesos construint una cosa que acabaran utilitzant cinc persones?

Per això he decidit compartir el "framework" de kleosvic per plantejar-se una idea. No és res revolucionari, ni molt menys una fórmula garantida per crear una app d'èxit, però serveix per pensar en una idea abans d'obrir l'IDE i passar-te els tres mesos següents construint-la.

Algunes coses que hauríem d'aclarir abans de començar

Fes apps al voltant d'una idea que ja existeix

No totes les idees han de ser úniques. Pots ser únic en la manera com converteixes aquesta idea en una app. Com estem acostumats a sentir, Amazon no va ser la primera llibreria, Facebook no va ser la primera xarxa social i Google no va ser el primer cercador. Ser el primer no fa automàticament que el teu producte sigui el que la gent escollirà.

Ja existeixen milers d'apps que solucionen milers de problemes, i això en realitat és una cosa bona. Si la gent ja utilitza alguna cosa per solucionar un problema, almenys tens certa evidència que el problema existeix. En lloc d'intentar inventar sempre una categoria completament nova, mira què ja existeix i pregunta't què es podria fer millor.

Potser les solucions existents són massa complicades, massa cares, massa lentes, estan mal dissenyades o simplement no funcionen bé per a un determinat tipus d'usuari. No necessites inventar una cosa que ningú hagi vist abans. A vegades només necessites agafar una idea que ja existeix i executar-la d'una manera que tingui més sentit per a les persones a qui vols ajudar.

Fuig de les idees massa grans

No estic dient que hagis de deixar de ser ambiciós. Dic que hauries de trobar un problema petit que solucionar i construir al seu voltant, en lloc d'intentar crear directament el pròxim SaaS gegant, la pròxima xarxa social o la pròxima empresa d'IA.

Començar petit fa que tot sigui més fàcil. Un problema petit és més fàcil d'entendre, més fàcil de validar i molt més fàcil de construir. Pots posar alguna cosa davant de la gent, veure què en pensa, canviar-la i repetir el procés sense haver de passar sis mesos construint una cosa que ningú t'ha demanat.

I si a la gent realment li importa, sempre pots fer-ho més gran després. No necessites saber com serà l'empresa d'aquí a cinc anys abans d'escriure la primera línia de codi. De fet, intentar decidir-ho per endavant probablement farà que construeixis coses que després ni tan sols necessites.

Toca gespa

De debò. Moltes idees no apareixen quan estàs assegut davant de l'ordinador intentant pensar en idees. Apareixen quan realment estàs vivint la teva vida. Ves a la universitat, a la feina, viatja, juga, parla amb gent, utilitza les apps d'altres persones i para atenció quan algú es queixa d'alguna cosa.

Els desenvolupadors tendim a fixar-nos en problemes de desenvolupadors perquè són els problemes que nosaltres mateixos experimentem. Això és útil, però també pot fer que pensem que tothom té els mateixos problemes que nosaltres. I no és així. A vegades la millor idea és una cosa completament allunyada de la tecnologia que descobreixes perquè eres allà quan algú va tenir problemes amb alguna cosa.

No necessites passar-te una tarda fent brainstorming d'idees per a startups. Simplement viu amb normalitat i para atenció a les coses que semblen innecessàriament complicades. Potser trobaràs alguna cosa molt més interessant d'aquesta manera.

El framework

El framework es pot resumir en quatre fases: Pain → Solution → Filter → MVP. La idea és passar-hi en ordre, però no tractar-les com una metodologia estricta. Són simplement quatre preguntes que t'ajuden a decidir si una idea mereix el teu temps.

Pain

Hauries de començar amb un problema, no amb una app. Para atenció a les coses que molesten, a les que triguen més del que haurien, a les tasques que la gent ha de fer manualment o a aquelles situacions en què penses que hi ha d'haver una manera millor de fer alguna cosa.

No ha de ser un problema enorme. De fet, un problema petit pot ser un punt de partida molt millor, especialment si el pots entendre clarament. L'important és que el problema existeixi realment i que sigui prou rellevant perquè algú el vulgui solucionar.

És molt fàcil crear una solució i després intentar convèncer-te que hi ha d'haver algun problema que la justifiqui. Potser una idea et sembla molt bona, però això no vol dir que ningú la necessiti. Un dels senyals més interessants és quan la gent ja està intentant solucionar el problema pel seu compte.

Potser utilitzen un full de càlcul, un munt de notes, un grup de WhatsApp, diverses aplicacions diferents o algun procés manual completament absurd. No importa que la seva solució actual et sembli estranya; l'important és que hi estan invertint temps i esforç per fer que el problema sigui gestionable. Ja han decidit que el problema mereix ser solucionat, simplement encara no tenen una bona solució.

També hauries de fixar-te en la freqüència amb què apareix el problema. Una cosa que molesta algú una vegada cada dos anys probablement no sigui una raó gaire bona per crear una app sencera al seu voltant. Una cosa que passa cada dia, en canvi, dona a la gent una raó molt més natural per continuar utilitzant el teu producte.

I si tu mateix experimentes el problema, encara millor. Ja entens què el fa molest i no has de començar intentant endevinar què vol l'usuari. Això no vol dir que hagis d'assumir que tothom té el mateix problema, però almenys tens un punt de partida.

Solution

Un cop tens un problema, pots començar a pensar com solucionar-lo. Aquí és on crec que els desenvolupadors sovint fem les coses al revés: comencem amb una idea per a una app i després intentem trobar una raó perquè aquesta app existeixi. És molt més fàcil fer-ho al contrari. Comença pel problema i pregunta't què podria fer-lo més fàcil.

La primera solució no ha de ser complicada. No necessita un assistent d'IA, deu integracions, una xarxa social, un sistema de recomanacions i un dashboard preciós. Només ha de solucionar el problema. Si pots eliminar el problema amb una cosa increïblement senzilla, normalment és molt més interessant que haver de construir un sistema enorme perquè la idea funcioni.

També hauries de mirar com està solucionant la gent el problema actualment. Si ja existeixen apps que fan una cosa semblant, utilitza-les. Mira què fan bé i, sobretot, de què es queixen els seus usuaris. Llegeix les ressenyes, parla amb usuaris si pots i fixa't en les petites coses que fan que l'experiència sigui frustrant.

Que ja existeixin solucions no és necessàriament una raó per abandonar una idea. De fet, poden ser una de les coses més útils que tens quan comences. Si la gent ja està pagant per una solució però es queixa constantment d'ella, has après dues coses importants: hi ha un problema i hi ha gent disposada a pagar per solucionar-lo.

Potser el mercat no necessita una altra app. Potser necessita una versió millor d'una que ja existeix. I això està perfectament bé. No necessites crear una categoria nova per crear alguna cosa que la gent vulgui.

Filter

En aquest punt tens un problema i una possible solució, però això encara no vol dir que l'hagis de construir. Aquí és on has de ser una mica crític amb la teva pròpia idea, perquè és molt fàcil agafar-li afecte a una cosa en què has estat pensant durant molt de temps.

Primer, pregunta't si el problema realment importa. Hi ha una diferència entre una cosa que estaria bé tenir i una cosa que la gent realment vol solucionar. Després fixa't en la freqüència amb què passa. Si el problema apareix cada dia, hi ha una raó natural perquè algú continuï utilitzant el teu producte. Si passa un cop l'any, serà molt més difícil justificar una app sencera al seu voltant.

També hauries de preguntar-te si la gent ja està fent alguna cosa per solucionar-lo. Si no estan fent absolutament res, això no ha de ser necessàriament dolent, però hauria de fer-te preguntar per què. Potser has trobat un problema que ningú havia detectat encara, o potser a ningú li importa prou per fer-hi res.

Un altre filtre interessant pot venir d'una cosa que vam comentar en el nostre últim post sobre Google Play Closed Testing. Si estàs desenvolupant una app per a Android, la fase de closed testing et pot donar informació força útil sobre si a la gent realment li importa el que has construït. Si els teus testers abandonen repetidament abans que puguis acabar el procés, o deixen d'utilitzar l'app poc després que els diguis que ja has complert els requisits de testing, pot ser un senyal al qual val la pena parar atenció.

Per descomptat, no ho hauries de tractar com una prova absoluta que la idea és dolenta. Els testers poden tenir els seus propis motius per marxar i un grup petit de testers no té per què representar el teu públic objectiu. Però si has de convèncer constantment la gent perquè continuï provant l'app i, tan bon punt saben que ja ha passat el procés, deixen de tenir motius per tornar-hi, almenys hauries de preguntar-te si realment estàs solucionant un problema que els importa.

La mateixa idea es pot aplicar fora del closed testing. Si algú prova el teu producte una vegada perquè li ho has demanat i després no el torna a obrir mai, això és informació. Si continua tornant sense que li ho hagis de recordar, també és informació. L'engagement per si sol no demostra que tinguis un gran producte, però la seva absència pot ser un senyal útil quan la combines amb tot el que estàs observant.

També has de considerar si pots construir la solució de manera realista. Una idea pot ser fantàstica en teoria, però dependre de dades a les quals no tens accés, d'una infraestructura que no pots pagar o d'una tecnologia que simplement no està disponible per a tu. Això no vol dir necessàriament que hagis d'abandonar la idea; de vegades simplement has de reduir-ne l'abast.

L'important és no confondre la mida de la idea amb la quantitat que necessites construir inicialment. No necessites construir-ho tot per descobrir si és útil. Només necessites prou per provar la hipòtesi que estàs plantejant.

MVP

Aquí és on finalment pots començar a programar. L'MVP hauria de ser la versió més petita de la teva idea que et permeti comprovar si la teva solució realment funciona. Crec que aquí és on el terme MVP es malinterpreta força sovint: no vol dir necessàriament construir una versió horrible del producte final.

Vol dir construir només el que necessites per respondre la pregunta que tens ara mateix. Si estàs fent una app de productivitat, potser no necessites una app mòbil, una aplicació d'escriptori, una extensió del navegador i un assistent d'IA. Potser només necessites la funcionalitat principal que resol el problema.

El mateix s'aplica pràcticament a qualsevol altra cosa. Si estàs fent una xarxa social, probablement no necessites totes les funcionalitats socials que se t'acudeixin. Si estàs construint un marketplace, tampoc necessites tots els mètodes de pagament, tipus de compte i sistemes de recomanació des del primer dia.

Com menys construeixis, abans podràs posar-ho davant d'algú. I això és important perquè realment no saps si les teves suposicions són correctes fins que algú utilitza el producte. Pots passar-te setmanes discutint com hauria de funcionar una cosa, però un usuari real et pot ensenyar més en cinc minuts.

Després escolta

Un cop tinguis l'MVP, dona'l a la gent. Probablement sigui la part més important de tot el procés perquè ara ja no estàs fent suposicions. Tens alguna cosa real amb què la gent pot interactuar, i això et dona informació que simplement no pots obtenir pensant en la idea pel teu compte.

Fixa't en el que la gent realment fa amb l'app i no només en el que et diu sobre ella. Que algú et digui que la teva idea està molt bé és agradable, però no et diu gaire. Que algú la utilitzi cada dia et diu molt més. El mateix passa amb les crítiques: si algú et diu que una cosa és confusa o que troba a faltar una funcionalitat, no ho descartis immediatament només perquè no formava part del teu pla original.

A vegades descobriràs que la gent utilitza la teva app d'una manera completament diferent de la que esperaves. Potser ignoren la funcionalitat que tu consideraves més important i passen tot el temps utilitzant-ne una altra. Potser demanen alguna cosa que mai havies considerat. No són necessàriament problemes; són peces d'informació que et poden ajudar a entendre en què s'hauria de convertir realment el teu producte.

L'objectiu no és demostrar que la teva idea original era correcta. L'objectiu és descobrir què és realment útil. La teva idea original és simplement una hipòtesi i el producte és la manera de comprovar-la.

Build, learn, repeat

I aquest és bàsicament tot el framework: Pain → Solution → Filter → MVP. Troba alguna cosa que realment sigui molesta, pensa en una manera de solucionar-la, assegura't que el problema val la pena i que la solució és realista, i després construeix la versió més petita que puguis.

A partir d'aquí, aprens del que passa i vas iterant. Potser la idea funciona i pots continuar ampliant-la. Potser el problema és real però la teva solució no és prou bona. Potser descobreixes un problema completament diferent mentre la construeixes. O potser a ningú li importa.

I tampoc passa res. Descobrir-ho després de dues setmanes és molt millor que descobrir-ho després de sis mesos. L'objectiu de l'MVP no és demostrar que la teva idea es convertirà en una gran empresa, sinó descobrir si realment hi ha alguna cosa que val la pena continuar construint.

L'important és no enamorar-te de la idea en si. No estàs intentant demostrar que ets molt llest per haver-la pensat. Estàs intentant construir alguna cosa que sigui útil per a algú, i de vegades això significa canviar la idea amb què vas començar.

Probablement hi ha milers de problemes al teu voltant que podrien convertir-se en apps. Només has de fixar-t'hi. Així que abans d'obrir el teu IDE i començar a construir la pròxima gran cosa, surt una estona, parla amb gent, utilitza coses, emprenya't amb coses i, sobretot, viu la teva vida.

Potser tornaràs amb una idea millor.