Een poosje terug kwam ik via Facebook op een blog van Hotjar terecht: “App mistakes: the 10 lessons we learned launching (& killing) our $200K mobile app”. Hotjar is een verzameling tools voor o.a. het analyseren van gedrag van bezoekers op een website. In het betreffende artikel vertelt de auteur dat ze in 2018 hun mobiele app de nek hebben omgedraaid, wat natuurlijk een pijnlijk proces was nadat er ruim 3.500 uur ontwikkeling in was gestopt. De auteur beschrijft vier belangrijke fouten die zijn gemaakt, waardoor de app volgens hen gedoemd was te mislukken. Vervolgens worden de stappen benoemd die ze zouden nemen als ze het allemaal over mochten doen.

Zelf hebben we eind 2018 onze eigen app voor Provisior gelanceerd, waarmee medewerkers een password reset kunnen uitvoeren en digitale workflows kunnen afhandelen. Na het lezen van het artikel was ik vanzelfsprekend “getriggerd”. Hoe hebben wij het gedaan? Hebben wij dezelfde fouten gemaakt… en is onze app ook gedoemd om te mislukken? Het leek me daarom interessant om in te zoomen op deze vier fouten en te kijken hoe wij het gedaan hebben.

“Mistake #1: We didn’t validate the idea before we acted on it”

Klanten van Hotjar zaten helemaal niet te wachten op een app, beschrijft de auteur. En ook de vraag wat de app zou moeten kunnen is vooraf nooit gesteld aan gebruikers. Deze eerste fout hebben wij in ieder geval niet gemaakt. Het idee van een app hebben we vooraf bij diverse bestaande klanten en partners getoetst, en ook over de functies die we voor ogen hadden hebben we met ze gespard. De enthousiaste reacties bevestigden ons idee dat we op de juiste weg waren met de ontwikkeling van de Provisior app.

“Mistake #2: We underestimated the resources required to build for mobile”

Ook hadden wij nog geen ervaring met het ontwikkelen van een native mobile app. Er is ook echt veel tijd ingestoken, maar dat had een belangrijke reden. Vanaf dag 1 heeft security een belangrijke rol gespeeld. Met een app van elke plek ter wereld een handeling kunnen uitvoeren binnen een bedrijfsnetwerk… dat moet veilig zijn. We zijn er van overtuigd dat het ook veilig is, juist doordat we veel tijd hebben besteed aan de manier waarop een mobiel apparaat gekoppeld wordt en de ontwikkelinspanningen die daarbij kwamen kijken. En we hebben ontzettend veel geleerd, soms door vallen en opstaan. Maar hé, dat hoort ook bij software ontwikkeling.

“Mistake #3: We didn’t focus on what would have the biggest impact for Hotjar”

Dit is iets waar we goed rekening mee hebben gehouden door naar onze roadmap te blijven kijken. Klanten vroegen om een app, dus de focus hierop was een juiste keuze. Echter, we hebben niet alleen aan de app gewerkt, het reguliere onderhoud op Provisior liep gewoon door en we hebben ook andere “epics” afgerond, zoals het automatisch kunnen anonimiseren van een database in het kader van GDPR, en simpele doch zeer waardevolle verbeteringen als het kunnen fiatteren van meerdere aanvragen tegelijk.

“Mistake #4: We didn’t think Minimum Viable Product (MVP) and lost sight of the original goal”

Het toepassen van “MVP” bij het ontwikkelen van nieuwe software applicaties of onderdelen hiervan is iets wat we al jaren doen. Binnen ons Scrum-proces is dit één van de basisprincipes die we hanteren. Zoals eerder vermeld, met onze app kan een password reset worden uitgevoerd en kunnen aanvragen digitaal goedgekeurd worden. Dit zijn twee van de meest gevraagde functies voor de app en lenen zich ook uitstekend voor een mobiel apparaat. Natuurlijk hadden we genoeg ideeën voor andere toepassingen, zoals het kunnen delegeren van je rol (wat praktisch is als je ziek bent of wanneer je dit vergeet te doen voor je op vakantie gaat). Maar door het relatief klein te houden hebben we sinds eind vorig jaar een app die enthousiast gebruikt wordt door klanten en hebben we al diverse nieuwe ideeën en verbeteringen verwerkt.

Terugkijkend op dit proces kan ik met gepaste trots zeggen dat de meeste fouten die Hotjar zegt te hebben gemaakt, wij (al dan niet bewust) niet gemaakt hebben. We hadden een idee, die we getoetst hebben bij klanten, en we hebben het bewust klein gehouden middels “MVP”. Een aanpak die we in de toekomst zullen blijven toepassen. En dat zien we ook terug bij de app. Onze klanten maken er steeds meer gebruik van en in de gesprekken met onze klanten merken we dat het als een pré wordt ervaren.

Stefan Krul-Donkersloot

Stefan Krul-Donkersloot

Senior Consultant