Usein kuulee sanottavan, että tuotepäällikön pitäisi olla ongelmanratkaisija, ja että ongelmanratkaisukyvyt ovat tärkeä taito tuotepäällikön tai omistajan roolissa. Tämä on hiukan vaarallinen tapa ajatella. En tarkoita, etteikö ongelmanratkaisun ajattelutavat olisi arvokkaita. Mutta on vaarallista ajatella, että tuotepäällikkö tai -omistaja on ainoana henkilönä pääosassa ongelmien ratkaisemisessa.

Mitä tarkoitan tällä? Yksi itselleni arvokas mantra on seuraava: “Asiakkailla on ongelmia, meillä on ratkaisuja.” 

Tämä mantra sisältää muutaman viestin:

• Älä hyväksy asiakkaalta tulevaa ratkaisuehdotusta tai pyyntöä. Sen sijaan, haastattele ja ymmärrä ongelma, mikä pitäisi ratkaista.
• Backlogin pitäisi sisältää ongelman kuvauksia, priorisoituna oikeaan järjestykseen.
• Ratkaisu tulee tiimiltä, ei tuoteomistajalta.

Ymmärrä – älä ratkaise

Tuotepäällikön pitäisi ennemminkin olla ongelman ymmärtämisen ekspertti, ongelmanratkaisun sijasta. Tuotepäällikölle tärkeää on ymmärtää ongelma, osata arvioida sen ratkaisemisen tärkeys, kiireellisyys ja arvo, ja auttaa sitten kehitystiimiä kehittämään ongelmaan paras ja siihen hetkeen sopivin ratkaisu.

Asiakkaat tai sidosryhmät pyytävät usein jotain spesifiä asiaa, joka on kuvattu suoraan ratkaisuna. Tämä ratkaisu on harvoin optimaalinen. Ongelma pitää ymmärtää ensin, ennen kuin siihen voi tehdä oikean ratkaisun. Einsteinkin sanoi “Jos olisi tunti aikaa ratkaista ongelma, miettisin 55 minuuttia ongelmaa, ja hakisin 5 minuuttia ratkaisua.”

Tuotepäällikön pitää ymmärtää ongelma nimenomaan asiakkaan tai käyttäjän näkökulmasta. 

• Miten tärkeä ja miten arvokas ongelman ratkaiseminen on? 
• Voiko ongelmaa kiertää? 
• Miten hankala ratkaisun tekeminen olisi? 
• Miten ongelma voidaan kirjoittaa ja kuvata, niin että sen kommunikointi on helpompaa? 
• Miksi ongelma pitäisi ratkaista juuri nyt? 
• Liittyykö tämän ongelman ratkaiseminen johonkin toiseen tehtävään työhön tai ongelmaan? 
• Sopiiko ongelman ratkaiseminen tuotteella tuotteen visioon?

Kysymyksiä ongelman ratkaisemiseen on paljon, ja yksi hyvä lista, joka auttaa tuotepäälliköitä tässä on John Cutlerin roadmap kysymyslista. Sen sijaan että tuotepäällikkö on ongelmanratkaisun asiantuntija, hänen pitäisi ennemminkin olla ongelman ymmärtämisen ja kuvaamisen asiantuntija. 

Priorisoi – älä ratkaise

Ongelman ymmärtäminen sisältää myös sen, miten ongelma sijoittuu prioriteettijärjestyksessä. Ongelmaa ja sen ratkaisua ei voi priorisoinnissa erottaa toisistaan. Prioriteetteihin vaikuttaa moni asia, mutta yksinkertaistetusti arvojärjestys on mahdollista sitten kun on ratkaisun arvo ja ratkaisun kustannus tiedossa. Kustannus on ohjelmistokehityksessä lähes aina arvio työmäärästä.

Kun ongelma on ymmärretty ja osataan kuvata ja kommunikoida oikein, eikä lähdetä millään tavalla sitä kuvaamisen yhteydessä ratkaisemaan, silloin luodaan tilaa luovalle ongelman ratkaisulle kehitystiimissä.

Parhaan ratkaisun valinnassa tuotepäällikkö on taas mukana. Hyvät kehitystiimit miettivät yhden sijasta useita mahdollisia ratkaisuja ongelmiin. Mikä näistä vaihtoehdoista sitten on paras, pitää yhdessä päättää. Tuotepäällikkö voi auttaa tiimiä valitsemaan parhaan ratkaisun osallistumalla arviointiin ja keskusteluun. Hän voi lisäksi kertoa, mikä kussakin ratkaisussa on hyvää ja mikä huonoa. 

Tarpeeksi hyvä voittaa täydellisen

Ongelmiin ei useinkaan ole täydellisiä ratkaisuja. Hyväkin ratkaisu ongelmaan saattaa tulevaisuudessa osoittautua parannusta kaipaavaksi. Tuotepäällikön kannattaakin olla “tämä on tarpeeksi hyvä ratkaisu juuri nyt” -ekspertti. Tarpeeksi hyvä on melkein aina parempi vaihtoehto kuin täydellinen. Se saadaan nopeammin tehdyksi ja tuotantoon, ja kun tulevaisuudessa opitaan lisää, voidaan tehdä vielä parempi ratkaisu. 

Jos tuotteen ensimmäinen release ei nolota, olet julkaissut liian myöhään – Reid Hoffman.