Van project naar product – Van output naar outcome

Van project naar product, van output naar outcome 

Bij Qframe werken we met vaste teams die vaak al lang samenwerken en elkaar door en door kennen. De verschillende klanten die we helpen hebben vaak uiteenlopende noden en specifieke vereisten eigen aan hun sector of marktsegment. In alles wat we doen proberen we altijd de waarde voor de klant voorop te stellen: hoe kunnen we ervoor zorgen dat de applicaties die we voor hen bouwen zoveel mogelijk bijdragen aan een betere, snellere en duurzamere dienstverlening naar de eindklanten en gebruikers. 

Zoals in vele andere sectoren werken we vaak project gebaseerd: we definiëren een projectplan dat aangeeft wat we allemaal gaan bouwen en uitvoeren, een duidelijke afgelijnde scope van functionaliteiten. Daarbij proberen we op voorhand een budgetinschatting te maken alsook een timeline: we beginnen rond datum X en proberen alles op te leveren tegen datum Y. 

De laatste jaren merken we echter een duidelijke shift van projecten naar producten, met name door invloeden en inzichten vanuit productontwikkeling en product management. Mede daardoor verschuift de focus meer van output (wat hebben we allemaal gebouwd) naar outcome (welke resultaten hebben we helpen te bereiken). In deze blogpost proberen we beide zaken uit te diepen en te kijken hoe we deze concepten kunnen combineren in onze dagelijkse werking. 

Van projecten naar producten 

Als we spreken over projecten of producten hebben beiden eigenlijk hetzelfde doel: een klant helpen om problemen op te lossen en beter, sneller en efficiënter te werken. Het is de manier waarop we het aanpakken die verschilt: de mindset is helemaal anders als we spreken over een project dan wel over een product. En bijgevolg is het resultaat ook vaak helemaal anders. 

Bij een project mindset starten we meestal van een fixed scope: “Dit is wat we absoluut moeten hebben. We hebben hier lang over nagedacht, vele onderzoeken en analyses gedaan en deze scope staat vast.” Als we dan naar de project management triangle kijken, zien we dat de andere aspecten, tijd en kost, iets flexibeler worden ingevuld. 

Vaste scope, maar flexibele budgetten en tijdslijnen, klinkt goed toch? De realiteit is echter dat kosten en tijdslijnen vaak niet flexibel kunnen zijn: we willen toch relatief snel resultaat hebben (want de concurrentie zit niet stil) en het budget heeft ook zijn grenzen (we moeten ook nog heel wat andere zaken bekostigen). 

Wat gebeurt er dus? Zowel scope, budget als timing zijn eigenlijk “fixed”, en daardoor gaan we de afgesproken scope proberen sneller en goedkoper op te leveren. Gevolg: de kwaliteit gaat drastisch naar beneden, en we eindigen met een ongewenst resultaat: ontevreden klanten of eindgebruikers, weinig of geen opgeleverde waarde, een “gefaald” software project. Vaststelling: we focussen op output zonder dat we echt waarde (of kwaliteit) leveren. Hierover meer verderop in deze post. 

Bij Qframe zijn we hier al een hele tijd van afgestapt. In onze offertes staat expliciet vermeld dat net de scope flexibel is: met de beschikbare tijd en budget proberen we een zo kwaliteitsvol mogelijk product te bouwen, waarbij niet op voorhand vastligt wat we allemaal gaan opleveren: we spelen in op de veranderingen in de markt en het voortschrijdend inzicht tijdens de ontwikkeling. 

Eigenlijk wordt er steeds minder gewerkt volgens de project mindset. Mede doordat scrum en agile steeds vaker worden toegepast en we inzien dat regelmatig kleine stukjes waarde leveren het veel makkelijker maakt om feedback te krijgen en daarop onze beslissingen te baseren. Een andere reden is de steeds toenemende complexiteit en onzekerheid in onze moderne wereld: er zijn minder zekerheden en we kunnen ons niet langer alleen baseren op assumpties. We moeten ze net regelmatig valideren in de markt en bij de eindgebruiker. 

Enter de product mindset: flexibele scope, focus op echte waarde voor de klant, gebaseerd op gevalideerde assumpties en constant bijgeschaaft door feedback en voortschrijdend inzicht. We bouwen producten die hopelijk lang gebruikt worden, en stappen af van projecten die vaak op voorhand gedoemd zijn om te mislukken. 

Toch zien we dat de product mindset nog niet helemaal ingeburgerd is. We werken met een flexibele scope, maar maken nog te weinig gebruik van de mogelijkheden die hierdoor ontstaan. Als we nog niet exact weten wat we allemaal gaan bouwen, geeft ons dat de opportuniteit om kritisch na te denken over wat de klant of de eindgebruiker nu echt nodig heeft. 

Het laat ons toe om, samen met de klant en/of eindgebruiker, een product visie of een “product goal” uit te werken, die we continue blijven bijschaven. Die product goal houdt ons scherp, vertelt ons waarom we aan bepaalde zaken werken en vooral: aan welke zaken we niet gaan werken. Dankzij de product goal focussen we op echte waarde leveren, die we dankzij scrum heel regelmatig aftoetsen bij de eindgebruiker, en op basis van de feedback onze product goal en focus nog wat scherper kunnen stellen. 

Kortom: een product mindset heeft een sterkere focus op outcome, en niet alleen op output. Waarde leveren voor een klant gaat niet meer alleen over features bouwen, maar ook en vooral over waardevolle veranderingen tot stand brengen in de werkwijze en manier van denken over de klant, wat die nodig heeft en hoe we dat kunnen bewerkstelligen. 

Van output naar outcome 

