Bygg et produkt

Fra idé til arbeidsprodukt som faktisk løser noe for noen som betaler for det

Som du leste i kapitlet om å starte et prosjekt, handler bygging av et prosjekt om å raskt teste ideen og se hvordan den blir mottatt, og så bygge videre på tilbakemeldingen (som i handlinger brukerne gjør, ikke alltid det de sier).

Med den lille retrospektiven fortsetter vi med spillboken for å bygge et produkt. En kort disclaimer: Jeg kommer ikke til å gå i dybden med forhåndsresearch som brukervennlighet og brukeropplevelse (UX) som dette noe er dekket i Agile-kapitlet, og det er virkelig en annen bok, men la oss nevne at det du bygger må se og føles godt ut.

God interaktivitet på rett nivå. Så få med deg gode UX-folk. Det vil gjøre en enorm forskjell. Å la UX til utviklere og ledere vil se ut som et 1980-talls regnskapsprogram med 1000 knapper. Så, nei.

Ok, så forutsatt at du har et “fint design” (en UX-designer ville drepe meg for å skrive det), neste trinn er å velge hvilke av funksjonene som er minst nødvendige for å gjøre produktet levedyktig.

Du har en flott designmocke med massevis av kule funksjoner. Si at du bygger en boligannonseringsside. Du trenger innlogging, abonner på nye annonser, søkefilter, en måte å legge til nye annonser på, dele dem, legge til bilder, innloggingslogger, informasjonssider, betalingsalternativer for annonseringsdager, administratorbrukeradministrasjon, osv., osv.

Hvilke av disse er grunnleggende for applikasjonens funksjonalitet og hvilke er ikke? Alle er grunnleggende. Så hvordan velger vi ut noen av disse for å bygge vårt MVP? Her kommer – det mest misforståtte aspektet ved hele MVP-tilnærmingen er at du må velge “hvilke funksjoner”. Du kan bygge dem alle hvis du vil, men du kan ikke bygge dem “fullt” eller “helt”.

Ta innlogging som eksempel. Du trenger kanskje ikke at brukeren bruker “glemt passord” eller setter et 8-tegn supertrygt passord eller bruker tofaktorautentisering med en gang.

Les mer i "CTO Spillbok" tilgjengelig på Amazon/Kindle.