als u gedurende enige tijd in een product hebt gewerkt, bent u een verscheidenheid aan verschillende toepassingen van de term “productkenmerk”tegengekomen.

Er zijn kenmerken die beschrijven welke kenmerken een product heeft. Dit bericht is geschreven op een MacBook pro met de volgende functies:

• 3.1 GHz Dual-Core Intel Core i7 Processor
• 16 GB 1867 Mhz DDR3 geheugen
• Intel Iris Graphics 6100 153 MB graphics.

Er zijn functies die beschrijven wat een product doet. Dit bericht is geschreven met behulp van Google Docs, die heeft de volgende kenmerken:

• Werkt altijd en overal (zelfs offline)
• Wijzigingen automatisch opgeslagen
• Real-time samenwerking
• Smart bewerken en styling tool
• Brede reeks sjablonen

Zijn er functies die worden weergegeven op uw achterstand. Wanneer de term “functies” wordt gebruikt in de context van de achterstand, verwijst het naar tijdelijke aanduidingen die het werk vertegenwoordigen dat nodig is om functies toe te voegen zoals hierboven beschreven aan uw product.

Het is belangrijk om duidelijk te zijn over wat je bedoelt met feature. Om duidelijkheid te brengen, hier is een blik op wat Product functies zijn, hoe ze in verband met voordelen, hoe u functies vertegenwoordigen, en hoe u functies in productplanning.

wat zijn kenmerken van een product?

Dan Shewan definieerde productfuncties als ” een functie is iets wat uw product heeft of is… dit is typisch functionaliteit die wordt aangeboden door een softwareprogramma dat gebruikers in staat stelt om iets te doen.’

de lijst met functies voor de MacBook Pro en Google Docs hierboven komen overeen met deze definitie. Functies die op deze manier worden gebruikt, beschrijven uw product en helpen uw klanten beslissen of ze het product in de eerste plaats willen kopen. U kunt kijken naar de lijst met functies voor Productboard om te beslissen of het zal u helpen met uw specifieke product management uitdagingen.

Als u verschillende versies van uw product opgeeft, kunt u lijsten met productfuncties gebruiken om ze te onderscheiden. U kunt verschillende lijsten met functies voor verschillende versies gebruiken om uit te leggen wat elke versie wel en niet heeft.

wanneer u functies op deze manier gebruikt, helpt u klanten die al hebben besloten om uw product te kopen beslissen welke versie ze gaan kopen.

u structureert uw beslissingen rond functies. U bepaalt welke functies u wilt aanbieden, welke functies u niet langer wilt aanbieden en in welke volgorde u deze functies verstrekt of verwijdert. Wanneer u beslissingen over wat op te nemen, te nemen, of te laten uit van uw product dat u denkt in termen van functies, maar je die beslissingen te nemen op basis van voordelen.

Features vs. benefits

wanneer uw klanten beslissingen nemen over het al dan niet kopen van uw product, kijken ze misschien naar de features, maar ze proberen echt te beslissen welke problemen uw product hen zal helpen oplossen. Ze proberen het resultaat te bepalen dat ze krijgen van het gebruik van uw product. Ze willen de voordelen begrijpen die ze zullen krijgen.

voordelen zijn de resultaten Of resultaten die gebruikers ervaren door het gebruik van uw product of dienst.

Features representeren outputs. Het zijn dingen die je team levert om je klanten of stakeholders te helpen een specifiek resultaat te realiseren.

begin met het opbouwen van inzicht in de voordelen die uw klanten zoeken. Identificeer vervolgens de functies die uw product nodig heeft en niet nodig heeft om uw klanten te helpen deze voordelen te ervaren. Succes komt wanneer u de voordelen uit te drukken in termen die uw klanten begrijpen, en banden van uw Product functies om die voordelen.

Productboard heeft deze voordelen geïdentificeerd waar potentiële klanten naar op zoek zijn. Onze klanten willen:

• Begrijpen wat gebruikers nodig
• Prioriteren wat op te bouwen
• Deel uw stappenplan
• toezien op de voortgang in de richting van de lancering
• Verdienen het vertrouwen en de buy-in van cross-functionele teams
• Betrek uw klant gemeenschap

op Basis van dat inzicht, Productboard biedt de functies die op onze pagina onderdelen. Terwijl we deze functies beschrijven, geven we aan hoe ze onze klanten helpen de voordelen te ervaren die we hebben geïdentificeerd. Bijvoorbeeld:

Research Repository

begrijpen wat gebruikers nodig hebben

gebruik het insights board om gebruikersonderzoek, feature requests en feedback-streaming vanuit een aantal bronnen te consolideren. Spot trends en identificeren van patronen die u zullen helpen prioriteren wat te bouwen volgende en bouwen op de juiste manier.

Het is handig om deze relatie tussen voordelen en functies in gedachten te houden wanneer u beslist welke functies te leveren en in welke volgorde. De aard van de relatie tussen functies en voordelen helpt u bepalen hoe functies te vertegenwoordigen.

hoe u functies weergeeft

de manier waarop u functies weergeeft, hangt af van of u al weet wat u nodig hebt om de gewenste voordelen te leveren, of of u nog steeds probeert uit te vinden hoe u de beste voordelen kunt bieden.

