Eindbaas van de website: waarom het niet stopt bij techniek.

Sinds 2007 heeft productowner.nl ruim 100 digitale projecten mogen begeleiden, zowel realisatie als optimalisatie van digitale producten. (webshop, software, app, intranet, platform, etc..)
Met de opkomst van de product owner en de stijgende agile volwassenheid bij de agencies en hun klanten zien wij dat de product owner steeds vaker zijn tentakels uit mag (en moet!) slaan binnen andere domeinen. Samen met techniek zien we vier domeinen: Proces, Adoptie, Content en Techniek. Samengevat; PACT.
Een product owner is verantwoordelijk voor het maximaliseren van de waarde voor de gebruiker. Dat betekent dat het digitale product zo dicht mogelijk bij een 10+ uit moet komen in de ogen van de gebruiker. En dat allemaal binnen de gestelde planning en budget.
Daarbij is de heersende opvatting dat de product owner met name een hele sterke rol heeft richting het SCRUM team. Dat is een team met softwareontwikkelaars en andere ondersteunende rollen zoals een UX-er en/of een scrummaster. Al met al heeft die techniek dus een grote zuigende werking op de aandacht en agenda van de product owner. En dat is prima wanneer de product owner in een organisatiestructuur zit waar de andere domeinen zijn belegd bij andere personen zoals een product manager of marketingafdeling. Maar dat is vaak niet het geval. In drie situaties is het meer regel dan uitzondering dat de rol van product owner moet worden gecombineerd met die van regisseur op het gebied van adoptie, content en/of procesbeheer.
De drie situaties zijn:
– Bij nagenoeg elke webshop die buiten de Twinkle100 valt.
– Het gros van digitale producten in het MKB waarbij de kartrekker in feite de product manager is.
– Wanneer een externe project manager wordt ingehuurd.
Wanneer we in contact komen met de verantwoordelijke persoon in één van deze situaties, dan zien we heel vaak de samenhang op de vier domeinen die samen PACT vormen. Voor de mensen die met dit bijltje moeten hakken zal één van de volgende situaties heel herkenbaar zijn:
– “Onze nieuwe website heeft veel minder bezoekers dan de vorige”
– “We konden live gaan, maar het bleek dat de teksten nog niet af waren. Dus zijn we maar live gegaan met een basis versie”
– “We halen de doelstelling niet, terwijl het wel allemaal goed werkt.”
Herkenbaar..? Het is vaak ontzettend frustrerend en in onze ogen goed te voorkomen. Maar het vraagt dan wel meer energie en focus van de product owner. En dat is bij een goede product owner niet het probleem. Het probleem zit vaak eerst in bewustwording en snel daarna in het vergroten van het mandaat en/of stakeholder management dat opeens een stuk complexer wordt. En daarin moet de product owner dan groeien. En waar die groei zit is vooraf moeilijk te voorspellen. Want geen enkel persoon is gelijk. En dus zijn er ook geen twee identieke product owners. We doen dan ook een dringende oproep aan de product owners om een goed om je heen te kijken. Waar ben je nu in de praktijk wel of niet verantwoordelijk voor? En hoe beleeft het management dat? Al met al een goede aanleiding voor een goed gesprek met elkaar.
Loop je vast als product owner en zoek je tips over hoe je jezelf in de juiste positie manoeuvreert? Of ben je zelf de ondernemer en red je het simpelweg niet qua tijd? Of wil je weten hoe je één van die domeinen onder controle moet krijgen? Neem contact met ons op. We gaan je helpen. Beloofd.
PROCES:
Een verandering in het IT landschap zorgt áltijd voor een aangepast werkproces. Het is zaak die werkprocessen vorm te geven mét de mensen, niet vóór de mensen. In de praktijk wordt vaak pas na de testfase het grootste deel van de gebruikers ingelicht. Er zal, zelfs bij het best uitgedachte product, veel weerstand ontstaan. Ons advies om hier als product owner grip op te krijgen is als volgt:
– LEAN procesoptimalisatie (go-to-gemba) is in onze ogen de beste manier om die processen in kaart te brengen.
– Processen zijn bewegende organismen. Reserveer budget om te optimaliseren na realisatie.
– Processen zijn leidend en de mensen moeten zich daar aan confirmeren. Het bouwen van een proces om een persoon heen maakt processen inefficiënt en het maakt de organisatie minder flexibel.
– Een slecht ontwikkeld proces moet worden gerepareerd voordat het digitale product wordt gelanceerd. Het product zelf is nooit de oplossing.
– Zet de gebruiker centraal door een ‘begrijpdag’ te organiseren met 5-7 stakeholders.
– Accepteer dat het actief begeleiden van de verandering na livegang minstens net zo lang duurt als het realisatietraject zelf.
– Speciaal voor e-commerce: Bedenk en bespreek ruim van tevoren of een aanpassing in de shop impact heeft voor logistiek of servicedesk. Slechte reviews zijn schadelijk voor conversie op korte en lange termijn.
ADOPTIE:
Of, in het geval van een externe doelgroep, activatie. In beide gevallen is het vertrekpunt dat een digitaal product een probleem moet oplossen voor een gebruiker, anders gaan mensen het niet willen gebruiken. Hoe groter het probleem en hoe beter de oplossing, hoe groter de kans is dat gebruikers het platform organisch gaan vinden. Maar soms moet je de gebruiker een handje helpen. Bij een externe doelgreep zijn daarvoor tientallen kanalen beschikbaar en honderden bureaus vol expertise. Maar hoe krijg je je collega’s enthousiast over een intern product? We geven de volgende tips:
– Wie zijn de key users? Betrek ze vanaf dag 1 in de productontwikkeling en vraag ze wat ze nodig hebben om hier écht gelukkig van te worden.
– Geef hen inzicht dat zij door de massa worden gezien als thermometer voor het succes van dit product. Vaak nog veel meer dan het management. Hoe de key users zich opstellen tegenover het product in de beginfase gaat grotendeels bepalend zijn voor de adoptie curve in de eerste maanden. Coach ze hierin indien nodig.
– Begeleid mensen in het nieuwe product. En dat is véél meer dan een dag training. Zorg voor goede video’s die altijd beschikbaar zijn, maar check ook proactief in. En dan uitsluitend op een positieve manier.
– Beloon goed gedrag. Adoptie gaat nooit om het straffen van mensen, maar om samenspel tussen ‘lead by example’ en het erkennen/waarderen van mensen die datzelfde gedrag vertonen.
– Laat de roadmap zien. Niet alleen bij de lancering, maar ook fysiek op een prominente plek waar veel gebruikers het gaan zien. Een product is nooit meteen af, dus geef mensen een doorkijk om te zien welke problemen voor ze opgelost gaan worden in de (nabije) toekomst. Leg daarbij ook uit waarom je welke prioriteiten hebt gesteld.
CONTENT:
Het is onze ervaring dat op de geplande livegang datum bij ruim 70% (!) van de projecten de content niet gereed is. En in de praktijk komt dit doordat het content team pas aan de slag gaat als ze voor het eerst in het Content Management Systeem (CMS) kunnen. En dat is zonde, want onze stelling is dat middelmatige techniek en hele goede content belangrijker is dan goede techniek en middelmatige content.
– Betrek vanaf dag één de contentexperts bij het project. Laat ze wireframes zien, zodat ze scherp hebben wat voor type content gemaakt moeten worden
– Maak vroeg in het project een sitemap en stem met het content team af welke content waar moet komen. Stel dan een planning op en maak er een kunst van om elke week content op te leveren. Liever heel veel kleine beetjes dan 1 bing bang. Want dat gaat onherroepelijk vertraging opleveren.
– Data migratie moet goed begeleidt worden. Het omzetten van 10.000 foto’s of EPD’s op de dag van livegang is geen grappig vooruitzicht. Het is goed om direct bij start van ontwikkeling nieuw product ook direct te beginnen met de start van een conversie/migratieplan
– Zorg voor een gebruiksvriendelijk CMS. Denk hierbij aan een wysiwyg-editor (what you see is what you get), een goede rollen- en rechtenstructuur en de mogelijkheid om alle vormen content (tekst, beeld, video) naadloos te combineren. Gelukkig zijn er veel goede CMS-en beschikbaar en in dit licht vinden we dat het zelf bouwen van een CMS altijd de allerlaatste optie moet zijn.
– Huisstijl is een middel, geen doel. Te vaak zien we een Marcom-afdeling of een creatieve ondernemer veel energie steken in een huisstijl, terwijl die huisstijl slechts dienend is en als losstaand component nooit iemand zal overtuigen om de geboden informatie/dienstverlening/producten te gaan gebruiken. Dat doet goed gemaakte inhoud wél.
– Is minder dan 50% van de content af als het bouwtraject op 50% zit? Dan zou dit moeten leiden tot een escalatie. Is bij 75% van de bouw van het digitale product de content niet op schema? Dan is livegang op de vooraf gestelde data vaak heel lastig zonder grote concessies te doen op functionaliteit.
– Het maken van content dwingt de organisatie om zich nóg meer in de klant te verplaatsen. De kans is aanwezig dat daar aangepaste functionaliteiten uit voort komen. Bespreek met elkaar wat daar mee gebeurt en besef dat, als die functionaliteit toe moet worden gevoegd er óf later op wordt geleverd óf dat een andere functionaliteit op pauze wordt gezet.
TECHNIEK
En tot slot de rol van techniek. Het internet staat vol met heel veel goede informatie over hoe een digitaal product gebouwd moet worden. Wil je snappen hoe wij dit hebben gedaan en hoe we jou kunnen helpen? Neem dan contact met ons op. Tot die tijd geven we hier graag wat tips:
– Agile en SCRUM zijn niet meer weg te denken uit het landschap. Maar met een korte ontwikkeltijd en een heel scherp pallet aan functionaliteiten zijn wij toch voorstander van een traditionele benadering. Een kop, een staart en duidelijke commitment van alle stakeholders is een valide manier om kleinere projecten of optimalisaties te realiseren
– Begin pas met bouwen als de propositie helder is. Een één- of meerdaagse Design Sprint is in onze ogen nog steeds de beste investering tegen een slechte investering.
– De volwassenheid van het ontwikkelteam moet van tevoren worden ingeschat. Volwassenheid op vakgebied, maar ook op attitude. Tenzij het ontwikkelteam vakvolwassen is op de inhoud en beschikt over een positieve agile mindset adviseren wij om een getrainde en ervaren product owner op het project te zetten. Zo worden teleurstellingen voorkomen.
– Betrek vanaf dag één de gebruiker. Vanaf de customer journey in de beginfase tot het valideren van de testscenario’s; de gebruiker moet centraal staan. Altijd.
– Energie en focus zijn je allerbelangrijkste wapens. Besef dat als jij een spreekwoordelijke 90% geeft, dat de mensen om je heen gaan zien dat het ook met minder kan. Dit wordt vervolgens een neerwaartse spiraal. Zolang jij al je energie en focus op dit project zet, gaat het een succes worden. Misschien met een beetje hulp, maar dat is OK. En als je die hulp niet vindt bij de mensen om je heen, dan staan wij voor je klaar. Neem gewoon contact met ons op en we gaan je helpen.
TOT SLOT:
Een digitaal product is, mits goed begeleid, de ultieme springplank naar blije gebruikers. Maar het samenspel tussen de disciplines is in onze ogen moeilijker te realiseren/repareren dan het op de rit krijgen en houden van een ‘boodschappenlijst’ aan technische functionaliteiten.
Een goede product manager, ondernemer of interimmer onderkent dit en zal, mits de ruimte wordt gecreëerd, in staat zijn om vanuit ‘ownership’ fantastische dingen te gaan doen voor de gebruiker en daarmee de organisatie.
Meer weten? check www.productowner.nl voor meer informatie.
Dit artikel is een ingezonden bericht en valt buiten de verantwoordelijkheid van de redactie.