Categorie: Post

Geplaatst op

Fantastisch falen als cruciale kans

Van jongs af aan leren we dat fouten maken iets is om je voor te schamen, iets om koste wat kost te vermijden. Fouten maken is echter niet alleen onvermijdelijk, onderzoek heeft ook uitgewezen dat ‘falen’ cruciaal kan zijn voor succes.
Dit is waarom:

Door fouten te maken, leren we. Omdat mislukkingen ons waardevolle feedback geven die we kunnen gebruiken om onze prestaties te verbeteren. Maar niet alle mislukkingen zijn waardevol. 

Wie slim met mislukkingen omgaat weet de lessen te verwerken tot brandstof voor je bedrijf. 

De rol van mislukking in innovatie

Innovatie gaat over het verkennen van het onbekende en het nemen van risico’s. Risico’s nemen betekent echter dat we onderweg onvermijdelijk mislukkingen tegenkomen. Kunnen we risico’s nemen als de angst om te falen ons tegenhoudt?

Je Faalangst overwinnen

Faalangst is een van de grootste obstakels voor succes. Het kan ons verlammen en ons ervan weerhouden risico’s te nemen of onze doelen na te streven. Door je ervaringen om te zetten in ‘lessons learned’ worden ze brandstof voor je toekomstige succes, en kan je beginnen je mislukkingen te omarmen.

Elke mislukking heeft consequenties, maar je business model moet bestand zijn tegen falen. Probeer daarom een gecontroleerde omgeving voor mislukkingen te creëren, bijvoorbeeld door te werken met het Assumption Driven Innovation model; het aanleggen van een logboek van aannames die een voor een gevalideerd kunnen worden. 

Natuurlijk zal er het nodige blijven mislukken. Door de kans op mislukking recht in de ogen te kijken leren we dat falen niet fataal is en onze toekomst niet definieert.

Hoe leer je van je fouten?

We hebben allemaal al vaak gefaald, en we zullen het weer doen – het is onvermijdelijk. Wat echter bepaalt of we ten onder gaan, op onze schreden terugkeren of doorzetten is wat je doet nadat je die fout hebt gemaakt. 

Fouten maken, mislukkingen, falen is een kans om te leren, te groeien en te verbeteren; daardoor ontwikkelen we veerkracht, ‘grit’ en vastberadenheid, essentiële kwaliteiten voor succes op elk gebied. Mooi gezegd natuurlijk maar hoe benut je die faal-kans?

Vraag “Waarom?”

Is iets vreselijk fout gegaan? Identificeer het probleem niet alleen aan de oppervlakte – graaf dieper. En het is echt zo simpel als vijf keer “waarom” vragen. De 5 Why’s-techniek werd in de jaren ’30 ontwikkeld binnen de Toyota Motor Corporation en zoekt naar “tegenmaatregelen”, in plaats van “oplossingen” die alleen de symptomen van het probleem aanpakken. Goede tegenmaatregelen zorgen ervoor dat de oorzaken worden weggenomen en zullen zo eerder voorkomen dat het probleem zich opnieuw kan voordoen.

Zoek je hulp of controle?

Als manager of ondernemer kan het verleidelijk zijn om te proberen alles over je bedrijf te leren en te controleren. Maar hoewel je als manager denkt alles te moeten begrijpen en alles wat er speelt moet weten, is dat eigenlijk niet nodig. Het is eigenlijk beter dat je dat niet doet. Weten wanneer je hulp moet vragen of die extern moet inschakelen is belangrijker. Het betekent niet dat je zwak bent; maar eerder dat je slim genoeg bent om te beseffen dat iemand anders je kan helpen het beter te doen. En als bonus leren meer mensen in jouw organisatie het probleem en de oplossing herkennen!

Blijf risico’s nemen!

Nadat je een flinke fout hebt gemaakt heeft bijna iedereen de neiging om een volgende situatie extra voorzichtig te benaderen. Vecht tegen die neiging – als je stopt met het nemen van risico’s, zal je gegarandeerd falen. Stop niet met het maken van fouten, maar creëer een cultuur waarin van elke fout lering wordt getrokken, een les die je team vooruit helpt.

Hoe leer je?

Om voordeel te hebben van  je “slimme” mislukkingen, zal je ook je werkprocessen en manier van communiceren moeten herzien. Door de manier van omgaan met fouten aan te passen creëer je een cultuur die ook beter op fouten kan anticiperen, waar iedereen beter van wordt en vooral de onderneming sterker.

Wat heb je scherp?

Hoewel gedreven Venture Builders en Product Developers gepassioneerd zijn over het bouwen van producten en het werven van gepassioneerd toptalent één aspect is van het bouwen van een geweldig bedrijf, is het hebben van focus vaak de kritische component voor zakelijk succes. En de juiste focus hebben komt neer op vooral “nee” zeggen tegen alles wat afleidt: houd scherp wat de meest risicovolle aannames zijn waar je business case op gebouwd is en bepaal dan waar de prioriteit op moet liggen. Bespreek de onderliggende aannames regelmatig met je team, deel je vermoedens en verzamel input. Organiseer liever een pre-mortem zodat je een post-mortem te vermijden! 

Uiteindelijk kan je, door scherp te blijven en je “falen” te analyseren, je concentreren op wat jouw bedrijf werkelijk laat functioneren. Lering trekken uit gemaakte fouten stimuleert groei – en dat is uiteindelijk de beloning van fantastisch falen.

Geplaatst op

Now-Next-Later voorbeelden

In deze post heb ik voor mezelf uitgezocht hoe je een goede Lean Roadmap kunt maken, en waarom het Now-Next-Later template daarvoor geschikt is om te gebruiken als een routekaart, die het doel op lange termijn aangeeft en helder maakt wat de stappen zijn om daar te komen. Hier heb ik een paar voorbeelden bij elkaar gebracht die het Now-Next-Later concept verder toelichten

