År 2014 startade jag VipKing, en app för att komma in på Barcelona-nattklubbar. Vi spinnade senare ut ett stycke av det som Pictus. Ingen av dem gjorde mig rik. Båda lärde mig saker som tio år av ingenjörsjobb hade inte.
Jag tar upp det eftersom jag nu tillbringar mycket tid i rum där en grundare och en teknisk ledare talar förbi varandra, och anledningen jag vanligtvis kan se gapet är att jag har varit fel från båda två stolen.
Misstag ett: Jag optimerade delen jag njöt av
Jag är ingenjör. Så jag byggde. Arkitekturen var ren, animationerna var smidiga, release-processen var städad. Jag tillbringade veckor på saker ingen användare skulle någonsin märka, och jag kände mig produktiv hela tiden, för att bygga är mätbar och sälja är det inte.
Medan den faktiska frågan — skulle klubbägare ge bort entré till främlingar? — gick otestade i månader. Det var besvarbar på två veckor med ett kalkylark och tio telefonsamtal.
Det här är det enda mest vanliga misslyckandet jag ser i tekniska grundare, och det ser aldrig ut som ett misslyckande inifrån. Det verkar som framsteg.
Misstag två: Jag blandade ihop produkten med verksamheten
Appen fungerade. Användare gillade den. Det kändes som traction. Det var det inte — traction var klubbar som förnyade, och klubbar förnyade av anledningar som nästan ingenting hade att göra med mjukvaran: relationer, timing, om promotern den månaden gillade oss.
Jag itererade hårt på en variabel som inte var begränsningen. Om din produkt förbättras och ingenting förändras, förbättrar du fel sak, och ingen mängd teknisk rigor kommer att rädda dig.
Misstag tre: Jag behandlade att slut på pengar som ett finansproblem
Det är ett beslutshastighet-problem. Varje vecka använd på något som inte minskar en verklig osäkerhet var en vecka landningsbana utgiven för ingenting. Jag tänkte inte i de termerna förrän det var sent.
Jag lärde mig den ramen ordentligt i de två programmen jag gick igenom det året — Yuzz, Banco Santander's pre-accelerator, och NEXT, Powered by Google for Entrepreneurs. Vad båda drillköde var obehagligt: vad skulle behöva vara sant för att detta ska fungera, och vad är det billigaste sättet att ta reda på? Jag har skrivit separat om vad de programmen gjorde rätt.
Varje vecka som inte minskar en osäkerhet är landningsbana utgiven på ingenting.
Lektionen som kostade mig ett företag att lära
Vad det förändrade om hur jag arbetar
När jag senare blev den tekniska ledaren för produkter med verkliga användare — en iOS-app med över en miljon nedladdningar bland dem — tog jag tillbaka tre vanor som inget ingenjörsjobb hade lärt mig.
- Fråga vad som händer om vi har fel. Innan du uppskattar något. Om att ha fel är billigt, ship och ta reda på. Om det är dyrt, sakta ned. De flesta team tillämpar samma rigor på båda, vilket är slösande i en riktning och vårdslös i den andra.
- Säg affärskonsekvensen högt. Inte "vi bör omstrukturera synklagret" utan "om vi inte gör det, tar varje ny kund tre veckor att komma igång istället för en dag." Cheferna ignorerar inte teknisk skuld — de blir berättade om det på ett språk som ger dem inget sätt att prioritera det.
- Skydda beslut, inte kod. Vacker kod som implementerar fel beslut är det dyraste ett ingenjörsteam kan producera, och det produceras av bra människor varje dag.
Varför något av det här spelar roll för dig
Om du är en grundare utan teknisk bakgrund, personen du mest behöver är inte den bästa ingenjören du kan köpa. Det är någon som kommer att säga dig att det du frågade om inte är värt att bygga — och som har tillräckligt med ärrvävnad för att ha rätt om det.
Om du är en CTO vars VD verkar orimlig, de optimerar vanligtvis en variabel du inte kan se, på en klocka du inte blir visad. Det är ett översättningsproblem, inte ett kompetens-problem.
Jag har varit grundaren som byggde fel sak noggrant, och ingenjören som hade rätt om koden och fel om vad som spelade roll. Att ha fel från båda två stolen är, så långt jag kan tala, det enda sättet att lära sig där gapet faktiskt är.