Vibe-koodaus 101: Käytännön työpaja nollasta yhteen

Lue litterointi:

Kokeilemme podcastiemme litterointia ohjelmiston avulla. Antakaa anteeksi mahdolliset kirjoitusvirheet, sillä botti ei ole sataprosenttisen tarkka.

Hannah Clark: Selvä, kaikki. Jakson vastuuvapauslauseke: jos olet jo Vibe-koodauksen asiantuntija, tämä jakso ei ehkä ole sinua varten. Mutta jos olet kuullut Vibe-koodauksesta ja haluat tietää faktat myyteistä, ja olet utelias siitä, miten voit käyttää teknologiaa omien tavoitteidesi edistämiseen, tulet rakastamaan tätä.

Jos et ole seurannut uutiskirjeitämme, kuten niitä, joita voit tilata osoitteessa theproductmanager.com/subscribe, en ole pystynyt olemaan hiljaa mahtavasta käytännönläheisestä Vibe-koodauksen työpajasta, jonka järjestimme muutama viikko sitten Moves The Needlen pääasiallisena vetäjänä toimivan Drew Falkmanin kanssa. Tämä Product Manager Podcastin jakso on itse asiassa tallenne 30 minuutin seminaarista, jonka pidimme ennen siirtymistä live-prototyyppisessioon. Kuulet erittelyn siitä, mitä vibe-koodaus on ja mitä se ei ole, inspiroivia käyttötapauksia teknologialle sekä työkalusuosituksia, joiden avulla voit alkaa kokeilla ja löytää omia käyttötapauksiasi. Aloitetaan.

Ai niin, käymme tällaisia keskusteluja joka viikko. Jos tämä kuulostaa kiinnostavalta, mikset tilaisi podcastia? Hyvä on, aloitetaan.

Olen Hannah Clark. Jos et tunne minua, olen The CPO Clubin vastaava päätoimittaja ja The CPO Clubin podcastin juontaja. Kanssani on toinen juontajani Katie.

Katie Sanders: Hei kaikille, olen Katie Sanders. Olen The CTO Clubin vastaava päätoimittaja. Ehkä myös The QA Leadin. Jotkut sivustoista yhdistettiin. Olen siis innoissani. Tämä on ensimmäinen työpajani, ja olen todella innoissani siitä, että teen tämän Hannahin kanssa, koska tuotteiden ja teknologiajohtajien välillä on paljon yhteistä. On siis hienoa tutustua kaikkiin. Tervetuloa!

Hannah Clark: Olen todella innoissani yhteistyöstä Katien kanssa. Jos et vielä seuraa häntä LinkedInissä, etsi Katie Sanders. Hän on todella kova tekijä. Hänellä on loistavaa sisältöä, joten olen aidosti innoissani siitä, että pääsette tutustumaan toisiinne.

Haluan esitellä myös vierailevan puhujamme. Täällä on Drew Falkman. Drew on tuotejohtaja, neuvonantaja ja kouluttaja, joka keskittyy esisiemen- ja siemenvaiheen yritysten tuotestrategiaan. Hän on tehostanut alkuvaiheen tiimejä ja optimoinut tuotteiden markkinasopivuutta.

Hän on tehnyt kaikkea. Hän on julkaisumme hyvä ystävä ja työskennellyt kanssamme valtavasti. Hän on työskennellyt myös paljon kanssani, mikä kertoo, että hän on erittäin kärsivällinen mies. Olette siis tänään hyvissä käsissä. Hänellä on myös paljon kokemusta verkko-, mobiili-, lohkoketju- ja tekoälytuotteista. Meillä on siis täällä mahtava asiantuntija.

Drew, haluatko tervehtiä mukavia kuulijoitamme?

Drew Falkman: Hei kaikille, olen todella innoissani täällä olemisesta. Tästä tulee hauskaa.

