Geweldige producten: Discovery vs. Delivery

De meesten van ons werken aan behoorlijk lastige problemen en normaal gesproken heb je vrij complexe systemen nodig om die problemen op te lossen.

Veel teams staan voor twee grote uitdagingen:

Allereerst moeten ze erachter komen hoe de oplossing voor de klant eruit moet zien (Discovery). Dat betekent zowel uitzoeken of er überhaupt klanten zijn die deze oplossing nodig hebben (vraag), als ook een oplossing vinden die werkt voor de klanten én het eigen bedrijf. Nog lastiger is het om één enkele oplossing te vinden die werkt voor veel klanten en niet slechts voor een paar specifieke klanten. Om dat voor elkaar te krijgen, moeten we snel bijleren.

Ten tweede moet je zorgen voor een robuuste en schaalbare implementatie, op de waarde waarvan onze klanten kunnen vertrouwen (Delivery). Het team moet vertrouwen hebben in de Release. Ook al kun je waarschijnlijk nooit 100% vertrouwen in iets hebben, zou je er ook niet voor hoeven bidden dat alles goed gaat wanneer je iets released.

Je moet dus zowel snel bijleren als vertrouwen hebben in je releases.

Kan dat werken?

Het is begrijpelijk dat veel mensen denken dat deze twee verschillende doelen tegenstrijdig zijn. We moeten proberen om snel iets te releasen, zodat we kunnen ontdekken wat werkt en wat niet. Maar we willen ook niets releasen dat nog niet volwassen genoeg is, en daarmee het risico lopen onze klanten en ons merk te schaden.

Ik heb met veel productteams gesproken en ben regelmatig ter verantwoording geroepen, omdat ik op het ene moment een team aanspoor om agressiever te releasen en feedback van klanten op te halen, en tegelijkertijd van hen eis dat ze geen compromissen sluiten als het gaat om betrouwbare, krachtige en veilige software.

Het Minimum Viable Product

Voor veel teams is het concept van een Minimum Viable Product (MVP) niet eenvoudig. Enerzijds ben je gemotiveerd om de klant snel iets te bieden en daar feedback op te krijgen, maar anderzijds heb je al gauw het gevoel dat het zogenaamde "product" een afgang zou kunnen worden – en hoe zou je zoiets ooit naar buiten kunnen brengen?

Snel leren en solide releases

Ik wil hier uitleggen hoe goede teams erin kunnen slagen om beide doelen – snel leren en solide releases – te combineren.

In principe geloof ik dat de meeste teams het tweede doel – namelijk goede software opleveren – makkelijker afgaat dan snel dingen uitproberen en nieuwe inzichten opdoen. Continuous Delivery, oftewel het continu opleveren, is een goede methode die ik heb waargenomen bij teams die het belang van veel kleine en incrementele veranderingen aan een complex systeem begrepen hebben.

Wat is eigenlijk een product?

De reden voor deze verwarring is onder andere het feit dat je vaak gewoon niet precies weet wat het betekent als er gesproken wordt over "product", "productkwaliteit", "live in production" enzovoort. Ik probeer de term "product" altijd te gebruiken voor een product dat zich in een staat bevindt waarin het daadwerkelijk vermarktbaar is. Het is schaalbaar en biedt een bepaalde performance. Er is een sterke regressietest-suite. Het is zo opgezet dat je de benodigde analytics kunt verzamelen. Afhankelijk van de behoefte is het geïnternationaliseerd of lokaal afgebakend. Het is goed te onderhouden. Het voldoet aan de merkbelofte. En het belangrijkste is dat het team het product met een gerust hart kan releasen.

Dat is niet eenvoudig en het kost het meeste tijd tijdens de ontwikkeling. Daarom doen we ons best om al deze inspanningen niet te verspillen.

Dit werk uitvoeren terwijl de productmanager zelf niet eens zeker weet of de klanten de oplossing überhaupt willen of nodig hebben, is een gegarandeerd recept voor verspilling.

De Product Discovery

Het doel van Product Discovery is dus om bewijs te verzamelen dat alle inspanningen van de ontwikkelaars voor kwalitatief hoogwaardige software niet voor niets zullen zijn.

Daarom bestaan er zoveel verschillende technieken voor Product Discovery. We hebben technieken om onze gebruikers en klanten beter te begrijpen en om productideeën kwalitatief en kwantitatief te valideren. En de meeste van deze technieken kosten niet eens tijd van de ontwikkelaars (dat is belangrijk, want we weten hoeveel tijd en moeite het kost om goede kwaliteit te leveren).

Effectieve Product Discovery heeft veel te maken met toegang krijgen tot de klant, en niet simpelweg zo snel mogelijk onze experimenten voor nieuwe producten uitvoeren.

Als je nog een hele jonge startup bent zonder klanten, dan is dit natuurlijk niet echt een issue (en het is misschien zelfs te vroeg voor software van productiekwaliteit).

De meesten van ons hebben echter echte klanten en echte omzet, en daarom moeten we hier ook over nadenken. Ik heb al geschreven over de belangrijkste technieken voor snel en verantwoord experimenteren met Product Discovery in gevestigde bedrijven.

Veel van deze technieken hebben te maken met het overtuigen van een aantal van onze klanten of potentiële klanten om onze nieuwe productideeën te testen (op welke manier dan ook). Een klantontwikkelingsprogramma is hier bijzonder geschikt voor, want deze personen hebben zich vrijwillig aangemeld om als proefkonijn te fungeren. We kunnen met hen praten of ze simpelweg observeren terwijl ze onze productideeën uitproberen, of we laten ze een tijdje onze prototypes testen en kijken wat eruit komt.

Conclusie: Discovery vs. Delivery

Als je echt geweldige producten wilt ontdekken, is het enorm belangrijk om je ideeën vroeg en vaak te testen bij echte gebruikers en klanten. Als je geweldige producten wilt opleveren, kun je het beste de beste ontwikkelmethoden gebruiken en proberen de zorgen van engineers niet te negeren.

Als we snel vooruit willen komen en nieuwe ideeën willen ontdekken, gebruiken we discovery-methoden en betrekken we de klanten erbij. Zodra we hebben vastgesteld welke oplossing we moeten ontwikkelen, laten we de ontwikkelaars software van productiekwaliteit bouwen, zodat ze die ook met volle overtuiging kunnen opleveren.

Deze tekst is afkomstig uit de blog van Marty Cagan en is door ons naar het Nederlands vertaald.