In de scrum en agile community heeft iedereen er de mond vol van en allemaal proberen we het onder de aandacht te brengen: output vs. outcome. Maar wat is nu het verschil? Laat ons starten met een heel eenvoudig, niet IT gerelateerd voorbeeld. 

Finn wordt 5 jaar en voor zijn verjaardagsfeestje hebben we een Spiderman taart besteld die we ophalen bij de plaatselijke bakker. Als we zouden vragen wat de uitkomst is van deze transactie, zullen veel mensen zeggen dat het de taart zelf is. Dat is niet correct. 

De uitkomst is namelijk een blije en verheugde Finn en een groep blije vriendjes met een volle maag dankzij de Spiderman taart. De output is de taart zelf die werd voorzien door de bakker. Als het geen lekkere taart was, of als het een Elsa taart was geweest, dan zou de gewenste uitkomst – blije kindjes – waarschijnlijk niet bereikt zijn. 
Als we dan in business termen denken, kunnen we dat als volgt beschrijven: 

–       Outcomes zijn wat de klant / business nodig heeft of wil bereiken 

–       Outputs zijn de acties en beslissingen die tot de gewenste outcomes leiden 

Outcomes zijn dus de voordelen die een klant ondervindt dankzij de technologische oplossingen die we opleveren. Het doel zijn de outcomes, het middel om daar te geraken is de output. Om de gewenste outcomes te achterhalen moeten we de echte noden van de klant weten: welke uitdagingen hebben ze, welke issues, beperkingen en prioriteiten zijn er? Waar doet het echt pijn bij de klant? Proberen te begrijpen welke ongemakken ze hebben, wat er meer tijd en geld kost dan het oplevert. 

Met die info kunnen we gaan bepalen welke output (activiteiten) kan zorgen voor positieve veranderingen in de geïdentificeerde probleemgebieden. Output blijft dus belangrijk om degelijke outcomes te bereiken, maar de focus mag niet alleen op output metrics liggen. Dat is nog wel vaak het geval, en dat is ergens ook begrijpelijk. 

Output is makkelijk te kwantificeren: er is data beschikbaar om aan te tonen wat werd opgeleverd en dat maakt het makkelijk om te rapporteren en te valideren: het is wel of niet opgeleverd. Outcomes zijn zowel kwantitatief als kwalitatief, en sterk afhankelijk van de perceptie bij de klant over de geleverde waarde. Bijgevolg niet makkelijk om over te rapporteren, maar het is wel belangrijk dat we hiervoor een manier vinden. 

Want als we enkel op output metrics blijven focussen, zoals bv. velocity (=kwantitatief), dan blijft er weinig ruimte over om te focussen op de outcome (=kwalitatieve meerwaarde). In de praktijk zie je dan dat er bijvoorbeeld weinig of geen contact is met de eindgebruikers, nochtans een belangrijke maatstaf om naar de juiste outcomes te peilen. 

De Product Owner 

Als we de product mindset en de extra focus op outcomes willen combineren, hebben we naast een zelfsturend team (met ondersteuning van een Scrum Master) ook een duidelijke nood aan een sterke Product Owner. Deze rol heeft een bijna obsessieve focus op het product dat moet gebouwd worden, een visie en product goal over waar dat product naartoe moet en welke problemen we er willen mee oplossen. Idealiter heeft de PO voldoende beslissingsrecht en een sterk mandaat om over het budget van het product geïnformeerde beslissingen te maken. 

Want zoals we eerder aangaven: een product mindset gaat uit van een flexibele scope: deze krijgt gaandeweg vorm op basis van voortschrijdend inzicht. Omdat de Product Owner geregeld “Neen” kan en mag zeggen tegen bepaalde feature requests of requirements, omdat deze geen deel uitmaken van de product goal. De PO probeert de “wat” en de “why” zo scherp mogelijk te stellen, het team zelf bepaalt hoe die outcome kan bereikt worden. 

Hoewel zowat iedereen vandaag agile en scrum werkt -of wil werken- waarbij zelfsturing en de echte rol van de Scrum Master stilaan meer vorm begint te krijgen, blijft de Product Owner rol vaak nog een “nice to have”. We denken dat een Project Manager hetzelfde denkt en doet, maar de realiteit is heel anders. Vaak zien we ook dat iemand langs de klantzijde de PO rol opgedrongen krijgt, zonder aandacht te besteden aan de mindset shift die daarvoor nodig is. Ook zijn het vaak stakeholders die ten onrechte als PO worden beschouwd. 

Daarom ben ik van de overtuiging dat de beste Product Owner vaak niet de klant zelf is. Als we een sterk ownership van het product willen, waarbij je geregeld “Neen” durft te zeggen tegen features of requests, dan moet je durven ingaan tegen de klant om je product goal vorm te geven. Dat is vaak makkelijker als externe persoon, omdat je minder vatbaar bent voor interne politiek, hiërarchie of doorgroeimogelijkheden die het vaak lastiger maken om beslissingen van “het management” in vraag te stellen. 

Conclusie 

Een mindset die focust op een product met flexibele scope, een team dat naast output vooral focust op de gewenste outcome en gedragsveranderingen, en een sterke Product Owner die de product visie bewaakt met zijn of haar eigen leven: dat zijn volgens ons de ingrediënten voor een succesvol software project. 

Bij Qframe hebben we al heel wat stappen in die richting gezet, tegelijk blijven we leren, ontdekken, experimenteren, inspecteren en aanpassen. Want de enige zekerheid is dat de omgeving waarin we opereren steeds onderhevig is aan VUCA: Volatility, Uncertainty, Complexity, and Ambiguity. Agile en scrum blijft volgens ons de beste manier om hier mee om te gaan.