Schoolyear wordt actief ontwikkeld en stelt daarbij de input van haar klanten zeer op prijs. Aan de hand van deze input kunnen de productmanagers een beter beeld vormen van de knelpunten waar haar gebruikers in de praktijk tegenaan lopen. In de ontwikkelingsstrategie zoekt Schoolyear naar deze knelpunten en probeert deze innovatief op te lossen. Daarbij is niet één klant belangrijker of invloedrijker dan de ander. In tegendeel, Schoolyear maakt nooit afspraken met klanten over "hun percentage van invloed op de roadmap", omdat is gebleken dat dit leidt tot niet-duurzame producten.
Probleem gefocust development
Hoe pakt Schoolyear het dan wel aan? In drie woorden: "Probleem gefocust development". Schoolyear maken onderscheidt tussen drie soorten feedback:
- Security meldingen: Schoolyear zoekt zelf actief naar gaten in de beveiliging, maar soms is een klant of pentester Schoolyear te snel af. Deze meldingen probeert Schoolyear dan zo snel mogelijk op te lossen. Dat is onderdeel van het kat-en-muisspel.
- Knelpunten: Schoolyear praat constant met haar klanten en uit deze gesprekken komen vaak knelpunten naar voren. Deze worden naar de productmanagers gecommuniceerd en het is vervolgens hun taak om aan de hand van deze input stroom coherente user-stories te ontwikkelen. Deze user-stories komen dan uiteindelijk op de roadmap terecht.
- Feature requests: Wanneer Schoolyear een feature request binnen krijgt, gaat het op zoek naar het achterliggende knelpunt dat de klant probeert op te lossen. Ervaring leert dat deze er altijd is. Dit knelpunt neemt Schoolyear vervolgens op in de input stroom, net zoals elk ander knelpunt. Feature requests komen zelden 1-op-1 terug in onze roadmap. Schoolyear zoekt naar oplossingen die de knelpunten van verschillende klanten in één klap oplossen. Het voordeel hiervan ten opzichte van de "percentage methode" is dat de klant meeprofiteert van alle ontwikkelingen i.p.v. alleen het eigen percentage van de ontwikkeltijd.
Roadmap
Schoolyear publiceert periodiek een roadmap om aan haar klanten te communiceren wat ze kunnen verwachten. Grote organisaties moeten vaak ver vooruitplannen en het helpt als Schoolyear soms het tipje van de sluier oplicht. Punten op de roadmap beginnen op het level van user-story, niet als beschrijving van de implementatie. Gaandeweg worden deze user-stories ingekleurd met implementaties en technische ontwerpen, totdat ze klaar zijn en de ontwikkelingspijplijn in gaan. Schoolyear verdeelt uitdrukkelijk de ontwikkeltijd van de roadmap niet tussen klanten maar tussen user-stories.
Invloed op de roadmap
Schoolyear krijgt vaak de vraag hoe klanten invloed kunnen uitoefenen op de roadmap. De beste manier is om concrete probleemstellingen in te dienen. Bijvoorbeeld: “we besteden nu 1 dag in de week aan X, dat kost veel tijd” of “we moeten nu steeds alles invullen in systeem A en B, dat maakt het hele proces foutgevoelig”. Schoolyear pakt de verschillende knelpunten waar de klanten tegenaanlopen samen en gaan op zoek naar duurzame oplossingen hiervoor. Zo lost Schoolyear meerdere knelpunten tegelijk op en kan Schoolyear effectiever een product bieden dat aan ieders verwachtingen voldoet. Door knelpunten samen te pakken lost Schoolyear dus sommige dingen al op voor je hier zelf tegenaan gelopen bent.