10 dingen die je moet weten als je een Saas-platform maakt

Eén van de eerste keuzes voor een SaaS-bedrijf is het insourcen of outsourcen van bepaalde expertises. Als je voor Saas kiest, dan kies je er feitelijk voor om een softwarebedrijf te runnen. Dus je hebt IT-expertise nodig. Of je nou zonnepanelen in Afrika installeert, een klantloyaliteitsprogramma runt of een makelaar bent. Met een online platform om te runnen en onderhouden, is het vaak slimmer om back-end developers te insourcen. Maar de keuzes daarna worden moeilijker. Hoe zit het met marketing, design en contentcreatie? Vorm je een volledig in-house team of is het beter om met een externe partner te werken? Voor onze klanten werkte het het beste om samen te werken in een gedeelde omgeving (zoals Git en onze eigen brand hub Brandstation). Daarin ontwikkelden we de UX, het visual design en de front-end. En onze klanten konden zo onze designs en code snippets embedden in hun eigen back-end.

Zodra je weet wie je moet aannemen en met welke partners je gaat werken, moet je kiezen wat je zelf gaat maken en wat je moet kopen. Bouw je je eigen CMS? Dan is die op-maat-gemaakt, maar kost het developen bakken tijd. Of ga je voor een bestaand standaard-CMS waar je meteen mee van start kan, maar die voor extra kosten zorgt? Hetzelfde geldt voor plug-ins, frameworks, API’s, e-commerce tools enzovoort. Een andere factor in besluitvorming is flexibiliteit. Wat zorgt voor meer flexibiliteit in de toekomst: in-house gemaakte software, of iets dat je hebt aangeschaft? Je moet het óf zelf onderhouden, óf je bent afhankelijk van je licentie en third party developers die hun werk up-to-date moeten houden. Daarbij, een aangeschaft pakket kan worden omgevormd tot een product dat niet meer bij jouw framework past. En er is nog de flexibliteit om code over te dragen aan andere toekomstige developers. Om deze reden kiezen de meeste klanten voor een open-source CMS, in plaats van een op-maat-gemaakt CMS. Andere voordelen zijn de grote community bases die je bij open-source CMS horen. Die verzorgen documentatie, tips en tricks, en updates in het geval van beveiligingsrisico’s.

Je hebt je team samengesteld en weet wat je moet maken of kopen. Dit is het moment om beter te kijken naar je propositie. Je hebt er vast goed over nagedacht en bent ervan overtuigd dat je een onweerstaanbare service hebt. Maar, misschien heb je sommige mensen horen zeggen dat het “just another screen” is. Uiteindelijk moet jouw service de aandacht van anderen trekken, in een zee van andere online services. Naast de zondvloed aan online services, weten mensen dat deze services vaak hun workload vergroten. Met uitstek B2B-platforms waar mensen moeten werken met data. Naast hun huidige werk, moeten ze ineens inloggen, data bekijken, grafieken en tabellen interpreteren en daar conclusies aan verbinden. Om je online service te laten slagen, is het verstandig om te focussen op echte gebruikersengagement. Wat motiveert gebruikers om je service te gebruiken, en hoe kun je ze aanmoedigen om jouw interface te gebruiken? Tegen welke problemen lopen ze aan en hoe kun je die het beste oplossen? In plaats van ze blindelings naar je service te sturen. Een van onze klanten had bijvoorbeeld ontdekt dat mensen simpelweg geen tijd hebben en introduceerde daarom de mogelijkheid om op elk gewenst moment een samenvatting van hun dataplatform te exporteren, waardoor hun gebruikers de cijfers in één oogopslag hebben. Een eenvoudige oplossing die de pijn van het ontbreken van tijd verlicht en die zich bezighoudt met effectieve datavisualisaties.

Naarmate je platform groeit, krijg je ook te maken met groeipijnen. Plots blijkt dat je code-framework niet zo schaalbaar is als je had gedacht, en je wordt gedwongen terug te gaan naar de tekentafel en je hele code-architectuur te herzien. Hoewel dit op een gegeven moment waarschijnlijk onvermijdelijk is, omdat je in het begin niet altijd alles kunt overzien, denk ik toch dat het goed is om vanaf het begin te ontwerpen voor schaalbaarheid. Dit betekent dat jemoet plannen hoe je platform gaat groeien en hoe dit er technisch uitziet. Kan je back-end dit aan? Moet je meer betalen voor modules van derden naarmate het verkeer toeneemt? Hoe zit het met hosting? Hoe zit het met de laadsnelheid? En veiligheid? In die gevallen waarin we onze klanten hebben geholpen om op deze dingen te anticiperen, kostte het iets meer om de initiële architectuur op te zetten, maar het bespaarde later een hoop gedoe - en kosten.

Als digitaal ontwerpbureau hebben we design altijd centraal gesteld in wat we doen. Wij geloven dat een goed ontwerp mensen helpt te begrijpen hoe iets werkt, en hen ertoe aanzet het te gebruiken, waardoor de acceptatie van producten wordt versterkt. Het is bewezen dat mensen goed ontworpen interfaces als gebruiksvriendelijker ervaren, of ze dat nu zijn of niet. Maar waar een goed ontwerp vroeger een onderscheidende factor was - soms zelfs een USP - als het gaat om SaaS-platforms, zie ik nu dat alle professionele platforms er absoluut verbluffend uitzien. Premium design is een commodity geworden. Dit betekent dat je gewoon niet wegkomt met iets dat slecht navigeert en er ondermaats uitziet. Zorg er in plaats daarvan voor dat uw platform goed is ontworpen, zowel op UX- als op brandingniveau, en begin na te denken over functionaliteiten waarmee u zich nog kunt onderscheiden.