1: De strategische routekaart

Strategische roadmaps gaan echt over doelen en doelstellingen en een plan om die te bereiken. Ze verbinden bedrijfsdoelstellingen en resultaten (via KPI’s) met klantbehoefte (jobs to be done) en voordelen / waarde.

De uitwerking hieronder geeft op zeer hoog niveau een jaarlijkse strategische roadmap weer voor een team. Laten we voor nu even aannemen dat het team bestaat uit mensen die allemaal in dezelfde discipline zitten (Wat iets anders is dan een team dat aan een gezamenlijk doel werkt maar uit heel verschillende disciplines kan bestaan). Deze roadmap toont daarom alleen wat voor dit team relevant is.

De uitwerking hieronder geeft op elke niveau inzicht in de 3 belangrijkste aspecten waar een roadmap inzicht in moet geven; wat je visie is over wat wilt worden, wat je kompas is en welke route je gaat afleggen en wat je in welke volgorde gaat plannen om die visie te bereiken.
Daarvoor zijn nog helemaal geen uitgewerkte features of functionaliteiten nodig.1: 

De visie is het focuspunt van wat in LATER beschreven wordt: Waar willen we uitkomen, wat willen we bereiken.

Deze heel hoog-over roadmap kan dan in een wat specifieker plan voor de uitvoering worden uitgevoerd, in blokken die weer aligned zijn met de kwartaaldoelen, weer volgens het Now, Next, Later principe. De NOW in het het jaarplan, Q1, kan voor een UX-team in meer detail worden uitgewerkt in een Now en Next die in totaal 3 maanden beslaan.

