PM & PO – Kolmannen timantin metsästys: tekemisestä todellisen arvon tuottamiseen

Yksi tuotekehityksen merkittävimmistä tulevaisuuden trendeistä on painopisteen siirtyminen tekemisen tehokkuudesta tuotetun arvon mittaamiseen. Tekoäly nopeuttaa ohjelmistokehitystä, prototypointia ja suunnittelua niin merkittävästi, että yhä keskeisemmäksi kysymykseksi nousee, teemmekö ylipäätään oikeita asioita. Kun ratkaisuvaihtoehtojen rakentaminen muuttuu nopeammaksi ja halvemmaksi, organisaatioiden kilpailukyky riippuu entistä enemmän niiden kyvystä kokeilla, oppia ja tunnistaa, mitkä ratkaisut todella tuottavat asiakas- ja liiketoiminta-arvoa.

Tämä artikkeli pohjautuu 20.10.2026 Projektipäivillä pitämääni esitykseen PM & PO – Hunting the Third Diamond: From Counting Story Points to Measuring Real Value in the Age of AI.

Kun toteuttaminen nopeutuu, oikeiden päätösten merkitys kasvaa

Monen Product Managerin ja Product Ownerin työssä korostuvat edelleen backlogin priorisointi, story pointtien arviointi, tiekarttojen laatiminen ja kehityksen etenemisen seuranta. Ketterän kehityksen myötä olemme oppineet mittaamaan työn virtausta, läpimenoaikoja ja ennustettavuutta. Nämä ovat tärkeitä mittareita, mutta ne eivät vielä kerro, syntyykö tehdystä työstä todellista arvoa asiakkaalle.

Tekoäly haastaa tämän ajattelutavan entistä voimakkaammin. Kun AI pystyy kirjoittamaan käyttäjätarinoita, ohjelmoimaan, rakentamaan prototyyppejä ja analysoimaan palautetta, tehtyjen ominaisuuksien määrä menettää merkitystään onnistumisen mittarina. Toteuttamisen kustannusten pienentyessä niukaksi resurssiksi muodostuu kyky arvioida, mitä kannattaa rakentaa, mitä kokeilla seuraavaksi ja milloin kehittäminen kannattaa lopettaa.

Tämä muuttaa myös tuotejohtamisen luonnetta. Product Managerin ja Product Ownerin tehtävä ei ole enää ensisijaisesti varmistaa, että organisaatio saa mahdollisimman paljon asioita valmiiksi, vaan että se oppii mahdollisimman nopeasti, mitkä asiat ovat tekemisen arvoisia.

Tuplatimantista kolmanteen timanttiin

UK Design Councilin tunnettu Double Diamond -malli kuvaa innovaatioprosessia kahden timantin avulla. Ensimmäisessä timantissa tutkitaan ongelma-avaruutta ja pyritään ymmärtämään asiakkaan todellinen tarve. Toisessa timantissa etsitään vaihtoehtoisia ratkaisuja ja valitaan niistä lupaavimmat.

Design sprintit, UX-suunnittelu ja jatkuva discovery ovat auttaneet organisaatioita kehittämään näitä kyvykkyyksiä. Tekoäly nopeuttaa molempia vaiheita merkittävästi. Käyttäjähaastattelujen analysointi, vaihtoehtoisten ratkaisujen ideointi ja prototyyppien rakentaminen onnistuvat parhaimmillaan murto-osassa aikaisemmin tarvittavasta ajasta. Perinteisen viisipäiväisen Design Sprintin sijaan voidaan joissakin tilanteissa toteuttaa vastaava kokeilusykli jopa kahdessa päivässä.

Mutta mitä tapahtuu sen jälkeen, kun ratkaisu on valittu?

Tässä kohtaa tarvitaan kolmas timantti. [3] Sen tarkoituksena on varmistaa, että kehitystyön tulokset todella tuottavat arvoa käytössä. Kolmannessa timantissa toteutus ja validointi kulkevat rinnakkain. Jokainen uusi inkrementti tarjoaa mahdollisuuden mitata vaikutuksia, verrata tuloksia odotuksiin ja päättää, kannattaako valittua ratkaisua kehittää edelleen.

Toimitus ei siis ole oppimisen päätepiste, vaan uuden oppimissyklin alku.

Kokeiluista tulee tuotekehityksen keskeinen toimintatapa

