Mooie features beleid (nieuwe aanpak)

[jelle.]

Welkom in Mooie features! Dit is de centrale plek om je ideeën, suggesties en feedback te delen over hoe we Tweakers verder kunnen verbeteren. Daarom horen we hier graag welke gebruikersproblemen je ervaart. Daarnaast gebruiken we dit forum voor centrale feedbacktopics rondom grote projecten, zoals gebruikersreviews, dark mode en de frontpagevernieuwing. Mooie features wordt gelezen en onderhouden door het Product-team, bestaande uit Sander, Femme, Bo en Jelle.

Nieuwe aanpak

De afgelopen tijd hebben we in Mooie features geconstateerd dat de manier van indienen van feature requests niet strookt met onze visie op productontwikkeling op Tweakers. Dat heeft verschillende redenen. Allereerst zagen we dat door het ontbreken van een template de topics varieerden van obscure n=1-verzoeken tot compleet uitgewerkte oplossingen. Regelmatig ontbrak de context waarom iets een probleem is.

Daarnaast werd onder andere met het waarderen (duimpje omhoog) van feature requests de suggestie gewekt dat nagenoeg elk verzoek vroeg of laat gebouwd zou worden. Daarmee gingen we voorbij aan onze verantwoordelijkheid als Product-team om waarde toe te voegen. Hiermee bedoelen we dat we Tweakers beter willen maken voor gebruikers en het bedrijf op basis van wensen die er leven, maar hier altijd keuzes in moeten maken. Dat doen we aan de hand van onze productvisie (waar willen naartoe), de strategie (hoe gaan we dat doen) en onze roadmap (wanneer doen we dat). Alles wat we bouwen moet tenslotte in verhouding staan tot de tijd die hierin geïnvesteerd wordt én het moet passen in waar we uiteindelijk naartoe willen bewegen.

Tot slot zagen we een populariteitsbias in het stemmen op feature requests, waarbij bovendien weinig rekening werd gehouden met de vele verschillende gebruikersgroepen die we op Tweakers bedienen.

Het resultaat hiervan was dat vele feature requests onbeantwoord bleven, wat leidde tot teleurstelling onder degenen die de moeite hadden genomen om een verzoek in te dienen. Daarom starten we vanaf nu met een nieuwe aanpak, die bestaat uit drie onderdelen:

1. Een focus op het gebruikersprobleem in plaats van de oplossing; het is namelijk onze taak om problemen op te lossen, niet om features te bouwen.
2. Een vaste template om je probleem en mogelijke oplossing(en) kenbaar te maken.
3. Een meer proactieve rol en structurele terugkoppeling vanuit het Product-team.

Template voor nieuwe topics

Allereerst: dit forum is bedoeld om voor het oplossen van gebruikersproblemen. Loop je ergens tegenaan dat stuk is, dan kun je daarvoor een topic openen in Stoute bugs. Kijk daarnaast eerst even via de zoekfunctie of jouw probleem niet al eerder is aangekaart.

Probeer in je topic de volgende vragen te beantwoorden:

1. Welk probleem ervaar je?
2. Waarom is dat een probleem?
3. Hoe vaak loop je er tegenaan?
4. Hoe ziet de ideale oplossing er voor jou uit?

Vervolgstappen en terugkoppeling

Nieuwe topics bekijken wij periodiek. De eerste vraag daarbij is of we het probleem écht goed begrijpen, of dat we nog aanvullende informatie nodig hebben. Pas daarna kunnen we dieper ingaan op mogelijke oplossingen. Als we de verbetering of feature waardevol genoeg vinden, het (technisch) haalbaar blijkt én het in lijn is met onze productvisie, komt het op onze backlog.

Wanneer iets wordt opgepakt, is onder andere afhankelijk van hoe groot en complex de wens is. Voor kleine verbeteringen is vaak wel ruimte in een sprint, voor grotere projecten moeten we tijd reserveren. De meeste wijzigingen valideren we vooraf, bijvoorbeeld met een A/B-test of ander kwantitatief onderzoek. Pas daarna kunnen we een besluit nemen over de wenselijkheid om dit te bouwen. Over deze vervolgstappen geven we periodiek updates in het topic, maar we kunnen nooit garanties geven over een planning.

Het staat verder iedereen vrij om mee te denken of discussiëren in het topic, ongeacht of je het probleem wel of niet ervaart. Het geven van duimpjes kan ook nog steeds. Daar kijken we ook naar, maar dit is voor ons niet doorslaggevend om een wens wel of niet te bouwen.

