Produktutvikling og Feedback

Usikkerhet rundt utforming og brukervennlighet i tidlig fase.

Kort oppsummert

La fremtidige brukere forme produktet: vis en prototype og still åpne spørsmål, og test med pilotkunder eller sparringspartnere før lansering. Gjenta i sløyfer – vis, lytt, juster – med folk som faktisk er i målgruppen.

Den tryggeste veien gjennom usikkerhet i tidlig fase er å la fremtidige brukere være med å forme produktet: planlegg presentasjoner for potensielle kunder for å hente inn feedback, og vurder samarbeid med pilotkunder eller sparringspartnere for å teste produktet før full lansering. Grunnen er enkel – det er nesten umulig å gjette seg frem til hva folk synes er brukervennlig, mens tilbakemeldinger fra ekte brukere raskt avslører hva som funker og hva som forvirrer. Slik gjør du det i praksis. Når du presenterer for potensielle kunder, vis gjerne en prototype (en tidlig, klikkbar skisse laget i for eksempel Figma) fremfor å forklare med ord – folk reagerer mye mer presist på noe de kan se og prøve. Still åpne spørsmål ('hva ville du gjort her?') i stedet for ledende spørsmål ('liker du dette?'), og noter hvor de nøler. En pilotkunde er en tidlig kunde som tar i bruk en uferdig versjon mot at de får være med å påvirke produktet – dette er gull verdt, fordi du får realistisk bruk og konkrete forbedringsforslag før full lansering. En sparringspartner er en erfaren person (gründer, mentor eller fagperson) du diskuterer ideer og valg med, gjerne jevnlig, for å se ting du selv er for nær til å oppdage. Det er smart å gjenta dette i sløyfer: vis, lytt, juster, vis på nytt – samme tankegang som i Lean Startup, der man lærer raskt gjennom små runder fremfor å bygge alt ferdig først. En vanlig fallgruve er å spørre venner og familie som vil være snille, fremfor reelle brukere som gir ærlige svar. En annen er å samle inn masse feedback uten å faktisk endre noe. Spark* anbefaler å teste tidlig og ofte med folk som faktisk er i målgruppen, og å se på hver tilbakemelding som en mulighet til å gjøre produktet bedre før lansering.

Begreper forklart

Prototype
En tidlig, klikkbar skisse av produktet, ofte laget i Figma, som folk kan se og prøve.
Pilotkunde
En tidlig kunde som tar i bruk en uferdig versjon mot å få påvirke produktet.
Sparringspartner
En erfaren person, som en gründer eller mentor, du jevnlig diskuterer ideer og valg med.
Lean Startup
En tankegang der man lærer raskt gjennom små runder av vis-lytt-juster fremfor å bygge alt ferdig først.

Trenger du hjelp med akkurat dette?

Er du student ved NTNU i Trondheim eller Ålesund? Da kan du få en gratis, personlig veileder fra Spark* som hjelper deg videre med nettopp din idé.

Søk veiledning

Ofte stilte spørsmål

Usikkerhet rundt budsjettering og økonomistyring i tidlig fase.

DNB tilbyr gratis, lavterskel budsjettkurs for gründere. Et budsjett viser hvor lenge pengene rekker (runway). Start enkelt i et regneark med faste og variable kostnader og realistiske inntektsanslag, og legg inn en buffer.

Les hele svaret →
Usikkerhet rundt personvern og GDPR ved utvikling av digitale tjenester.

Få selskapets jurist til å avklare GDPR-kravene før du lanserer MVP-en. Kartlegg hvilke personopplysninger du samler inn og hvorfor, og hold det enkelt: samle minst mulig.

Les hele svaret →
Hvordan håndtere usikkerhet rundt patentering og eierskap i tidlig fase?

Det er helt greit å skrive i søknader at dere kjenner patentproblematikken, men prioriterer å validere idé og marked først. Skriv en teamkontrakt om at IP tilhører prosjektet, og ikke offentliggjør tekniske detaljer dere senere vil patentere.

Les hele svaret →
Usikkerhet rundt valg av selskapsform i tidlig fase av oppstarten.

Kartlegg fordeler og ulemper ved AS og ANS, men ikke la formalitetene stjele fokus i tidlig fase. De fleste vekstteam ender på AS på grunn av begrenset ansvar og fleksibilitet med aksjer – selskapsformen kan uansett justeres senere.

Les hele svaret →
Hvordan spare ressurser i tidlig fase av produktutvikling?

Spar ressurser ved å lage en front-end MVP der du gjør jobben manuelt bak kulissene ('Wizard of Oz'-MVP) i stedet for å bygge full automatisering. Da ser du raskt hvilke funksjoner kundene faktisk etterspør, før du investerer i koden.

Les hele svaret →

Har du et annet spørsmål? Ta kontakt med oss.