Kun tekoäly alentaa kokeilujen kustannuksia, organisaatiot voivat tutkia samanaikaisesti useampia ratkaisuvaihtoehtoja. Tämä ei kuitenkaan automaattisesti tarkoita parempia tuotteita. Jos kokeilujen tavoitteita ja onnistumiskriteereitä ei määritellä etukäteen, tuloksena voi olla suuri määrä nopeasti rakennettuja ratkaisuja, joiden arvosta ei ole todellista näyttöä.

Strategyzerin testikortit [3] tarjoavat yksinkertaisen tavan tuoda kurinalaisuutta kokeiluihin. Ennen kokeilun aloittamista määritellään, mitä oletamme, miten oletuksen paikkansapitävyyttä testataan ja millainen tulos vahvistaisi oletuksen. Näin kokeilusta tulee tietoinen oppimistapahtuma eikä vain uusi tapa tuottaa ominaisuuksia.

Tekoäly voi auttaa vaihtoehtojen muodostamisessa, kokeilujen suunnittelussa ja tulosten analysoinnissa, mutta se ei korvaa todellista asiakaspalautetta. AI tuottama arvio siitä, että asiakkaat pitäisivät uudesta ratkaisusta, ei ole sama asia kuin oikeilta asiakkailta kerätty näyttö.

Google

Arvon mittaaminen edellyttää uusia mittareita

Story pointit ja velocity kuvaavat kehitystiimin työtä, mutta eivät tuotettua asiakasarvoa. Työn virtausta kuvaavat mittarit, kuten läpimenoaika ja keskeneräisen työn määrä, puolestaan kertovat kehitysprosessin tehokkuudesta. Todellisen arvon ymmärtämiseksi tarvitaan mittareita, jotka kuvaavat asiakkaan käyttäytymistä ja tuotteen liiketoiminnallisia vaikutuksia.

Yksi käyttökelpoinen viitekehys digitaalisten tuotteiden arvon mittaamiseen on Googlen Pirate metrics eli AARRR-malli [4], joka tarkastelee asiakkaan etenemistä tuotteen löytämisestä sen käyttöön, käytön jatkumiseen, liiketoiminta-arvon syntymiseen ja suositteluun.

Erityisen kiinnostava mittari on retention eli asiakaspysyvyys. Jos tuote tuottaa jatkuvaa arvoa, asiakkaat palaavat käyttämään sitä. Jos arvoa ei synny, käyttö vähenee ajan myötä. Siksi esimerkiksi kohorttikohtainen retention-analyysi voi kertoa tuotteen onnistumisesta enemmän kuin perinteinen asiakastyytyväisyyskysely.

Mittareiden valinnassa olennaista on kuitenkin ymmärtää, millaista käyttäytymisen muutosta tavoittelemme. Gojko Adzicin Impact Mapping tarjoaa tähän hyödyllisen lähestymistavan: ensin määritellään liiketoiminnallinen tavoite, sen jälkeen tunnistetaan toimijat ja tavoiteltavat käyttäytymismuutokset ja vasta lopuksi päätetään, mitä ominaisuuksia tarvitaan.

Jos kehitysjonossa olevaa ominaisuutta ei pystytä yhdistämään tavoiteltuun vaikutukseen, on perusteltua kysyä, miksi sitä ollaan rakentamassa.

Product Managerin ja Product Ownerin roolit muuttuvat

Kolmannen timantin ajattelu muuttaa myös tuotekehityksen rooleja. Product Managerin tehtävänä on tunnistaa arvokkaimmat mahdollisuudet ja tehdä päätöksiä siitä, mihin organisaation kannattaa investoida. Product Owner puolestaan auttaa muuttamaan nämä valinnat mahdollisimman nopeasti oppimiseksi ja konkreettisiksi toimituksiksi.

UX-suunnittelun tehtävänä on varmistaa, että ratkaisut vastaavat todellisiin käyttäjätarpeisiin, kun taas arkkitehtuurin on mahdollistettava nopea ja turvallinen kokeileminen. Arvo ei synny yksittäisen roolin työn tuloksena, vaan näiden kyvykkyyksien yhteistyöstä.

Tekoälyn myötä yhteistyön merkitys korostuu entisestään. Kun suunnittelu, prototypointi ja toteutus nopeutuvat, perinteiset tehtävien siirrot roolilta toiselle voivat muodostua kehityksen pullonkauloiksi. Esimerkiksi MobAI®-työskentelyssä eri osaajat kehittävät ratkaisua yhdessä tekoälyn kanssa, jolloin tarkennukset, suunnitteluratkaisut ja päätökset voidaan tehdä osana samaa työskentelyvirtaa.

