Rooli: Tuote- ja projektipäällikkö / Prototyypitys
Tuote lyhyesti
GTFS Manager on joukkoliikenneoperaattoreille suunnattu SaaS-palvelu, joka digitalisoi bussiliikenteen koko operatiivisen ketjun. Järjestelmä integroituu ulkoisiin palveluihin kuten OSRM (reititys), Digitransit, Digiroad ja Google-rajapinnat, sekä tuottaa GTFS-standardin mukaista reaaliaikadataa, jota reittioppaat kuten Google Maps ja Apple Maps kuluttavat.
Toiminnallisesti tuote kattaa reittisuunnittelun karttapohjaisella editorilla, aikataulujen luonnin kalentereineen ja kausivaihteluineen, GTFS-datan validoinnin ja julkaisun, ajoneuvojen blokkauksen (optimointi pienimmällä mahdollisella kalustomäärällä), kuljettajien vuorosuunnittelun EU-ajoaika-asetuksen ja TES-sopimusten rajoitteiden mukaisesti, sekä päivittäisten poikkeustilanteiden hallinnan.
Tuotepäällikön perinteinen ongelma
Jokainen tuotepäällikkö tunnistaa saman kaavan. Sinulla on selkeä visio siitä, miten ominaisuuden pitäisi toimia. Kirjoitat speksin, piirrät Figmassa wireframet, esittelet ne tiimille. Sitten alkaa dilutoituminen.
Vision dilutoituminen. Speksi on aina tulkinnanvarainen. Kehittäjä lukee saman dokumentin eri tavalla kuin tuotepäällikkö tarkoitti. Reunatapaukset, joita ei kirjoitettu auki, ratkaistaan kehityksen aikana ad hoc — usein eri tavalla kuin tuotepäällikkö olisi valinnut. Lopputulos on 80% oikein, mutta se viimeinen 20% vie suhteettomasti aikaa korjausiteraatioissa.
Kontekstin siirron häviö. Tuotepäällikkö kantaa päässään kokonaiskuvaa: toimialalogiikat, käyttäjien todelliset työnkulut, ominaisuuksien väliset riippuvuudet, regulaation reunaehdot. Tämä konteksti ei siirry speksiin eikä Jira-tikettiin. Kehittäjä näkee yksittäisen ominaisuuden — ei sitä miksi se on juuri sellainen. Tulos: teknisesti toimivaa, mutta tuotteellisesti väärin painotettua työtä.
Figma-prototyypityksen rajat. Figma on loistava visuaaliseen suunnitteluun, mutta se ei validoi logiikkaa. Figma-proto ei kerro, toimiiko aikataulun kalenterisääntö oikein poikkeuspäivinä. Se ei näytä, mitä tapahtuu kun kuljettajan kumulatiiviset tunnit ylittävät EU-rajan keskellä viikkoa. Se ei simuloi, miten ajoneuvojen blokkaus muuttuu kun yksi vuoro poistetaan. Staattiset ruudut eivät paljasta dynaamisen järjestelmän ongelmia.
Aikataulu ja iteraationopeus. Perinteisessä mallissa yksi ominaisuus kulkee speksi → wireframe → suunnittelu → kehitys → testaus → palaute → korjaus -ketjun läpi viikkojen aikana. Jos perustavanlaatuinen ongelma paljastuu vasta kehitysvaiheessa — väärä tietomalli, puuttuva logiikka, käyttöliittymän toimimattomuus oikealla datalla — ollaan viikkoja myöhässä.
Mitä tein toisin
Prototyypitin tekoälyavusteisesti jokaisen tuotteen ominaisuuden toimivaksi ja testattavaksi versioksi. Ei wireframeja — toimivia sovelluksia. Reittisuunnittelun karttaeditori, aikataulujen luonti kalenterisääntöineen, kuljettajien vuorosuunnittelu lakisääteisine rajoitteineen, GTFS-export ja -validointi — kaikki prototyypitettiin pisteeseen, jossa ominaisuutta pystyi käyttämään oikealla datalla ja näkemään, miten se käyttäytyy reunatapauksissa.
Tämä muutti koko dynamiikan:
Visio ei dilutoidu, koska kehittäjä ei tulkitse dokumenttia — hän käyttää toimivaa prototyyppiä. Jokainen interaktio, jokainen reunatapaus, jokainen virheilmoitus on jo määritelty konkreettisesti.
Konteksti siirtyy tuotteen mukana. Prototyyppi kantaa sisällään sen toimialalogiiikan, jonka tuotepäällikkö ymmärtää mutta jota on vaikea kirjoittaa auki. Kehittäjä näkee miten EU-ajoaikasääntö vaikuttaa vuorosuunnitteluun, koska hän voi kokeilla sitä — ei siksi, että se olisi kuvattu tikettiin.
Validointi tapahtuu ennen kehitystä. Kun prototyyppiä testaa oikealla datalla, perustavanlaatuiset ongelmat paljastuvat päivissä, eivät sprintin lopussa. Väärä tietomalli? Näkyy heti. Käyttöliittymä ei toimi kymmenen reitin datamäärällä? Näkyy heti.
Kehittäjien rooli selkeytyy. Kehittäjät eivät ole enää speksin tulkitsijoita, vaan arkkitehtuurin ja laadun varmistajia. He saavat toimivan toteutuksen, jonka pohjalta heidän tehtävänään on varmistaa tietoturva, testikattavuus, skaalautuvuus ja tuotantokelpoisuus. Tämä on se työ, jossa ammattikehittäjät ovat parhaimmillaan.
Tulos
Kokonainen SaaS-tuote suunniteltiin, prototyypitettiin ja vietiin tuotantoon tavalla, joka perinteisesti olisi vaatinut erillisen suunnittelutiimin, pidemmän aikataulun ja huomattavasti enemmän korjausiteraatioita. Tuotepäällikön suurin haaste — vision siirtäminen muuttumattomana ideasta valmiiksi tuotteeksi — ratkaistiin sillä, että visio ei koskaan ollut pelkkä dokumentti. Se oli aina toimiva sovellus.