De levenscyclus van innovatie volgen
Tailwind Traders heeft ook vragen over innovatie die van invloed zijn op veel andere organisaties:
- Hoe verhogen we het wijzigingspercentage zonder dat dit van invloed is op het actieve bedrijf?
- Hoe bepalen we waar we moeten innoveren en welke wijzigingen moeten worden geïmplementeerd om het bedrijfsrendement van die innovaties te maximaliseren?
Het antwoord op beide vragen is: Tailwind Traders moet verandering omarmen als onderdeel van de organisatiecultuur. Een van de redenen waarom wijzigings-averse organisaties vaak wijzigingsgerelateerde storingen hebben, is dat deze wijzigingen te groot en impactvol zijn. De wijzigingen zijn moeilijk te testen in gecontroleerde en realistische omgevingen.
Als processen tot stand worden gebracht om regelmatig wijzigingen te introduceren, zijn deze wijzigingen kleiner en risico. Dit proces houdt echter niet alleen in dat bepaalde hulpprogramma's of technologieën worden gebruikt. Het vereist een cultuur die verandering bevordert en fouten accepteert.
Het concept van het accepteren van fouten lijkt misschien contraintintief, maar het is essentieel voor de innovatiecyclus. Als mensen bang zijn om te falen omdat fouten hen in het centrum van schuldspellen plaatsen, zullen ze waarschijnlijk geen nieuwe benaderingen voor probleemoplossing volgen vanwege de angst voor falen. De hele organisatie wordt dan een gevangene van zijn gevestigde praktijken.
Het is mogelijk om een 'fail fast'-cultuur tot stand te brengen waarbij mensen worden aangemoedigd om nieuwe methoden uit te proberen. Ze kunnen snel de richting veranderen als ze niet het verwachte resultaat krijgen, waardoor ze een rijkere innovatiecultuur kunnen creëren.
Op hypothese gebaseerde innovatie
U kunt innovatie beschrijven als een iteratieve cyclus op basis van hypothesen. Wanneer u het bestaan van een probleem identificeert, kunnen een of meer hypothesen worden geformuleerd om de hoofdoorzaak mogelijk uit te leggen en naar de oplossing te leiden. De definitie van het probleem zelf kan lastig zijn, omdat het meetbaar moet zijn.
De probleemdefinitie 'Klanten zijn niet tevreden met onze betalingsplatformkeuzes' is bijvoorbeeld niet meetbaar, dus het is moeilijk om op te lossen. Als u het probleem kunt definiëren als '23 procent van de klanten verlaat hun winkelsessie bij de stap van het kiezen van het betalingsplatform', bent u in een betere positie om het succes van elke mogelijke oplossing te meten.
Nadat u een probleem op meetbare wijze hebt gedefinieerd, kunt u hypothesen formuleren die geschikt zijn om het probleem uit te leggen en op te lossen. Een hypothese voor Tailwind Traders kan bijvoorbeeld worden beschreven als: 'ContosoPay toevoegen aan onze ondersteunde betalingsplatforms zou het klantverloop op de betalingspagina verlagen van 23 procent tot 10 procent'. Nu staat er een idee op de tafel en doet er actie op, is het een kwestie van het controleren van de geldigheid ervan.
Hypothesen moeten zich richten op het toevoegen van waarde aan klanten en het verbeteren van hun ervaring in hun interacties met uw organisatie. Dit idee staat bekend als empathie van klanten: uw klant in het centrum van uw innovatie plaatsen en zich richten op toenemende waarde voor hen en voor u.
Er zijn veel manieren om een hypothese te valideren zonder toepassingscode aan te raken. Klantonderzoeken en marktonderzoek zijn twee voorbeelden van waardevolle informatiebronnen die kunnen helpen bij het bepalen van de geldigheid van een hypothese. Door deze bronnen te controleren, kunt u uw hypothese kwalificeren en hypothesen bouwen met de hoogste waarschijnlijkheid van nauwkeurigheid en toegevoegde bedrijfswaarde.
Compilatie
Nadat een hypothese voldoende waardepotentieel heeft om in uw toepassing te worden ingebouwd, wordt het buildproces gestart. Nogmaals, snelheid is cruciaal.
Uw ontwikkelsprints moeten zo kort mogelijk zijn. Het kort houden van sprints maakt snelle verificatie of afwijzing van de hypothese mogelijk. Ook kunt u hiermee de manier verfijnen waarop de vereiste functionaliteit in de toepassing is geïntegreerd. Het resultaat is snellere innovatiecycli.
Meetcriterium
U wilt de nauwkeurigheid van uw hypothese zo snel mogelijk controleren. Een minimum viable product (MVP) is een voorlopige versie van de nieuwe functionaliteit die feedback verzamelt en helpt te bevestigen of u in de juiste richting overstapt.
Het doel van de MVP is niet alleen uw hypothese te verifiëren, maar ook eventuele veronderstellingen die u hebt gemaakt. Als bijvoorbeeld 23 procent van de klanten van Tailwind Traders het aankoopproces op de betalingspagina verlaat, is de hypothese dat de reden hiervoor is dat het bedrijf onvoldoende betaalplatforms aanbiedt. De reden kan echter anders zijn. De MVP moet worden ontworpen om deze veronderstellingen en de hypothese te bevestigen of af te wijzen.
leren
De leerfase is vergelijkbaar met het begin van het proces. Nadat u meer hebt geleerd over uw veronderstellingen en hypothesen, kunt u erachter komen dat ze juist, gedeeltelijk juist of onjuist waren. Door een groeimentaliteit en voldoende bescheidenheid te hebben om fouten toe te geven, kunt u het volgende doen:
- Draai snel als u wilt blijven werken aan uw MVP.
- Richt uw inspanningen op andere gebieden opnieuw in en formuleer een alternatieve hypothese.
Het is belangrijk om te beseffen dat zelfs als uw veronderstellingen en hypothesen onjuist waren, het proces u heeft toegestaan om iets nieuws te leren over uw klanten en uw bedrijf. Denk er niet aan als verspilde tijd. De sleutel is om die kennis zo snel mogelijk te verkrijgen en toe te passen op een toekomstige hypothese. Dit idee is de kern van de fail-fast cultuur.
Waar moet ik naartoe kijken?
Het innovatieoverzicht van het Cloud Adoption Framework is de beste plek om te beginnen met het verkennen van hoe u kunt innoveren.