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
Wanneer we het hebben over projecten of producten, streven beide naar hetzelfde doel: klanten helpen om problemen op te lossen en efficiënter te werken. Het verschil zit in onze aanpak en mindset, wat leidt tot een ander resultaat.
Bij projecten starten we meestal met een fixed scope. "Dit is wat we absoluut nodig hebben. We hebben hier goed over nagedacht en veel onderzoek gedaan, dus deze scope staat vast."
Als we dan naar de project management triangle kijken, zien we dat de andere aspecten, tijd en kost, wat flexibeler worden ingevuld.
Een vaste scope met flexibele budgetten en tijdslijnen klinkt ideaal, toch? In werkelijkheid kunnen de kosten en tijdslijnen vaak niet zo flexibel zijn. We willen snel resultaten zien (de concurrentie zit immers niet stil) en het budget heeft zijn grenzen (we hebben nog veel andere uitgaven).
Wat gebeurt er dus? Zowel scope, budget als timing zijn eigenlijk "fixed", waardoor we proberen de afgesproken scope sneller en goedkoper op te leveren. Het resultaat: de kwaliteit gaat drastisch omlaag en we eindigen met ontevreden klanten of eindgebruikers, weinig of geen opgeleverde waarde en een "gefaald" softwareproject. Conclusie: we focussen op output zonder echt waarde (of kwaliteit) te leveren. Meer hierover verderop in deze post.
Bij Qframe zijn we al geruime tijd afgestapt van de traditionele aanpak. In onze offertes vermelden we expliciet dat de scope flexibel is: met de beschikbare tijd en budget streven we naar een zo kwaliteitsvol mogelijk product, zonder vooraf vast te leggen wat we precies gaan opleveren. We spelen in op marktveranderingen en voortschrijdend inzicht tijdens de ontwikkeling.
Er wordt steeds minder gewerkt volgens de project mindset. Dankzij de toenemende toepassing van scrum en agile leveren we regelmatig kleine stukjes waarde, wat het makkelijker maakt om feedback te krijgen en onze beslissingen daarop te baseren. Bovendien zorgt de toenemende complexiteit en onzekerheid in onze moderne wereld ervoor dat we minder zekerheden hebben en ons niet langer alleen op aannames kunnen baseren. We moeten deze regelmatig valideren in de markt en bij de eindgebruiker. Omarm daarom de product mindset! Een flexibele scope, focus op echte waarde voor de klant, gebaseerd op gevalideerde aannames en constant bijgeschaafd door feedback en voortschrijdend inzicht. We bouwen producten die 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 een product visie of een “product goal” uit te werken, die we (samen met de klant) 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 bij de plaatselijke bakker. Veel mensen zouden zeggen dat de uitkomst van deze transactie de taart zelf is, maar dat klopt niet. De echte uitkomst is een blije Finn en een groep tevreden vriendjes met een volle maag dankzij de taart. De output is de taart zelf, geleverd door de bakker. Als de taart niet lekker was of als het een Barbie-taart was geweest, zou de gewenste uitkomst waarschijnlijk niet bereikt zijn.
Als we dan in business termen denken, kunnen we dat als volgt beschrijven:
Outcomes zijn wat de klant 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 en het middel om daar te geraken is de output. Om de gewenste resultaten te bereiken, moeten we de echte behoeften van de klant begrijpen: welke uitdagingen hebben ze, welke problemen, beperkingen en prioriteiten spelen een rol? Waar liggen de pijnpunten? We moeten proberen te begrijpen welke ongemakken ze ervaren en wat hen 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, wat het rapporteren en valideren eenvoudig maakt. Het is duidelijk of iets wel of niet is opgeleverd. Outcomes daarentegen zijn zowel kwantitatief als kwalitatief en sterk afhankelijk van de perceptie van de klant over de geleverde waarde. Dit maakt het moeilijker om hierover te rapporteren, maar het is essentieel dat we hier een manier voor vinden. Als we ons alleen op output metrics blijven richten, zoals bijvoorbeeld velocity (kwantitatief), blijft er weinig ruimte over om te focussen op outcomes (kwalitatieve meerwaarde). In de praktijk zie je dan vaak dat er weinig of geen contact is met de eindgebruikers, terwijl dit juist een belangrijke maatstaf is om 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. Zoals eerder aangegeven, gaat een product mindset uit van een flexibele scope die zich gaandeweg vormt op basis van voortschrijdend inzicht. De Product Owner kan en mag regelmatig "nee" zeggen tegen bepaalde feature requests of requirements die niet bijdragen aan de productdoelstelling. De PO stelt de "wat" en de "waarom" zo scherp mogelijk, terwijl het team bepaalt hoe de gewenste outcome bereikt kan worden.
Hoewel tegenwoordig bijna iedereen agile en scrum werkt, waarbij zelfsturing en de rol van de Scrum Master steeds duidelijker wordt, blijft de rol van de Product Owner vaak handig om te hebben. We denken vaak dat een Project Manager dezelfde taken uitvoert, maar dat is niet het geval. Vaak wordt iemand aan de klantzijde de PO-rol opgedrongen zonder de benodigde mindsetverandering, of worden stakeholders ten onrechte als PO beschouwd. Daarom geloven we dat de beste Product Owner vaak niet de klant zelf is. Voor sterk eigenaarschap van het product, waarbij je regelmatig "nee" durft te zeggen tegen features of requests, moet je durven ingaan tegen de klant om de productdoelstelling te bewaken. Dit is vaak makkelijker voor een externe persoon, omdat die minder beïnvloed wordt door interne politiek, hiërarchie of doorgroeimogelijkheden, wat het moeilijker maakt om beslissingen van "het management" in twijfel te trekken.
Conclusie
Een mindset die zich richt op een product met flexibele scope, een team dat naast output vooral focust op de gewenste outcomes en gedragsveranderingen, en een sterke Product Owner die de productvisie met passie bewaakt. Dat zijn volgens ons de ingrediënten voor een succesvol softwareproject.
Bij Qframe hebben we al veel stappen in die richting gezet. We blijven continu leren, ontdekken, experimenteren, inspecteren en aanpassen. De enige zekerheid is dat de omgeving waarin we opereren altijd onderhevig is aan VUCA: Volatility, Uncertainty, Complexity, and Ambiguity. Wij geloven dat agile en scrum de beste manieren zijn om hiermee om te gaan.