Hannah Clark: Aloitamme myyttien kumoamisella. Esitän ensimmäisen kysymyksen, ja sen jälkeen ihana kanssajuontajani Katie käy läpi muutamia myyttejä ja Drew kumoaa ne. Aloitetaan taustoittamalla aihetta.

Vaikuttaa siltä, että kaikki puhuvat nyt vibe-koodauksesta ja se tulee vastaan jokaisessa LinkedIn-julkaisussa, myös monissa omissani. Ihmiset vaikuttavat joko erittäin innostuneilta, hyvin peloissaan tai todella hämmentyneiltä. Puhutaan siis siitä, miksi vibe-koodaus on niin suosittua. Miksi se on juuri nyt niin tärkeää? Pureudutaan siihen liittyvään myyttiin.

Katie Sanders: Selvä, ensimmäinen myytti: vibe-koodaus korvaa insinöörit. Yleisesti tekoälyn sanotaan korvaavan kaikkien työt. Sanoisin, että tämä on myytti. Se ehkä muuttaa insinöörin työtä ja tuottaa sovellusvalmista koodia, mutta se ei todellakaan korvaa insinöörin työtä kokonaan.

Kuten aina tekoälyn kanssa, ihminen on pidettävä mukana prosessissa. Sanoisin siis, ettei mitään julkaista ilman ihmisen silmiä, joten voimme kumota tämän myytin.

Hannah Clark: Drew, haluatko lisätä tähän jotain?

Drew Falkman: Kyllä. Insinöörinä kannattaa tiedostaa, että tämä on asia, joka on tulossa väistämättä eteen.

Se voi vain nopeuttaa prosessiasi. Suunnittelijoilla, tuotepäälliköillä ja ei-teknisillä perustajilla on nyt mahdollisuus luoda vähimmäisratkaisuja, prototyyppejä, validoida niitä ja tehdä muita asioita ennen niiden luovuttamista insinööreille. Kun haluat päästä tuotantotasoiseen koodiin, yleensä vähimmäisratkaisua pidemmälle, tarvitaan kuitenkin insinöörejä.

Nykyään koodikatselmuksia täytyy ehdottomasti tehdä ja kaikki käydä läpi varmistaakseen, että kokonaisuus on viimeistelty, erityisesti jos mukana on vaatimustenmukaisuuteen liittyviä ongelmia tai muuta, mikä pitää ottaa huomioon.

Hannah Clark: Siirrytään toiseen myyttiin. Jotkut sanovat, että vibe-koodaus on kehityssyklin ulkopuolinen maailma.

Toisin sanoen, jos rakennat jotain vibe-koodaussovelluksessa, se ei ole oikeasti käyttökelpoista ja se pitää rakentaa kokonaan uudelleen alusta asti kehittäjän toimesta, joka kirjoittaa kaiken koodin käsin. Drew, pitääkö tämä todella paikkansa?

Drew Falkman: Työkalut ovat kehittyneet valtavasti, ja tilanne muuttuu kirjaimellisesti joka päivä.

Claude julkaisi juuri viime kuussa uuden version koodin generoinnistaan, ja se on paljon parempi kuin ennen. Se kehittyy jatkuvasti. Kuten kaikki generatiivisen tekoälyn sovellukset, se voi hallusinoida, tehdä hupsuja asioita ja tuottaa odottamattomia tuloksia. Se voi kuitenkin olla osa kehityssykliä, ja sen avulla voi todella luoda tällaisia koodiosia.

Ne voidaan luovuttaa insinööreille, mutta on tärkeää tiedostaa, että niitä todennäköisesti täytyy muokata. Joitakin komponentteja voi joutua käyttämään uudelleen, ja uskon, että jotkut insinöörit saattavat yllättyä siitä, kuinka hyvää koodi todellisuudessa on.

Hannah Clark: Toinen paljon kuulemani myytti on, ettei vibe-koodaustyökalun rakentamiseen tarvita PRD:tä tai tuotestrategiaa.

