Miten tuotepäällikkö voi antaa rakentavaa palautetta tiimille
Miten tuotepäällikkö voi antaa rakentavaa palautetta tiimille
Tuotepäällikön roolissa palaute on oleellinen osa jokapäiväistä työtä. Kun kuulen sanat palaute ja tuotepäällikkö, ensimmäinen ajatus on siinä, miten tuotepäällikkö kerää asiakkailta palautetta tuotteesta, ja muokkaa sen suunnitelmiksi roadmapille tai backlogille. Tästä asiasta on kirjoitettu paljon. Haluan kuitenkin tässä blogissa nostaa esiin hyviä tapoja antaa ja vastaanottaa palautetta nimenomaan tuotepäällikön ja kehitystiimin välillä. Palaute haastaa molemmat etsimään jatkuvasti parempia toimintatapoja, ja sen takia se on hyvin arvokasta tuotekehityksessä.
Ole varovainen monikulttuuritilanteissa
Eri kulttuureissa palautteen antamisen ja vastaanottamisen tavat voivat olla erilaisia, ja on tärkeää ymmärtää ja kunnioittaa näitä eroja. Jos toimit monikulttuurisessa projektissa, ole varovainen palautteen antamisen suhteen, erityisesti jos palautteen kohteena on kokonaan ulkomailla toimiva tiimi.
Palautteen saaminen herättää aina tunteita
Palautteen antaminen ja vastaanottaminen voi olla haastavaa. Palaute saattaa herättää monenlaisia tunteita, kuten puolustautumista, pelkoa tai epävarmuutta. Palautteen kohteeksi joutuminen voi olla erityisen haastavaa, kun se koskee henkilökohtaista suoritusta tai luonteenpiirrettä, eikä vain konkreettista tehtävää tai projektia. Kuitenkin, kun palaute annetaan rakentavasti ja vastaanotetaan avoimin mielin, se voi johtaa parempaan ymmärrykseen, yhteistyöhön ja lopulta parempiin lopputuloksiin.
Palaute on parasta tuoreena
Tuoreus on avain tehokkaaseen palautteeseen. Palaute, joka annetaan heti teon jälkeen, kun asia on vielä tuoreena molempien osapuolten mielessä, on usein paljon tehokkaampaa ja merkityksellisempää kuin viikkojen tai kuukausien päästä annettu palaute. Tämä on osittain siksi, että yksityiskohdat ja konteksti ovat vielä selkeästi mielessä, jolloin keskustelu ja mahdollinen muutos tai parannus ovat helpompia.
Anna palautetta usein ja nopeasti
Sen sijaan, että kertyisi lista asioista, joita haluaa ottaa esille ja puhuu niistä vain muutaman kerran vuodessa, on paljon tehokkaampaa antaa palautetta säännöllisesti ja ajoissa. Tämä ei tarkoita, että jokaisesta pienestä asiasta pitäisi antaa palaute, vaan että isojen asioiden sijaan keskitytään pieniin, jatkuvasti eteneviin parannuksiin ja keskusteluihin. Tämä auttaa luomaan kulttuurin, jossa palautetta arvostetaan ja jossa sitä odotetaan.
Liian harvoin annettu palaute tuntuu hyökkäykseltä
Jos palautetta annetaan harvoin, on vaarana, että se muuttuu yleistäväksi. Kommentit kuten “te aina toimitte näin” eivät ainoastaan luo puolustavaa asennetta palautteen saajassa, vaan myös menettävät merkityksensä. Tällaiset yleistykset voivat myös peittää alleen todelliset ongelmat ja estää rakentavan keskustelun. Palautteen pitäisi olla tarkkaa, konkreettista ja tilannesidonnaista, jotta se voi johtaa todelliseen muutokseen ja oppimiseen.
Vältä hampurilaismallia
Yleinen palautekäytäntö on “hampurilaismalli”, jossa negatiivinen palaute “pehmennetään” aloittamalla ja päättämällä positiivisella palautteella. Vaikka tämä voi toisinaan olla tehokasta, sen automaattinen ja jatkuva käyttö voi tehdä positiivisesta palautteesta teennäistä ja vähentää sen arvoa.
Kun positiivinen palaute on aitoa ja spesifiä, se voi vahvistaa haluttuja toimintatapoja, lisätä itsetuntoa ja motivoida jatkamaan hyvällä polulla. Positiivinen palaute kannustaa. Mielestäni positiivista palautetta ei voi oikeastaan antaa liikaa. Kehuja voi antaa mistä tahansa, joka menee edes osittain oikein. Täydellisyyttä ei kannata odottaa.
Älä aina tarjoa valmista ratkaisua ongelmaan
Joskus kuulee ohjeen, että rakentava palaute vaatisi sitä, että kerrottuun ongelmaan tarjoaa jotain ratkaisua. Minä olen eri mieltä. Ratkaisun tarjoaminen voi jopa kuulostaa kehitystiimin korviin sanelevalta tai alistavalta. On tärkeää, että epäkohtia voidaan nostaa esiin myös ilman ratkaisuvaihtoehtoa. On kuitenkin tärkeää, että osoitetaan eri tavoin kommunikoimalla kehitystiimille, että tähän asiaan on varmasti olemassa erilaisia ratkaisuvaihtoehtoja, ja että tuotepäällikkö luottaa kehitystiimiin näiden etsimisessä, arvioinnissa ja valinnassa. Se viestii: “Tiedän, että teillä on taito ja asiantuntemus ratkaista tämä, ja luotan teihin.”
Kun esität epäkohdan ilman valmista ratkaisua, se antaa tiimille mahdollisuuden innovoida, keskustella ja löytää useita erilaisia tapoja lähestyä ongelmaa. Tämä voi johtaa parempaan ja tehokkaampaan ratkaisuun kuin jos olisit tarjonnut valmiin vastauksen. Joskus pelkkä oikean kysymyksen esittäminen voi olla katalysaattori muutokselle. Sen sijaan, että tarjoaisit ratkaisun, voit kysyä: “Miten voimme parantaa tätä?” tai “Onko tässä tilanteessa parempia tapoja toimia?”
Minä-viestit
Kun lukee kirjoituksia palautteen antamisesta, puhutaan usein “minä-muodon” käyttämisestä. Tällä tarkoitetaan sitä, vältetään esimerkiksi toteamusta “Tämä toiminto on liian monimutkainen”, vaan käytetään ennemmin muotoa “Minä koen tämän toiminnon liian monimutkaiseksi”. Itse olisin varovainen tämän “minä-muodon” käyttämisessä.
Tuotekehityksessä yleinen vaara on, että suunnitellaan tuotetta itselle. Kehittäjä tekee toteutuksesta sellaisen, kuin hän itse haluaisi sen olevan. Tuotepäällikkö kehittää tuotteesta tai toiminnosta sellaisen, että se sopii hänelle itselleen. Tämä on useimmiten virhe. Tuotteella on käyttäjäryhmät, ja tuotepäällikkö ja kehittäjä ovat harvoin käyttäjäryhmien parhaita edustajia. On erittäin todennäköistä, että tuotteen kehittäjät tietävät tuotteesta, sen käyttöliittymästä ja ominaisuuksista paljon keskivertoa käyttäjää enemmän. Tämä on yksi vaara “minä-muodon” käyttämisessä palautteen antamisessa.
Havainto-tuntemus-toivomus -faktapohjainen palautemalli
Itse suosittelen enemmän palautteen antamisessa mallia, joka aloittaa palautteen viestinnän antamalla havainnon, sen jälkeen esittää tunteen, minkä tilanne toi, ja sen jälkeen toivomuksen. Tämä voisi toimia esimerkiksi näin: (esimerkkinä lennon varausjärjestelmä)
“Yritin varata meno-paluu lentoa Helsingistä Alicanteen. Minua kiinnosti vain suorat lentoyhteydet. Lennon hakukäyttöliittymässä ei voinut kuitenkaan valita suoraa tai välilaskullista lentoa. Tämän takia minun piti erikseen käydä selvittämässä, minä päivinä lentoyhtiö lentää tätä reittiä suoralla lennolla. Kun olin tämän käynyt selvittämässä, palasin takaisin tekemään lentohakua. Hakutuloksissa ei edelleenkään kuitenkaan näkynyt paluulennolle kuin välilaskullinen vaihtoehto. Tässä vaiheessa en enää ymmärtänyt, miten minun pitäisi toimia, jos haluan molempiin suuntiin suoran lennon. Tunsin oloni tyhmäksi ja turhautuneeksi, koska lennon valinta pitäisi yleensä sujua viidessä minuutissa, ja nyt olin käyttänyt tähän jo kohta puoli tuntia. Toivoisin, että suoran lennon valinta hakuvaiheessa olisi mahdollista, ja että käyttöliittymä näyttäisi helpommin, jos minun pitäisi muuttaa hakumäärityksiä, jos valitsemalleni lipputyypille ei ole suoraa lentoa tarjolla.”
Tällainen palautemalli, jossa esitetään
- Havainto
- Tuntemus, jonka tilanne aiheuttaa
- Toivomus
On helpompi vastaanottaa. Tämä johtuu siitä, että kaksi ensimmäistä ovat asioita, joita vastaanottaja ei voi kiistää. Havainto on kiistaton. Myös tuntemus, jonka tilanne aiheutti, on kiistaton. Tällainen kommunikaatiotapa johtaa vastaanottajan nopeammin hyväksymään tilanne, ja alkamaan etsiä ratkaisua. Tämä viestintä ei myöskään ole syyttelevää. On tärkeää, että emme viestinnällä saa aikaan sitä, että palautteen vastaanottaja menee siilipuolustukseen, ja lakkaa kuuntelemasta meitä.
Ole avoin palautteen kanssa
Tuotepäälliköiden ja kehitystiimien välillä avoin kommunikaatio on erityisen tärkeää. Tuotepäällikkönä voit miettiä, miten voit rohkaista tiimiäsi jakamaan ajatuksiaan ja tuntemuksiaan kanssasi, ja miten voit itse ottaa vastaan ja toimia saamasi palautteen perusteella. Tämä edistää yhteistyötä, luottamusta ja yhteistä ymmärrystä tiimin kesken.
Paranna palautteen antamista ja vastaanottamista jatkuvasti
Palautekulttuurin luominen ja ylläpitäminen vaatii jatkuvaa ponnistelua. On tärkeää muistaa, että kaikki eivät ole samalla tasolla palautteen antamisessa tai vastaanottamisessa. Joidenkin voi olla helpompi ilmaista itseään, kun taas toiset saattavat tarvita enemmän tukea ja ohjausta.
Arto Kiiskinen
Lead Consultant
Artolla on 25 vuoden kokemus tuotekehityksestä eri rooleissa ja 7 vuoden kokemus tuoteomistajien ja tuotepäälliköiden kouluttamisesta ja valmentamisesta.