KI gjorde leveranselederen til gründer
Michael Gold jobbet med prosjektledelse i 15 år før KI ga ham muligheten til endelig å bygge programvareproduktet han alltid hadde ønsket seg. Historien hans handler ikke om at KI gjør prosjektledere til gründere – den handler om å fjerne den siste unnskyldningen for dem som allerede var det.
Michael Gold
KI-tilgang: KI ga en ikke-teknisk gründer en praktisk måte å lage prototyper av programvare på, og reduserte hindringene uten å erstatte teknisk ekspertise.
Brukerinnsikt: Michaels førstehåndserfaring med prosjektledelse formet Aria rundt praktiske frustrasjoner, et tilgjengelig design og forsiktig bruk av KI.
Helgeprototyp: En prototype laget i løpet av en helg beviste konseptet, men ingeniører forble avgjørende for sikkerhet, arkitektur, fakturering og pålitelighet.
Prosjektlederfordel: Prosjektledere definerer allerede arbeid, håndterer konkurrerende prioriteringer og takler usikkerhet – ferdigheter som kan støtte entreprenørskap.
Markedsendring: KI gjør det nå mulig for fagfolk å omsette oppsamlede frustrasjoner med programvare til testede produkter i stedet for å vente på leverandørenes veikart.
Da Michael Gold var 15 år, drev han sitt eget arrangementsfirma og arrangerte sammenkomster for 500 personer. Faren hans drev sin egen virksomhet hele livet. Entreprenørskap var ikke så mye en ambisjon i familien hans som en selvfølge.
Og så, et eller annet sted på veien, ga han det opp.
«Da jeg vokste opp, ble jeg på en måte skremt bort fra det å være gründer», fortalte han meg. I stedet bygget han en karriere innen prosjektledelse: nesten 15 år, først innen kreative fag før han gikk over til teknologi. For rundt to år siden gikk han over til en brøkbasert arbeidsmodell, grunnla sitt eget prosjektledelsesbyrå og begynte å jobbe som en brøkbasert leveranseleder for oppstartsbedrifter og virksomhetskunder. Uansett målestokk var dette en vellykket vei. Men gründertrangen forsvant aldri helt. Den gikk bare i dvale.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Jeg vokste opp og ble skremt bort fra det å være gründer.
Denne måneden, mer enn to tiår etter de første arrangementene, lanserte Michael programvareproduktet Aria, et verktøy for automatisering av profesjonelle tjenester (PSA). Han bygger det sammen med et lite grunnleggerteam som inkluderer kona Rachael, en illustratør.
Jeg har intervjuet Michael to ganger de siste månedene, og i begge samtalene dukket det samme spørsmålet stadig opp: Hva var det som endret seg? Han er nemlig ikke utvikler. Det ble han aldri. Det som endret seg, var at kunstig intelligens gjorde det til et mindre problem enn før at han ikke var utvikler.
Det startet med irritasjon, ikke ambisjon
Michaels vei inn i programvareutvikling begynte ikke med en forretningsplan. Den begynte med små, velkjente frustrasjoner.
Rachael hadde bygget byråets nettsted på Wix, og hver endring måtte gå gjennom henne. «Jeg hatet virkelig å være avhengig av henne for å gjøre alt», sa han. Derfor koblet han nettstedet til et AI-verktøy for koding. «I løpet av en time hadde jeg det samme nettstedet, men nå kunne jeg kontrollere det selv.» Deretter kodet han sitt eget CRM ved hjelp av AI for å erstatte et abonnement til 100 dollar i måneden, noe som føltes absurd for en virksomhet med én person. Det var ikke bedre enn det ekte produktet, og det vil han selv fortelle deg, men det gjorde det han trengte, og avgjørende nok: «Det var virkelig morsomt å bygge det.»
Den opplevelsen fikk frem et spørsmål han aldri tidligere hadde hatt mulighet til å stille:
«Noe som HubSpot må ha alle mulige funksjoner for å betjene alle mulige kunder. Og derfor koster det det det koster, fordi det er et utrolig verktøy. Men hvis du bare trenger 0,5 % av det verktøyet, oppstår spørsmålet: Hvorfor betaler jeg for de andre 99,5 %?»
Det [Hubspot] koster det det koster fordi det er et utrolig verktøy. Men hvis du bare trenger 0,5 % av det verktøyet, oppstår spørsmålet: Hvorfor betaler jeg for de andre 99,5 %?
Hver lille byggeprosess gjorde den neste mulig å se for seg. Dette var ikke en person som bestemte seg for å bli programvaregründer. Dette var en prosjektleder som løste sine egne problemer og samtidig, i det stille, bygget opp igjen selvtilliten han hadde mistet.
Han hadde allerede erfart problemet han nå løser
Dette er saken med programvare, historisk sett: Personene som bygget den, og personene som led under den, var sjelden de samme. Å bygge et produkt krevde utviklere, UX-designere og produktledere. Sluttbrukerens rolle var å sende inn et funksjonsønske og håpe på det beste. Avstanden mellom personen som opplevde problemet, og personen som leverte løsningen, besto av en supportsak, en portal for funksjonsønsker, en kundeansvarlig og en annens produktplan.
Michael har tilbrakt flere år på feil side av denne avstanden.
For åtte eller ni år siden begynte han i et byrå som hadde tatt i bruk en ny PSA-plattform uken før han startet. Reaksjonen hans var ikke mild. «Jeg var nær ved å slutte i prøvetiden fordi jeg syntes det var det verste i verden. Jeg hatet det så intenst.»
Han tok det opp med eieren. Han ville ha verktøyet fjernet. Så skjedde noe uvanlig; han endte opp på leverandørens veikart for betaversjonen av produktet. «Jeg hjalp dem med å forme verktøyet», sa han, og etter hvert som produktet ble bedre med innspill fra fagfolk, ble også forholdet hans til det bedre. «Jeg gikk fra å være denne fyren som nesten sluttet i prøvetiden, til etter hvert å ta det i bruk og så bli den interne forkjemperen.»
Det var den gamle modellen for innflytelse fra praktikere: Vær heldig nok til å få plass i et betaprogram, og form andres produkt utenfra. Legger man til årene byrået hans har brukt på å implementere PSA-verktøy for kunder, har Michael sett denne kategorien fra alle plasser bortsett fra utviklerens. Han vet nøyaktig hvor disse verktøyene skaper friksjon: den klønete innføringen, de kalde og gledesløse grensesnittene. «Jeg synes ikke noen PSA-verktøy er spesielt pene. Jeg synes ikke det er spesielt hyggelig å være i dem», sa han. Det er derfor Rachael er med på grunnleggerteamet, og hvorfor han «virkelig ønsket at Aria skulle føles som et varmt og innbydende sted».
Jeg synes ikke noen PSA-verktøy er spesielt pene. Jeg synes ikke det er spesielt hyggelig å være i dem. Det er derfor jeg ønsket at Aria skulle føles som et varmt og innbydende sted.
Han vet også, etter å ha fulgt virkelige leveranseteam i stedet for LinkedIn, at de fleste prosjektledere fortsatt ikke bruker kunstig intelligens. Derfor varsler Aria-assistenten om problemer og spør før den handler, i stedet for å kjøre autonomt. «Agenter høres skremmende ut for meg, uansett om de burde gjøre det eller ikke», sa han. «Jeg tror det er en lavere terskel å ha en vennlig assistent som bare er på din side.»
Ingen av disse innsiktene kunne et produktteam fått gjennom brukerintervjuer. Dette er arr etter erfaring. Michael gjetter ikke på hva som frustrerer en prosjektleder klokken fire en torsdag ettermiddag. Han har selv vært den prosjektlederen. Det nye er ikke at praktikere har denne kunnskapen. Det nye er at de endelig kan handle direkte på den.
Fra prototype til produkt
Beviset kom i løpet av én helg. Da medgrunnleggeren James luftet ideen om at de skulle bygge et PSA-verktøy selv, sa Michael først nei. Dette er genuint kompleks programvare, av den typen som håndterer en virksomhets mest sensitive drifts- og økonomidata. «Det er ikke snakk om at jeg skal vibekode et PSA-verktøy», husker han at han tenkte.
Så satte han seg ved tastaturet uten å fortelle det til noen. «Jeg brukte 24 timer på å vibekode. Det er så avhengighetsskapende. Og i løpet av en helg hadde jeg bokstavelig talt en prototype som var et PSA-verktøy som gjorde alt et PSA-verktøy skal gjøre. Eller i det minste så det slik ut på overflaten.»
I løpet av en helg hadde jeg en prototype som var et PSA-verktøy som gjorde alt et PSA-verktøy skal gjøre. Eller, i det minste var det slik det så ut på overflaten.
Den siste setningen er viktig, og Michael understreker det tydelig. Prototypen var begynnelsen på arbeidet, ikke slutten. Månedene siden har omfattet en fullstack-utvikler som har håndtert sikkerhet, fakturering og den dypere arkitekturen. Erfarne teknologidirektører har gjennomgått koden og fungerer som rådgivere. Produktet har nylig bestått CASA Tier 2, en tredjeparts sikkerhetsverifisering.
«Det finnes selvfølgelig fortsatt feil. Så ideen om at du bare skal vibekode et PSA-verktøy, er rett og slett tøv.»
Ideen om at du bare skal vibekode et PSA-verktøy, er rett og slett tøv.
Så hvis kunstig intelligens ikke bygget produktet hans, hva gjorde den da? «Jeg kunne aldri ha utformet dette med penn og papir.»
Dette er oversettelseslaget som forsvinner. Michael kunne ikke ha skrevet en spesifikasjon eller laget en skisse av brukeropplevelsen. For ti år siden ville det ha vært slutten på historien: Ideen forblir fanget i hodet til praktikeren, slik grunnleggerideer har dødd stille inne i prosjektledere for alltid. I stedet lot kunstig intelligens ham tenke visuelt og iterativt, og bearbeide en prototype helt til femten års oppsamlet erfaring og frustrasjon som sluttbruker tok form foran ham. Noe han kunne reagere på, videreutvikle og overlevere til faktiske utviklere.
Han kaller den nåværende arbeidsflyten sin «en svært strukturert versjon av vibekoding», der han håndterer mindre rettelser og funksjonsendringer «innenfor tekniske personers mandat og styring».
"Det har vært fantastisk at en ikke-teknisk gründer i en oppstartsbedrift faktisk kan fortsette å drive produktet fremover. Men forbeholdet er at jeg måtte samarbeide med personer som var mer teknisk kyndige enn meg selv."
Var det PM-ferdighetene hele tiden?
Jeg skrev nylig om prosjektledelse som et entreprenørielt ferdighetssett, så jeg stilte Michael spørsmålet direkte: Er PM-er bedre rustet til å bli gründere enn personer med annen bakgrunn?
Han var enig i deler av det. PM-er har «større tilbøyelighet til å håndtere stress», sa han. De bytter konstant kontekst og balanserer samtidige prioriteringer, mens andre fagområder kan fokusere på én ting. Og helt avgjørende definerer de sitt eget arbeid: «En PM gir en grafisk designer en oppgave for dagen, mens en PM må finne ut hva den oppgaven er. Og det er entreprenørskap.»
Men så snudde han premisset mitt på hodet.
«Jeg tror at det var fordi jeg var gründer tidlig, og at det var derfor jeg var god på prosjektledelse. Ikke at prosjektledelse har utviklet gründerferdighetene mine. Jeg tror jeg alltid har vært gründer, og det er derfor prosjektledelse passet meg så naturlig.»
Jeg tror jeg alltid har vært gründer, og det er derfor prosjektledelse passet meg så naturlig.
Med andre ord går årsakssammenhengen motsatt vei. Prosjektledelse gjorde ham ikke til gründer. Det å være en gründertype gjorde ham til en god prosjektleder, og yrket ble et komfortabelt sted for denne energien å utfolde seg, mens den egentlige barrieren – å bygge selve løsningen – forble for høy.
Jeg vil vedde på at Michael ikke er et særtilfelle. Hvor mange fagfolk har et tiår med oppsamlet frustrasjon over verktøyene de bruker hver dag, uten mulighet til å gjøre det om til noe annet enn funksjonsforespørsler? Mennesker som liker å eie resultater, definere arbeidet og ha hele systemet i hodet. Mennesker som vet nøyaktig hva som er galt med programvaren deres, og som inntil nylig ikke hadde noen måte å vise andre hvordan det riktige burde se ut på.
For denne gruppen endret de siste to årene spillereglene. Ikke fordi AI gjorde prosjektledere til gründere, men fordi teknologien fjernet den siste unnskyldningen for dem som allerede var det.
Hvis du vil vite mer om hva Michael og teamet hans har jobbet med, kan du se nærmere på det her.
—--------
Vil du ha flere innsikter som dette? Opprett en gratis DPM-konto for å høre fra flere eksperter som disse.
