Auteur: Onno

Geplaatst op

Waarom Visies mislukken zonder duidelijkheid waar beslissingen over moeten gaan

Een visie kan inspireren. Maar zonder beslishelderheid is het vaak niet meer dan een mooi verhaal en eerder zelfs een rem op vooruitgang.
Een visie wordt graag gezien als het definitieve – zo niet beslissende – startpunt voor verandering. Er worden heel wat hie-sessie aan besteed om een visie goed te verwoorden. Maar in de praktijk schiet een visie, hoe briljant ook verwoord, vaak tekort omdat die als het op de uitvoering aankomt alsnog te vaag is omschreven. Soms wordt vaag als veilig gezien, Maar het is riskant om te denken dat zolang die visie vaag genoeg blijft en losstaat van echte beslissingen die toch richtinggevend kan zijn. Erger nog is het wanneer zo’n visie als in steen gebeiteld wordt gezien en de organisatie verkrampt, waarmee die een beperking wordt op de vooruitgang die een visie juist hoopt bewerkstelligen.

Helmut Schmidt vatte die scepsis al ooit messcherp samen: “Wer Visionen hat, sollte zum Arzt gehen” (“Wie visioenen heeft, moet naar de dokter”). Ook Mark Rutte waarschuwde in vergelijkbare termen dat een visie kan blokkeren in plaats van verhelderen: “als een olifant die het zicht blokkeert”. In de kern wijzen deze vermaningen naar hetzelfde gevaar: een levendig ingebeelde toekomst kan verharden tot schijnzekerheid en beslissingen dwingend gaan sturen vóór we goed en wel weten of die toekomst überhaupt realistisch is.

Maar is het omgekeerde ook waar. Besluitvorming zonder heldere visie ontaardt al snel in een eindeloze reeks “pivots”, waar gebrek aan richting, een duidelijke koers voorwaarts, zich vermomt als pragmatisme. Dan wordt elke stap verdedigbaar, maar is niets nog betekenisvol: waar stuur je naartoe als het onduidelijk is welke toekomst je eigenlijk dient?

De echte uitdaging in corporate innovatie zit precies in die spanning: hoe vertaal je toekomstdenken naar beslissingen die vandaag genomen moeten worden—onder onzekerheid?

  • Wanneer visie botst met technologische realiteit (een praktijkverhaal)

In mijn werk als innovatieconsultant zag ik hoe snel een gedurfde visie kan wankelen wanneer de beslissingen die haar moeten dragen niet expliciet zijn.

Een innovatieteam vertrok vanuit een ambitieus idee: een getokeniseerd distributieplatform bouwen dat nieuwe businessmodellen en bredere ecosysteemparticipatie mogelijk zou maken. De start was veelbelovend:

  • een interne businessunit stapte in als launching customer met een solide businesscase
  • een technologiepartner bood een geavanceerd DLT-platform dat structureel concurrentievoordeel beloofde

De aanpak was gefaseerd. Fase 1 digitaliseerde het end-to-end proces voor de interne klant (contractafhandeling stroomlijnen, doorlooptijd verkorten). Dat was een bewuste opstap naar fase 2: een gedeeld multi-party transactieplatform waarop meerdere financiële instellingen konden aansluiten—met potentiële netwerkeffecten en nieuwe proposities.

Op papier had fase 1 ook met een conventionele API-oplossing gekund. In de praktijk zat het verschil niet in “of het werkt”, maar in wat je later nog kán.

Een API-route zou een zware datalaag vragen (governance, standaardisatie, integratie tussen partijen). En vooral: zodra je die route kiest, wordt het later veel moeilijker om alsnog door te groeien naar een getokeniseerd multi-party platform. Architectuurkeuzes zijn niet neutraal; ze sluiten opties af.

Vanuit het perspectief van fase 2 was DLT daarom geen implementatie-detail, maar een strategische keuze: het openhouden van de beoogde ontwerp-ruimte.

Het kantelpunt: een ‘pragmatische’ keuze die de toekomst afsluit

Toen trok de technologiepartner onverwacht de nieuwste platformversie terug wegens tegenvallende marktadoptie. Wat strategisch leek, werd ineens onzeker.

De reactie was voorspelbaar: besluitvormers kozen voor de veilige, standaarden-conforme API-oplossing. Die paste bij bestaande governance- en kostendoelen en leverde nog steeds een robuuste businesscase voor fase 1.

Maar die keuze had een prijs:

  • toekomstig schaalvoordeel en geloofwaardige netwerkeffecten werden veel minder waarschijnlijk
  • externe partijen hadden weinig incentive om aan te haken
  • het venster om leiderschap (of zelfs fast-follower status) te claimen sloot
  • en belangrijker: de platformthese kon niet meer realistisch getest worden