Tot slot: deze nieuwe aanpak zullen we over enkele maanden evalueren. Heb je suggesties of feedback hierover, laat het ons dan weten

[ Voor 3% gewijzigd door jelle. op 04-09-2023 14:33 ]

[FirePuma142]

@jelle.

Wellicht kun je onderstaande tekstueel wat aanpassen aan die verschillende gebruikersgroepen? Ik denk dat de non-Agile/IT'ers er wellicht geen chocola van kunnen maken.

Daarnaast werd onder andere met het waarderen (duimpje omhoog) van feature requests de suggestie gewekt dat nagenoeg elk verzoek vroeg of laat gebouwd zou worden. Daarmee gingen we voorbij aan onze Product-verantwoordelijkheid om waarde toe te voegen en wensen te prioriteren aan de hand van onze roadmap, visie en productstrategie.

[P_Tingen]

Is die backlog op een of andere manier ook inzichtelijk? Wat ik nog een beetje mis is de link tussen zaken die hier genoemd (gaan) worden en die backlog. Hoe weet ik straks of een probleem wel of niet wordt opgepakt?

[Anoniem: 1777010]

Als we de verbetering of feature waardevol genoeg vinden, het (technisch) haalbaar blijkt én het in lijn is met onze productvisie, komt het op onze backlog.

De ervaring leert (niet alleen op Tweakers) dat "nee" een eindeloze discussie oplevert, nog langer dan de oorspronkelijke discussie over het probleem. Hebben jullie al een werkwijze bedacht om die discussie te kunnen beslechten, zonder weer in eindeloze herhaaldiscussies verzeild te raken?

Ik heb zelf op een gegeven moment een "deze features komen er niet"-lijst gemaakt waarop alles te vinden was dat sowieso niet ging gebeuren. Denk daarbij aan zaken die technisch veel te complex zijn, n=1, past niet in de visie, whatever. Korte toelichting, en klaar. Zeker geen lange toelichting!

Ik denk bijvoorbeeld aan de "mute een user"-discussie waarvan ik vrij zeker weet dat jullie het niet gaan inbouwen. Of de prioriteit is zo laag dat je nooit boven andere requests uit zal gaan komen. Kan je daar niet beter gewoon van zeggen: "gaan we niet doen, reden X, einde discussie"?

[jelle.]

FirePuma142 schreef op maandag 4 september 2023 @ 14:00:
@jelle.

Wellicht kun je onderstaande tekstueel wat aanpassen aan die verschillende gebruikersgroepen? Ik denk dat de non-Agile/IT'ers er wellicht geen chocola van kunnen maken.

Goed punt, aangepast

P_Tingen schreef op maandag 4 september 2023 @ 14:16:
Is die backlog op een of andere manier ook inzichtelijk? Wat ik nog een beetje mis is de link tussen zaken die hier genoemd (gaan) worden en die backlog. Hoe weet ik straks of een probleem wel of niet wordt opgepakt?

Nee, die is niet inzichtelijk. De communicatie over de opvolging zal plaatsvinden in het betreffende topic. We zullen dus ook aangeven als we iets sowieso niét gaan doen. Wat me brengt bij het volgende punt:

Anoniem: 1777010 schreef op maandag 4 september 2023 @ 14:36:
De ervaring leert (niet alleen op Tweakers) dat "nee" een eindeloze discussie oplevert, nog langer dan de oorspronkelijke discussie over het probleem. Hebben jullie al een werkwijze bedacht om die discussie te kunnen beslechten, zonder weer in eindeloze herhaaldiscussies verzeild te raken?

Ik heb zelf op een gegeven moment een "deze features komen er niet"-lijst gemaakt waarop alles te vinden was dat sowieso niet ging gebeuren. Denk daarbij aan zaken die technisch veel te complex zijn, n=1, past niet in de visie, whatever. Korte toelichting, en klaar. Zeker geen lange toelichting!

Ik denk bijvoorbeeld aan de "mute een user"-discussie waarvan ik vrij zeker weet dat jullie het niet gaan inbouwen. Of de prioriteit is zo laag dat je nooit boven andere requests uit zal gaan komen. Kan je daar niet beter gewoon van zeggen: "gaan we niet doen, reden X, einde discussie"?

Ja, we streven ernaar om daar duidelijk(er) over te communiceren zodat voor iedereen duidelijk is wat we wel en niet gaan doen. Ben het met je eens dat dat zou moeten helpen in de discussies, al kunnen plannen in de toekomst natuurlijk altijd weer veranderen. Het voorbeeld dat je noemt heb ik toevallig vandaag nog besproken met onze communitymanager, to be continued