Drew, Katie, mitä ajatuksia tämä herättää?

Drew Falkman: Kuule, aina pitää ajatella. Joskus ihmiset ajattelevat, että vibe-koodatessaan he voivat vain avata työkalun ja saada sovelluksen valmiiksi huomenna. Kuten missä tahansa muussakin, ilman ennakkosuunnittelua lopputulos ei ole sitä mitä haluat. Pitää miettiä, kuka yleisösi ja kohdemarkkinasi ovat.

Pitää miettiä arvolupausta sekä sitä, mitkä sovelluksen ydinominaisuudet ja kulut tulevat olemaan. Kannattaa siis käyttää aikaa jonkinlaisen suunnitelman tekemiseen. Vibe-koodauksen hienous on se, ettei tarvitse luoda 5–10-sivuista PRD:tä, jossa määritellään käytettävä teknologia ja kuvataan kaikki kulut kaavioineen.

Sitä ei tarvitse tehdä. Riittää, että hahmottelet visiosi ja sen, mitä olet rakentamassa. Olen itse asiassa kehittänyt pienen vibe-PRD:n. Se on yhden tai kahden sivun mittainen, ja se on tarkoitettu sinulle sekä kaikille muille yhteistyökumppaneillesi, jotta olette samalla sivulla ja lähestytte työtä järjestelmällisesti.

Näin koodisi on pitkällä aikavälillä siistimpää.

Hannah Clark: Hyvä tietää. Siirrytään seuraavaan myyttiin, joka koskee tarkasti säänneltyjä toimialoja. Katie edustaa CTO Clubia, joten haluatko ottaa tämän myytin käsittelyyn?

Katie Sanders: Kyllä. Haluan nostaa esiin vielä yhden asian: tämä ei ole uutta, vaikka ihmiset sanovatkin, että olemme koodanneet vibellä jo vuosia.

Emme vain kutsuneet sitä aiemmin sillä nimellä. Olemme kopioineet ja liittäneet koodia GitHubista, Redditistä tai Hacker Newsista. Hyvät insinöörit ratkaisevat ongelmia: he etsivät, tunnistavat malleja, mukauttavat ja rakentavat. Uskon siis, että tämä kehote on vain seuraava kehitysaskel jossain, mikä on aina ollut olemassa. Hannah, mikä oli toinen myytti, jonka halusit kumota?

Hannah Clark: Se, ettei tarkasti säännellyllä toimialalla voisi käyttää vibe-koodausta. Että se ei olisi turvallista.

Katie Sanders: Kun ajattelemme terveydenhuoltoa tai rahoitusalaa, kyseessä on selvästi tarkasti säännelty toimiala. Kuten millä tahansa muullakin alalla, pitää varmistaa HIPAA-vaatimustenmukaisuus ja kaikki muut vastaavat asiat.

Tiedän, että suuret kielimallit voivat joskus hakea tietoja. On siis tärkeää huomioida toimialan vaatimustenmukaisuuteen liittyvät asiat. Terveydenhuollossa, rahoituksessa ja vastaavilla aloilla tarvitaan kuitenkin hieman ylimääräisiä suojakaiteita.

Hannah Clark: Se on mielestäni vähän kuin monet muutkin kehitysprosessit: vibe-koodaustyökalut eivät korvaa henkilöstöä.

Ne ovat vain apuvälineitä, jotka nopeuttavat kehityssykliä. Perusteellinen koodikatselmusprosessi on kuitenkin todennäköisesti tärkeämpi kuin koskaan nyt, kun ulkoistamme osan tästä työstä. Puhutaan hieman käyttötapauksista. On hauska tutkia muutamia eri tapoja, joilla ihmiset käyttävät vibe-koodausta tehokkaasti juuri nyt.

Katie vetää tämän osion ja käy läpi muutamia kiinnostavia käyttötapauksia.