De visie werd niet “weerlegd”. Ze werd simpelweg onmogelijk gemaakt.

De les achteraf: wat er ontbrak was geen ambitie, maar een besliskader

Achteraf leek het alsof de organisatie de visie niet serieus nam. In werkelijkheid ontbrak iets anders: een expliciet besliskader voor het moment waarop onomkeerbare keuzes moesten worden gemaakt.

De keuze tussen API en DLT werd behandeld als implementatiekwestie. Maar voor de propositie als geheel was het een strategische beslissing met langetermijnimpact op:

  • schaalbaarheid
  • ecosysteempositionering
  • ontwerpvrijheid

Mijn eigen rol speelt hier ook mee. Ik heb onvoldoende expliciet gemaakt dat de DLT-keuze niet ging over “succes garanderen in fase 1”, maar over de optie-waarde: het behouden van de mogelijkheid om fase 1 te laten evolueren naar een getokeniseerd multi-party platform.

Die optie-waarde had je moeten:

  • articuleren (welke toekomst dient dit?)
  • beprijzen (welke extra kosten accepteren we?)
  • en koppelen aan timing (hoe lang staat dit venster open?)

Van visie naar beslishelderheid: vier vragen die je móét beantwoorden

Visie hoeft niet te falen. Maar dan moet je expliciet maken welke beslissingen vandaag de toekomst van morgen openhouden.

Vier vragen helpen om visie te vertalen naar beslishelderheid:

  1. Welke toekomstige uitkomst dient deze optie?
  2. Hoe lang blijft het beslisvenster open?
  3. Welke triggers rechtvaardigen opschalen (of stoppen)?
  4. Welke kosten zijn acceptabel om de optie levend te houden?

Als je deze vragen niet beantwoordt, wordt visie óf een illusie (te vaag om richting te geven), óf een blauwdruk (te rigide om met realiteit mee te bewegen).

Beslishelderheid voorkomt beide. Zonder beslishelderheid leidt visie innovatie niet; ze verdampt stilletjes bij de eerste echte ontmoeting met onzekerheid.

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

Workshop ‘Innoveren vanuit klantperspectief’

U gaat een nieuw product ontwikkelen dat werkelijk onderscheidend is. Daarom wilt u begrijpen welke typen klanten er zijn, hoe hun dag verloopt en welke problemen ze momenteel ervaren rondom de te ontwikkelen product of dienst.

Wat komt aan bod?

In de workshop ‘Innoveren vanuit de klant’ duikt u in de wereld van uw doelgroep. U verzamelt en deelt kennis over de klant en legt de klantreis – de customer journey – vast. Welke stappen doorlopen klanten, welke touchpoints komen ze tegen? Wat ervaren ze daarbij? En wat zijn de knelpunten die ervoor zorgen dat de huidige oplossing niet of minder wordt gebruikt?

Resultaat

  • Inzicht in de knelpunten en kansen waarop het nieuwe product een antwoord gaat bieden.
  • Poster met uitgewerkte klantreis om aan de muur te hangen, als houvast tijdens het ontwikkelproces.
  • Een team dat denkt vanuit klantbehoeften

Workshop details

Voor wie?

Voor productontwikkelaars, productmanagers, marketeers, ontwerpers, architecten, enz.

Hoeveel deelnemers
Deze workshop kan incompany gegeven worden voor een team van 4 tot 16 man.

Tijdsbesteding:
2 tot 3 dagdelen

Geplaatst op

Workshop Businessmodelling

Voelt u de noodzaak om uw businessmodel te vernieuwen maar ontbreekt het u aan de tools om hiermee te beginnen?

Het Business Model Canvas is een praktische tool om de bouwstenen van uw businessmodel in kaart te brengen, te analyseren en innoveren. Deze workshop geeft u een helder model van hoe uw bedrijf opereert en praktisch tools om uw business model zo te vernieuwen dat uw organisatie gericht kan innoveren.

Wat komt aan bod?

Tijdens deze workshop combineren we tools als het business model canvas met andere technieken om tot een vernieuwende inzichten te komen en u te helpen uw strategie in te vullen.
Onderwerpen:

  • De negen bouwstenen van het een businessmodel,
  • Analyse van uw huidige business model met het business model canvas,
  • Impact van trends op uw businessmodel,
  • Nut van doelgroepomscrhijving: Personas en Empathy mapping,
  • Vinden en benoemen van innovatiekansen,
  • Business Model Redesign

Resultaat

  • Inzicht in de sterke en zwakke kanten van uw businessmodel
  • inzicht in het toepassen van de tools om uw businessmodel te vernieuwen
  • nieuwe, concrete ideeën en inzichten voor uw businessmodel

