Fem vanliga fallgropar du vill undvika som Produktägare

Idag växer rollen produktägare i många organisationer, både i betydelse och komplexitet. Det agila ramverket har ett tydligt fotfäste som arbetsmetod för förändring, och därmed blir rollens utövning avgörande. Hantering av krav, produktförståelse och kommunikation är affärskritisk och produktägaren får lov att vara skicklig och aktiv. Saknas detta ser vi en försämrad värdehemtagning av agilt arbete. Verksamheten får helt enkelt inte ut så mycket som den förtjänar.

Under åren har vi på Onbird vandrat med hundratals produktägare och deras kollegor kring det som fungerar bra och mindre bra. Vi har besökt produktägarens fallgropar, samt hur en kan vända dessa till framgångsfaktorer. Inför denna sammanställning intervjuade vi ett antal produktägare om vilka deras största utmaningar är för att lyckas. Utifrån det samlade materialet kunde vi identifiera fem punkter där förbättringsarbete skulle ge tydliga effekter – våra ”Fem vanliga fallgropar för en produktägare”:

1. En otydlig produkt.
2. Produktägare är inte (delaktig) i teamet.
3. Produktägare drunknar i dev/teamet.
4. Oklarhet gällande produktens intressenter.
5. En okontrollerad backlog.

Vi vet att avsikterna är goda, men stigen är snårig. Trampa försiktigt!

Ladda ner vår populära e-bok

Agil produktägare

I en värld där begrepp som ”Agil”, ”Iterativ”, ”Retrospektiv” och ”MVP” kastas omkring med självklarhet kan det vara skönt att få lite kött på benen för åtminstone de generella begreppen. Vi siktar på att ge er exakt det, kött på benen, med vår produktägarguide!

Ladda ner vår populära e-bok

Agil produktägare

I en värld där begrepp som ”Agil”, ”Iterativ”, ”Retrospektiv” och ”MVP” kastas omkring med självklarhet kan det vara skönt att få lite kött på benen för åtminstone de generella begreppen. Vi siktar på att ge er exakt det, kött på benen, med vår produktägarguide!

Fallgrop nummer 1 – En otydlig produkt

Produkten är samlingspunkten för det agila teamet och en skicklig produktägares ögonsten. Hela poängen med teamets arbete är produktens förädling. Därför bör vi inte tåla en vag samling av system eller ett ständigt skiftande funktionsomfång som produktdefinition. Det är vitalt att produkten är tydlig och avgränsad. Kravställare från verksamheten skall kunna veta vart de kan rikta sina krav om förädling, och teamet skall veta vart de ska rikta energi och fokus.

Hur tydliggör vi produkten? Onekligen är detta en konst. Syftet med produkten är värde till verksamhet, så produktens värde måste framgå så tydligt som möjligt. Praktiska produktdefinitioner består också av ett produktnamn, system och konstruktionselement, samt funktioner som utförs. Lyfter man blicken skall även produktvision och roadmap formuleras som en riktning.

Få hjälp att definiera produkten med hjälp av vår produktcanvas-mall

Fallgrop nummer 2 – Produktägare är inte (delaktig) i teamet

Ett av agilitetens stora bidrag är att explicit identifiera rollen produktägare som en kritisk aktör i förändring. Teamet skall inte agera på egen hand, men i stället med en tydlig koppling till verksamheten. Produktägaren förkroppsligar denna roll och agerar som prioriterad representant av produkten i verksamheten och verksamheten i produkten.

Därför ÄR produktägaren en medlem i det agila teamet. Därför finns inte ett agilt team utan produktägare. Och därför skall produktägaren vara en aktiv deltagare i teamets agila arbete.