Katie Sanders: Poimin monet näistä alun perin Redditistä, kun vibe-koodaus alkoi yleistyä. Halusin nähdä tosielämän esimerkkejä. Kaikki puhuivat siitä, mutta en oikeastaan nähnyt mitään onnistunutta.

Kirjoitin aiheesta artikkelin. Yksi esimerkeistä oli henkilö, joka rakensi eräänlaisen jalkapallo-otteluiden järjestäjän, siis hyvin rajatun jalkapallopelien järjestelysovelluksen omaksi harrastuksekseen. Hän ei ollut kehittäjä, mutta ymmärsi pinon sovellusten toimintaa ja oli aina joutunut palkkaamaan kehittäjiä toteuttamaan ideansa.

Kun hän alkoi kokeilla Lovablea, Cursoria ja muita vastaavia työkaluja, hän rakensi tämän rajatun jalkapallosovelluksen viikoittaisten peliensä järjestämiseen ja julkaisi sen onnistuneesti. Hän julkaisi muutamassa viikossa kannattavasti sata riviä tekoälyn tuottamaa sovellusta. Taisi olla niin, että se toi noin 700 dollaria viikossa tai jotain vastaavaa.

Toinen esimerkki oli Workaid, joka on tekoälyn tehostama pelillistetty tehtävienhallinta. Se mullistaa tehtävälistan ja tekee työnteosta pelin kaltaista. Nämä olivat muutamia onnistuneita esimerkkejä, jotka poimin Redditistä, ja voimme linkittää teidät kyseiseen Reddit-julkaisuun.

Esimerkkejä oli muutamia lisää. Uskon, että monet tulevat vain kokeilemaan tätä, mutta jotkut onnistuvat sen avulla todella hyvin. On hienoa nähdä se.

Hannah Clark: Todella hieno esimerkki. Halusin vain nopeasti keskeyttää, koska Katya esitti hyvän kysymyksen.

Katya kysyy: ”Mietin, pitääkö minun projektipäällikkönä edelleen luoda käyttöliittymän rautalankamalleja ja mallikuvia? Voisin vain luoda sen vibe-koodaamalla, ja kehittäjät voisivat käyttää käyttöliittymääni oman kehityksensä lähtökohtana.”

Drew Falkman: Kyllä, sataprosenttisesti. Itse asiassa sanoisin, että useimmilla näistä työkaluista olisi vaikeampaa yrittää toteuttaa olemassa oleva design vibe-koodaamalla.

Näyttöjen tuominen työkaluun ja kaiken muun tekeminen on vaikeaa. On itse asiassa helpompaa määritellä kokonaisuus ja työskennellä generatiivisen tekoälyn kanssa ulkoasun ja käyttötuntuman saamiseksi kohdalleen. Sen jälkeen voit luovuttaa sen kehittäjille, jotka voivat varmistaa, että se noudattaa käytössä olevaa suunnittelujärjestelmää tai muita vaatimuksia.

Hannah Clark: Kiitos, että vastasit siihen, Drew. Anteeksi, Katie, että keskeytin. Haluatko palata käyttötapauksiin? Sinulla taisi olla vielä pari esimerkkiä.

Katie Sanders: Michael, haluatko kertoa käyttötapauksesta, jonka joku yrityksessämme loi? Hän rakensi irtisanomisten vaikutusten analysointityökalun. Michael, haluatko jakaa sen hyvänä esimerkkinä?

Michael Mordak: Toki. Tämä on loistava esimerkki. Yksi kollegoistamme työskentelee henkilöstöhallinnon julkaisussa ja halusi rakentaa työkalun, jolla ihmiset voisivat analysoida suunnitellun irtisanomisen vaikutuksia.

Hän koodasi sen niin, että työkalun käyttäjien täytyy täyttää kysely etukäteen. Näin hän kerää tietoja käyttäjistä, mikä oli hänen oma tavoitteensa. Kun kysely on täytetty, sovellus vie käyttäjän laskuriin.

