Values geven aan tickets/prio's zonder echte measurable KPI

[meermarco]

Ten eerste hoop ik dat dit de juiste sectie is. Zo niet, excuus en evt graag verplaatsen.

Vraag: Voor heel veel zaken binnen prioritering etc is mij alles duidelijk bij het huidige project. Duidelijke tickets, welke prio op basis van waardetoevoeging etc.

Maar hoe prioriteren jullie minder duidelijke measurable (financial) KPI's

Voorbeeld:

Ipv papieren ticket en/of PDF biedt je een mogelijkheid aan om het ticket in Wallet/Pay te zetten.
Je zult er niet meer tickets door verkopen. Het is enkel wat fijner voor de gebruiker. X procent geeft aan het fijner te vinden. Maar het maakt in hun aanschaf niet uit.

Zeggen jullie dan: Dus niet doen, of kan je het op een andere manier waarde geven?

[gitaarwerk]

NPS. Als je niet weet of je feature wel gebruikt gaat worden en bijdraagt aan ROI betreft financien, kun je ook NPS meten. Wil je geen zin hebben in een hele feature te bouwen, kun je ook een zogenaamde pretotype bouwen. Is eigenlijk niets meer dan een prototype zonder functionaliteit. Je released het met tracking/feedback optie en als mensen het willen haal je het na X-keer gebruiken weer offline, en ga je het opnieuw prioriteren.

Is een mogelijkheid.

[meermarco]

Thnx. Ik bedoel hoe kun je een betere NPS op bovenstaande bijvoorbeeld omzetten naar een financiële? Of kortere wachttijd klantenservice betere NPS. Maar door die x seconden korter gaan ze niet meer besteden. Alsnog nuttig of?

[ Voor 38% gewijzigd door meermarco op 08-07-2019 18:10 ]

[Douweegbertje]

Gevoel, ervaring en ervaringen van derden.
Ten eerste heb je het al over: "Je zult er niet meer tickets door verkopen."

Volgens mij is dat al discutabel. Misschien zijn er wel mensen die dit perse willen en naar een concurrent gaan.

Dus je zou een ticket/story kunnen maken om nu eens een degelijk onderzoek te doen. Hier kan je wel degelijk een KPI aan hangen natuurlijk Aan de hand van de uitkomst zou je weer een vervolg story kunnen maken met een KPI gebaseerd op je onderzoek. Eventueel door een proof of concept te maken en bepaalde effecten hiervan te meten.

Daarnaast is het soms waardevol om te blijven investeren en innoveren. Ook al heeft x-% van de features geen daadwerkelijk (direct) effect.

[TRON]

Ik zou zelf de focus meer leggen op zaken waar van je weet dat jouw klanten ontevreden over zijn of waar ze echte en gemis aan hebben. Denk hierbij aan het Pareto-principe: 80% oplossen door 20% energie er in te steken. De resterende 20% oplossen kost 80% van de energie. Leg de focus op de eerste 80%.

Om het makkelijker te maken, zou je je klanten indirect in het verbeterproces kunnen betrekken door bijv. een mini-enquête uit te zetten waarbij men hun voorkeuren van volgorde van wijzigingen kan aangeven.

[Hydra]

Wat in mijn ervaring het beste werkt is te prioriteren op wat gebruikers willen. En dat betekent dus dat je echt mensen hebt die de eindgebruikers interviewen, bijvoorbeeld in een online community, of via echte meetups. Vanuit die wensenlijst kun je dus een prioritised list van stories maken. Als je het niet aan de gebruiker vraagt, blijft het gissen.

Hiermee beweer ik dus niet het omgekeerde, dat je nooit dingen moet bouwen waarvan gebruikers nog niet weten dat ze het willen hebben!

[ShitHappens]

Je zou met een puntensysteem kunnen werken, waarmee stories met de meeste punten de hoogste prioriteit krijgen.
Die puntentelling kun je dan baseren op alle aspecten die je af wilt wegen:
- Voldoen aan wettelijke voorschriften/reguleringen/richtlijnen
- Gebruikers geld besparen
- Je eigen omzet verhogen
- Het gebruikersgemak verhogen
- Kosten drukken
- Stabiliteit verhogen
- % van klanten dat erom vraagt
- USP
- Behouden van klanten (voorkomen dat ze opzeggen)

Maar vooral vragen aan klanten. Wij hadden eens een lijst met 10 potentiële nieuwe features, waarvan we geen idee hadden wat onze klanten 't belangrijkst vonden (we wisten alleen dat ze állemaal belangrijk waren). Simpelweg enquête gedaan om ze te ranken van 1-10. Het laatste is sowieso het belangrijkst om aan te blijven denken. Je maakt software niet voor jezelf, maar voor je gebruikers.