Deze fase toont de bredere focus, met Epics maar ook klantonderzoek dat moet worden uitgevoerd en grotere doelen, gekoppeld aan de Key Results (OKR's)

Met het uitwerking van Now wordt de link gelegd met de backlog, sprintdoelen, en wat per sprint zou moeten worden opgepakt.

Now toont de sprints die in de eerstvolgende release opgenomen wordt: uitgewerkte stories van functionaliteit of features.

Je ziet dat met deze uitwerking een productroadmap zowel uitvoerend als strategisch tegelijk kan zijn, door de realisatie voor een team concreet te maken in “Now” en “Next”. Op deze manier is het eigenlijk ook vrij eenvoudig om de roadmap up to date te houden en helpt het je om de grotere doelen niet uit het oog te verliezen.
De gelaagde uitwerking biedt je ook inzicht in het tijdsbestek: in dit geval is “NOW” 3 sprints van 2 weken en “NEXT” is nog eens 3 sprints extra. Daarmee is het eerste kwartaal beschreven.

2: Een herontwerp- / change-plan

Soms willen stakeholders wat meer detail. Ze willen bijvoorbeeld weten wat de verschillende brokken werk zijn die moeten gebeuren in de belangrijkste fasen of stadia van een change of re-design project, zodat ze zelf aan hun eigen doelgroep kunnen uitleggen hoe die transformatie zal uitpakken.

Iedereen kan die Now, Next, Later fasen zelf invullen, maar een manier is de volgende:

    1. Now: Re-design: Dit is het “nu”. Dit is waar je het bestaande product neemt en een nieuw fundament legt; omdat de huidige dienst niet langer voldoet aan de behoeften van klanten of een bedrijf, of meestal omdat een nieuwe kans is geïdentificeerd die een diepe veradnering, een transformatie nodig maakt om de kans te kunnen benutten.
    2. Next: Optimaliseren: Dit doe je zodra het fundament is gelegd; je hebt de leidingen gelegd en in de basisvoorwaarden van de (nieuwe) waardepropositie voorzien, vervolgens ga je aan de slag om die te differentiëren, of die dingen toe te voegen die het unieker of waardevoller gaan maken.
    3. Later: Innoveren: Totdat je weet hoe het nieuwe product, of de dienst werkt is het vaak moeilijk om te innoveren. Zeker wanneer je een bestaand product opnieuw wilt uitvinden. Maar een innovatie, of een “vernieuwer” zijn in een specifieke industrie is wel wat echte groei op de lange termijn kan ontsluiten.
Deze re-design roadmap laat een andere uitwerking zien waar de fase gekoppeld zijn aan "NOW", "NEXT", "LATER". 

In dit voorbeeld is een re-design roadmap uitgewerkt volgens deze ‘now-next-later’ aanpak, wat een heel andere uitwerking geeft dan die van een strategische routekaart, maar het format geeft nog steeds per fase weer waar de dienst of het product uit gaat bestaan. Het stelt je in staat om gemakkelijk dingen te verplaatsen en te vervangen als je leert, zonder dat je een heel schema opnieuw hoeft te maken.

De “now-next-later” aanpak kan zelfs worden gebruikt voor validatie-experimenten:

    • ‘Now‘ is het plannen van het experiment, zoals gebruikersinterviews of een smoke test,
    • ‘Next‘ het uitvoeren van het experiment zelf, en
    • ‘Later‘ staat voor het verzamelen en analyseren van resultaten en het trekken van conclusies.

In de dynamische en veranderlijke omgeving van productontwikkeling en -innovatie, waar planningen worden samengesteld uit schattingen, is het gebruik van harde einddata niet altijd aan te raden. Zeker Startups hebben te maken met producten die nog gevormd moeten worden. De flexibiliteit van een ‘now-next-later’ roadmap sluit daar goed bij aan omdat het een grote mate van evolutie en verandering toelaat.

Doelstellingen en kernresultaten

In het voorbeeld hierboven is voor elke fase van de roadmap beschreven welke doelen behaald moeten worden en wat de kernresultaten per doel moeten zijn. Het op deze manier in kaart brengen van alle activiteiten op een roadmap helpt je de doelstellingen die je wilt bereiken helder te communiceren.

Als je je productteam mee laat bepalen wat er per fase gedaan kan worden, dan zal je team ook de doelstellingen per fase onderschrijven.  De teamleden zullen ook meer gemotiveerd zijn om zelf met een aanpak te komen om de resultaten  te behalen.

Natuurlijk weet je team niet op voorhand welke functionaliteiten moeten worden gebouwd zullen worden gebouwd of wanneer die opgeleverd zullen zijn. Maar je teamleden weten wel dat ze 3 maanden hebben om zoveel mogelijk experimenten uit te voeren,  te itereren en meten om tot die resultaten te komen. Deze flexibiliteit maakt een  lean roadmap een goed hulpmiddel om experimenten in kaart te brengen en te plannen.

In plaats van al dat je je tijd te besteed aan he zo nauwkeurig maken van je tijdsinschattingen richt het team zich nu op het scherp krijgen van de experimenten die het meeste impact kunnen hebben voor de minste tijd.

Elke doelstelling zou je kunnen opdelen in Epics en verder in stories. Elke fase van je roadmap toont dan van elke doelstelling een aantal stories. Now bevat dan alle stories die in je huidige en eerstvolgende sprint moeten komen, Next toont de Epics en stories die al op je backlog staan.

Op deze manier kan je zowel je team inzicht blijven geven in waar aan gewerkt moet worden, als het hoger management laten zien hoe je werkt aan de totstandkoming van de gezamenlijk overeengekomen productdoelstellingen.

Een projectdoelstelling opdelen per fase
Een projectdoelstelling opdelen per fase
Een projectdoelstelling kan een Epic zijn met stories per fase, of in meerdere Epics en stories worden opgedeeld
Een projectdoelstelling kan een Epic zijn met stories per fase, of in meerdere Epics en stories worden opgedeeld
De Now fase toont de stories, naar prioriteit, in de huidige en eerstvolgende sprints
De Now fase toont de stories, naar prioriteit, in de huidige en eerstvolgende sprints
De rest van de backlog is gevuld met wat je 'Next' wilt oppakken.
De rest van de backlog is gevuld met wat je 'Next' wilt oppakken.

Verantwoording: Er is online veel te vinden over roadmap planning en de Now – Next – Later aanpak. In plaats van daar mijn eigen verhaal aan toe te voegen heb ik de beste informatie die ik vond vertaald en daar deze samengestelde post van gemaakt. De voornaamste bronnen die ik heb gebruikt zijn:

Geplaatst op

Een agile roadmap maken

Iedereen weet nu wel dat een bedrijf in een snel veranderende markt wendbaarheid moet zijn om op tijd in te kunnen inspelen op allerlei ontwikkelingen. Agile werkprocessen stimuleren die wendbaarheid en worden daarom vaak ingezet. Om over langere periodes een koers vast te kunnen houden is een lineaire roadmap handig. Dat lineaire schuurt alleen met de iteratieve agile aanpak.

Het probleem met roadmaps

De Agile Way of Working heeft voordelen als je de productontwikkeling wilt kunnen afstemmen op de veranderende vraag vanuit de markt en wensen vanuit het bedrijf; helderheid over wat wanneer wordt gedaan, de mogelijkheid om nieuwe wensen snel mee te nemen en een proces om obstakels vroegtijdig te benoemen en tackelen. Productroadmaps bieden op een andere manier ook helderheid en inzicht; over wat de visie is, waar we naartoe gaan en welke stappen we nemen om daar te komen.

De uitdaging is vaak om de Agile methodes goed te laten aansluiten op een productroadmap, en omgekeerd: De productplanning in een roadmap wordt lineair weergegeven en kan niet goed de build-measure-learn cyclus verbeelden die een agile ontwikkelproces juist zo effectief maakt. Een productroadmap kan dan als ongewenst gevolg hebben dat de organisatie gaat verwachten dat de oplevering ook lineair en tijdsgebonden is, wat de gewenste flexibiliteit en wendbaarheid in de weg staat. Maar alleen werken vanuit een actuele backlog borgt onvoldoende dat de productontwikkeling op koers blijft met de lange termijn doelen.
Is er een manier om Agile werken en roadmapplanning goed op elkaar te laten aansluiten?

Nut en noodzaak

Een productroadmap is een strategisch document op hoog niveau dat de algemene fasen van de ontwikkeling van een product in kaart brengt. Het is goed om de visie van een product op zo’n manier te verbinden met de bedrijfsdoelstellingen, dat de verschillende stakeholders inzicht hebben in de route die afgelegd gaat worden om de geformuleerde doelen te halen, en om de status van de productontwikkeling op een bepaald moment van te kunnen aflezen. Een productroadmap wordt gemaakt als resultaat van strategische planning, en verwerkt de inzichten van de verschillende stakeholders in een strategische routekaart. Het documenteert zowel de strategische aanpak die wordt gehanteerd als de algemene doelstellingen van een product en inzicht daarin is nodig. Een goede productroadmap kan in principe een hele organisatie op weg helpen met de realisatie van de bedrijfsstrategie.

De bouwstenen

Er zijn verschillende manieren om roadmaps te maken, maar wat je kiest om op je roadmap te zetten hangt af van voor wie je de roadmap maakt; wat wil je dat blijft hangen bij je publiek. Dat bepaalt uiteindelijk ook de opzet, het formaat en het soort informatie dat je in de roadmap wilt zetten. Traditioneel bevat een productroadmap een meerdere van de volgende punten:

    1. Productvisie – wat je wilt dat jouw product in de toekomst wordt
    2. Strategische aanpak – een plan dat tot in redelijk detail beschrijft wat men gaat doen om de visie te realiseren.
    3. Doelen – een in tijd bepaald doel dat op een helderen en eenduidige manier kan worden gemeten.
    4. Initiatieven – grotere thema’s die functies verenigen die moeten worden gebouwd en geïmplementeerd om het doel te bereiken.
    5. Features – een stuk functionaliteit vanhet product dat deel uitmaakt.
    6. Time-frames – globale tijdseenheden waarin, bij benadering een bepaald stuk functionaliteit wordt opgeleverd of een bepaald doel wordt behaald.
    7. Status markers – om aan te geven wat de status van een onderdeel is (complete, late on schedule, future).
    8. Meeteenheden – om te kunnen bepalen waaruit een bepaald doel dat behaald moet worden bestaat: e.g. churn rate of organisch verkeer.

Een standaard roadmap

Een typische roadmap en productvisie kan er uitzien zoals hieronder: Hoofdthema’s zijn in blokken functionaliteit onderverdeeld, globaal beschreven in Epics en in volgorde van prioriteit gezet. De doorlooptijd is met het team bepaald met T-shirt sizing, de onderlinge afhankelijkheid is verder af te lezen in de backlog.
Een standaard roadmap waarin hoofdthema’s in blokken functionaliteit zijn opgedeeld en in volgorde gezet.
De roadmap geeft zo de concrete vertaling in doorlooptijd en deadlines van de onderliggende productvisie.
De productvisie die bij bovenstaande roadmap hoorde werd als volgt geformuleerd:
 

For employees of the [company name] who want to use their expertise to their full potential and as effectively as possible, [product name] is a workflow management system for the visa and travel document application process, that guides the users through their activities in such a way that they can optimally apply their expertise, helping them to accurately perform tasks in compliance with laws and regulations.
Unlike the current process, this software fully digitizes all steps for handling visa- and travel document-application process, enabling more controlled processing of all applications, and more manageable and much speedier processing of the bulk of applications.
The endgoal is fourway:

      1. Replace the current end of lifecycle software
      2. Support the transition of the organisation from a decentralised to a centralised one.
      3. Support the transition of of the current application process from analog to digital
      4. Optimise the application workflow process​

Deze productvisie volgt het format voor een positioneringsstatement dat Geoffrey Moore in zijn boek Crossing the Chasm geeft.

For (target customer)
who (statement of the need or opportunity),
[product name] is a (product category)
that (statement of key benefit – compelling reason to buy).
Unlike (primary competitive alternative),
our product (statement of primary differentiation).

In twee korte zinnen wordt kernachtig geformuleerd wat het product voor wie wil zijn en hoe het zich wil onderscheiden.
De productvisie biedt zo een kader voor de productontwikkeling en formuleert het hogere doel dat we willen bereiken.

Wie is in de lead: DE PO OF DE PM?

De product manager (PM) en product owner (PO) houden zich beiden bezig met het communiceren van productdetails. Een PO is verantwoordelijk voor product value, backlog, en user stories, maar het belangrijkste verschil is dat een PO rol alleen binnen scrum-projecten bestaat. Een PO is dus vooral een rol en een Product manager (PM) een beroep. Een product manager kan ook een product owner zijn binnen een scrum-team, maar de PM levert een product roadmap met de visie en strategie, terwijl een PO werkt aan een product backlog en de business / technische requirements specificeert. De Product manager is dus degene die verantwoordelijk is voor de product visie en het opstellen van de product roadmap.
Maar als de rollen gescheiden zijn ontkom je er niet aan hier gezamenlijk werk van te maken.

Hoe kom je aan de input voor je productroadmap

Een product roadmap begint bij het formuleren van je strategie en visie op het product. Interne en externe stakeholders, klanten en afnemers, bieden inzichten die bruikbaar zijn, net zoals ontwikkelingen in de markt en die van concurrenten. Maar uiteindelijk is een visie ook iets wat vanuit een persoonlijk standpunt wordt gemaakt: hier sta jij, vanaf dit punt kijk je naar de toekomst heb je daar een bepaald perspectief op. Dat verwoord je in de productvisie.

Natuurlijk moet je de verwachtingen van alle belanghebbenden en teamleden wel op één lijn kunnen brengen, wat vaak nog een heel gedoe is, maar dan is er ook voldoende input om aan de roadmap te beginnen werken.

Meestal heb je meerdere teams die betrokken zijn bij roadmapping, zoals een development team, UX, test team, marketing, operationeel team, etc. Al die mensen in die teams helpen het product realiseren. Een type roadmap zal dan ook gericht zijn om al deze teams te begeleiden tijdens het ontwikkelingsproces. Het lukt niet om in een roadmap de veelheid aan informatie die voor alle verschillende teams relevant is duidelijk en eenvoudig te houden. Hoe ga je in een overzicht helderheid geven wat de strategie achter de productontwikkeling is, hoe die evolueert en verandert al naar gelang de product- en de marktvereisten, wat een hoge en wat een lage prioriteit heeft en wat alle afhankelijkheden per onderdeel tussen de teams zijn, welke doelen door welk team wanneer gehaald moeten worden, en aan welke bedrijfsdoelstellingen die gelieerd zijn

Wat je presenteert, en hoe je welke informatie communiceert wil je laten afhangen van je publiek, je stakeholders. Je wilt steeds helder de veranderingen door de tijd heen kunnen duiden, zodat voor iedereen duidelijk blijft hoe we ergens gekomen zijn en wat vanaf een bepaald punt de route wordt.

Het is een behoorlijke klus om van een redelijk complex product, dat in meerdere releases zijn uiteindelijke vorm moet krijgen, de productroadmap op te stellen.

En dan ga ik nog voorbij aan het probleem dat na verloop van tijd inzichten veranderen en dan nog een keer en weer opnieuw, en dat de roadmap die veranderende inzichten moet verbeelden. De beste plannen liggen ook meestal in de kast te verstoffen omdat de plannen waarmee je echt werkt steeds averij oplopen door onvoorziene omstandigheden die alles weer overhoop gooien. Roadmapping kan, als je niet oppast een hoofdpijndossier worden omdat je roadmap voortdurend dreigt te verouderden, of onmogelijk is te beheren.

Een productroadmap kan helaas ook niet een one-size-fits-all vorm hebben; zoals gezegd maakt het uit voor wie en met welk doel je een roadmap maakt: dat bepaalt het type, de inhoud en mate van detaillering. De roadmap heeft meestal meer dan één doelgroep, net zoals je product. 

Wat laat je hoe zien?

Gaat het je om de strategische koers te bespreken dan moet je focussen op de algemene visie en strategie, niet op de kleine details en overwegingen die voor je ontwikkelteam van belang kunnen zijn. Die kleinere stukjes informatie zijn waardevol maar ontnemen wel het zicht op de strategische keuzes: het moet duidelijk en makkelijk te begrijpen blijven. Voor je ontwikkelteam geldt wellicht meer dat ze ook willen weten welke keuzes ze qua techniek moeten maken, maar vooral wat ze de komende periode moeten gaan ontwikkelen.

Een goede roadmap heeft net de juiste mate van abstractie om wel inzicht te geven in wanneer wat mag worden verwacht, zonder dat het je teveel vastpint op harde datums of het je ontwikkel- en realisatieteam verhindert om flexibel te bepalen wanneer wat het best kan worden opgepakt.

Interne roadmaps zijn over het algemeen bedoeld voor leidinggevenden, het productieteam en verkoop, die een meer strategische kijk hebben op de gegevens. Dus de presentatie van roadmap moet zich dan richten op visie, strategische doelen, tijdlijnen, marktcijfers, enzovoort. Het ontwikkel- en implementatieteam is vaak meer geïnteresseerd in de tactische aspecten, deadlines, en technische details van de uitvoering. Om voor hun echte waarde te hebben moet de roadmap inzicht geven in low-level informatie, over concrete onderdelen van een product, de features of technische aspecten. Een verkoopteam zal weer vooral geïnteresseerd in die combinatie van productkenmerken en productvoordelen die voor klanten interessant zijn. Dan moet uit de roadmap blijken wanneer welke product features beschikbaar komen. Maar je ontwikkelteam moet uit dezelfde roadmap kunnen halen wat er moet worden voorbereid en waar al aan gewerkt moet worden.

Niet zo verwonderlijk dat veel Product Managers worstelen om zowel de strategisch als de uitvoerende aspecten goed in een roadmap samen te brengen, zeker als die ook nog voor een agile team werkbaar moet blijven. Want in het ergste geval verwordt een roadmap tot een release kalender van features, wat dus geen roadmap is, maar waar het senior management je graag aan houdt ook als er veranderingen moeten worden doorgevoerd!

En natuurlijk betrek je je team bij het maken van inschattingen, maar het punt is, en iedere product manager weet dit, dat de data die je op je roadmap zet compleet verzonnen zijn, en het is hoogst onwaarschijnlijk je team ook maar iets zal opleveren zoals geschetst.

Wat is een aanpak om een goede eenduidige roadmap te maken die makkelijk up to date is te houden, kan omgaan met veranderingen en daarbij niet de strategische doelen en kritische tijdschema’s uit het oog verliest?

Lean roadmapping: Now – Next – Later

Een roadmap wil je idealiter lezen als een gids, een routekaart, die het doel op lange termijn aangeeft, helder maakt wat de stappen zijn om daar te komen en flexibel genoeg is om wijzigingen in aan te brengen die nodig zijn om relevant, want up to date, en nuttig te blijven.

Daarom kan je een roadmap het best concentreren op 3 zaken (die dan wel alle 3 op een of andere manier helder moeten worden verbeeld):

    1. Je visie: wat willen we zijn & waar willen we eindigen.
    2. Je kompas: in welke algemene richting moeten we gaan om daar te komen.
    3. Je plan: de reeks stappen, richtlijnen en instructies die we zullen nemen om er daadwerkelijk te komen.

Het ‘Now-Next-Later‘ format is ontworpen om de essentie van deze 3 aspecten in een simpel kader te tonen, maar biedt ook ruimte voor flexibiliteit en dwingt niet af dat je je moet vastpinnen op harde einddata in een toekomst waar je je nog op moet kunnen aanpassen.

De 3 fasen toegelicht:

Met de ‘Now-Next-Later’ aanpak splits je de roadmap op in drie secties (Now, Next, Later) zodat je op elk moment aan stakeholders het volgende detailniveau kan laten zien, terwijl er ruimte blijft om aanpassingen te maken. De roadmap kan gaandeweg worden aangepast om in lijn te blijven met veranderende in- en externe omstandigheden.

Deze fase omvat waar het team in de eerstvolgende sprints aan gaat werken en wat zal worden opgenomen in de eerstvolgende release. In deze fase kan het team specifieke details laten zien over functionaliteit en features, inclusief ontwerpen, prototypes, werkende software en demonstraties.

Deze fase is wat breder dan de Now-fase. Het omvat de zakelijke uitdagingen die het team van plan is aan te pakken in een volgende release van het product. Maar omdat het verder weg is, is het wat algemener omschreven en daarmee flexibeler dan de Now-fase.

Deze Next fase beschrijft bijvoorbeeld waar we aan denken voor een volgende release en waar we nog feedback van klanten van moeten krijgen, en over de high level aanpak op de komende ontwikkelingen. Die fase moeten we wel voorbereiden om de Objectives and Key Results ( OKR’s) goed op te stellen en de stories in de refinement meet te kunnen nemen. Want anders gaat die volgende release niet voldoen aan wat de stakeholders en klanten als ‘business value’ willen opgeleverd krijgen. Er mogen geen features blijven liggen omdat ze nog niet scherp omschreven zijn en daarom niet opgepakt kunnen worden wanneer het nodig is.

In deze fase kijken we op een hoger niveau naar wat er nog veel verder in de toekomst gaat komen. Waar denken we nog meer aan, maar wat komt nog niet in de eerstvolgende releases? Wat is waar in de komende 1 tot 3 jaar behoefte aan is, of waar we mee te maken zullen krijgen. Bijvoorbeeld hoe het technologisch landschap gaat veranderen, wat we moeten doen om ons product voor te bereiden op veranderingen in de markt of andere acties die nodig zijn om waarde te kunnen blijven bieden.

Deze Now, Next, Later-aanpak stelt je in staat om ook conceptueel met klanten en stakeholders te praten over bedrijfsproblemen en technologische keuzes, zonder dat je je al vroeg hoeft vast te leggen op specifieke functionaliteit die beschikbaar gaat komen. Hetzelfde format kan zowel op hoog abstract niveau worden gebruikt voor strategische discussies, als voor het bepalen welk werk moet worden voorbereid voor je ontwikkelteam.

Andere voordelen van deze vorm van roadmapping:

    • Het pint je niet vast op specifieke data maar richt zich meer op periodes van tijd en intentie.
    • Het verdeelt werk in brokken en helpt zo te begrijpen wat je in welke volgorde moet doen en voorbereiden.
    • Het is makkelijk te reorganiseren en is makkelijk om de strategische punten te overzien (bijvoorbeeld tussen “Now” en “Next”) om zo het stappenplan aan te passen zonder alles weg te gooien of opnieuw te moeten beginnen.
    • Het kan worden toegepast op veel verschillende soorten situaties (jaarlijkse strategische planning, een re-design / digitaal transformatieproject of een product van de grond af aan).
    • Het biedt duidelijk te begrijpen kaders voor iedereen, niet alleen mensen uit het ontwikkelteam, en kan zo breed worden ingezet bij de realisatie.

Benieuwd naar hoe een Now-Next-Later roadmap concreet kan worden ingevuld? In deze vervolg-post heb ik een paar voorbeelden uitgewerkt van hoe een Now-Next-Later roadmap kan worden. 

Verantwoording: Er is online veel te vinden over roadmap planning en de Now – Next – Later aanpak. In plaats van daar mijn eigen verhaal aan toe te voegen heb ik de beste informatie die ik vond vertaald en daar deze samengestelde post van gemaakt. De voornaamste bronnen die ik heb gebruikt zijn:

Geplaatst op

Succesvolle fouten

Art Fry - Post it inventor

Eric Ries deed de uitspraak Fail fast to succeed faster en in zijn boek legt hij uit wat hij daarmee bedoelt; hoe je snel succesvolle producten of diensten kunt ontwikkelen door snel achter de fouten te komen in je aannames. Maar soms ontstaan goede uitvindingen uit die fouten zelf.

Bekende voorbeelden van dit soort succesvol ‘falen’, zijn de zoetstof Sacharin, ontdekt omdat iemand zijn handen niet had gewassen en opmerkte dat bij het avondeten alles plots zoet ging smaken, de Pacemaker (door per ongeluk een verkeerde weerstand te gebruiken ontstond er een impuls in een elektrisch circuit die leek op een hartslag), Teflon, de Magnetron en de inktjetprinter.

Al deze ‘foute uitvindingen’ hebben met elkaar niet alleen gemeen dat het falen een kans kreeg, maar dat de uitvinder de waarde van de fout herkende. Zou het niet mooi zijn om een aanpak te hebben die helpt fouten van waarde te maken.

Iemand die bijvoorbeeld actief op zoek ging naar fouten was reclamepionier David Ogilvy. Hij nam vaak bewust “foute” advertenties op in zijn tests – advertenties die volgens hem nooit zouden kunnen werken. De meeste van deze “losers” faalden ook zoals verwacht, maar een paar bleken dan toch te slagen – en die brachten hem op innovatieve reclamebenaderingen.

Alsmaar falen kan ook duur worden, zeker als gevestigd bedrijf wanneer je niet de ‘luxe’ van een startup hebt, waarvan klanten nog geen duidelijke verwachting hebben. Dus de vraag is dan relevant hoe je goedkoop en met weinig risico succesvol kan falen.

Ik las in een oud HBR artikel de volgende omstandigheden de kans op het vinden van succesvolle fouten groter maken.

    1. Experimenteer bijvoorbeeld met opzettelijk fouten maken wanneer de risico´s in het niet vallen bij de mogelijke opbrengsten. zoals in het reclamevoorbeeld van Ogilvy.
    2. Experimenteer met fouten maken wanneer je breed kunt testen: Citibank besloot op gegeven moment bijvoorbeeld om toch aan studenten creditcards te verstrekken zonder iemand garant te laten staan. Tot die tijd moest dat wel omdat studenten vaak grote schulden aangingen zonder een baan te hebben. Door die aanpak kregen ze plots veel nieuwe klanten, wat ook de opzet was. Maar tegen de verwachting in bleken veel ouders toch bij te springen als de schulden te hoog werden. Daarnaast bleven studenten die al vroeg een creditcard kregen vaak tot ver in hun werkzame leven klant bij Citibank.
    3. Experimenteer met je aannames wat ‘fout’ is wanneer de omgevingsfactoren drastisch veranderen in je testopzet. Procter & Gamble bleef lange tijd hun patenten agressief verdedigen en hield vast aan het idee dat innovaties alleen van binnen konden komen. Op een gegeven moment besloot het de patenten die toch niet in gebruik waren open te stellen voor andere bedrijven. Sommige van de producten die externe ondernemers op basis van deze patenten ontwikkelden bleken kaskrakers te worden, zoals Swiffer, zonder dat P&G daar zelf veel  ontwikkelgeld in had hoeven steken. BMW heeft met hun Connectdrive programma soortgelijke innovaties ‘ontwikkeld’.

De volgende stappen helpen om er achter te komen welke fouten je het best kunt maken om verrast te worden door mogelijk succes:

    1. Breng je aannames in kaart. Organiseer een brainstorm om al je aannames in kaart te brengen. Een tool als het validation canvas kan nuttig zijn hierbij (Een praktische tool om producthypotheses te testen).
    2. Prioriteer je aannames om te bepalen welke je het best kunt testen. Vraag je af wat je anders zou doen als je zou weten dat je aanname niet klopt. Hoe groter de impact op je bedrijf is, des te waardevoller het kan zijn juist deze aanname te testen.
    3. Ontwikkel een teststrategie en voer die uit. Bepaal welke aanpak het best werkt om je test mee uit te voeren en specificeer aan welke voorwaarde de test moet voldoen.
    4. Evalueer het effect: wat leverde het op en welke aannames moeten worden bijgesteld

Het actief testen van je aannames en je productideeën, zoals in deze laatste vier stappen, is een vast onderdeel van de Lean productinnovatie aanpak en een tool om je te helpen met het in kaart brengen van de aannames is het assumption canvas. In Pics or it didn’t happen licht ik toe hoe je dat kunt gebruiken. 

Geplaatst op

Ouderdom radicaal omdenken

Leven in een oude schoolbus in de bergen van Canada is waarschijnlijk niet hoe de meeste gepensioneerden voor zich zien hun oude dag te slijten. Maar als het gaat om zelfredzaamheid en het leven zelf invullen, ook als oudere, dan is er niet veel op het verhaal van Dag Aabye af te dingen.

Put people in an elderly home and you tell them it’s time to die.
Dag Aabye

Z’n hele verhaal kan je hier lezen, maar de video is leuk genoeg.

Geplaatst op

Thankyou! Life-changing goods

Een prachtig uitgangspunt voor iedereen, dankbaar zijn en dat uiten, is door de oprichters van dit bedrijf als leidraad genomen.

Thankyou. Thankyou is a social enterprise. We believe we can end global poverty in this lifetime, together. That’s why we commit 100% of the profit from our products to helping people in need:

Of zoals ze zelf als statement op hun site zetten:

Er is een duisternis in onze wereld. 1 miljard mensen leven in extreme armoede.
Dat wordt nog donkerder door het feit dat in dezelfde wereld extreem consumentisme bestaat. Elke dag geven we als consumenten miljarden dollars aan ’s werelds grootste multinationals voor dagelijkse producten.
Wij denken we dat het tijd is om het licht te brengen.

Dat laatste klink misschien wat aanmatigend, maar ze maken het tot nu toe wel waar: Thankyou, Life-Changing Personal Care, Water and Baby Products.

Geplaatst op

Algoritmen aan het stuur?

Wanneer laten we machines en algoritmen beslissen, waar willen we zelf aan het stuur blijven,en wanneer willen we dat de overheid zicht houdt op digitalisering?

In dit opinieartikel van de VNG wordt gepleit voor dat laatste. Maar met alle problemen die de overheid nu al heeft met de digitalisering in goede banen leiden is het maar de vraag of dat zo’n goed idee is.
Al eerder had de Nationale Onbudsman daar ook zo zijn bedenkingen tegen.

Geplaatst op

LAWN PAINTING!?

Innovatieve ideeën ontstaan vaak door een bekende oplossing in een compleet andere context toe te passen. Deze schilder doet dat met zijn werk en verdient nu bij met wat in essentie ook nog een geweldige lifehack is: Lawn painting Je was er niet opgekomen, maar nu je het ziet is het heel voor de hand liggend.
Geplaatst op

Gambling for innovation

Ik las een leuke blogpost van Jeroen van der Weide van Tasman innoveert Goed fout  waarin hij zich afvraagt waarom wij zo krampachtig omgaan met fouten. Fouten zijn nodig voor verandering wat iedereen beaamt maar toch zijn weinig mensen bereid fouten toe te geven en daarvan te leren. Zo verstart je creativiteit en innovatievermogen! Meer openheid dus en hij voegt de daad bij het woorden en plaatst zijn eigen failure journal op de site :)
Bouwen op je fouten geeft je innovatievoordeel: Als je wilt onderzoeken waar je succesvol in kunt zijn dan zal je immers moeten experimenteren. Falen is dan onvermijdelijk want goed experimenteren kan niet zonder; je komt er achter wat fout gaat. Ik heb daar eerder een presentatie over gegeven: Vision innovation and inevitable failure. Je businessmodel moet falen juist ondersteunen en niet uitbannen.