Siihen on rakennettu muutamia esimerkkejä. Jos työskentelet esimerkiksi tuotantoyrityksessä ja suunnittelet 200 työntekijän irtisanomista, voit valita tämän esimerkin nähdäksesi, miten työkalu toimii.

Syötät erilaisia tietoja ja vastaat esimerkiksi siihen, kuinka paljon osaamista näillä ihmisillä on ja kuinka kauan jonkun kouluttaminen tähän tehtävään kestäisi. Sen jälkeen voit laskea irtisanomisen vaikutuksen, ja työkalu kertoo tarkasti, millaisia seurauksia sillä olisi.

Tämä olisi hyvä työkalu henkilöstöhallinnon työntekijöille, jotka suunnittelevat irtisanomisia. Hän tarjoaa sen ilmaiseksi kaikille, jotka haluavat kokeilla sitä ja antaa palautetta. Tämä on siis yksi esimerkki omasta tiimistämme. Toinen esimerkki on kyselytyökalu, jota juuri käytimme. Koodasin sen itse.

Minulla ei ole lainkaan tai on hyvin vähän koodauskokemusta. Rakensin tämän kyselysovelluksen, jotta voisimme kerätä liveyleisön äänet ja näyttää tulokset ilman, että meidän täytyisi maksaa palvelusta. Usein sovelluksissa on tällainen ominaisuus, mutta siitä joutuu maksamaan ja samalla maksaa kaikista muista ominaisuuksista, joita ei oikeastaan käytä.

Minua kiinnostaa vain kyselyominaisuus, joten rakensin työkalun, jolla voin luoda omia kyselyitä. Voin antaa niille minkä tahansa nimen ja lisätä niin monta vaihtoehtoa kuin haluan. Voin esikatsella kyselyn ennen sen julkaisemista ja käynnistää tai poistaa sen täältä.

Tältä kyselyt näkyvät näytöllä. Te äänestätte luomassani sovelluksessa. En kerää teistä tietoja, ei huolta. Kaikki tapahtuu tässä sovelluksessa. Tulokset näkyivät siis tuolla. Tein tämän nopeasti. Työskentelin sen parissa noin 30 minuuttia ennen tätä puhelua, mutta kokonaisuudessaan sen rakentaminen ja mielestäni hyvän brändi-ilmeen lisääminen vei ehkä yhdestä kahteen tuntia.

En kuitenkaan ole suunnittelija, joten älkää ottako minulta suunnitteluvinkkejä.

Katie Sanders: Olemme puhuneet hyödyistä. Jotkut kokeilevat tätä ja ajattelevat, etteivät enää koskaan tarvitse teknistä henkilöä. Eräs esimerkki on Leo Junior.

Hänen julkaisunsa levisi viraaliksi X:ssä. Hän on Enrich Leadin perustaja. Työkalu kerää IP-osoitteita ja käyttää suurta kielimallia myyntiliidien tuottamiseen. Hän rakensi koko sovelluksen Cursorilla ja sanoi ylpeänä, ettei siinä ollut lainkaan käsin kirjoitettua koodia: tekoäly on rakentaja. Sitä voi valittaa tai voi alkaa rakentaa. Puhe oli siis hyvin itsevarmaa, mutta vaatimattomuus puuttui.

Internet päätti tietenkin ryhtyä vastahyökkäykseen. 48 tunnin sisällä hakkerit ottivat sovelluksen haltuunsa, tilaukset ohitettiin ja kustannukset räjähtivät. Suuri kielimalli alkoi hallusinoida liiditietoja tyhjästä. Leon täytyi julkaista Twitterissä hätäviesti: ”Minun kimppuuni hyökätään. Satunnaisia asioita tapahtuu.”