Samalla myös suunnittelun painopiste muuttuu. AI voi valmistella suunnitelmia, analysoida riippuvuuksia ja auttaa arvioimaan vaihtoehtoja, mutta ihmisten tehtäväksi jää edelleen tavoitteiden yhteensovittaminen, päätösten tekeminen ja yhteiseen lopputulokseen sitoutuminen.

Kolmannen timantin metsästys on jatkuvaa päätöksentekoa

Tulevaisuuden tuote- ja portfolionhallinnassa korostuu kyky ohjata investointeja kokeiluista saadun tiedon perusteella. Sen sijaan, että organisaatio sitoutuu pitkäjänteisesti ennalta määriteltyyn ominaisuuslistaan, se määrittelee tavoiteltavat vaikutukset ja antaa tiimeille mahdollisuuden etsiä parhaita keinoja niiden saavuttamiseksi.

OKR-ajattelu tukee tätä muutosta. Product Manager määrittelee tavoitteen ja sille mitattavat avaintulokset, kun taas tiimit suunnittelevat kokeiluja, joiden avulla näitä tuloksia pyritään saavuttamaan. Kehityksen onnistumista ei arvioida pelkästään valmistuneiden ominaisuuksien perusteella, vaan sen mukaan, ovatko tavoitellut vaikutukset toteutuneet.

Jokaisessa merkittävässä päätöspisteessä pitäisi pystyä vastaamaan siihen, mitä odotimme tapahtuvan, mitä asiakkaat todella tekivät ja mitä opimme. Tämän perusteella päätetään, jatketaanko kehittämistä, muutetaanko suuntaa, skaalataanko ratkaisua vai lopetetaanko työ kokonaan.

Tämä edellyttää myös uudenlaista johtamiskulttuuria. Kokeilun lopettaminen ei saa näyttäytyä epäonnistumisena, jos sen perusteella on saatu luotettavaa tietoa siitä, ettei ratkaisu tuota odotettua arvoa. Päinvastoin, ajoissa tehty lopettamispäätös voi säästää huomattavia investointeja ja vapauttaa kapasiteettia arvokkaampiin mahdollisuuksiin.

AI-aikakaudella tärkeintä ei ole tekemisen määrä

Tekoäly mahdollistaa yhä useampien ratkaisujen rakentamisen yhä lyhyemmässä ajassa. Tämä tekee tuotekehityksestä nopeampaa, mutta ei automaattisesti vaikuttavampaa. Jos organisaatio jatkaa onnistumisen mittaamista ensisijaisesti tuotosten määrällä, tekoäly voi pahimmillaan vain kiihdyttää väärien asioiden tekemistä.

Kolmannen timantin ajattelu tarjoaa tähän vaihtoehdon. Tuotekehityksen tehtäväksi muodostuu jatkuva arvon etsiminen, kokeileminen ja todentaminen. Product Managerin ja Product Ownerin tärkein yhteinen vastuu on varmistaa, että organisaatio oppii tekemistään investoinneista ja pystyy muuttamaan suuntaansa uuden tiedon perusteella.

Lopulta kolmannen timantin metsästyksessä ei ole kysymys siitä, että oikea ratkaisu löydettäisiin aina ensimmäisellä yrittämällä. Kysymys on organisaation kyvystä tunnistaa mahdollisimman nopeasti, mitkä ratkaisut tuottavat arvoa ja mitkä eivät.

Kun tekoäly tekee kokeilemisesta halpaa, rohkeudesta lopettaa väärän ratkaisun etsiminen tulee entistä arvokkaampaa.

‍

[1] UK Design Council, Double Diamond, https://www.designcouncil.org.uk/resources/the-double-diamond/

[2] UK Design Council, Integrating service design, systems thinking and complexity into systemic design https://www.launchnotes.com/blog/the-triple-diamond-design-process-a-comprehensive-guide

[3] Strategyzer, Test Card https://www.strategyzer.com/library/validate-your-ideas-with-the-test-card

[4] Raj, AARRR, or “Pirate Metrics”, Medium https://medium.com/design-bootcamp/aarrr-or-pirate-metrics-5110836367bf

[5] Adzic, Impact Maping, https://gojko.net/books/impact-mapping/

[6] MobAI, https://www.wikiagile.com/fi/mobai

[7], OKRs, https://www.whatmatters.com/