representeer functies als oplossingen

Soms weet u wat u moet leveren om uw klanten de voordelen te bieden die ze zoeken. Uw product kan volwassen zijn en u voegt een functie toe die veel van uw klanten hebben aangevraagd. Of je voegt een functie toe om een gat met je concurrenten te vullen. U werkt mogelijk aan een B2B-product dat specifieke mogelijkheden nodig heeft om nuttig te zijn.

in die gevallen is het eenvoudigste om uw functie weer te geven zoals deze beschreven zou worden op uw pagina met functies. U kunt bijvoorbeeld expliciet PDF-Export of prioritering Matrix aanroepen als functies waaraan u werkt.

wanneer u functies als een oplossing voorstelt, is het makkelijker om een gedeeld begrip op te bouwen van wat het team gaat produceren, en u hebt een beknopt label voor het team om dingen te refereren in een discussie.

helaas kan het vertegenwoordigen van functies als een oplossing uw team in een specifieke oplossing vergrendelen. Dat kan leiden tot het oplossen van een behoefte die gebruikers niet echt hebben, of het missen van een nog betere oplossing voor het echte onderliggende probleem

je bent nooit echt zeker van de beste manier om een probleem op te lossen wanneer je voor het eerst begint, dus het is het beste om functies als behoeften te representeren.

representeer functies als behoeften

wanneer u functies uitdrukt als behoeften, beschrijft u niet hoe u een resultaat gaat bereiken, u identificeert wat u wilt bereiken. In plaats van het beschrijven van de functie als PDF-Export, je beschrijft het als ik nodig heb om gegevens te kunnen delen met mijn baas.

wanneer u de functie beschrijft als een behoefte, laat u uw opties open voor hoe u aan die behoefte zult voldoen. Je vergroot de kansen op een innovatieve oplossing en je team is meer betrokken bij het leveren van die oplossing omdat ze een stem hebben.

het nadeel van het uitdrukken van functies als behoeften is dat het moeilijker kan zijn om een gedeeld begrip te krijgen over de functies waaraan u werkt. U kunt meer onzekerheid ervaren binnen uw team als u probeert om met de juiste oplossing te komen.

gebruik een mix van beide benaderingen

U kunt het beste worden bediend door beide benaderingen te gebruiken. Wanneer u een duidelijk idee van de oplossing en het heeft geen zin om meer exploratie te doen, definieer de functie als een oplossing. Wanneer discovery is gerechtvaardigd, beschrijf uw functies in termen van behoeften.

hoe functies te integreren in productplanning

wanneer u probeert te beslissen wat u in uw product wilt opnemen en wat u wilt weglaten, begin dan met de resultaten die u probeert te realiseren. Gebruik de strategie van uw organisatie om de functies die u levert te filteren. Communiceer de resultaten van uw beslissingen op uw roadmap.

prioriteer uw functies op basis van resultaten en strategie

zorg ervoor dat u en uw team duidelijk begrijpen welke voordelen u wilt bieden aan uw klanten en identificeer vervolgens de minimale set van functies om deze voordelen te realiseren.

wanneer u een verzoek van uw klanten voor een specifieke functie, graven dieper om te begrijpen waarom. Welk probleem zal die functie hen helpen oplossen? Welke voordelen biedt die functie voor hen?

Als u begrijpt waar uw klanten echt naar op zoek zijn en waarom, kunt u bepalen of de oplossing zinvol is of dat u verder moet zoeken om een betere oplossing te vinden.

alleen omdat u klanten hebt die u vragen om aan een bepaalde behoefte te voldoen, betekent dit niet dat het zinvol is voor uw product of uw organisatie.

u moet de strategie van uw organisatie begrijpen. Gebruik die strategie als een filter om te bepalen welke moet voldoen en welke te negeren. Gebruik die strategie als een filter om te beslissen welke functies te leveren en welke te negeren. De strategie van uw organisatie moet een Poolster zijn voor uw productbeslissingen.

Features en de product roadmap

zodra u hebt besloten om een functie te leveren, is het tijd om het op uw roadmap te zetten. Dit is uw manier om te communiceren over de functies die u van plan bent om te werken aan en wanneer je gaat om te werken aan hen.

betekent dit dat uw roadmap feature-driven moet zijn? Niet noodzakelijk.

u moet uw roadmap rond resultaten organiseren in plaats van outputs. Beschrijf de voordelen die u wilt bieden aan uw klanten in plaats van de functies die u gaat gebruiken om deze voordelen te bieden.

Als u uw roadmap per functie stuurt, communiceert u specifieke informatie over wat u gaat leveren. Dit kan op de korte termijn juist zijn, maar op de lange termijn kan het ver weg zijn. Als u onredelijke verwachtingen wilt vermijden, kunt u beter de resultaten die u van plan bent aan te pakken in specifieke termijnen uitdrukken zonder expliciet te vermelden welke functies u zult leveren om deze voordelen te bieden.

u kunt specifieke functies op uw roadmap hebben, vooral op korte termijn. De sleutel is het stellen van verwachtingen op het juiste niveau van zekerheid in elke situatie.