Een feature team bouwt een lijst gevraagde features. Een productteam is verantwoordelijk voor een uitkomst en bepaalt zelf wat er gebouwd wordt om die te halen. Dat verschil bepaalt hoe je plant, hoe je budgetteert en wat je uiteindelijk krijgt.
Hieronder lees je hoe een feature team en een productteam verschillen, waarom wij kiezen voor werken als productteam en wat dat voor de klant betekent.
Wat is een feature team?
Een feature team is een team dat een lijst met features krijgt en die bouwt. De roadmap is een set verzoeken, meestal van stakeholders of klanten, en de taak van het team is ze op tijd op te leveren.
Succes wordt gemeten aan output: is wat we afspraken opgeleverd, binnen budget en planning?
De term heeft in Scrum en LeSS een tweede betekenis: een cross-functioneel team dat een complete feature van begin tot eind bouwt in plaats van één technisch onderdeel (zie LeSS feature teams). In dit artikel bedoelen we de andere betekenis: een team dat features aangereikt krijgt om te bouwen, tegenover een productteam dat een probleem krijgt om op te lossen.
Wat is een productteam?
Een productteam is een cross-functioneel team dat verantwoordelijk is voor een uitkomst, zoals een bedrijfsresultaat of een verandering in gebruikersgedrag. Het krijgt een probleem om op te lossen, geen lijst met oplossingen.
Het team doet zelf discovery: het praat met klanten, test aannames en meet wat gebruikers echt doen. Op basis daarvan bepaalt het wat er gebouwd wordt en het wordt afgerekend op resultaat. Dit is het idee achter empowered productteams in het product operating model. Marty Cagan beschrijft het verschil in Product vs. Feature Teams.
Feature team vs productteam: de verschillen
| Feature team | Productteam | |
|---|---|---|
| Startpunt | Een lijst met features | Een probleem of uitkomst |
| Roadmap | Een vaste lijst met verzoeken | Een set aannames die verandert met wat het team leert |
| Planning | Vooraf offreren en plannen | Korte cycli, bijgesteld op basis van resultaten |
| Discovery | Vooraf of buiten het team gedaan | Continu en onderdeel van het werk van het team |
| Wie bepaalt wat er gebouwd wordt | Stakeholders | Het team, samen met stakeholders |
| Succes wordt gemeten aan | Features die op tijd zijn opgeleverd | KPI’s en veranderingen in gebruikersgedrag |
Waarom een feature team naar waterval duwt
Als een team een lijst met features krijgt, moet iemand vóór de start een prijs en een datum aan die lijst hangen. Dat dwingt een watervalwerkwijze af, ook als het team in sprints werkt: vooraf offreren, vooraf voorspellen en vooraf adviseren over hoe effectief elke feature zal zijn.
Dat zien we vooral in het geld. Omdat de scope vastligt voordat er iets geleerd is, moeten we in elke offerte een extra marge voor risico opnemen. Daardoor lopen we het risico te hoog of te laag te offreren, en allebei is slecht voor de klant.
Te hoog offreren betekent dat de klant betaalt voor risico dat misschien nooit optreedt.
Te laag offreren raakt de klant op twee manieren. Of we houden een project over dat de moeite niet loont, waardoor we er onze beste mensen niet op kunnen zetten. Of we vragen extra werk aan om het gat te dichten, en dan krijgt de klant te maken met onverwacht werk en kosten waar hij geen rekening mee hield.
Je kunt vooraf niet weten wat gebruikers willen
Om een offerte te kunnen maken heeft een feature team een stuk werk nodig dat groot genoeg is om te prijzen. Dat stuk combineert dingen die goed bekend zijn met dingen die nog niet bekend zijn.
Het gevolg is dat aannames worden omgezet in feature requests. Niemand kan vooraf weten wat gebruikers willen, dus een deel van wat gebouwd wordt doet er niet toe en dat merk je pas achteraf.
Een productteam werkt anders. Het kan bij klanten gaan zitten om de vraag te begrijpen en het kan KPI’s op gebruikersgedrag volgen. Als een kleine aanpassing live gaat, laat de data zien of het gedrag veranderd is of niet.
Zo kun je bouwen wat je bij het doel brengt en stoppen met bouwen wat dat niet doet.
Productteams voor experts die niet technisch zijn
Veel van onze klanten zijn expert in hun vakgebied, maar weten niet hoe technische productontwikkeling werkt. Voor hen nemen wij de verantwoordelijkheid en begeleiden we ze door het proces.
We bouwen een strategische roadmap, werken die uit, plannen alle lagen tot op sprintniveau en volgen de KPI’s. Zo maken wij in onze ervaring veel meer impact. Sommige klanten hebben ons zelfs aandelen gegeven.
Zo maken we de waarde vanaf het begin zichtbaar
Budget is het moeilijkste onderwerp in dit gesprek. Een klant die nog niet met ons gewerkt heeft, moet erop kunnen vertrouwen dat hij voor de prijs iets substantieels krijgt.
Die zorg is begrijpelijk. Klanten die nog niet met ons gewerkt hebben, zijn vaak terughoudend. Ze vrezen een retainer waarin uren worden verbrand zonder duidelijk resultaat, of erger nog, uren die alleen op papier bestaan.
Daarom zijn we waarde- en uitkomstgedreven en wordt dat binnen de eerste drie maanden duidelijk. In die periode maken we een strategische roadmap, bepalen we de KPI’s en leveren we direct waarde. Lukt dat niet, dan garanderen we dat je je geld terugkrijgt.
Werken als productteam met Wise Minds
Een product team as a service van Wise Minds werkt vanaf de eerste dag zo. Weet je nog niet wat je als eerste moet bouwen? Lees hoe je je volgende feature bepaalt of bekijk onze product discovery.
Voor de mensen in zo’n team, zie hoe je een softwareteam structureert en het verschil tussen een product owner en een product manager.
Wil je ervaren productleiderschap zonder een fulltime hire? Bekijk product management als dienst.
Veelgestelde vragen
Wat is het verschil tussen een feature team en een productteam?
Een feature team bouwt een lijst features die het krijgt. Een productteam krijgt een probleem of uitkomst en bepaalt zelf wat er gebouwd wordt om het op te lossen, op basis van discovery en data.
Wat is een feature team in Scrum?
In Scrum en LeSS is een feature team een cross-functioneel team dat een complete klantgerichte feature van begin tot eind kan bouwen, zonder afhankelijk te zijn van andere teams. Het is het tegenovergestelde van een componentteam.
Wat is het verschil tussen een feature team en een componentteam?
Een feature team werkt over alle technische lagen heen om een complete feature op te leveren. Een componentteam beheert één technisch onderdeel, zoals de database of de API, waar andere teams van afhankelijk zijn.
Wat heeft een productteam nodig om goed te werken?
Toegang tot klanten en gebruiksdata, een duidelijke uitkomst om naartoe te werken, de vaardigheden om in één team te ontwerpen, bouwen en testen, en de ruimte om zelf te kiezen welke oplossing gebouwd wordt.
Kan een bedrijf feature teams en productteams naast elkaar hebben?
Ja. Het label beschrijft hoe een team zijn werk krijgt. Veel bedrijven hebben teams die oplossingen aangereikt krijgen naast teams die een probleem krijgen, en groeien in de loop van de tijd naar het tweede.