Paul Katsen från Blockspring
Founder Coffee-avsnitt 025
Jag heter Jeroen och det här är Founder Coffee.
Varannan vecka tar jag en kaffe med en annan grundare. Vi pratar om livet, passioner, lärdomar … i ett intimt samtal där vi lär känna personen bakom företaget.
I det här tjugofemte avsnittet pratade jag med Paul Katsen, medgrundare av Blockspring, ett automatiseringsverktyg som hämtar data från olika API:er för att automatisera rapporter, listor och landningssidor.
Blockspring började faktiskt som ett verktyg för datavisualisering, men ställde om till en serverlös plattform direkt efter att de gått med i YCombinator och pratat med medgrundaren Paul Graham. Ungefär ett år senare, när Amazon hade gett sig in på just det här området, behövde de ställa om igen. Efter mängder av iterationer landade de till slut i den Blockspring-plattform vi känner till idag.
Till slut, för några månader sedan, blev Blockspring uppköpt av Coinbase. Vi pratar om det, om deras period i restaurangbranschen medan de ställde om, om hur det är att arbeta på ett stort företag nu och om varför spel kanske är bättre än verkligheten.
Välkommen till Founder Coffee.
Var kan du lyssna?
Du hittar det här avsnittet på:
Transkript
Jeroen: Hej, Paul. Det är roligt att ha dig med i Founder Coffee.
Paul: Hej, tack. Hur är läget?
Jeroen: Det är bra. Du är en av grundarna av Blockspring. För dem som ännu inte vet vad ni gör, vad gör ni?
Paul: Blockspring har en väldigt lång historia. Vi startade faktiskt 2014, men det vi gör nu är att hjälpa marknadsförare, säljare och rekryterare att få kontakt med olika API:er och datatjänster för att automatisera sin rapportering, berika listor och bygga leadslistor. Och slutligen faktiskt hämta in all den datan på landningssidor och livewebbplatser. Vi indexerar i princip en mängd API:er och gör dem enkla att använda och få tillgång till för personer som arbetar med företag.
Jeroen: Kan du kanske, eftersom det låter lite abstrakt, ge ett konkret exempel på något man kan göra?
Paul: Absolut. Att automatisera rapportering är ett av användningsområdena. Marknadsförare lägger i princip mycket av sin tid på att logga in i Facebook Ads Manager, hela det gränssnittet, Google Analytics, Google Ads, YouTube Ads och liknande, och exportera data från allt detta till samma instrumentpanel varje vecka eller månad. Det är manuell rapportering. Det tar en hel del tid.
Paul: Vi har en mängd integrationer med alla de här olika tjänsterna och plugin-program för verktyg som Excel, Google Sheets och Tableau, så att en person kan välja flera av de här olika datakällorna, klicka på ”hämta data” och sedan hålls rapporten automatiskt uppdaterad. Det fungerar genom att använda samma API-plattform som vi utvecklade, men med ett plugin-gränssnitt som fungerar inuti rapporteringsverktyg, i stället för i vissa av våra användningsområden inom försäljning. De använder samma plattform, men kopplar in den i andra verktyg.
Jeroen: Om jag ska upprepa det du sa: man kan alltså hämta information, till exempel från Facebook Ads och YouTube, och vad som helst annat. Man kan samla allt i ett Google Sheet. Det är något jag skulle kunna använda Blockspring till.
Paul: Ja. Det är definitivt ett väldigt vanligt användningsområde. Ett annat användningsområde som säljare och rekryterare använder är att bygga en leadslista. Men mycket av den här datan kommer kanske från Clearbit, Hunch.io, Google Maps eller alla de andra nya datatjänsterna som man kanske inte inser faktiskt är bra för försäljning eller rekrytering. De kanske alltså vill hämta in den datan i ett Google Sheet eller något annat verktyg också. Den gemensamma nämnaren för plattformen är att göra API:er och data enkla att få tillgång till från ett verktyg för företag. Men användningsområdena sträcker sig från att automatisera rapportering och bygga leadslistor till en mängd annat.
Jeroen: Jag förstår. Det gör det mycket enklare att i princip samla data på ett ställe.
Paul: Ja.
Jeroen: Du nämnde att Blockspring har haft en lång historia under de senaste fem åren. Vad hände mer specifikt?
Paul: När vi startade 2014 byggde mina medgrundare faktiskt en produkt för datavisualisering, vilket var väldigt annorlunda från det här. Jag brukar beskriva företagets olika faser så här: det började med en produkt för datavisualisering, sedan kom vi in i YC och en massa andra galna saker hände, vilket faktiskt ledde till att vi blev en av de första produkterna inom serverlös databehandling. Därefter kom en fas där Amazon körde över oss och vi gick igenom en lång rad omställningar för att försöka hitta rätt. Till slut nådde vi en fas där vi insåg: det här är ett företag som inte är det vi började med. Men det är ett bra företag, det tjänar pengar och vi växer. Slutligen ledde det till att mycket av det som den produkten hade byggt upp och lärt sig faktiskt fick följa med in i Coinbase.
Paul: Så ja. Det var en mängd olika faser. Men vi började faktiskt på en helt annan plats än där vi slutade, vilket jag vet att många grundare går igenom just nu. Så jag berättar gärna mer om delar av den historien, eftersom det var en väldigt lärorik erfarenhet.
Jeroen: Ja. Vilka delar av historien var särskilt intressanta eller utmanande?
Paul: Tja, det finns olika utmaningar i varje steg. I början handlade det bara om att vi föll pladask för idén om datavisualisering. Hur det faktiskt började var att jag befann mig i Chicago, och jag minns att jag gick på YC Startup School, en endagskonferens där man fick se alla de här fullständigt galna teknikmänniskorna, som Marc Andreessen, Jack Dorsey, Balaji Srinivasan och så vidare. Jag minns att jag gick därifrån och tänkte: herregud. Jag är superinspirerad. Jag vill starta något.
Paul: Jag tänkte: jaha, det här kan jag också göra. De här människorna är ju helt vanliga människor. Det råkade vara så att jag åt middag med en nära vän i San Francisco samma kväll, och vi insåg båda att datavisualisering är svårt. Låt oss bygga en enkel app. Det kanske inte blir ett företag av det, men åtminstone något som gör det enklare.
Paul: Det slutade med att vi byggde något väldigt enkelt: man laddar upp en CSV-fil eller ett kalkylark och får en interaktiv visualisering, något som vi själva hade ägnat timmar efter timmar åt att bygga på våra tidigare jobb. Men vi ville göra det enklare. Det som sedan hände var att vi fick ett samtal från data-chefen på ett av världens största medieföretag. Han sa ungefär: hörrni, er produkt suger, men vi har försökt bygga det här i sex månader. Kan ni flyga till New York, jobba med oss i några veckor, så blir vi er första företagskund?
Paul: Så började det med den produkten. Något av det viktigaste jag lärde mig var för det första att man ska skriva bra innehåll när man bygger något, så att människor förstår vad man gör och vilket ens uppdrag är, eftersom de kan hitta en genom det. För det andra: om du kan få en kund att bjuda in dig till sitt kontor för att jobba där och bli superentusiastisk över dig trots att produkten suger just nu, då är du förmodligen något på spåren. De där veckorna var nog några av de mest spännande i det företagets historia. Att bygga för en kund och få omedelbar feedback var verkligen spännande. Det var en av våra första stora lärdomar från den produkten, och sedan ledde det till att vi kom in i YC sommaren 2014.
Jeroen: Ja. Så ni byggde faktiskt något och fick ganska snabbt en första kund. Hur kom det sig att ni inte fortsatte med exakt det här företaget, utan gick vidare till något annat?
Paul: Det är en riktigt bra fråga. Under den första veckan på YC byggde vi den här produkten, hade en kund och dessutom en massa andra användare som inte var företagskunder men som betalade för den enligt en freemium-modell. Vi försökte komma fram till vad vi skulle göra, så vi gick på YC-middagen, som är en återkommande veckoträff där man får träffa andra grundare och lyssna på talare. På den första middagen var Paul Graham där, och det var efter att han hade slutat leda YC. Jag tittade på min medgrundare och sa: hörru, vi går och pratar med honom. Vi älskar alla hans essäer, han är supersmart. Vi berättar om vårt företag.
Paul: Han gick längs en rad av grundare som presenterade sina idéer och gav dem feedback: 60 sekunder, sedan nästa person. Vi berättade om vårt företag. Vi berättade att vi hade upptäckt ett annat problem: vi hade byggt det här verktyget för oss själva, men i princip alla datavisualiseringar vi behövde krävde lite beräkningar. Tänk dig till exempel ett stapeldiagram som behöver göra lite klustring eller segmentering. Vi ville inte skicka det till EC2 och Amazon varje gång vi behövde köra den beräkningen, och det var väldigt svårt att göra i JavaScript på frontend.
Paul: Så vi byggde ett verktyg som i princip lät oss skriva kod, klicka på publicera och få ett API. I dag kallas det serverless. Amazon har en sådan lösning, och det har Google och Microsoft också nu. Men när vi berättade om det i vår presentation drog han i princip igång en 20 minuter lång monolog om hur något sådant skulle kunna förändra programmeringens framtid. Han sa: om ni tror att ni så småningom vill göra det här, borde ni göra det redan i dag. Det där tror jag verkligen på. Om du har ett startupföretag och tror att du tio steg längre fram kommer att göra något enormt, varför gör du då inte bara det direkt? Försök inte vara super… jag vet inte, försök inte vara ett geni kring det. Om det är möjligt, gör det i dag.
Paul: Så vi kom hem och fick ett slags panikartat infall: ”Vi gör det här bara.” Det var en så stor idé, vi var supertaggade på den, och sedan gjorde vi det.
Jeroen: Men ni lyckades inte göra det stort inom serverless. Andra började göra det ni hade gjort, antar jag?
Paul: Ja. Det som hände var i princip att vi fick tusentals utvecklare att börja använda det. Vi lanserade precis innan YC var slut. Ett problem var att vi inte visste hur man säljer serverless computing till företag. Vi var för tidiga, eftersom det innebär ett så stort skifte i programmeringsparadigm. Men samtidigt var vi också för sena, eftersom vi till slut träffade Amazons teknikchef. Vi trodde att vi skulle sälja in oss till honom och sälja produkten till Amazon så att de skulle använda den. I själva verket tror jag att han bara tänkte: vad håller de här clownerna på med? För tre eller fyra månader senare lanserade de exakt samma sak, och de hade arbetat med den i flera år.
Paul: Jag tror att vi var både för sena och för tidiga på exakt samma gång, eftersom det här för AWS var nästa punkt på deras enorma färd mot framtiden. Vi var bara ett litet startupföretag som hade förstått att det här faktiskt var en grej. Men de hade redan andra relationer och så vidare. Inom några månader efter deras lansering insåg vi: hörrni, vi har egentligen ingen framtid inom det här. Det här är framtiden för alla stora molnplattformar. Vi kommer inte att kunna konkurrera med dem. Amazon gjorde det till slut. Microsoft, Google, IBM – you name it.
Paul: Det här var ännu en svår sak vi behövde göra. Vi insåg att företaget inte skulle fungera. Så vi var tvungna att låta en hel del personer i teamet gå, banta ner verksamheten till bara grundarna och börja fundera på vad nästa steg för företaget skulle bli och vilken typ av verksamhet vi ville ägna oss åt.
Jeroen: Hur många var ni innan ni bantade ner teamet?
Paul: Vi var ungefär sex till åtta personer, om jag minns rätt, plus ungefär tre till fyra konsulter vid den tidpunkten. Så totalt var vi runt tio. Det var inte enormt. Men då hade vi tagit in finansiering, presenterat den här visionen för en massa olika personer och verkligen tyckt om alla. Alla var fantastiska, och det var otroligt svårt att vända på allt. Men jag tror att vi visste att vi behövde göra det, eftersom det är väldigt svårt att lista ut nästa sak när man har personer som inte nödvändigtvis är grundare. De kom dit av en viss anledning, och de kanske inte vill vara kvar när det handlar om något helt annat. Det är svårt att gå in i ett upptäcktsläge när personer väntar och säger: jaha, vad ska jag göra nu? Det finns definitivt en skillnad mellan personer som arbetar med dig och personer som är grundare och redo att lista ut: okej, det kan bli vilket företag som helst, låt oss ta reda på vad det ska vara.
Jeroen: Så ni kom fram till att det bästa sättet att nå nästa steg var att låta alla gå och ta er lite tid. Hur lång tid tog ni?
Paul: Det var definitivt flera månader. Vi testade alla möjliga olika idéer, och en del av det handlade om att säga: okej, nu är det bara grundarna kvar. Det andra var: bra, låt oss minimera våra kostnader så mycket som möjligt så att vi kan testa olika saker och lista ut vilken nästa väg företaget skulle ta. Det här var definitivt en av de svåraste delarna – när man har ett företag men inte vet vilken verksamhet man egentligen är i.
Paul: Det var en väldigt, väldigt svår tid, för man springer nu runt som en yr höna och försöker lista ut hur man ens ska börja identifiera vilket problemet är. Det här är inget du kan somna ifrån utan att tänka på.
Jeroen: Ja. Hade ni tagit emot någon finansiering fram till dess?
Paul: Ja. Vi hade tagit in pengar utifrån den här stora visionen om att konkurrera med AWS och ta över framtiden. Föreställ dig då att behöva vända på allt det. Vi har ett riktigt smart team, ni investerade i teamet, men nu vill vi ta reda på något annat att göra – och göra det precis lika stort.
Jeroen: Varför gick ni inte tillbaka till idén om datavisualisering?
Paul: Det är en bra fråga. Jag tror att vi vid den tidpunkten inte visste om vi var annorlunda. Vi ville göra något. Då hade vi också förändrat omfattningen av det vi ville göra en aning. Vi hade sett alla de här andra företagen. Vi hade flyttat till San Francisco och sett alla de här andra människorna som var otroligt ambitiösa och arbetade med produkter byggda kring stora visioner. Jag tror att vi då tänkte: okej, den här produkten för datavisualisering är spännande och rolig, det var det första vi kom på och vi har kunder till den. Men vi vill göra något som påverkar miljontals människor, utvecklare eller slutanvändare. Vi var väldigt intresserade av idén att göra de supertekniska saker som utvecklare gör varje dag tillgängliga för slutanvändare, eller att göra dem mycket enklare att genomföra.
Paul: Vi befann oss i ett känslomässigt tillstånd där jag tror att vi helt enkelt var redo för något annat. Vi hade redan fått avslut kring datavisualiseringsdelen. Så vi försökte lista ut: okej, vilken vision kan vara lika stor som den vi har här med den här plattformen, och som vi kan få ut på marknaden? Vad skulle kunna vara nytt och lika stort?
Jeroen: Så ni letade efter en ny, stor vision. Vad såg ni då?
Paul: Vi försökte till slut med en massa olika saker, och vi provade också en massa olika processer för att hitta en massa olika saker. I efterhand var många av dem verkligen, verkligen svåra. Jag har många vänner som går igenom det här just nu – hur hittar jag min nästa startup? Vi lyckades aldrig hitta en fantastisk process för det. Jag kan berätta om några av idéerna som vi tyckte var riktigt stora och som vi till slut förverkligade, särskilt en som jag tycker var väldigt intressant.
Paul: Men i grunden insåg vi att de enda idéerna vi verkligen kunde få igång och få att fungera var en kombination av frågorna: hur får vi övertygelsen om att det här är något som vi tycker är spännande och som vi vill få att fungera? När man har gått igenom alla de här idéerna är det svårt att känna övertygelse. Jag tror att vi vid en viss punkt helt enkelt hade tur och upptäckte Blockspring, som redan använde 80 procent av den kodbas vi hade byggt. Vi hade själva upplevt problemet. Vi visste definitivt att det fanns en stark trend kring att ta produktivitetsverktyg och integrera dem med alla andra produktivitetsverktyg som byggdes. Det fanns alltså en exponentiell trend mot mer SaaS för allt.
Paul: Jag tror att vi fångade upp den trenden. Vi hade tur och lyckades fånga upp den, samtidigt som alla stjärnor stod rätt när det gällde problemet, övertygelsen och en potentiellt stor marknad. Nu behövde vi bara lista ut hur produkten skulle se ut för att få det att hända. Men på vägen fanns det en massa andra idéer. Vi skapade till slut AWS för mat i Chicago. Vi ägnade faktiskt tre månader åt att få det på plats och bygga upp det, och jag tror att det faktiskt kommer att bli ett väldigt stort företag. Det visade sig bara att det inte var något för oss.
Jeroen: Vad betyder AWS för mat?
Paul: En dag var jag fortfarande helt uppjagad och tänkte: vad ska vi göra härnäst, vilken idé ska vi fokusera om på? Jag satt bokstavligen på Chipotle. Det här låter dumt i efterhand, men vi satt på Chipotle och jag tänkte: wow, jag tror att det kommer att finnas ett oändligt antal företag som fungerar så här, alltså sådana här snabbmatsrestauranger med lite mer ambitiös mat. Det borde finnas en plattform som gör det möjligt för dem att skala upp över hela landet utan att behöva bygga upp sina egna lokaler. Min liknelse var att lokaler och personal är som datorkraft, medan koden är receptet och ingredienserna.
Paul: Det vi till slut gjorde var att gå till en massa frukostrestauranger i Chicago och övertyga dem om att låta oss använda deras kök på kvällarna när de var stängda, till en väldigt låg kostnad. Sedan gick vi till en massa populära snabbmatsrestauranger med lite mer ambitiös mat och övertygade dem om att lära vår personal hur man lagar deras mat. Därefter startade vi upp dem i virtuella kök över hela staden på UberEats, Postmates, DoorDash och alla andra leveransplattformar, så att de här restaurangerna faktiskt fick full täckning på marknaden och bara betalade per timme. De behövde alltså inte ha någon egen personal eller något annat. De skalade helt enkelt upp utifrån sin idé.
Jeroen: Så det var alltså inte restauranger dit man kunde gå och äta, utan det handlade enbart om leveranser?
Paul: Ja, enbart leveranser. Det här började faktiskt ge oss intäkter, men det var ingen bra affär för restaurangerna och inte hållbart för dem i det skedet, på den skalan. Men vi hamnade också i den smått absurda situationen att Uber Eats kom över till köken, Amazon kom över och alla de här olika leveransplattformarna frågade: okej, vad är det som händer här? Det visade sig att modellen faktiskt är något som jag vet kommer att växa exponentiellt, i takt med den fortsatta leveranstrenden – det händer redan och jag tror att det kommer att fortsätta. Jag vet att Ubers medgrundare faktiskt precis har börjat göra samma sak, men på ett lite annorlunda sätt.
Paul: Så ja. Vid en viss punkt befann vi oss alltså med att bygga programvara i kök sent på kvällarna och tänka: är vi de enda som arbetar med den här idén? Vi tappade övertygelsen. Vi tänkte att vi förmodligen var galna och de enda som arbetade med idén om en plattform för virtuella kök. Är det här verkligen framtiden, eller kommer vi att sitta i kök resten av livet och kämpa i motvind? Där hittade vi, tror jag, en väldigt stor vision och en produkt som faktiskt hade kunnat förverkliga den. Men jag tror inte att det var rätt för oss, och det var det.
Jeroen: Ja, det låter som en väldigt intressant idé. Det finns företag som byggs ovanpå Airbnb, eftersom Airbnb är en så enorm plattform. Från början handlade det i princip om att man sov hemma hos någon annan. Men sedan började människor köpa bostäder enbart för Airbnb. Det känns som samma sak, i den meningen att du har tjänster som Uber Eats eller Deliveroo eller vad de nu heter. De är plattformar med kunder, och man kan enkelt tillföra något nytt till dem.
Paul: Ja, ett nytt utbud. Hundra procent. Ja, det stämmer helt. När mobilen kom började man bygga appar med mobilen i första hand. När Airbnb kom kunde man få fastigheter som byggdes med Airbnb i första hand, och fastighetsförvaltare.
Jeroen: Just det.
Paul: Det intressanta med leveranser är att när man går in på en restaurang och ser en massa cykelbud eller chaufförer som står och väntar i kö och tränger ihop sig i lokalen, samtidigt som köken svämmar över av beställningar. Det är helt enkelt en grundläggande designfråga. Ska vi bygga en restaurang för våra kunder, eller en produktionsanläggning som också fungerar för leveranser? Det visar sig att de flesta restauranger inte är utformade för leveranser. Därför öppnar många av dem faktiskt separata kök som enbart hanterar leveranser, utanför sina vanliga restauranger, och problemet är att det är ett enormt slitsamt arbete för dem. När vi lanserade den här modellen fick vi ett omedelbart ja från restaurangägarna, vilket överraskade mig väldigt mycket, eftersom jag inte kunde någonting om mat eller restauranger. Vi anställde en chef som var riktigt, riktigt bra. Det hjälpte oss att få ut det här på marknaden. Men varje restaurangägare sa: ja, det här vill jag göra.
Paul: Så det var tydligt att efterfrågan fanns. Jag tror att den som faktiskt kommer att få det här att fungera är någon som kan ta in väldigt mycket pengar för att köpa fastigheterna och göra det till en ännu bättre affär, eller någon som kontrollerar hela efterfrågan. Uber Eats och Deliveroo gör redan det här. De vet vad människor vill köpa och skickar insikter tillbaka till olika restauranger för att få dem att börja ta fram mat. Företag som Deliveroo öppnar faktiskt redan kök och hyr ut lokaler för det här. Jag tror att det är dit marknaden är på väg, men det var en av de där sakerna där vi utgick från grundprinciperna och såg något som jag tror var väldigt stort – det visade sig bara att det inte var något för oss.
Jeroen: Just det. Varför tror du att det inte var något för er?
Paul: Vi slog delvis in på fel väg genom att bli en mellanhand mellan ett leveransföretag och restaurangen. I själva verket borde vi ha blivit den smartare fastighetslösningen, och det försökte vi aldrig med. Jag tror att vi vid en viss punkt tänkte: är vi bara galna nu? Och vi tappade övertygelsen, eftersom det här var så annorlunda jämfört med allt vi någonsin hade försökt göra. Vi befann oss fortfarande i läget där vi måste hitta den rätta idén. Så vi kan ha avfärdat även den här idén för tidigt, men jag tror inte nödvändigtvis att den var något för oss, eftersom vi ärligt talat tyckte att den var så märklig att vi förmodligen jagade på fel ställe.
Jeroen: Kände du dig bekväm i restaurangbranschen?
Paul: Inte inom restaurangbranschen, men definitivt inom drift och verksamhetsstyrning. Jag hade egentligen aldrig gjort något sådant tidigare. Det var faktiskt jättekul. Det fanns vissa delar av det – som att bygga programvara för verkliga situationer för att förbättra arbetsflöden, att ha ett företag som man enkelt kunde berätta om för alla och som alla ens vänner kanske till slut skulle använda. Om man har något som klarar tandborsttestet, alltså ett användningsfall för vardagen, kommer man till slut att bygga ett företag som finns kvar i hundratals och åter hundratals år. Det tar tid. Men vi kom på ett helt nytt sätt att göra det på, och varför det behövdes just då blev logiskt. Den exponentiella trenden blev logisk. Allt föll på plats. Så den delen, allt sammantaget, var otroligt spännande.
Paul: Att sitta på en restaurang och se leveransbeställningarna komma in, hantera människor som stjäl från en efter att man just anställt dem, hantera relationer med människor – särskilt på den inkomstnivån och med tanke på hur snabbt vi anställde – det är en helt galen värld. Det är väldigt annorlunda jämfört med SaaS. Det kommer med en egen uppsättning problem som man måste bli riktigt bra på att hantera, så pass att man går runt och tänker i molnen på hur stort det här kan bli, samtidigt som man i vardagen hanterar de här problemen. Man tänker hela tiden: hur ska det här någonsin få någon inverkan?
Jeroen: Fanns det några andra idéer som ni arbetade med under den tiden?
Paul: Det fanns några som var otroligt spännande. Men jag tror att det mest avgörande var att vi började göra vissa sökningar på några av våra gamla produkter. Jag hittade i princip ett väldigt enkelt produktproblem: jag försöker göra en dataanalys i Google Sheets, men all min data finns i en databas eller via ett API, så jag var tvungen att börja skriva skript för att integrera den informationen.
Paul: Det förde mig tillbaka till mitt första jobb, som var inom konsultverksamhet. Jag minns att det här var en idé som jag brukade ägna mycket tid åt. Jag var ingenjör och hade gått på universitetet. Jag hade lärt mig att programmera, men jag började inom konsultverksamhet och lade mycket av min tid på Excel-ark. Jag insåg att alla jag kände arbetade i Excel. De programmerade egentligen bara med API:er. Man matar in några siffror som indata och får något som utdata. Många, särskilt inom konsultverksamhet, lägger mycket tid på att gå till olika webbplatser och appar, samla in data och föra in allt på samma ställe.
Paul: Många av de tjänster som hämtade in den datan började få API:er. Den stora visionen som började växa fram för mig var därför: varför lägger jag all den här tiden på att kopiera och klistra in saker från ett ställe till ett annat och hålla dem synkroniserade, när allt det här i själva verket kommer att ha API:er? Det kommer att finnas allt fler SaaS-verktyg. De borde på något sätt synkroniseras och kopplas ihop. Den stora visionen är slutanvändardatoranvändning. Folk i näringslivet kommer till en punkt där de förstår hur man använder API:er och hämtar data från ett ställe till ett annat, och det borde finnas ett enkelt sätt att göra det.
Paul: Vi tittade på vilka produkter som fanns, och där fanns IFTTT och Zapier. De var alla händelsebaserade och flyttade små mängder data fram och tillbaka, men de löste inte uppgiften. Till exempel: hur går jag in i ett Google Sheet, hämtar en Google Analytics-rapport, håller den uppdaterad och kör ett datorseende- eller NLP-algoritm via något annat API, för att sedan skicka min data genom det och till slut använda API:er för att programmera på samma sätt som en utvecklare gör när hen skriver ett skript?
Paul: Det var faktiskt ett helghack där jag byggde ett Google Sheets-tillägg som integrerades med den serverlösa plattform vi hade byggt och anropade alla de olika API:er som folk arbetade med. Sedan visade jag det för mina medgrundare och sa: det här är faktiskt helt galet. Vi var alla överens om att problemet var logiskt och att visionen på sätt och vis fanns där. Den verkliga frågan var bara: hur gör vi det här till en produkt som vi kan börja få folk att använda? Och den öppna frågan var: vilka är alla de centrala användningsfall som folk faktiskt skulle använda det här till? Det var något vi till slut arbetade oss igenom och kom fram till, tills vi hade något i stil med: här är de tre användningsfallen, så här tjänar vi pengar – och det var då det verkligen började växa.
Jeroen: Hur gick det för er? Hur många anställda växte ni till slut till?
Paul: Det som hände var att vi lanserade produkten utan att ha en särskilt bra bild av användningsfallen. Det tog ett tag, men vi började helt enkelt få ut den genom dörren, släppa in folk, lyssna på vad de försökte åstadkomma och sedan börja förstå vad den här plattformen skulle handla om.
Paul: Jag vet inte om det är den bästa modellen för nya plattformar, men det var den väg vi till slut valde. Tidiga användare kom in. De gjorde något inom tillväxt, som: hej, jag vill hämta en lista över våra användare från Salesforce och sedan skicka vykort till dem alla från Lob, och dessutom det här. Här är mitt slumpmässiga projekt. Och plötsligt dök det upp ett helt annat projekt: hej, jag är digital marknadsförare och försöker hålla den här rapporten uppdaterad i Google Sheets eller Tableau. Hur får jag det att fungera med er produkt? Ni har inte Facebook-annonser – kan ni lägga till det? Ni har inte det här – kan ni lägga till det?
Paul: Då insåg vi att nyckeln till plattformen vi hade kommit fram till var att vi hade byggt den serverlösa lösningen på ett sådant sätt att vi kunde skriva ett snabbt skript, klicka på publicera och plötsligt hade vi en ny integration på plats i alla våra produkter. Vi kunde röra oss väldigt, väldigt snabbt för att se till att nästa användningsfall som någon hade kunde genomföras. Det var då vi började ta in folk för att hjälpa oss bygga de integrationerna, hjälpa till att fylla ut plattformen så att vi kunde lösa några av de här användningsfallen och nå en punkt där vi visste att automatiserad rapportering var något folk ville ha.
Paul: Idag finns det en hel del startups som fokuserar på det segmentet. Lead-berikning, där man hämtar information från en mängd olika API:er. Det finns egentligen ingen bra startup som gör just det, men folk går för närvarande till ett oändligt antal tjänster för lead-berikning, en i taget, och försöker lista ut vilken som är bäst. Så vi samlade alla de API:erna, och det finns ytterligare några användningsfall, men de där två är de klart största.
Paul: Många av våra användare var verkligen tvungna att slita för att göra sådant här på egen hand och ta reda på vad som var möjligt, och det hjälpte oss att komma till en punkt där vi sa: här är de två eller tre viktigaste sakerna som vi bör lyfta fram, introducera användarna till och göra till riktiga produkter. Det började växa. Det växte till en bra och lönsam verksamhet. Vid en viss tidpunkt förra året befann vi oss i ett steg där vi sa: okej, det här är en växande verksamhet, men vi började med visionen att vi skulle köra över AWS och skapa ett företag värt flera miljarder dollar.
Paul: Det var det som satte igång många av samtalen om var den här produkten skulle kunna landa när det gällde uppköp och allt sådant, och det visade sig att det fanns ett antal företag som faktiskt behövde snabba på sin API-roadmap, sin API-plattform och allt sådant – behov som hade en direkt koppling till allt vi hade byggt med Blockspring och produkten. Det var då vi började ha några av de här samtalen.
Paul: Det visade sig att allt gick hela varvet runt. Personen som lanserade AWS Lambda 2014 är VP of Engineering på Coinbase. Balaji Srinivasan, en person vi hade känt, är nu CTO på Coinbase. De har en mängd olika grundare och en riktigt fantastisk kultur. Det passade oss väldigt, väldigt bra. Så det var där Blockspring till slut hamnade.
Jeroen: Just det. Bara för att ge mig en bild av det: vad planerar Coinbase att göra med det ni har byggt?
Paul: Mycket av det är ännu inte offentligt, men vi är där för att arbeta med API:er och plattformar, både internt och externt. Det kommer att komma ut en hel del spännande saker. Ja, vi är supertaggade. Jag tror att min personliga övertygelse är att om man går tillbaka till Facebook 2007 hade de tiotals miljoner användare. Sociala medier var något helt nytt, och inte ens de själva visste vad som skulle bli viktigt efter flödet. Vad skulle folk vilja ha? Hur skulle folk vilja interagera? De använde plattformen för att upptäcka alla nästa stora succéappar.
Paul: Om du byggde saker på universitetet 2007, när Facebook väl lanserades, tillbringade du förmodligen fyra eller fem nätter med att försöka bygga hundra olika saker som utnyttjade deras sociala nätverk, hittade dina användare och skapade en stor produkt. Jag tror faktiskt att mycket av krypto befinner sig där idag, med några få stora succéappar som Coinbase just nu, och det handlar då om spekulation. Men det finns potentiellt en ganska stor plattformsmöjlighet att hjälpa till att bana väg för nästa våg av enorm tillväxt. Utvecklare är intresserade, användare är intresserade. Jag tror att det finns en stor möjlighet där.
Paul: Vi är otroligt entusiastiska över det. Många av de här nya paradigmen får sina nästa stora succéappar upptäckta av utvecklare och tredjeparter via en plattform. Så ja, vi är definitivt entusiastiska över potentialen där.
Jeroen: Okej. Vad är det som håller dig vaken om nätterna just nu?
Paul: Vad som håller mig vaken om nätterna just nu? Tja, jag tror att det är väldigt annorlunda nu jämfört med de senaste fyra åren. Under de senaste fyra åren har det bokstavligen handlat om att tänka igenom varje enskilt beslut: gör vi rätt sak? Är det här det bästa vi skulle kunna göra? Är det här det största vi skulle kunna göra? Vi vill ha störst möjliga påverkan på världen. Slösar vi bort vår tid? Är det här rätt företag för oss att driva? Alla de här frågorna snurrade runt, och den verkliga nyckeln var att koka ner allt till: vilken är den enda nästa sak jag behöver göra för att positionera oss för att lyckas? Och oftast var svaret: okej, vad vill användarna ha och hur växer vi?
Paul: Nu tycker jag att saker och ting är väldigt, väldigt annorlunda, eftersom jag är en del av den här stora maskinen som rör sig framåt av egen kraft, jämfört med när man är startupgrundare och själv utgör den kraften. Om du stannar upp stannar i princip hela maskinen. Det är en helt annan värld för mig nu, och det har varit fantastiskt att börja lära känna och träffa en massa supersmarta människor. Jag tycker att det är en helt annan upplevelse att vara i San Francisco för andra gången än när jag var här som grundare, stressade runt och försökte lista ut hur jag skulle göra mitt jobb på ett bra sätt.
Paul: Nu tycker jag definitivt att det är en mer avslappnad period av lärande, där jag träffar fantastiska människor, arbetar med stora saker, blir entusiastisk över det och uppskattar den här delen av resan.
Jeroen: Okej. När vi så småningom börjar runda av: vilken är den senaste bra boken du läste, och varför valde du att läsa den?
Paul: Åh, det var en bra fråga. Den senaste bra boken. Okej, det här var en rekommendation från en av mina vänner. Låt mig bara försöka komma ihåg vad den hette. Hoppsan, ursäkta. En sekund. Det var en bok om speldesign, och den heter Reality is Broken. Den stora frågan var: varför tillbringar människor så mycket av sina liv i spel? Hur kan vi använda det vi lär oss om speldesign för att påverka världen? Anledningen till att jag läste den var att jag verkligen tror att de viktigaste komponenterna i ett spel har utvecklats och upptäckts över tid, och att de går att tillämpa på allt.
Paul: Så om du bygger en dejtingapp och den inte på något sätt använder speldesign kommer du att misslyckas, medan de som faktiskt använder det i slutändan bygger Tinder. Jag tycker att allt blir mer och mer likt ett spel, samtidigt som alla spel faktiskt blir mer som traditionella mjukvaruprodukter, sociala nätverk, kommunikationsprodukter och allt sådant. Allt det här flyter ihop, så anledningen till att jag läste boken var helt enkelt att försöka förstå det. Jag har spelat spel hela mitt liv, men ville försöka förstå mer av vetenskapen bakom dem, vad den säger om oss själva och hur det kan hjälpa mig att bli bättre på att bygga produkter. Det var verkligen en otrolig bok. Jag rekommenderar den varmt till alla.
Jeroen: Vad var det galnaste du läste där?
Paul: Jag tog massor av anteckningar om just den här boken, men vad var det galnaste? Det var en bra fråga. Det galnaste jag insåg var att det i princip finns en återkopplingsloop där speldesigners försöker bygga spel som får dig att spela mer, få ut mer värde av dem och så vidare. Reglerna som gäller i spelens världar är faktiskt en tydlig spegling av människor och av vad som motiverar dem. Vad får dem att göra saker och att gå till jobbet, men ändå vilja komma hem och tillbringa all den här tiden med att spela spel?
Paul: Jag tror att en av de galnaste insikterna här är att anledningen till att boken heter Reality is Broken är att sättet vi har utformat spel på faktiskt är bättre än den upplevelse vi får på jobbet och i vår vardag i verkligheten. I verkligheten går du till jobbet. Mycket är okänt. Du får ingen återkoppling. Du vet inte om du vinner eller förlorar. Du rör dig framåt och hoppas att du på något sätt gör framsteg. Men i spel finns det tydliga regler. Det finns en tydlig återkopplingsloop. Du vet om du har vunnit eller förlorat. Det finns alla de här sakerna som vi vill ha i våra liv, och det är därför människor spelar spel: de får sådant i spelen som de inte får i verkliga livet.
Paul: Det vi upptäcker i spel handlar enligt mig inte bara om hur vi får människor att spela mer Super Smash Bros. Det handlar faktiskt om att upptäcka saker om människans natur, våra känslor och vad vi vill ha ut av livet, och jag tror att det är därför många av de här världarna flyter ihop. Man kan bara bygga ett samhälle i USA, men man kan bygga hur många samhällen som helst i spel, förändra reglerna och allt sådant. Det är som en kambrisk explosion av frågor kring hur samhällen fungerar och vad vi kan lära oss om dem. Jag tror att det är väldigt viktigt att använda det i andra appar, andra produkter och vardagslivet.
Jeroen: Just det. Okej.
Paul: Ja.
Jeroen: Sista frågan. Vilket är det bästa affärsråd du någonsin har fått?
Paul: Det bästa affärsrådet. Jag tror att det är en blandning av två saker. Det ena är samma sak som YC säger: bygg för dig själv, bygg något som människor vill ha, prata med användare — hela den loopen stämmer. Jag har misslyckats med flera delar av det vid olika tidpunkter, men om du håller fast vid det kommer du till slut att bygga något som kan fungera på något sätt, tjäna pengar eller skapa en bra livsstil för dig.
Paul: Motsatsen till det är i princip att du, när du har slut på idéer eller när du tycker att det är dags att återställa eller försöka arbeta med något större, kanske ännu inte vet vad det är — och då ska du återställa. Känn inte att du har misslyckats eller något sådant. Människor befinner sig helt enkelt i olika faser av livet vid olika tidpunkter. Så mitt stora råd är: om du vet vad du vill arbeta med, gå och arbeta med det. Om du inte vet, gå och ta reda på saker. Lär dig och identifiera andra problem genom att leva, prata med människor och allt sådant.
Paul: Om du befinner dig i den tredje gruppen, där du vill starta ett startupföretag och försöker hitta ett problem att lösa, är det en väldigt svår värld att verka i, och det är definitivt inget jag skulle vilja göra igen.
Jeroen: Okej.
Paul: Ja.
Jeroen: Tack igen, Paul, för att du var med i Founder Coffee.
Paul: Ja.
Jeroen: Det var verkligen roligt att ha dig här.
Paul: Det var roligt att vara här. Tack för att jag fick komma.
Gillade du det? Läs intervjuer med andra grundare i Founder Coffee. ☕
Vi hoppas att du gillade det här inlägget. Om du gjorde det, recensera oss på iTunes!
För att hålla dig uppdaterad om vår Founder Coffee-podd och samtidigt lära dig mer om startups, growth marketing och försäljning:
👉 Anmäl dig till vårt nyhetsbrev, som skickas varannan vecka:
👉 följ @salesflare på Twitter, LinkedIn eller Facebook