Hän ei ollut tekninen henkilö, joten asioiden selvittäminen kesti tavallista kauemmin. Nyt hän opettelee koodaamaan kantapään kautta. Opetus on siis jälleen se, että ihminen pitää aina olla mukana prosessissa. Ei-teknisenä henkilönä on hauska kokeilla näitä työkaluja, mutta teknisen henkilön täytyy aina tarkistaa koodi.

Hannah Clark: Michael, haluatko kertoa lyhyesti, millainen oppimiskäyrä sinulla oli, kun aloitit näiden työkalujen kokeilemisen?

Michael Mordak: Toki. Kuten sanoin, koodausosaamiseni on hyvin rajallista. Näen joskus tilanteita, joissa ihmiset sanovat olevansa ideaihmisiä. He eivät ole koskaan rakentaneet mitään aiemmin. Se kuvaa minua täydellisesti, koska mietin usein erilaisia tapoja tehostaa sisäisiä prosesseja tai tehdä asioita ilman kolmannen osapuolen sovelluksista maksamista, mutta niiden rakentaminen on vaikeaa.

Grand kysyi, millainen oppimiskäyrä käytännössä on. Tänään käytettävä työkalu on Lovable, ja sama pätee moniin muihin saatavilla oleviin sovelluksiin. Oppimiskäyrä on oikeastaan hyvin loiva. Se oli todella matala, koska kaikki perustuu tekstikehotteisiin.

Kuvaat tarkasti, mitä haluat nähdä, mikä sovelluksen rakentamisen tavoitteesi on ja millaisia lopputuloksia haluat. Sen jälkeen työkalu tuottaa esimerkkejä siitä, mitä se voisi rakentaa. Voit myös antaa lisätietoja.

Jos sinulla on jokin esikuva, voit kertoa sen. Tässä tapauksessa sanoin haluavani jotain Slido.comin kaltaista. Jos Slido on tuttu, se on kyselysovellus. Työkalu voi käyttää tosielämän esimerkkejä lähtökohtana, ja voit lisätä oman brändi-ilmeesi sekä muut vaatimukset, joita sovellukselta tarvitset.

Kun ensimmäinen versio on rakennettu, se ei ole vielä loppu. Voit jatkaa keskustelua työkalun kanssa. Siinä on keskustelutila, jossa voit esittää kysymyksiä ennen kuin se muuttaa koodia tai rakentaa mitään.

Minulle toimi myös se, että kun asiat menivät hieman oman osaamiseni ulkopuolelle, kopioin osan Lovablen vastauksista ChatGPT:hen ja pyysin sitä selittämään asian niin kuin olisin viisivuotias.

Se yksinkertaisti asiat minulle, joka en ymmärrä kaikkia teknisiä yksityiskohtia, ja selitti ne erittäin perusteellisesti. Prosessi oli siis hyvin sujuva ja tällaisen asian rakentamisen kokeileminen oli helppoa.

Hannah Clark: Tuo on todella hienoa. Toivon, että se rohkaisee niitä meistä, myös minua, jotka aloitamme aivan alusta.

Halusin nostaa esiin Talin kysymyksen ja esittää sen Drew’lle. Tal kysyy: ”Millainen työnkulku olisi mielestäsi hyvä olemassa oleville tuoteyrityksille? Olen startupissa työskentelevä projektipäällikkö. Meillä on suunnittelujärjestelmä ja toimiva, käyttäjien käytössä oleva tuote. Miten voisin käyttää vibe-koodausta tiettyihin ominaisuuksiin tai ideoihin?”

”Milloin asia palautettaisiin suunnitteluun, vai ohitettaisiinko suunnittelu ja siirryttäisiin suoraan kehitykseen?”

Drew Falkman: Uskon, että tämä työnkulku on tällä hetkellä täysin keskeneräinen. Parhaita käytäntöjä ei vielä ole. Tämä on edelleen villi länsi kaiken yhdistämisen osalta. Jos olisin yrityksessä, ohittaisin suunnitteluvaiheen, mutta koordinoisin suunnittelijan kanssa.