Här kommer vi inte med explicita mått eller moment, såsom t.ex. måste vara med minst 12h/v, måste vara med på alla ceremonier, måste godkänna varenda user story… Låt det dock räcka med ”mycket”. Produktägare skall vara ”mycket” med, och genomgående ”mycket” aktiv i den agila cykeln samt produktens framfart. Arbetet sköts inte med vänster hand här – teamet skall uppleva otvivelaktig närvaro och delaktighet från produktägaren. (Här kommer även frågan om var produktägarens lojalitet ligger när det uppstår konflikt mellan team och omvärld. Naturligtvis hos teamet säger vi, men det får lov att vara foder för ett annat blogginlägg 😊.)

Fallgrop nummer 3 – Produktägare drunknar i dev/teamet

Livet är en balansgång, och visst gäller det för produktägare också. Enligt ovan skall produktägare vara delaktig och aktiv i teamet… Samtidigt vill vi inte se en produktägare som drunknar kravdetaljer, teknik eller utvecklingsuppgifter. När backlog är väl förmedlad och en sprintplan har lagts, skall då utvecklingsteamet ta vid i produktion. Produktionsfasen är utvecklarens ”sweet spot” och här skall produktägare inte tassa för mycket. Återigen balansgång här – vi litar på utvecklingsteamets arbete – ingen detaljstyrning och vidta försiktighet med att komma med ständig förändring (ja, jag vet att vi är flexibla men …)

Under tiden utvecklingsteamet är i gång med sina underverk har produktägaren en chans att lyfta blicken till framtiden – refinement i backlog, förändringshorisonten och intressenterna.

Fallgrop nummer 4 – Oklarhet gällande produktens intressenter

Produkter finns inte till för teamets skull, men i stället för produktägare och verksamhet. I ovanliga fall kan produktägaren vara den enda primärintressenten, dock vanligast är att produktägare företräder en eller fler intressenter (eng. stakeholders) i verksamheten. Dessa intressenter är mottagare av produkten och dess värde och därför är det kritiskt att produktägaren upprättar kommunikation med dem.

Det här kan dock vara knepigt, särskilt i större organisationer och inom skalad agilitet. Vissa produkter kan få ett existensberättigande som liknar gamla möbler – de ska finnas där de står, men det är oklart varför. Därmed kan det lätt bli att det fortgår allt dyrare förvaltning och förädling, dock utan förankring i verksamheten. Andra produkter representeras lite slentrianmässigt av en verksamhetsledare här, en annan där och i sommarmånader av en tredje. Ytterligare kan en produkt helt sakna aktiv koppling till verksamheten. Alla vet att det är viktigt, men ingen vill ta i det.

I sådana fall blir det svårt för produktägaren. Förankringen som produkten kräver skall ha tydlig, namngiven representation i verksamheten. Annars riskerar produktägaren och teamet att börja skapa förädling utan mottagare, och då kan det bli tokigt med prioritering, funktionella features, värdedefinition, m.m.

Fallgrop nummer 5 – En okontrollerad produkt-backlog

Produktens backlog är verksamhetens och teamets samlingspunkt där produktens förändringskurs beskrivs. Här samlar vi idéer, stora som små, som tjänar som påståenden om värdeutveckling av vår produkt.

Vi på Onbird får ibland höra att ”det inte finns en backlog” men vi tror att situationen är lite annorlunda än så. Många krav på produkten brukar finnas. De är dock skrivna på post-its här, i ett Excel-blad där och förresten glöm inte ticketdatabasen där det också finns en massa kort. I andra fall kännetecknas idéer och visioner av oändligt prat, utan dokumentation, som aldrig riktigt blir någonting.

Produktägarens ansvar är att bringa ordning här. Samlingspunkten får skapas och samling får ske. När väl kraven är kända och samlade skall de helst uttryckas som user stories där värdet blir tydligt. Refinement drivs på här också, där kravet utvecklas med detalj, prioritering och värdet blir tydligare, och storleken på krav sätts på rimlig nivå.

Har du snubblat in på en av våra fallgropar?  Berätta mer på kommande webinar (se nedan) och/eller kontakta oss med feedback!