Hva jeg ser etter før jeg går inn som teknologisk medgründer

Et problem noen allerede kjenner på

Jeg ønsker samtaler med mennesker som vil bygge noe de er villige til å ta ansvar for. En ferdig presentasjon er mindre interessant enn en tydelig forståelse av hvem produktet skal hjelpe. Hvem opplever problemet, hvor ofte skjer det, og hva gjør de med det i dag?

Tenk på forskjellen mellom «bedrifter trenger bedre oversikt» og «økonomiansvarlig bruker hver fredag på å sammenstille tall fra tre systemer». Den siste beskrivelsen gir oss en person å snakke med, en arbeidsoppgave å observere og en mulig forbedring å undersøke. Det gjør ideen mulig å arbeide med.

Tilgang til dem som skal bruke løsningen

Bransjekunnskap blir særlig verdifull når den gir tilgang til virkelige brukere. Kan vi få se hvordan jobben gjøres? Kan noen prøve en tidlig versjon og fortelle oss hva som ikke fungerer? Et nettverk som åpner slike dører kan være avgjørende for de første månedene.

Jeg vil også skille mellom brukeren og den som betaler. De kan ha ulike behov. En ansatt kan like en løsning, samtidig som lederen ikke ser grunn til å kjøpe den. Begge perspektivene må inn før vi behandler interesse som et marked.

Et lag med plass til uenighet

En teknologisk medgründer bør kunne utfordre både funksjonslisten og forretningsmodellen. Hvis oppgaven allerede er bestemt i detalj og kun skal utføres, kan et vanlig utviklingsoppdrag være en bedre samarbeidsform.

Det samme gjelder andre veien: Teknologien skal tåle spørsmål fra dem som kjenner kundene. Jeg ønsker at vi kan si «dette vet vi ikke ennå» uten at det oppfattes som svakhet. Før vi begynner, bør vi avtale hvem som avgjør hva når vi fortsatt er uenige.

En hverdag som faktisk går opp

Ambisjonene må passe med tiden og ressursene vi har. Hvor mye kan hver person bidra med de neste seks månedene? Hvem følger opp salg og brukere mens produktet bygges? Hvordan dekker vi kostnadene som kommer før inntektene?

Jeg ville skrevet svarene ned sammen med en første milepæl. For eksempel å få én avgrenset arbeidsflyt prøvd av relevante brukere. Da blir det lettere å se om vi faktisk har forutsetningene for å jobbe sammen, før vi binder oss til en stor plan.

Ta med dette til den første samtalen

Du trenger ikke en ferdig kravspesifikasjon. En kort, ærlig beskrivelse gir ofte et bedre utgangspunkt. Det viktigste er at vi kan undersøke ideen sammen.

• Hvem har problemet, og hvordan løser de det i dag?
• Hva har du undersøkt med potensielle brukere?
• Hva kan du selv bidra med i selskapet?
• Hva trenger du at en teknologisk medgründer tar ansvar for?
• Hvilken usikkerhet må vi avklare først?