Hogyan kell a funkció ötleteket priorizálni?

Funkció ötletekből valószínűleg egyik digitális cég sem szenved hiányt. Eleget tegyünk-e ennek vagy annak a feature reqestnek, a meglévőkből érdemes mindent megtartani, egyáltalán tudjuk-e, hogy mik a legfontosabb funkciók?

Ezek olyan kérdések, amivel minden product team gyakran szembetalálja magát. Ráadásul, ha nem vigyázunk, az idő előrehaladtával egy karácsonyfára fog hasonlítani a weboldalunk, vagy az appunk a soha véget nem érő feature requesteknek automatikus implementálása miatt. A túl sok funkció növeli a komplexitást, ami viszont a konverzió legnagyobb ellensége.

Óvatosan a panaszkodó felhasználókkal

Mielőtt belevágnánk a feature priorizálásba, egy jelenségről ejtsünk szót, ami sok tekintetben rossz irányba viheti el a terméket. Sőt gyakran közvetlenül felelős azért, hogy végül karácsonyfaszerű, rosszul használható termékek lesznek korábban jól használható rendszerekből. Egy fejlesztési igény ettől az ügyféltől, egy másik attól, és már úszunk is a feature tengerben, szóval könnyebb ilyen helyzetbe kerülni, mint gondolnád.

Gyakori ugyanis, hogy a leghangosabban panaszkodó ügyfél/user megkapja végül, amit akar, függetlenül attól, hogy mennyiben volt jogos az igény. A product menedzsmentben pedig nehéz a stratégiára fókuszálni miközben valamilyen dühös felhasználó egyetlen funkció hiánya, vagy drasztikus megváltoztatása miatt lázadozik. Így érdekes módon ezek a kis igények hosszú távon is ártalmasak lehetnek, mert ellopják a fókuszt.

Általában, aki panaszkodik emailben, telefonon az frusztrált, és az is megeshet, hogy a megfogalmazott igénye nem is az ő tényleges problémájáról szól, csupán abban manifesztálódik. Az igényt ennek megfelelő óvatossággal kell kezelni.

Ezzel természetesen nem akarom azt mondani, hogy ne hallgasd meg a panaszokat egyáltalán, hanem ne reaktívan – valaki kér valamit, te meg lefejleszted – reagálj, hanem proaktívan keresd meg a felhasználói problémákat, user kutatásokkal, mert ez az egyetlen működő módja, hogy feltárd a valódi szükségleteket és problémákat. Ez nem mond ellent a human-centered szemléletnek, sőt.

Persze néha az is előfordul, hogy az ügyfélszolgálatnak panaszkodónak igazuk van, az viszont fontos, hogy ne az alapján priorálj egy funkció igényt, hogy kiadta elő leghangosabban.

Fontos kérdések mielőtt belevágnál egy új funkció fejlesztésébe

Természetesen a házon belülről érkező funkció kéréseknél is szükséges a körültekintés, mert azok is könnyedén vihetnek tévútra. Egyébként is jellemző, hogy az ötletek a tulajdonos/PM fejéből pattannak ki, az ő saját problémájára válaszul, ami viszont egyáltalán nem biztos, hogy a felhasználónak is problémája:

Mielőtt egyetlen placeholdert letennél a drótvázadba érdemes 10 percet szánni a miértek feltérképezésére:

• Miért dolgozunk ezen a fejlesztésen? Milyen user problémát old meg a feaure?
• Kinek a problémája, és honnan tudjuk, hogy tényleges, nem csak feltételezett problémával állunk szemben?
• A felvetett funkció a megfelelő módja a probléma megoldásának?

Tehát ha egy mód van rá, szenteljünk egy kis időt arra, hogy megértsük a kiindulási problémát és győződjünk meg róla, hogy a kitalált funkció kínálja a legjobb megoldást. Az is előfordulhat, sőt igen gyakori, hogy már az alapok sem validak, nem értjük a problémát, vagy a kitalált válasz sem oldja azt meg.

Funkció ötletek kockázatmentes tesztelése fake door MVP-vel

A fake door tesztben egy funkciót úgy mutatsz meg a felhasználóknak, hogy ténylegesen még nem is létezik. Tehát anélkül, hogy fejlesztenél bármit, az emberek elé tárod a featuret és arra kéred őket, hogy lépjenek vele interakcióba, ami lehet például egy gomb, vagy egy ikon. Amikor a felhasználó rákattint, feldobhatsz egy modalt, amiben tájékoztatod, hogy a funkció még nem létezik, de hasznos visszajelzést adott az érdeklődésével. Ilyen módon kockázatmentesen derülhet ki az új feaure felé mutatkozó igény.

Két legyet üthetsz egy csapásra, ha a modalban email címet is bekérsz, hogy később a felhasználó értesülhessen a funkció elindulásáról. A Buffer éppen ezzel a módszerrel tesztelte a fizetős verzióra mutatkozó igényt:

Feature audit

Hogyan lehet kideríteni, hogy melyek azok a meglévő funkciók, amelyek hasznosak, és melyek kevésbé? A képlet nagyon egyszerű, azt kell megvizsgálni hányan használják a funkciót és milyen gyakran.

Ha vizualizálni akarod a kérdést, akkor még jobban kitisztulhat a kép, a gyakoriságot és a felhasználók számát tegyük tengelyekre:

Ezzel a feature auditnak nevezett rendszerrel hiteles kiindulási képet lehet kapni a tényleges használatról. Mert lássuk be sokunk fejében az a kép él, hogy minden egyes funkciónkat, az összes felhasználónk rendszeresen, örömmámorban úszva használ, tehát a feature audit például egy ilyen képet mutat:

Aztán persze ha ténylegesen elkezdünk auditálni az álom más testet kezd ölteni:

Például az audit segítségével rábukkanhatunk olyan funkciókra, amit kevesen használnak de gyakran. Mondjuk van egy feature, ami csupán 10%-a a felhasználóknak használja, de minden egyes nap. Ez azt üzeni, hogy a funkció érdekes, de valószínűleg nehezen megtalálható. Persze itt már mélyebbre is lehet fúrni és kideríteni az okokat, hogy miben látják a hasznosságát a felhasználók ennek a funkciónak.

Mit kezdjünk a feature audit eredményeivel?

Az eredmények 4 lehetőséget kínálnak a továbblépéshez:

• Killed it: Tedd túl magad a kudarcon, és kukázd a funkciót.
• Növeled az adaptációs arányt: Szerezz több embert, aki használja a feature-t.
• Növeld a gyakoriságot: Vedd rá a felhasználókat, hogy gyakrabban használják
• Fejleszd tovább

Feature audit tool

Nem kell túllihegni a kérdést, de segíthet, ha valamilyen áttekinthető módon vizualizálódnak az adatok. Van rá már kész tool is, hasonlóan működik mint a Google Analytics. Js kódot kell berakni az oldalba, a funkciókat pedig az Analytics-hez hasonló event méréssel ellátni, a rendszer pedig a használati gyakoriság és user szám tengelyen mutatja az adatokat

A funkció ötletek priorizálásakor a karácsonyfa kinézet elkerülése érdekében légy szigorú, és következetesen alkalmazd a kevesebb több mantrát. Új ötleteket tesztelni tudsz fake door MVP-vel, a meglévő funkcionalitás vizsgálatához pedig a feauture audit jó módszer lehet.