Finn ut hva som faktisk finnes
Begynn med å be gründerne beskrive produktet. Be så om å få se det. En demonstrasjon er en rask og rimelig måte å undersøke påstandene om produktet på. En gründer med et fungerende produkt bør være villig til å vise det.
Bruk en testkonto med syntetiske eller forsvarlig anonymiserte data, og be om å få prøve den relevante arbeidsflyten. Tilgang til faktiske kunde- eller ansattdata krever rettslig grunnlag, nødvendighet, riktige tillatelser og kontrollert tilgang. Investorinteresse alene er ikke nok.
Produktutviklingen er her delt inn i fem trinn. Hvert trinn krever sin dokumentasjon. Spør hvilket trinn selskapet er på, og be deretter om dokumentasjonen.
| Fase | Hva som kjennetegner det | Hva du bør be om |
|---|---|---|
| Idé | Et problem og en foreslått løsning på papiret. | Kundesamtalene som formet ideen, med navn. |
| Prototyper | Noe som fungerer for gründerne når alt går som planlagt. | En demonstrasjon på gründerens maskin og en liste over det som er simulert. |
| MVP, minste levedyktige produkt | En versjon faktiske brukere kan bruke til én oppgave fra start til slutt. | Testtilgang og forsvarlig anonymisert dokumentasjon på bruk. |
| Samsvar mellom problem og løsning | «Det er etterspørsel etter denne typen løsning.» Kunder bruker den, og noen betaler. | De betalende kundene, fornyelsesdatoene og hva de brukte før. |
| Samsvar mellom produkt og marked | «Vi er klare til å skalere.» Kundene kommer uten at gründerne selger til hver enkelt, og de blir værende. | Kundebevaring per kundekull, kostnad ved å skaffe kunder per kanal og salgene gründerne ikke gjorde personlig. |
Engler investerer vanligvis fra like etter prototypene og frem til samsvar mellom problem og løsning. De fleste selskapene du ser, ligger derfor i de tre midterste radene. Den oppgitte fasen må stemme med dokumentasjonen i raden. Et selskap som hevder å ha samsvar mellom produkt og marked, men har seks kunder som daglig leder selv har skaffet, har i beste fall samsvar mellom problem og løsning.
Bruksdata viser om kundene har tatt i bruk det selskapet har bygget. Spør hvor mange brukere som logget inn forrige uke, hvor mange som brukte funksjonen pitchen bygger på, og hvem hos hver kunde som bruker produktet.
Et produkt med to hundre registrerte kontoer og elleve ukentlige brukere er tatt i bruk av elleve personer. Det er de elleve du bør ringe.
Hva kundenes bruk forteller om produktet
Referansekundene i presentasjonen er valgt av gründeren. Søk mer dokumentasjon fra kunder du velger selv, og fra produktets bruksdata.
- Hvor ofte bruker kundene produktet, og har bruken økt eller falt siden de begynte?
- Hvem har fornyet, hvem har utvidet bruken, og hvem har sluttet? Hva var grunnen i hvert tilfelle der en kunde sluttet?
- Hva brukte hver kunde før, og hva sluttet kunden å betale for da de byttet?
- Hvilke kunder betaler, hvilke bruker en gratisversjon, og hva ville skjedd med bruken hvis gratisversjonen ble stengt?
- Hvor fornøyde er de, med egne ord, og hva etterspør de som produktet ikke gjør?
Skill betalte piloter fra gratispiloter. Selv en liten betaling viser at noen fikk budsjett og godkjenning. For gratispiloter spør du hvor mange som går over til betalte avtaler. At noen vil prøve et produkt gratis, dokumenterer ikke betalingsvilje.
Publiserte sammenligningstall for kundebevaring, som SaaS Capitals årlige undersøkelse av private selskaper som selger programvare til bedrifter og har over USD 1 million i gjentakende inntekter, beskriver selskaper langt forbi seedfasen.
Ved seed må du undersøke de enkelte kundene: hvem som kjøpte, fornyet, utvidet bruken og sluttet. Med elleve kunder går du gjennom hver enkelt ved navn. En prosentandel alene skjuler for mange detaljer.
Ny teknologi og forbedret teknologi gir ulik risiko
Spør om teknologien er ny og omveltende eller en forbedring av noe som finnes. De to alternativene har ulik risiko og krever ulik dokumentasjon. En gründer som hevder begge deler samtidig, har ikke bestemt hvilken virksomhet selskapet skal drive.
En påstand om omveltende teknologi er en påstand om et uprøvd marked. Den krever bevis på at teknologien virker, i en form en uavhengig bruker eller test kan bekrefte. Den krever også en begrunnet forklaring på hvordan markedet vil ta den i bruk: hvem som endrer atferd først, hvorfor og hva det koster dem.
Planen for bruk må forklare hvordan kundene skal få vite om produktet og begynne å bruke det. Be om å snakke med de første kundene planen navngir.
En forbedring retter seg mot et etablert marked. Det kan redusere usikkerheten om det grunnleggende behovet. Kundene trenger likevel en grunn til å bytte, og fortrinnet må tåle at en etablert aktør svarer.
Spør hvor mye bedre løsningen er, målt etter kriterier som betyr noe for kunden, og om forbedringen dekker kostnaden ved å bytte. En forbedring på ti prosent i et marked der et bytte tar et kvartal, er en funksjon den etablerte aktøren vil legge til.
Avhengigheter
Alle produkter er avhengige av forhold selskapet ikke kontrollerer. Hver avhengighet reiser et spørsmål om hva som skjer hos andre aktører. Kartlegg dem med gründeren. Spør for hver av dem hva selskapet ville gjort de nitti dagene etter at leverandøren endret vilkår, pris eller praksis.
| Avhengighet | Hva du bør spørre om | Faresignal |
|---|---|---|
| En plattform: andres API, appbutikk, markedsplass eller grunnmodell | Hvor mye av produktets verdi som avhenger av plattformen, hva vilkårene tillater, og om selskapet noen gang har fått bruken begrenset, blitt fjernet eller fått prisen endret. | Produktet er en funksjon i plattformen, og plattformen kan levere den selv. |
| Én leverandør av en komponent, et datasett eller et produksjonstrinn | Om det finnes en alternativ leverandør, hvor lang tid det tar å kontrollere at den oppfyller kravene, og hvilke lagerreserver eller avtaler selskapet har. | Én leverandør, ingen avtale utover innkjøpsordrer og leveringstid som er lengre enn tiden pengene varer. |
| En kritisk tredjepartskomponent i produktet | Hva den gjør, hva lisensen tillater, og hvor mange måneder det vil ta å erstatte den. | Ingen i selskapet kan si hva komponenten gjør eller hvor den kom fra. |
| En offentlig godkjenning, sertifisering eller tillatelse som ennå ikke foreligger | Hvilken myndighet som gir den, hvor langt søknaden har kommet, tid og kostnad frem til godkjenning og hva selskapet selger i mellomtiden. | Inntekter i planen før godkjenningsdatoen, eller ingen dato i det hele tatt. |
| En person: den ene ingeniøren som forstår systemet | Hva som er dokumentert, hva gründerne kan drifte uten vedkommende, og hva avtalen og opptjeningsvilkårene sier. | Én person med ansvar for vedlikehold og en oppsigelsestid som er kortere enn tiden det tar å erstatte vedkommende. |
Vurder faresignalene gjennom gründernes forklaring og dokumentasjonen som støtter den. En avhengighet er akseptabel når gründerne har identifisert den, beregnet kostnaden og laget en plan for de nitti dagene. Hvis gründerne ikke har sett avhengigheten, registrerer du den som et funn.
Hvor vanskelig er teknologien å kopiere?
Spør hva som faktisk er vanskelig å gjenskape. Prøv hvert svar mot det en konkurrent med tilstrekkelig kapital med et godt team kan bygge på ett år. Oppsamlede data kundene har skapt, dyp integrasjon i kundens systemer, en sertifisering som tok atten måneder, og vernede immaterielle rettigheter er vanskelige å kopiere. Kode er enkelt.
Et særtrekk en konkurrent kan levere på et kvartal, er et forsprang, og det har verdi. Det varige konkurransefortrinnet er fortsatt noe selskapet må bygge. Verdsettelsen må gjenspeile at dette foreløpig er en plan.
Spør om noe lignende finnes, og hva som er unikt nok til å gi selskapet en fordel. Spør deretter om produktet kan beskyttes med immaterielle rettigheter, hvordan og hvor: gjennom patent, designregistrering eller varemerke.
Svaret skiller gründere som har tenkt gjennom vern mot konkurranse, fra dem som har skrevet «patentsøkt» på en slide.
Registrerte rettigheter: en første oversikt
Rettighetene som kan registreres, skiller seg i hva de dekker, hvor lenge de varer, og hva som holder dem i kraft. Patentstyret innvilger og registrerer alle tre i Norge. Patentstyrets designveiledning samler vilkårene på ett sted.
| Rettighet | Hva den beskytter | Varighet og hva som holder den i kraft |
|---|---|---|
| Patent | En teknisk oppfinnelse som er ny og har oppfinnelseshøyde. | Inntil 20 år fra søknadsdato, forutsatt at årsavgiftene betales, etter patentloven. |
| Designregistrering | Utseendet til et produkt, forutsatt at det er nytt og har individuell karakter. Tekniske løsninger faller utenfor. | Fem år fra søknadsdato, med fornyelse i femårsperioder inntil 25 år, etter designloven § 23. |
| Varemerke | Et kjennetegn som skiller selskapets varer eller tjenester fra andres. | Ti år fra søknadsdato, med ubegrenset fornyelse ti år av gangen, etter varemerkeloven § 32. Et merke som ikke er tatt i reell bruk i Norge innen fem år etter den endelige registreringsavgjørelsen, kan slettes ved dom eller administrativ overprøving (§ 37). |
Due diligence (selskapsgjennomgang) undersøker rettighetene i detalj. På dette stadiet avklarer du hovedtrekkene for programvare og offentliggjøring.
Etter patentloven § 1 er et datamaskinprogram alene ikke en oppfinnelse. Unntaket gjelder ikke når programmet har teknisk karakter: Det må gi en ytterligere teknisk effekt utover det vanlige samspillet med maskinvaren.
Patentstyrets retningslinjer gir eksempler som styring av en teknisk prosess, videokomprimering, gjenoppretting av et forvrengt bilde og kryptering av kommunikasjon. De samme retningslinjene behandler algoritmer og nevrale nettverk som abstrakt matematikk i seg selv. Et patentkrav som gjelder en fremgangsmåte med tekniske midler eller en innretning, har derimot teknisk karakter som helhet.
I den innledende vurderingen spør du om Patentstyret eller Det europeiske patentverket har gitt søkeren beskjed om at kravet ikke oppfyller vilkåret om teknisk karakter.
Det andre punktet er offentliggjøring. Etter patentloven § 2 må en oppfinnelse være ny. Patentstyret opplyser at enhver offentliggjøring hvor som helst i verden kan hindre søknaden, inkludert et foredrag, en utstilling, en brosjyre eller en muntlig beskrivelse.
Spør når oppfinnelsen først ble vist utenfor selskapet, og når søknaden ble levert. En gründer som presenterte virkemåten på tre demodager før søknaden, kan ha mistet muligheten til å søke vern.
Kontroller offentlige søknader og registreringer mot selskapets påstander:
- Patentstyrets søketjeneste viser norske patenter, varemerker og design, inkludert status og innehaver.
- European Patent Register dekker europeiske søknader og patenter.
- EUIPO eSearch dekker EU-varemerker og EU-design.
Søk på selskapet og hver gründer. Noter rettigheter som er registrert på andre enn selskapet.
Eierskapsspørsmålene du bør stille nå
Kontroller eierskapet under due diligence, men still de grunnleggende spørsmålene nå. Svarene hjelper deg å fastsette omfanget eller finne et problem som er alvorlig nok til å avslutte saken før du bestiller arbeidet.
Undersøk hvem som skrev koden, og under hvilken ordning. Etter åndsverkloven § 71 går opphavsrett til et datamaskinprogram over til arbeidsgiveren hvis det er skrevet som ledd i arbeidsforholdet eller etter arbeidsgiverens instrukser, med mindre annet er avtalt.
Overgangen omfatter rett til å endre programmet og overdra det videre.
Regelen dekker datamaskinprogrammer og ingenting annet. Dokumentasjon, design, data og modeller bygger på en ulovfestet regel eller på avtale. Spør derfor hva arbeidsavtalene sier om dette.
For oppdragstakere, byråer og gründere før stiftelsen må du avklare rettighetene gjennom avtalen og omstendighetene rundt oppdraget. Betaling alene overfører ikke opphavsrett. En uttrykkelig eller underforstått lisens kan tillate bruk, og programvarereglene kan tillate endringer som er nødvendige for den tiltenkte bruken. Ingen av delene etablerer eierskap eller en ubegrenset rett til å overdra verket.
Avklar hva selskapet faktisk har rett til å gjøre med kode det har bestilt. Betaling alene dokumenterer verken eierskap eller en ubegrenset rett til å endre eller overdra koden. Avtalen kan gi slike rettigheter. Den som har rett til å bruke programmet, kan også ha lovfestet rett til å gjøre endringer som er nødvendige for den tiltenkte bruken, innenfor de avtalebegrensningene som gjelder (åndsverkloven § 41). Dokumenter rettighetene som trengs for videreutvikling og en planlagt exit. Ikke gå ut fra at en lisens automatisk kan overføres til kjøperen.
Ble noe av koden laget mens en gründer jobbet hos en tidligere arbeidsgiver? Undersøk arbeidsoppgavene, instruksene og avtalene. Regelen om programvare laget av ansatte gjelder kode som er skapt under utførelsen av arbeidsoppgaver eller etter arbeidsgiverens instrukser. Bruk av arbeidstid eller utstyr avgjør ikke alene hvem som eier rettighetene. Dokumenter at selskapet har rettighetene det trenger, om nødvendig gjennom en avklaring eller overdragelse fra den tidligere arbeidsgiveren.
Finnes det patenterbare oppfinnelser, og hvem laget dem? Etter arbeidstakeroppfinnelsesloven får en arbeidsgiver ingen rettigheter til en ansatts patenterbare oppfinnelse automatisk. Arbeidsgiveren får dem ved å kreve overføring innen fire måneder etter den ansattes skriftlige melding. Hvor mye arbeidsgiveren kan kreve, avhenger av hvor nær tilknytning oppfinnelsen har til jobben.
Undersøk om den ansatte varslet skriftlig, og om arbeidsgiveren fremsatte et eventuelt krav skriftlig innen fire måneder etter at varselet ble mottatt. Mangler varselet, kan du verken gå ut fra at arbeidsgiverens lovfestede rettigheter er falt bort, eller at rettighetene allerede er overført. Undersøk både lovens fremgangsmåte og det som er avtalt, inkludert den ansattes mulige krav på rimelig godtgjøring.
Var et universitet, en høyskole eller et forskningsinstitutt involvert? Finn ut hvem som ansatte oppfinneren, og hvilke regler og avtaler som gjelder. Lærere og vitenskapelig personale ved universiteter og høyskoler har en særskilt publiseringsrett etter § 6, på vilkårene om varsling og tredjepartsrettigheter som står der. Unntaket gjelder ikke automatisk alle forskningsinstitutter. Be om avtalen med institusjonen eller teknologioverføringskontoret og dokumentasjon på varsler og krav. Manglende dokumentasjon skal følges opp i due diligence.
Hvilke komponenter med åpen kildekode ligger i kjernen, og hvilke lisenser gjelder? Tillatende lisenser åpner for bruk i et proprietært produkt på vilkår om navngivelse og bevaring av merknader. Copyleft-lisenser krever i tillegg at det selskapet distribuerer, gjøres tilgjengelig på de samme vilkårene. Nettverksvariantene utløses når programvaren tilbys som en tjeneste.
En tredje gruppe, lisenser med tilgjengelig kildekode, publiserer koden, men begrenser kommersiell bruk. De er ikke åpen kildekode etter Open Source Initiatives definisjon.
Be om komponentlisten med lisenser. En gründer som ikke har en slik liste, har ikke undersøkt dette. Da må arbeidet med å lage listen inngå i due diligence.
List opp hva due diligence må avklare, med forholdene som kan få de alvorligste konsekvensene først. Bruk listen når du bestemmer hva gjennomgangen skal omfatte før term sheet-et utformes, slik at vilkårene kan bygge på den.
Konsulentkode uten overdragelse, en patentsøknad i gründerens navn og en copyleft-komponent i et distribuert produkt kan være mulig å rette opp, avhengig av rettighetene og samarbeidsviljen hos dem som er involvert. Avklar tiltaket, kostnaden og om det kan fullføres før du bestemmer pris eller vilkår for gjennomføring.