BBC & The Office

Ik vond onderstaande video van Jeremy Gutsche waarin hij (een beetje schreeuwerig) in gaat op de noodzaak van falen als je wilt innoveren. Hij geeft een mooi voorbeeld van de BBC dat op een gegeven moment merkte dat er minder mensen keken naar hun programma’s en zoals veel bedrijven uit angst om nog meer te verliezen conservatief ging innoveren: volgens een rigide en gecontroleerd proces moesten nieuwe ideeen bedacht worden. Dat  hielp niet en de directie werd vervolgens naar huis gestuurd.

De nieuwe directie wilde niet direct teveel overhoop halen en besloot alles bij het oude te laten met ?®?®n verschil: er kwam een potje om te gokken. Idee?½n die te wild of afwijkend leken om gelijk breed te programmeren maar die ergens toch kansrijk konden zijn kregen wat gambling money mee. Zo kwamen ook Ricky Gervais en Stephen Merchant aan een klein budget om hun eerste afleveringen van The Office te make: want het idee was te afwijkend van wat de BBC tot dan toe deed.

En dankzij dat budget om mee te gokken werd The Office het grootste succes van de BBC.

Wil je meer lezen over hoe  je een bedrijfscultuur kan ontwikkelen die wil leren van de eigen fouten om zo beter te innoveren dan kan je hier Fail Forward lezen het artikel  waar Jeroen in zijn blogpost ook naar verwijst.

