De productontwikkeling cyclus is rond

Succesvolle bedrijven moeten digitaal wendbaar zijn. Daarvoor is een goede productontwikkeling noodzakelijk. De vraag is echter: hoe organiseer je de productontwikkeling? Het korte antwoord: het moet in elk geval een cyclus zijn. Een focus op alleen het opleveren van features is gedoemd te mislukken.

2/13/20243 min lezen

Frameworks voor productontwikkeling

Productmanagement speelt een cruciale rol in het succes van een product of bedrijf. Er zijn echter verschillende manieren om het productmanagement proces te organiseren. In deze blog bespreek ik een aantal frameworks / modellen. Ik focus me daarbij alleen op modellen die productontwikkeling zien als een cyclus waarbij nieuwe producten of features worden opgeleverd, gemeten, geëvalueerd en vervolgens worden verbeterd. Want de aanpak dat er alleen wordt gefocust op het opleveren van features is achterhaald. We zien een ontwikkeling in de markt van een focus op het opleveren van (output naar resultaten (outcome). En dat is maar goed ook. Want features opleveren zonder vervolgens goed te kijken hoe die features worden gebruikt door de klant, en hoe die features geoptimaliseerde kunnen worden, is een recipe for disaster.

Mede tegen deze achtergrond heb ik vier modellen uitgelicht: de bekende 'build-measure-learn' cycle, die van Roman Pichler, het model van Pendo en tot slot het model dat wordt gebruikt door Spotify.

Pendo model

Pendo kent een business model bestaat uit de volgende fasen:

  • Business Outcome: vaststellen van wat we willen bereiken met het product. En, zoals de naam al zegt: denk in outcomes, niet in output.

  • Discover: achterhalen pain points van de gebruikers, hoe maken we de gebruiker blij, hoe ziet de user flow eruit?

  • Validate: toets het idee in de markt. Kijk bijvoorbeeld naar het gebruik van vergelijkbare producten, en probeer feedback te krijgen via polls, interviews en de feedback van Customer support.

  • Build: evident, het bouwen. Het hebben van een goede, transparante roadmap kan hier helpen om de stakeholders goed op de hoogte te houden van wat er gebouwd wordt - en te voorkomen dat er stiekum toch wat extra features bijgestopt worden door invloedrijke stakeholders.

  • Launch: lancering van het product.

  • Evaluate: het echte harde werken... meten hoe het product in de markt valt. Gebruiksdata, feedback via diverse kanalen, NPS onderzoeken - ze helpen allemaal om een beeld te vormen over de acceptatie van de feature of het nieuwe product.

  • Iterate: het denkwerk. Hebben we iets in onze handen wat potentie heeft? Wat werkt wel en wat niet? En waarom? Welke knoppen moeten we aan draaien? En hoe gaan we dat elke keer goed meten? Je raadt het al. Hier onderscheidt het kaf zich van het koren.

Roman Pichlers model

Roman Pichler heeft een zeer bruikbaar model ontwikkeld voor de gehele productmanagement cyclus. Hij onderkent de volgende fasen:

  • Product strategie (inclusief valideren van de strategie)

  • Product roadmap. Dit bevat een planning van de te releasen features / product increments. Zie ook de blog over hoe je een goede roadmap kunt opstellen.

  • Product backlog. Dit behoeft hoop ik geen toelichting.

  • Development. Ook hier geldt: itereren! Release onderdelen van de features, verzamel feedback, en ontwikkel door.

  • Product (increment): het verbeterde product

  • KPI's / development progress: hoe meten we de impact van de nieuwe features / product increments. Goede dashboards helpen daarbij!

Build Measure Learn

Dit model bestaat, uiteraard, uit de volgende fasen: bouwen, meten en leren. Met het bouwen wordt doorgaans een MVP bedoeld (Minimum Viable Product). Ook wel weer onderverdeeld in 'Design Experiment > Build Experiment > Run Experiment'. In de meet-fase wordt data verzameld en gekeken in hoeverre het product aanslaat. In de laatste fase tenslotte wordt geanalyseerd en besloten hoe verder te gaan. "Persevere or Pivot" wordt hier vaak genoemd: of doorgaan met bestaande uitgangspunten maar wat kleine verbeteringen. Pivot betekent zoveel als .... even opnieuw beginnen

Het spotify model

Spotify is bekend geworden door het werken in 'squads', waarbij teams van 6 tot 12 mensen relatief autonoom werken aan features. Ondanks dat de teams zeer zelfstandig werken, vindt er wel een duidelijk afstemming plaats met de andere teams. De ontwikkelcyclus bestaat uit de fasen: Think it, Build it, Ship it, Tweak it. De eerste fase is een discovery fase en bestaat met name uit het generen van ideeën en experimenteren met concept. De MVP wordt gebouwd in fase 2, en de uitrol in fase 3. Die uitrol is gefaseerd, initieel wordt de MVP ter beschikking gesteld aan een zeer beperkt deel van de gebruikers. De laatste fase is de langste van alle fasen: het tweaken van het product. Het tweaken betreft niet alleen de features, maar bijvoorbeeld ook optimalisatie van performance en verlaging van kosten.

Welk model gebruiken?

Alle beschreven modellen zijn handig in gebruik. Het Build-Measure-Learn model vind ik zelf net iets te generiek. Vanwege het gebruik van KPI's gaat mijn voorkeur uit naar het model van Roman Pinchler. Maar dat is uiteraard persoonlijk. En suggesties zijn uiteraard welkom!