We beginnen bij het probleem van de klant. We onderzoeken voor wie het belangrijk genoeg is om op te lossen en welke uitkomst het product moet leveren. Ook toetsen we vroeg of AI hiervoor de juiste techniek is.
Product en development bouwen vervolgens gericht verder. De architectuur wordt vroeg uitgewerkt. Met evals ziet het team vanaf de eerste versies of de kwaliteit verbetert. Eisen voor implementatie nemen we mee voordat kostbare productkeuzes vastliggen.
Werkt u bij een zorgorganisatie? Bekijk de route voor zorgorganisaties →Het team weet welke fouten ertoe doen en hoeveel kwaliteit nodig is voor de eerste release. Nieuwe modellen kunnen daarna tegen dezelfde lat worden gelegd.
Klantonderzoek bepaalt wat er wordt gebouwd. Technische keuzes en de eerste klantimplementatie blijven onderdeel van hetzelfde producttraject.
U weet voor welke klant u bouwt en welk probleem de investering rechtvaardigt. De productkans is met klanten onderzocht. Daardoor kunt u intern uitleggen waarom deze feature aandacht verdient.
Bekijk de AI-productkans sprintHet team weet wat de feature moet doen en welke architectuur daarbij past. De kwaliteit wordt met evals gemeten. Daardoor hoeft de definitie van een goede eerste release niet iedere sprint opnieuw besproken te worden.
Bekijk de AI-productontwikkeling sprintGebruikers beoordelen vroege versies tijdens development. De eisen voor implementatie zijn daardoor bekend voordat de release klaarstaat. Na de eerste implementatie kan uw productteam volgende implementaties zelf begeleiden.
Bekijk de eerste-klant sprintNieuwe modellen kunnen in korte tijd veel meer dan hun voorgangers. Zonder een scherp klantprobleem vult de roadmap zich met interessante mogelijkheden. Vaak blijkt pas na weken development of een klant zijn werkwijze ervoor wil aanpassen.
AI-output is nooit helemaal af. Zonder vooraf afgesproken kwaliteitsgrens kan iedere wijziging nog een verbetering lijken. Het technische experiment blijft interessant, terwijl de release steeds wordt uitgesteld.
Tijdens de implementatie worden eisen rond integratie en monitoring concreet. Ook het beoogde gebruik kan gevolgen hebben voor het ontwerp. Als deze onderwerpen pas aan het einde aan bod komen, moet development eerder werk opnieuw doen.
De precieze opleveringen hangen af van uw productfase en de eerste klantcontext. Dit zijn voorbeelden van wat uw team kan gebruiken en zelfstandig kan voortzetten.
Onderbouw voor welk klantprobleem ontwikkeling werkelijk de moeite waard is.
Geef development een meetbare kwaliteitslat en een herhaalbare aanpak.
Maak van de eerste implementatie een aanpak die bij volgende klanten werkt.
Ik werkte met het team aan de productkeuzes en technische opzet. We bepaalden hoe kwaliteit werd gemeten en legden vroege versies voor aan gebruikers. De toepassingen zijn nu onderdeel van het product.
Bekijk de caseArtsen beoordeelden de samenvattingen tijdens de ontwikkeling. Hun feedback had invloed op de modelkeuze en op wat we als een goede samenvatting beschouwden.
Bekijk de caseVia Platform ZorgAI houd ik bij welke AI-oplossingen voor de Nederlandse zorg beschikbaar zijn. Daardoor kunnen we concreet vergelijken wat al bestaat en welke ontwikkeling nog productwaarde toevoegt.
Als een leverancier het grootste deel van het klantprobleem al goed oplost, vraagt eigen ontwikkeling om een sterke reden. Integratie kan voldoende zijn. Een bestaande oplossing kan ook aanpassing nodig hebben. Alleen wanneer de onderscheidende productwaarde in eigen techniek zit, ligt zelf bouwen voor de hand.
Heeft u een concrete feature in gedachten of komt development niet verder? Ik denk graag mee over een logische volgende stap.
Leg uw toepassing voorNee. Ik werk samen met product en development. De software en roadmap blijven bij uw organisatie.
Ja. Bij nieuwe AI-functionaliteit begin ik daar vaak mee. Zonder helder klantprobleem is het eenvoudig om maanden te besteden aan een technisch interessante feature die weinig waarde oplevert.
Ja. Ik help bij technische keuzes die invloed hebben op het AI-product en de latere implementatie. Wanneer zeer specialistische engineering nodig is, kan een passende expert aansluiten.
Ja. We brengen structuur aan in technische experimenten en leggen vast hoe de kwaliteit wordt gemeten. Daardoor hoeft het team bij een nieuwe modelrelease niet opnieuw uit te zoeken wat goed genoeg is.
We beginnen bij het beoogde gebruik. Daaruit volgt welke regels relevant zijn en welke productkeuzes daardoor geraakt worden. Ik zorg dat deze vragen vroeg worden behandeld. Specialistisch juridisch of regulatoir werk wordt uitgevoerd door de juiste expert.
Nee. Als bestaand aanbod beter past, is dat vaak de betere keuze.
Het traject is klaar wanneer de feature bij een klant gebruikt kan worden en uw team voldoende kennis heeft om zelfstandig verder te gaan. De kwaliteit is meetbaar en de afspraken voor monitoring zijn vastgelegd.