Geplaatst op

Pics or it didn’t happen!

Regelmatig merk ik dat de bouwfase van een project wordt gestart zonder dat de aannames die aan het project ten grondslag liggen goed zijn getest. De businesscase waarop het project goedkeuring heeft gekregen blijkt dan met name bedoeld  om het hoger management te overtuigen van mooie omzetkansen en het productconcept is niet veel meer dan de vertaling van de wensen van het eigen business team in een fraaie powerpoint met mock up.

Het blijkt lastig om op zo’n moment dan ruimte te vinden om kritische vragen te stellen; Is het idee ook bij de feitelijke doelgroep  getest: die mensen waarvan in de Powerpoints en Excelsheets wordt uitgegaan dat ze ook echt op het product zitten te wachten?

Ontwerp-aannames zijn te vaak met name gebaseerd op deskresearch en een marktscan. Uitgebreid onderzoek onder potentiële gebruikers wordt vaak te duur gevonden wat natuurlijk ook zo kan zijn. De heersende gedachte is dat een product zich uiteindelijk toch in de markt moet bewijzen en dat het testen van aannames wel tot vertraging en extra kosten leidt maar nauwelijks het succes van het product zal beïnvloeden. Maar de eerste vraag is eigenlijk welke aannames het grootste risico met zich meebrengen, en de vervolgvraag moet dan zijn: hoeveel zekerheid hebben we dat deze aanname correct is? Zonder antwoord op die twee vragen vaar je een blinde koers. Dus hoe kunnen we de aannames valideren, wat kan als bewijs dienen dat we goed zitten enn hoe hard kunnen we dat bewijs maken: Pics or it did’t happen?