[Anoniem: 1777010]

jelle. schreef op maandag 4 september 2023 @ 14:47:
[...]


Ja, we streven ernaar om daar duidelijk(er) over te communiceren zodat voor iedereen duidelijk is wat we wel en niet gaan doen. Ben het met je eens dat dat zou moeten helpen in de discussies, al kunnen plannen in de toekomst natuurlijk altijd weer veranderen. Het voorbeeld dat je noemt heb ik toevallig vandaag nog besproken met onze communitymanager, to be continued

Ja ik wist wel dat je zou zeggen, "plannen kunnen veranderen" en dat klopt, maar het punt is dat jij dat bepaalt. Dus jij zegt nu nee. Je kan altijd nog ja zeggen, sure, maar op het moment dat je daar teveel ruimte voor biedt krijg je elke 3 weken de vraag "en nu?", "en nu?".

Als middenweg (maar dit doe ik zelf niet) kan je nog zeggen: het antwoord is nee en om 4 september 2024 mag je het nog een x vragen.

Ben overigens benieuwd!

[Sando]

Is dit een reactie op mijn twee feature requests die met stip bovenaan stonden op de lijst die nu niet meer gebruikt wordt? Ik had dit topic even gemist, maar het is misschien ook een beetje flauw dat er niet even iemand reageert op de vraag om te reageren, maar dat er wel stilletjes dit topic wordt gepost. Dat is nog niet helemaal in lijn met het streven "om daar duidelijk(er) over te communiceren zodat voor iedereen duidelijk is wat we wel en niet gaan doen".

Wat is een populariteitsbias? Dat de ene feature request gewilder is dan de ander? Als ik het goed begrijp verwijderen jullie elke (publieke) vorm van overzicht op backlog en feature populariteit. Dat vind ik jammer. Als niemand (van Tweakers) antwoord geeft op mooie features, is eigenlijk de enige energie die je er nog uit haalt het idee dat je hoog in het lijstje van medestanders staat en de karma die je daarmee verdient. Maar nu haal je dat ook min of meer weg. Kan je dit subforum niet gewoon verwijderen dan? Dat schept minder verwachting, en dus minder teleurstelling.

Zo niet, dan klinkt het inderdaad wel logisch om de boel wat te moderniseren, een template te maken en de focus te richten op het probleem in plaats van de oplossing (feature). Alleen moet de naam van dit forum dan wel anders, want 'mooie features' impliceert juist dat jullie hier wél zijn om mooie features te bouwen. Wat dat betreft is niet de indruk "ontstaan", maar hebben jullie de indruk "gewekt".

Feedback op nieuwsberichten moderniseren
Duurzaamheidsscore en Privacyscore bij smartphones

[ Voor 35% gewijzigd door Sando op 07-10-2023 02:36 ]

[jelle.]

Bedankt voor je feedback!

Sando schreef op zaterdag 7 oktober 2023 @ 01:21:
Is dit een reactie op mijn twee feature requests die met stip bovenaan stonden op de lijst die nu niet meer gebruikt wordt?

Nee hoor, dat is geen reactie daarop Deze nieuwe aanpak hebben we geïntroduceerd omdat we al langere tijd zagen dat in het algemeen de manier van feature requests indienen lastig te verenigen was met onze werkwijze. Dat had zoals gezegd te maken met het ontbreken van een template, maar ook met dat een "meest gewaardeerde requests"-lijstje de suggestie wekte dat we hoe dan ook alles zouden bouwen. Dat is tevens het probleem van een publieke backlog, want dat wordt gauw gezien als een commitment, terwijl onze prioriteiten of planning altijd kunnen veranderen. Daarom is het zo belangrijk dat we wensen goed onderzoeken vóórdat ze op onze delivery backlog belanden, en dat is iets wat we in de topics zelf willen uitvragen en terugkoppelen.

Ik had dit topic even gemist, maar het is misschien ook een beetje flauw dat er niet even iemand reageert op de vraag om te reageren, maar dat er wel stilletjes dit topic wordt gepost. Dat is nog niet helemaal in lijn met het streven "om daar duidelijk(er) over te communiceren zodat voor iedereen duidelijk is wat we wel en niet gaan doen".

Jouw topics zijn we zeker niet vergeten, maar we zijn er nog niet aan toegekomen om er inhoudelijk op te reageren: Feedback op nieuwsberichten moderniseren gaat @Femme naar kijken en Duurzaamheidsscore en Privacyscore bij smartphones moet ik nog verder onderzoeken.

Wat is een populariteitsbias? Dat de ene feature request gewilder is dan de ander?