Tekisin oman vibe-PRD:ni ja kuvaisin siinä näytöt ja elementit. Suunnittelijoilta täytyy kuitenkin saada hyväksyntä. He voivat myös osallistua tähän yhteistyökumppaneina. Tätä ei tarvitse tehdä siilossa. Voimme kaikki tarkastella samaa projektia ja työskennellä sen parissa yhdessä.

Sen jälkeen loisin tuotoksen. En ole ainakaan kuullut maagisesta tavasta integroida suunnittelujärjestelmiä Lovableen. Jotkin muut työkalut, kuten Cursor, ovat tähän tarkoitukseen alemman tason työkaluja, koska niihin voi yhdistää keskustelut ja kaiken muun, mutta työskentely tapahtuu suoraan koodissa.

Kyse on integroidusta kehitysympäristöstä, ja usein täytyy ajaa komentorivikomentoja. Se on täysin ei-teknisille ihmisille hieman teknisempää, mutta mahdollistaa paremman koodin integroinnin ja vuorovaikutuksen. Se saattaa siis sopia tähän käyttötapaukseen paremmin.

Jos tekisin tämän Lovablella, se synkronoituisi kaksisuuntaisesti GitHubin kanssa. Yritän näyttää sen, jos meillä on tänään aikaa.

Voisit tehdä näytöstä version ja julkaista sen GitHubiin. Kehittäjät voisivat hakea sen, soveltaa kaikkia komponenttejaan ja suunnittelujärjestelmiään sekä työntää sen takaisin. Kun palaisit projektiin, sinun pitäisi nähdä kaikki muutokset ja niiden pitäisi ihannetapauksessa toimia hyvin.

Hannah Clark: Mahtavaa. Donald esittää tämän kysymyksen Drew’lle: ”Millaisia kokemuksia sinulla on vibe-koodauksesta, kun kyseessä on jokin toisen tehtävienhallinnan kaltainen ratkaisu verrattuna ainutlaatuiseen ideaan, kuten Google Trends -datan muuttamiseen äänimaisemaksi?”

Toisin sanoen, miten vibe-koodaus toimii, kun rakennetaan monien jo olemassa olevien ratkaisujen kaltainen versio verrattuna täysin uuteen, ennennäkemättömään ideaan?

Drew Falkman: Erinomainen kysymys. Kokemukseni prototyyppi- ja vibe-koodaustyökaluista on yleisesti se, että kaiken olemassa olevan rakentaminen on melko suoraviivaista. Työkalu ymmärtää sen. Tämän päivän oletusesimerkkimme on matkailusovellus. Se osaa tehdä matkailusovelluksia vaikka koko päivän.

Kun siirrytään Google Trends -datan äänimaisemaan, työstä tulee vaikeampaa. Jos tarvitaan hyvin räätälöityjä visualisointityökaluja tavallisten käyttöliittymäelementtien, kuten pudotusvalikoiden ja painikkeiden, sijaan, näiden työkalujen kanssa tulee todennäköisesti vaikeuksia, ainakin Lovablen nykyisessä versiossa.

Muut työkalut voivat tehdä tästä helpompaa, mutta tällä hetkellä tällaisissa tapauksissa täytyy ottaa mukaan asiantuntijoita ja työskennellä heidän kanssaan, jos rakennetaan jotain todella poikkeavaa.

Hannah Clark: Selvä. Aika alkaa loppua. Haluan kiittää valtavasti Katieta osallistumisesta ja tietenkin Drew’ta siitä, että hän oli näin mahtava tietolähde ja antoi aikaansa ja asiantuntemustaan.

Kiitos kuuntelusta. Saat lisää oivalluksia, käytännön oppaita ja työkaluarvosteluja tilaamalla uutiskirjeemme osoitteessa theproductmanager.com/subscribe. Voit kuunnella lisää tämän kaltaisia keskusteluja tilaamalla The CPO Clubin sieltä, mistä kuuntelet podcastisi.