Dit lijkt oud nieuws, maar ik zie veel eigenaars van SaaS-platforms vanuit hun eigen belevingswereld feedback geven op prototypes. Dit is gerechtvaardigd bij de tone-of-voice, maar niet bij feedback op de UX. Daarvoor moet je luisteren naar je gebruikers. Waar zoeken zij naar als ze op je platform zitten, weten ze hoe ze moeten navigeren, zien ze je call-to-actions? Gelukkig worden de meeste online platforms tegenwoordig volgens de scrummethode gemaakt. Daarbij wordt het werk opgedeeld in relatief korte development sprints. Scrum als een design- en developmentaanpak past goed bij grote en complexe projecten zoals SaaS-platforms. Het klassieke watervalmodel is beter geschikt voor de creatie van brand experiences en campagnes. Werken in scrum maakt gebruikerstests makkelijker, omdat elke sprint eindigt met een werkend prototype dat getest kan worden. Er is dus geen excuus meer om gebruikerstests over te slaan!

Vanwege het vrij grote tijdsbestek bij het maken van een SaaS-platform - 6 tot 12 maanden zijn niet ongebruikelijk - krijg je onderweg waarschijnlijk nieuwe inzichten, waardoor prioriteiten moeten verschuiven. Deze inzichten kunnen afkomstig zijn van gebruikersfeedback, verschuivende markten, veranderingen in je bedrijf enzovoort. Maar dit is oké! Wees wendbaar en laat prioriteiten verschuiven, je product wordt alleen maar beter! Als je in scrum werkt, betekent het verschuiven van prioriteiten dat je andere user stories uit de backlog naar de volgende sprint moet brengen, in plaats van degene die je aanvankelijk dacht, of zelfs nieuwe user stories maakt. Houd er echter rekening mee dat wanneer je team aan andere stories gaat werken, dit ten koste gaat van de oorspronkelijk geplande stories (aangezien sprints een vaste lengte en budget hebben). Dit is vooral belangrijk om te beseffen als je samenwerkt met een externe ontwerp- en/of ontwikkelpartner. Waarschijnlijk hebben ze met jou een contract getekend waarin precies staat wat er voor welke prijs geleverd gaat worden, terwijl het verschuiven van prioriteiten vraagt om flexibiliteit op dit gebied. Flexibel zijn met het contract is misschien eng als je er niet aan gewend bent, maar bij scrum is veel gebaseerd op vertrouwen. Je externe partner zal waarschijnlijk zijn best doen om zoveel mogelijk binnen de gestelde tijd en budget te leveren, want uiteindelijk wil iedereen een goed product en een tevreden klant.

“We willen niet nóg een Facebook zijn” heb ik de laatste tijd te horen gekregen tijdens briefings of bij het vullen van de backlog van een scrumproject. Het besef dat een SaaS-platform misschien niet de hele wereld aan mogelijkheden zou moeten bieden, lijkt te beginnen. En ik ben het daarmee eens. Scope creep (het proces van het toevoegen van functionaliteiten terwijl je de initiële focus van het platform uit het oog verliest) is een fenomeen dat altijd op de loer ligt. En dat komt omdat het zo verleidelijk is om simpelweg functionaliteiten toe te voegen op basis van gebruikersfeedback, vooral als je technische framework dit toelaat. Hou daarom altijd je productpropositie in gedachten en balanceer de scope zorgvuldig als je nieuwe ontwerpsprints aangaat.

Net als elk ander bedrijf heeft ook jouw SaaS-platform een verkoopstrategie nodig. Aan wie verkoop je? Wat is je prijsschema? En vooral: hoe ga je leads aan boord krijgen? Dit is waarschijnlijk een van de grootste problemen die ik heb gezien bij SaaS-bedrijven. Ze leggen hun platform uit, wat het oplost en hoe het dat oplost. Ze bieden demo's, gratis proefversies, allemaal gericht op het converteren van geïnteresseerde leads. Maar dan blijft het stil. Het definitieve besluit om daadwerkelijk een licentie voor het platform aan te schaffen wordt steeds uitgesteld. Waar gaat het mis in deze funnel? Hoewel het vele redenen kunnen zijn - zoals het feit dat het al dan niet kopen van een licentie voor een groot SaaS-platform vaak deel uitmaakt van een grotere interne bedrijfsstrategie, wat het daarom tot een complex en politiek besluitvormingsproces maakt - heb ik ervaren dat het vaak te wijten is aan het niet kennen van alle verschillende mensen die de uiteindelijke aankoopbeslissing beïnvloeden tijdens de on-boarding funnel. Wie zijn de verschillende belanghebbenden? Wie zijn externe beïnvloeders? Wie is de daadwerkelijke koper (de eindbaas)? Daarom is het absoluut noodzakelijk om ze allemaal in kaart te brengen, te weten te komen wat ze drijft en ze zorgvuldig op het juiste moment in je on-boarding funnel te plaatsen. Bedenk tenslotte een manier om ze allemaal aan boord te krijgen: toon demo's aan sommigen van hen, prijzen aan anderen en stel je team voor aan degenen die vertrouwen zoeken, enzovoort. Ja, het is moeilijk.

Eindelijk zie je de vruchten van al je inspanningen groeien. Dit alles was een nauwkeurige klus van het draaien aan de juiste knoppen, toegevoegd met een vleugje geluk en de juiste timing, en daar ging je! Nu is het zaak om dit vol te houden! We hebben hier te maken met een SaaS-platform, gebouwd op webtechnologie in een wereld waar innovatie steeds sneller gaat en code achterhaald is voordat je het weet. Zorg daarom dat je een onderhoudsteam klaar hebt staan, bestaande uit developers, designers, content creators, product owners en scrum masters, om je platform ‘alive and kicking’ te houden!