Met een populariteitsbias bedoelen we in dit geval dat een lijstje dat gesorteerd is op meeste +1's, geen zuivere manier is om te stemmen. Je ziet immers altijd als eerste de items die door anderen al als populair zijn bevonden, wat leidt tot een bias. Bovendien zegt dit ook nog eens weinig over de representativiteit van de groep mensen die de moeite neemt om in dit forum te kijken en te stemmen. Nou zou je natuurlijk een complete lijst met alle feature requests kunnen maken die willekeurig gesorteerd is en niet het aantal stemmen toont, maar dan kom ik weer terug bij mijn eerste punt: er zijn veel betere manieren om de wenselijkheid en mate van behoefte te toetsen, iets wat wij product discovery noemen.

Alleen moet de naam van dit forum dan wel anders, want 'mooie features' impliceert juist dat jullie hier wél zijn om mooie features te bouwen. Wat dat betreft is niet de indruk "ontstaan", maar hebben jullie de indruk "gewekt".

Het wekt inderdaad de suggestie dat het doel is om features te bouwen, maar in het kader van het herkenbaarheid hebben we besloten dit zo te laten. En in de praktijk zal het ook regelmatig voorkomen dat we een gebruikersprobleem kunnen oplossen met een "mooie feature". Maar als je suggesties hebt voor een betere naam, laat het gerust weten. "Mooie problemen" vonden wij in ieder geval niet zo positief klinken

[Ursamajor]

Beste product owners, wat leuk dat jullie te horen waren in de Product Owner podcast! Ik zag er nog geen reacties van op dit forum, maar bij deze! Ik vond hem erg interessant en goed eens jullie verhaal zo te horen.

[Warpozio]

https://gathering.tweakers.net/forum/list_messages/1903242
Deze feature request uit 2019 stond in 2023 op de eerste plaats van de dynamische lijst met meest gewaardeerde feature requests.
https://gathering.tweakers.net/forum/list_messages/1744311

[franssie]

ik zocht op gebruiker filteren css en kom hier uit? (edit: via twee gesloten topics oid)

Hoe dan ook, er zijn gebruikers waar ik me aan irriteer, en waarschijnlijk ook gebruikers die zich aan mij dood ergeren.

Ik had een filter met wat moeite via CSS ingesteld, maar kan dat geen optie worden?

[ Voor 6% gewijzigd door franssie op 08-08-2024 21:11 ]

[jelle.]

franssie schreef op donderdag 8 augustus 2024 @ 21:11:
ik zocht op gebruiker filteren css en kom hier uit? (edit: via twee gesloten topics oid)

Hoe dan ook, er zijn gebruikers waar ik me aan irriteer, en waarschijnlijk ook gebruikers die zich aan mij dood ergeren.

Ik had een filter met wat moeite via CSS ingesteld, maar kan dat geen optie worden?

Je bent hier waarschijnlijk gekomen via dit topic? Zoals daar uitgelegd is dit geen optie die we overwegen.

Dit topic is overigens niet bedoeld voor specifieke feature requests, maar gaat in het algemeen over het beleid in dit forum. Voor specifieke wensen kun je een nieuw topic maken, tenzij er natuurlijk al een topic voor bestaat

[84hannes]

Het is inmiddels ruim een jaar gelden dat dit topic geopend werd, met de afsluitende woorden:

Tot slot: deze nieuwe aanpak zullen we over enkele maanden evalueren. Heb je suggesties of feedback hierover, laat het ons dan weten

Hoe ging deze evaluatie?

Je ziet immers altijd als eerste de items die door anderen al als populair zijn bevonden, wat leidt tot een bias.

Samen met @Sando heb ik erg mijn best gedaan de leden van Tweakers naar ons verbetervoorstel te laten kijken. De suggestie dat 84hannes in "Feedback op nieuwsberichten moderniseren" alleen bovenaan staat omdat ie boven aan staat wil ik dan ook ver van me werpen. Een paar keer per dag leveren mensen een misplaatste feedback-post onderaan een artikel. Regelmatig hebben we daarop gereageerd door ons voorstel te noemen, en iedere keer kwamen er weer een paar stemmen bij. We hebben veel moeite gestoken in het probleem en mogelijke oplossingen te bespreken, en dat werd gewaardeerd door een eerste plaats in het overzicht. Dat dit overzicht vervolgens zonder fatsoenlijke mededeling met pensioen wordt gestuurd voelt als een steek in de rug van een paar leden die veel energie hebben gestoken in het verbeteren van de ervaring op Tweakers.net. Begrijp me goed, ik weet dat het niet zo bedoeld is, maar ik zou liegen als ik beweer dat het anders overkomt.

