5 gouden regels voor ondernemers met online ambities | Ripplestarters
Terug naar blogs menu

5 gouden regels voor ondernemers met online ambities

back

Toen ik tien jaar geleden voor het eerst voor de uitdaging stond om mijn ambitieuze plannen om te zetten in een online platform, werd ik al snel geconfronteerd met een nieuwe complexe wereld. Hoe zorgde ik ervoor dat mijn concept zo efficiënt mogelijk in eentjes en nulletjes omgezet werd? Iedereen die ik sprak was er in die tijd al over uit dat het waterval-effect (lees: briefings van dertig pagina’s) volledig uit de tijd was. Als de programmeur de software geschreven heeft, is de wereld alweer veranderd of blijkt dat de gebruiker helemaal niet zit te wachten op het uitgewerkte plan. Je bent onderaan de waterval uitgekomen en moet helemaal naar boven klauteren waar je opnieuw kunt beginnen.

Wie online ambities heeft, moet naar mijn idee een paar belangrijke lessen goed in z’n oren knopen.

Regel 1: bepaal zelf welke elementen variabel moeten zijn

Om dat waterval-effect te voorkomen, is het zogeheten agile, oftewel behendig en snel ontwikkelen in het leven geroepen. Bij agile development houdt het ontwikkelingsteam er rekening mee dat de software aan verandering onderhevig is. De code wordt zo opgebouwd dat veranderingen als het ware met één druk op de knop doorgevoerd kunnen worden. Dit brengt mij bij mijn eerste les: zorg ervoor dat jij als concepteigenaar direct schakelt met de engineer die de programmeurs aanstuurt. Jij bent namelijk als beste in staat om in te schatten welke variabelen onderhevig zijn aan eventuele wijzigingen.

Een voorbeeld: bij SellaBand werkte we met zogeheten parts. Dat waren een soort aandelen die je kon kopen in de bands die op het platform stonden. Deze parts waren 10 dollar waard. Hier kreeg je als Believer (zo noemden we deze mensen) een album voor terug, wanneer het doelbedrag van 50.000 dollar gehaald was. Maar, en nu komt het, nadat we live waren gegaan kwamen we erachter dat Believers bereid waren om veel meer dan 10 dollar te investeren. Toen ik naar het software-ontwikkelingsbureau ging om uit te leggen dat we de spelregels wilden wijzigen, kreeg ik te horen dat het in te leggen bedrag niet zo maar te wijzigen was. Deze was als het ware ‘hard’ in de code gezet. Met andere woorden: de programmeurs moesten door de hele code heen om overal de bedragen variabel te maken. De consequentie was helder. We moesten bijna alles opnieuw bouwen of de wijziging van de spelregels uitstellen. We kozen voor het laatste, met desastreuze gevolgen.

Regel 2: eerst testen, dan bouwen

Het is tegenwoordig met applicaties als Invision, Marvel en Flinto mogelijk om een prototype te maken van je platform dat heel dicht in de buurt komt van de echte gebruikerservaring. Weer terug naar Sellaband. Stel dat wij met een prototype het concept getest hadden. Voordat we ook maar een letter code geschreven hadden, zouden we er al achter zijn gekomen dat de bedragen die muziekliefhebbers over wilden maken naar een band varieerden van een paar dollar tot honderden dollars. De product engineers hadden hier rekening mee kunnen houden bij het opzetten van de technische infrastructuur. En wij hadden variabele tegenprestaties kunnen bieden zoals Kickstarter dat gedaan heeft. Dat hebben ze slim afgekeken. Valideer dus alle aannames voordat je start aan de ontwikkeling van je software.

Regel 3: don’t repeat yourself

Een andere basisfout die wij met SellaBand gemaakt hebben (en veel tech-ondernemers nog steeds maken) is zo snel mogelijk live gaan. Het iteratief opbouwen van een software-applicatie kost in het begin van het ontwikkelproces veel tijd. Je moet namelijk ieder element zo maken dat het herbruikbaar in te zetten is. Dit wordt het DRY-principe genoemd: Don’t Repeat Yourself. Later in het ontwikkelingsproces verdien je de ‘droge’ geïnvesteerde uren met rasse schreden terug.

Regel 4: fuck de ijzeren driehoek

Software-ontwikkelaars stellen vaak dat er een ijzeren driehoek bestaat in ontwikkelingsland: (1) de hoeveelheid features die ontwikkeld moeten worden, (2) het budget en (3) de kwaliteit van de software. Ze stellen dat je niet al deze drie variabelen vast moet willen zetten, omdat software-ontwikkeling nu eenmaal aan verandering onderhevig is door voortschrijdend inzicht. Om dit probleem te tackelen, is scrummen in het leven geroepen. Een team gaat in sprints van één of twee weken aan de slag zonder dat de output precies vastligt. Deze methodiek is prima voor doorontwikkeling van een bestaand product, wanneer er voldoende budget beschikbaar is. Bij de start van je bedrijf wil je dit soort onzekerheden niet. Zorg er dus voor dat je met je prototype voldoende testen uitgevoerd hebt zodat je een scherp beeld hebt van de functionaliteiten die nodig zijn om jouw concept te laten slagen. Laat een budget maken voor deze minimale vereisten en houd je ontwikkelaars hier aan. Ga live en ontwikkel pas door wanneer je voldoende data verzameld hebt om verbeteringen door te voeren.

Regel 5: hier met dat IP

Het laatste punt van aandacht. Wanneer je een applicatie laat bouwen door een programmeur of bureau, dan moet je altijd afspraken maken over het intellectueel eigendom. Volgens de auteurswet is elke letter code die geschreven wordt door een programmeur automatisch van hem of haar. Maar, aangezien jij het creatieve brein achter de software bent, behoort het intellectueel eigendom jou toe. Zorg ervoor dat je dit regelt met een IP-overdracht document.

Wanneer je je aan deze gouden regels houdt, dan wordt de transitie van je idee naar een werkend online platform een feestje. Iedere stap geeft gigantische voldoening, omdat je de juiste middelen op het juiste moment inzet. En zo hoort het ook wanneer je als startup de gevestigde orde uitdaagt.

Schrijf je in voor onze nieuwsbrief met
ondernemersnieuws, tips en tricks