Het validation canvas is praktische, kortcyclische en hands on methode om snel de belangrijkste aannames over de kernproblemen van je doelgroep, en je beeld van wat daar de beste oplossing voor zou zijn, te testen. Met de uitkomst van het canvas kan je met meer vertrouwen starten en tekortkomingen onderbouwd worden aangekaart. Met de uitkomsten van je experimenten kan je het management makkelijker overtuigen om noodzakelijke veranderingen door te voeren of de prognoses bij te stellen

Het Validation Canvas

De kick off fase van een project is een goed moment om een korte workshop te plannen rond het validation canvas. In een of twee dagen kan met een klein team van niet meer dan 5 man de doelgroep- en ontwerphypotheses van het product worden doorgelicht waardoor je nog voor aanvang van het project foutieve aanname opgespoord krijgt..

Het validation Canvas kan er een beetje intimiderend uit zien maar het is vrij eenvoudig in het gebruik.

Werksessie

Het invullen van het validation canvas wordt door je team gedaan in de vorm van een workshop. Begin met alle producthypotheses op post-it notes te schrijven. Schrijf alle aannames over de doelgroep het probleem en de bedachte oplossing op en zorg ervoor dat je ze makkelijk kunt herschikken: je wilt beginnen met de belangrijkste aannames dus je moet de post its makkelijk kunnen prioriteren.

      1. kernhypotheses.
        Begin met onder elkaar je klanthypothese dan de daarop gebaseerde probleemhypothese en vervolgens de oplossing waarvan je aanneemt dat die de veronderstelde customer pain kan oplossen op te plakken.
      2. veronderstelde oplossingen.
        Bepaal vervolgens wat de belangrijkste veronderstelling is waarop je de productoplossing hebt gebaseerd. Bepaal daarbij de mate waarin die hypothese cruciaal is voor het succes van je productidee of businessmodel.
      3. prioritering
        Bepaal nu wat de meest risicovolste veronderstelling is voor jouw businesscase en ga die testen om er zeker van te zijn dat je niet bezig bent een probleem op te lossen dat niet bestaat voor je klanten.
        Dit doe je in de Minimal Viable Product (MVP) fase. Hier ga je beslissen hoe je de hypothese feitelijk gaat testen. Belangrijk hierbij is dat je bepaalt wat de minimale criteria voor succes zijn van de test: het minimale resultaat moeten gelden om de aanname als valide te beschouwen. Als je bijvoorbeeld wilt testen of jouw doelgroep jouw dienst wil afnemen dan kan je succescriterium zijn: 90% van de ondervraagden is bereid om direct 5 Euro te betalen. Een andere omschrijving: 90% van de bezoekers op de dummysite is bereid adres- en e-mailgegevens achter te laten o meer over het product te weten te komen.
        NB: Vrienden en collega’s tellen niet als geïnterviewden.
      4. Field test
        Volgens stap: test je hypothese: get out of the building. Dit kan betekenen dat je daadwerkelijk de straat op gaat om je verhaal te testen bij zoveel mogelijk mensen maar je kan ook een Google Ad campagne opzetten en je hypothese online A/B-testen
      5. Pivot
        Na de field test is is je hypothese hetzij gevalideerd of ongeldig gebleken. Als je hypothese niet bleek te kloppen dan moet je jouw productaanname hereiken en soms misschien je hele propositie omgooien: een pivot.’

A pivot is a change in strategy without a change in vision.

U cannot have a pivot without a vision.

thats just wandering around!

Dat lijkt frustrerend maar feitelijk heb je jezelf zojuist een dienst bewezen door in een vroeg stadium al een belangrijke hypothese onderuit te halen.
Is je hypothese wel gevalideerd dan pak je de eerstvolgende kernhypothese en ga je net zo lang door totdat je alle hypothese hebt gevalideerd of een businesscase of productdefinitie hebt gevonden die zowel voor je bedrijf waardevol is als ook een echt probleem van je klant oplost.

Het validation canvas is een snelle en hands on manier om er achter te komen of je businessmodel of productidee wel hout snijdt. En mocht je gefrustreerd raken van de vele pivots die je moet maken vergeet dan een ding niet: if you Fail Fast you will Succeed Faster.