Om terug te komen op mijn oorspronkelijke vraag: hoe verloopt het nieuwe beleid?

[jelle.]

84hannes schreef op donderdag 26 september 2024 @ 13:06:
Hoe ging deze evaluatie?

Leuk dat je ernaar vraagt We hebben binnen ons team een aantal keer besproken wat er met deze werkwijze wel goed gaat en wat minder goed. Om met het eerste te beginnen: we zien dat de template goed werkt en dat de meest feature requests die worden ingediend, voorzien zijn van de juiste context om het probleem goed te begrijpen. Dat helpt ons enorm om het verzoek te kunnen beoordelen en in een aantal gevallen meteen te kunnen zeggen of we hier (op korte termijn) iets mee gaan doen.

Tegelijkertijd zien we ook nog steeds een grote uitdaging in de hoeveelheid wensen die er zijn en de tijd die we daarvoor beschikbaar kunnen maken. We zijn maar met een klein team (9 developers, 2 UX-designers en 2 PO's) waarmee we heel Tweakers moeten onderhouden. Van frontpage tot Pricewatch tot forum, maar ook voor de gebruiker onzichtbare systemen als het CMS en Pricewatch Manager. Dat leidt er onvermijdelijk toe dat bepaalde onderdelen minder aandacht krijgen dan we zouden willen. En dus ook dat verzoeken en suggesties die in dit forum gedaan worden, vaker onbeantwoord blijven dan we zouden willen.

Het verbetervoorstel van jou en @Sando rondom het geven van feedback op nieuwsberichten is een goed voorbeeld hiervan. We kennen dit gebruikersprobleem en het is ook meerdere keren intern besproken, we hebben zelfs al gekeken welke oplossing we het meest geschikt vonden. Maar het ontbreekt vervolgens simpelweg aan tijd om dit daadwerkelijk uit te voeren. Of beter gezegd: er zijn andere (gebruikers)problemen die waardevoller, belangrijker of urgenter waren om op te lossen. Niet alles daarvan is zichtbaar voor de gebruiker. Zo hebben we afgelopen maanden bijvoorbeeld hard gewerkt aan verbeteringen onder de motorkap van de Pricewatch, om ervoor te zorgen dat deze in de toekomst even goed blijft werken als nu. En daarnaast hebben we te maken met bijvoorbeeld wet- en regelgeving waar we als Tweakers aan moeten voldoen en die grootscheepse aanpassingen achter de schermen vereisen.

Samen met @Sando heb ik erg mijn best gedaan de leden van Tweakers naar ons verbetervoorstel te laten kijken. De suggestie dat 84hannes in "Feedback op nieuwsberichten moderniseren" alleen bovenaan staat omdat ie boven aan staat wil ik dan ook ver van me werpen. Een paar keer per dag leveren mensen een misplaatste feedback-post onderaan een artikel. Regelmatig hebben we daarop gereageerd door ons voorstel te noemen, en iedere keer kwamen er weer een paar stemmen bij. We hebben veel moeite gestoken in het probleem en mogelijke oplossingen te bespreken, en dat werd gewaardeerd door een eerste plaats in het overzicht. Dat dit overzicht vervolgens zonder fatsoenlijke mededeling met pensioen wordt gestuurd voelt als een steek in de rug van een paar leden die veel energie hebben gestoken in het verbeteren van de ervaring op Tweakers.net. Begrijp me goed, ik weet dat het niet zo bedoeld is, maar ik zou liegen als ik beweer dat het anders overkomt.

Ik begrijp wat je hier zegt en hoe dit kan overkomen. We zijn ons er bewust van dat deze wens al heel lang leeft en gigantisch veel steun vanuit de community heeft gekregen. Zoals ik hierboven al schreef is het binnen ons team ook meerdere keren aan bod gekomen, maar komen we er simpelweg niet aan toe. Onze communicatie daarover kan zeker beter dus dat is iets wat ik zal aankaarten. Een proactieve rol en structurele terugkoppeling op verzoeken was namelijk ook onze insteek bij deze nieuwe aanpak, maar dit lijkt me een duidelijk voorbeeld van waar dat tekortschiet. Goed dat je daarop ons wijst. Wat betreft het inhoudelijke vraagstuk: deze verbetering staat nog steeds op onze backlog en we zullen wederom bekijken of dit iets is wat we tussen de grote projecten door kunnen doen. De uitkomst daarvan zal ik in het betreffende topic delen