Workshop details

Voor wie?
Voornamelijk voor productontwikkelaars, productmanagers, marketeers, ontwerpers, architecten, enz.

Hoeveel deelnemers
Deze intensieve workshop wordt gegeven in een centraal punt in Nederland voor een groep van 12 tot 16 man.

Tijdsbesteding:
2 dagdelen

Geplaatst op

Kairos FOBO2020

Uitdaging: 

Het Ministerie van Buitenlandse Zaken stond voor de uitdaging om het aanvraag- en behandelproces van visa te moderniseren. Het bestaande systeem was analoog en centraal georganiseerd, wat leidde tot inefficiënties en verouderde werkwijzen. Er was behoefte aan een digitale, decentrale oplossing die de organisatie zou kunnen transformeren en legacy systemen zou kunnen vervangen.

Aanpak

Als Product Owner leidde ik de ontwikkeling van Kairos Visa, een innovatief back-officesysteem voor visumaanvragen binnen het FoBo-programma. Mijn taken omvatten requirements afstemmen, roadmap opstellen en het ontwikkelteam aansturen. Ik vertaalde complexe processen naar een gebruiksvriendelijke interface en beheerde de ontwikkeling. Een uitdaging was het balanceren van zakelijke behoeften met teamsnelheid, terwijl ik stakeholders en eindgebruikers in een politiek gevoelige omgeving moest managen.

Impact

Het nieuwe systeem optimaliseerde werkprocessen door zaken te verdelen op basis van expertise. Dit verkortte beoordelingstijden en transformeerde operationele workflows. Het project moderniseerde consulaire diensten, faseerde legacy systemen uit en creëerde een flexibel platform voor applicatie-integratie, wat de organisatie-efficiëntie aanzienlijk verbeterde.

Kairos 2.0 interface, afhandeling visumaanvragen
Rol: PRODUCT OWNER
Bedrijf: MINISTERIE BUITENLANDSE ZAKEN
Doel: REALISATIE KAIROS

” Het project Kairos ontwikkelt het backofficesysteem voor de afhandeling van visumaanvragen (ter vervanging van de bestaande systemen NVIS en Visana) om een digitaal proces mogelijk te maken. Dit Kairos project bestaat uit 3 fasen. Kairos 1.0 maakt het nu reeds mogelijk om de documenten van een visumaanvraag digitaal naar de backoffice te sturen ter beoordeling. Ook is het al mogelijk aanvragen op basis van bepaalde kenmerken onder de medewerkers te verdelen. De verdere afhandeling van de Schengenaanvragen vindt in deze fase echter nog plaats in het bestaande systeem NVIS. Kairos 2.0 is bedoeld om Caribische visumaanvragen af te handelen en komt ter vervanging van Visana. Deze module is begin 2022 geïmplementeerd waarmee het Caribische visumproces nu volledig digitaal kan worden uitgevoerd. Het oude systeem Visana is inmiddels uitgefaseerd. In 2023 zal Kairos 3.0 in gebruik worden genomen. Daarmee zal ook het Schengen visumproces volledig digitaal worden uitgevoerd en NVIS worden vervangen. “

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

De Opstartfabriek

Uitdaging: 

Jaarlijks stoppen duizenden goed functionerende MKB-bedrijven vanwege het ontbreken van een opvolger. Bedrijvenmakelaars tonen weinig interesse in deze sector vanwege de lage overnamemarges. Tegelijkertijd bieden gemeentes werkzoekenden slechts twee opties: begeleiding naar werknemerschap of het starten van een eigen onderneming, waarbij overnames buiten beschouwing worden gelaten.

Aanpak:

De Opstartfabriek heeft een innovatieve methodiek ontwikkeld die het ondernemerspotentieel bij werkzoekenden stimuleert en doorontwikkelt. Deze aanpak ziet de situatie als een markt van latente vraag en aanbod, waardoor overnames in het klein-MKB mogelijk worden. Het idee werd uitgewerkt tot een businesscase en subsidievoorstel, gevolgd door de opzet en het management van een marketing- en trainingsprogramma na toekenning van subsidie door SZW.

Impact:

In één jaar tijd hebben 149 deelnemers het trainings- en coachingsprogramma doorlopen. Tot 70% van de deelnemers is na afronding weer toegetreden tot het arbeidsproces, waarvan de helft als ondernemer of zzp’er. Er zijn zes succesvolle overnames gerealiseerd. Deze aanpak draagt bij aan het behoud van werkgelegenheid in de regio en stimuleert werkzoekenden om via een overname te starten als zelfstandig ondernemer.

Rol: CO-OwnER | Programmamaker | Coach
Bedrijf: de opstartfabriek
Doel: Vergroten Arbeidsparticipatie door overnames