Du har en idé til en app. Hva gjør du før du begynner å bygge?

Beskriv situasjonen før du beskriver appen

En appidé kommer gjerne som et bilde av en løsning: en kalender, en markedsplass eller et sted der alt er samlet. Jeg ville først skrevet ned situasjonen som gjør løsningen nødvendig. Hvem står fast? Hva prøver personen å få til? Hva koster det å fortsette som før?

Anta at du vil bygge en tjeneste for å bestille håndverkere. «Enklere bestilling» er foreløpig for bredt. Handler det om å få svar, finne ledig kapasitet, forstå prisen eller føle seg trygg på arbeidet? Hvert problem kan kreve en ganske forskjellig løsning.

Spør om sist gang det skjedde

Begynn med noen få samtaler med personer som faktisk møter problemet. Be dem fortelle om en konkret hendelse. Hva gjorde de, hvem kontaktet de, og hvor stoppet det opp? Be gjerne om å få se verktøyene de bruker, dersom det kan gjøres uten å dele fortrolige opplysninger.

Unngå å bruke hele samtalen på å presentere ideen. «Ville du brukt dette?» gir lett høflige svar. «Hvordan løste du dette sist?» gir mer å arbeide med. Noter også tegn som taler mot ideen. Kanskje eksisterende løsninger allerede fungerer godt nok.

Finn ut hvem som kan si ja til et kjøp

Når problemet er tydeligere, må du undersøke kjøpssituasjonen. Hvem har budsjettet? Hvor mye arbeid krever det å ta løsningen i bruk? Er behovet stort nok til at kunden vil bytte fra det de allerede gjør?

Innovasjon Norge fremhever problemforståelse, kundedialog og testing av et betalingsvillig marked i veiledningen til Oppstartstilskudd 1. Det er en nyttig arbeidsrekkefølge også når du ikke skal søke støtte. En positiv samtale er et spor å følge opp, ikke en bekreftet inntekt.

Kilde: Innovasjon Norge: Oppstartstilskudd 1

Test det mest usikre med minst mulig bygging

En klikkbar skisse kan vise om folk forstår en oppgave. En manuelt gjennomført tjeneste kan teste om resultatet er nyttig. En avgrenset, tydelig avtalt pilot kan undersøke om noen er villige til å forplikte tid eller penger.

Testen må være ærlig om hva som finnes. Ikke selg en automatisert løsning dersom arbeidet fortsatt gjøres manuelt uten at kunden vet det. Bestem på forhånd hva resultatet skal føre til: bygge videre, endre retning eller legge bort ideen.

Et bedre utviklingsmøte

Når du kan vise konkrete behov og hva du har lært, blir det enklere å diskutere omfang. Ta med målgruppen, én viktig oppgave, notater fra samtalene og dagens alternativer. Legg til en ramme for tid og penger til neste test.

Da kommer du med noe mer nyttig enn en funksjonsliste. Du kommer med et problemgrunnlag som en utviklingspartner kan hjelpe deg å gjøre om til en gjennomførbar første løsning.