I 2014 startet jeg VipKing, en app for å komme inn i Barcelona nattklubbene. Vi spunnet senere et stykke ut som Pictus. Ingen gjorde meg rik. Begge lærte meg ting som ti år med ingeniørjobber ikke hadde.
Jeg bringer det opp fordi jeg nå bruker mye tid i rom hvor en gründer og en ingeniørledelse snakker forbi hverandre, og grunnen til at jeg vanligvis kan se gapet er at jeg har vært galt fra begge stoler.
Feil en: Jeg optimerte delen jeg likte
Jeg er en ingeniør. Så jeg bygget. Arkitekturen var ren, animasjonene var glatte, release prosessen var ryddig. Jeg brukte uker på ting ingen bruker ville noen gang merke, og jeg følte meg produktiv hele tiden, fordi bygging er målbar og salg er ikke.
Mens det faktiske spørsmålet — vil klubbeiere gi bort adgang til fremmede? — gikk utestet i måneder. Det var svar på to uker med et regneark og ti telefonsamtaler.
Dette er den eneste mest vanlige feilen jeg ser i tekniske gründere, og det ser aldri ut som en feil innenfra. Det ser ut som fremgang.
Feil to: Jeg forvirret produktet med virksomheten
Appen fungerte. Brukerne likte det. Det føltes som traction. Det var ikke det — traction var klubber som fornyet, og klubber fornyet av grunner som hadde nesten ingenting å gjøre med programvaren: forhold, timing, om promotøren den måneden likte oss.
Jeg itererte hardt på en variabel som ikke var begrensingsfaktoren. Hvis produktet ditt forbedres og ingenting endrer seg, forbedrer du det gale tingen, og ingen mengde ingeniørdyd vil redde deg.
Feil tre: Jeg behandlet å gå tom for penger som et finansproblem
Det er et beslutningshastighhetsproblem. Hver uke brukt på noe som ikke reduserte en ekte usikkerhet var en uke runway brukt for ingenting. Jeg tenkte ikke i disse termer til det var sent.
Jeg lærte den innramingen ordentlig i de to programmene jeg gikk gjennom det året — Yuzz, Banco Santander's pre-accelerator, og NEXT, Powered by Google for Entrepreneurs. Hva begge drilte inn var ubehagelig: hva måtte være sant for at dette skal fungere, og hva er den billigste måten å finne ut på? Jeg har skrevet separat om hva disse programmene gjorde riktig.
Hver uke som ikke reduserer en usikkerhet er runway brukt på ingenting.
Leksjonen som kostet meg et selskap å lære
Hva det endret om hvordan jeg arbeider
Når jeg senere ble teknisk leder på produkter med virkelige brukere — en iOS app med over en million downloads blant dem — tok jeg tilbake tre vaner som ingen ingeniørjobb hadde lært meg.
- Spør hva som skjer hvis vi tar feil. Før du estimerer noe som helst. Hvis å ta feil er billig, ship og finn ut. Hvis det er dyrt, saktne ned. De fleste team bruker samme dyd på begge, noe som er bortkastet i en retning og hensynsløst i den andre.
- Si forretningskonsekvensen høyt. Ikke "vi bør refaktorere sync laget" men "hvis vi ikke gjør det, tar hver ny kunde tre uker til å komme på banen i stedet for en dag." Direktører ignorerer ikke teknisk gjeld — de blir fortalt om det på et språk som gir dem ingen måte å prioritere det på.
- Beskytt beslutningen, ikke koden. Vakker kode som implementerer feil beslutning er det dyreste tingen et ingeniørteam kan produsere, og det produseres av gode folk hver dag.
Hvorfor noe av dette betyr noe for deg
Hvis du er en gründer uten teknisk bakgrunn, er personen du mest trenger ikke den beste ingeniøren du kan ha råd til. Det er noen som vil fortelle deg at tingen du spurte etter ikke er verdt å bygge — og som har nok arr til å ha rett om det.
Hvis du er en CTO hvis CEO virker urimelig, optimerer de vanligvis en variabel du ikke kan se, på en klokke du ikke blir vist. Det er et translasjons spørsmål, ikke et kompetansespørsmål.
Jeg har vært gründeren som bygget det gale tingen omhyggelig, og ingeniøren som hadde rett om koden og galt om hva som betyr noe. Å ha feil fra begge stoler er, så langt jeg kan fortelle, den eneste måten å lære hvor gapet faktisk er.