Google, Facebook, Apple, Dropbox,… De tech bedrijven in Silicon Valley zijn fantastische vernieuwers. Ze zijn toonaangevend, niet alleen door de producten die ze bouwen, maar ook voor de manier waarop ze dat doen. Ze gebruiken quasi allemaal agile methodes, die erop gericht zijn om heel snel nieuwe producten in de markt te zetten en continu te verbeteren op basis van klantenfeedback. Ze worden alom geprezen – en terecht! – en druk gekopieerd. Maar wat in Silicon Valley werkt, werkt daarom niet zomaar bij ons. Dit zijn 2 redenen waarom de recepten uit Silicon Valley soms heel moeilijk toepasbaar zijn in de meeste Belgische organisaties, en wat je eraan kan doen.

1. Starten met een minimaal product is geen optie

1 van de standaard strategieën binnen Silicon Valley is om bij nieuwe producten zo snel mogelijk een ‘minimale versie’ van dat product te lanceren (Minimal Viable Product, MVP). Dit minimale product wordt dan gelanceerd in de markt, en als het aanslaat wordt het stapsgewijs verder uitgewerkt tot een verfijnder product met meer functies en een betere look.

Dit is een geweldige strategie om een totaal nieuw product uit de grond te stampen, waarvan je nog niet weet welke richting het precies moet uitgaan om succes te hebben. Het is minder evident om deze strategie toe te passen als je een bestaand product wil vervangen. Als het Sportpaleis een nieuw systeem voor online ticketverkoop wil introduceren, dan is het geen optie om eerst een minimale variant te lanceren waarin bijvoorbeeld geen functionaliteiten zitten voor rolstoelgebruikers of wachtlijsten.

Hoe kan je hiermee omgaan?

• Hou het bestaande product in de lucht, en introduceer je minimale nieuwe product als een ‘beta’-versie die beperkt is tot een kleine groep eindgebruikers. Op basis van hun feedback kan je de beta-versie stap per stap gaan uitbreiden en verbeteren, tot je uiteindelijk je oude product kan afschaffen. Deze aanpak is interessant, maar frequente en vlotte communicatie met die beta-groep is heel belangrijk.
  

• Soms wordt gekozen om het minimale product te bouwen, maar het nog niet vrij te geven aan eindgebruikers. Het uittesten wordt dan beperkt tot enkele werknemers binnen de organisatie. Intussen wordt er verder gewerkt aan volgende versies, en pas als het product compleet genoeg is wordt het echt gelanceerd. In mijn ervaring werkt dit minder goed: je krijgt geen ‘echte’ feedback van eindgebruikers die kan helpen om de verdere uitwerking te sturen.
• Hou in gedachten dat deze strategie dient om te testen of een product aanslaat bij gebruikers, en om feedback te capteren. Hij is niet bedoeld om meteen winstgevend te zijn. (Heel veel tech-reuzen waren jarenlang zelfs verlieslatend, inclusief Google en Facebook).

2. Je product moet inhaken op bestaande systemen

Een vaak gebruikte agile methodologie is Scrum. Hierbij wordt de ontwikkeling van een product toevertrouwd aan 1 team, dat samen aan de slag gaat om alles van A-Z uit te pluizen, te plannen, te bouwen, te testen en in de markt te zetten. Scrum is fantastisch, maar is voorzien op teams die zelfstandig werken. Vaak is dit moeilijk of onmogelijk, omdat het team zijn product moet laten inhaken op andere systemen of processen.

Een nieuwe webshop moet bijvoorbeeld perfect aansluiten op een bestaand facturatiesysteem, een voorraadsysteem en een klantendatabase, met verschillende achterliggende technologieën. Het team moet dan aankloppen bij andere teams, of zelfs bij externe partijen. Hier begint de miserie: het team komt vast te zitten omdat er informatie ontbreekt, omdat de andere partijen niet klaar zijn met hun deel van het werk, of omdat er misverstanden ontstaan.

Wat hiermee gedaan?

• Probeer zoveel mogelijk om alle nodige expertise in 1 team te bundelen. Vaak gemakkelijker gezegd dan gedaan… Dit vraagt dat je op een andere manier gaat nadenken over de structuur van je organisatie. Heb je aparte teams voor facturatie, rapportering, infrastructuur, voorraadbeheer en de website? Met 1 product-team waarin al die specialisaties vertegenwoordigd zijn vermijd je het eindeloze afstemmen.
• Zoek experts die je kunnen begeleiden om integraties tussen systemen op een toekomstbestendige manier aan te pakken (bij AE hebben we er wel een aantal rondlopen ?).

Intussen is deze blogpost al redelijk lang geworden, terwijl mijn inspiratie nog niet opgedroogd is. Het vervolg van het verhaal is dus voor volgende week ?

Photo by Madhur Chadha on Unsplash