Ako pomocou AI analyzovať zákaznícku spätnú väzbu pri vývoji produktu
Praktický návod podľa profesie · Modelové príklady

Profesia: Produktový manažér (16. profesia zo 100) Tematické zaradenie: Prvý z piatich spôsobov využitia AI Pracovný výstup: Register používateľských problémov, dôkazov a otázok na ďalší výskum. Príklad: Menšia softvérová firma s aplikáciou na tímové plánovanie; všetky prípady a čísla sú modelové.
1. Keď každý zákazník žiada inú funkciu
Produktový manažér dostáva spätnú väzbu cez podporu, obchodné stretnutia, rozhovory a formulár v aplikácii. Jeden používateľ chce farebnejší kalendár, druhý export do PDF a tretí tvrdí, že nevie zistiť, kto schválil zmenu termínu. Obchodný tím tlačí na export, pretože ho žiadal veľký klient. Vývojári upozorňujú na technický dlh a manažment žiada rýchly plán.
Ak produktový manažér iba spočíta požadované funkcie, môže vybrať nesprávnu prioritu. Za vetou „Potrebujem export do PDF“ môže byť problém odovzdania reportu kolegovi, ktorý nemá účet. AI pomôže vyhľadať spoločné problémy naprieč zdrojmi, no nesmie z požiadavky automaticky vytvoriť technické zadanie.
2. Zozbierajte dáta tak, aby sa k nim dalo vrátiť
Vytvorte jednotný záznam feedback_id | kanál | dátum | rola používateľa | fáza práce | doslovný výrok | produktová oblasť | odkaz na zdroj. Zachovajte rozdiel medzi priamym výrokom používateľa a interpretáciou pracovníka podpory. Do osobitného poľa môžete uviesť ďalší kontext, ale nesmie potichu splývať s citáciou.
Pred spracovaním vyriešte prístupové práva. V zápisoch z rozhovorov bývajú mená zákazníkov, obchodné tajomstvá, interné projekty a niekedy aj citlivé údaje. Použite schválené prostredie a minimalizujte prenos. Nahradenie mena identifikátorom ešte nemusí vytvoriť anonymný údaj, ak firmu alebo jednotlivca možno z kontextu spätne rozpoznať.
Oddelte tiež zdroje podľa povahy: rozhovor vedený výskumníkom, tiket podpory, poznámka obchodníka a kvantitatívna analytika nedávajú rovnaký druh dôkazu. Desať tiketov od jediného klienta nie je to isté ako desať nezávislých zákazníkov.
3. Vyťažte problém, nie navrhované riešenie
Prompt 1 – Štruktúrovanie spätnej väzby
Pracuješ ako asistent produktového manažéra.
Analyzuj anonymizované záznamy s ID.
Pre každý záznam rozlíš:
1. doslovný výrok používateľa;
2. pozorovaný problém alebo prekážku;
3. situáciu, v ktorej problém nastáva;
4. navrhované riešenie používateľa, ak ho uviedol;
5. otázky, ktoré treba overiť rozhovorom alebo dátami.
Nevydávaj svoj odhad za citáciu. Zachovaj ID zdroja.
Nevytváraj fiktívne persony, počty ani súvislosti.
Ak chýba kontext, uveď NEDOSTATOK DÔKAZOV.Modelový vstup: „Potrebujem PDF export; riaditeľ nemá konto v aplikácii a chce stav projektu každý piatok.“
Dobrá extrakcia: Používateľ potrebuje pravidelne odovzdať prehľad stavu projektu osobe bez prístupu do systému. PDF export je jeho navrhované riešenie, nie nevyhnutne jediný spôsob. Na preverenie: kto prehľad číta, aké údaje obsahuje, či sa môže zdieľať odkaz a aké sú požiadavky na prístupové práva.
Z takého výstupu môže neskôr vzniknúť export, plánované zasielanie reportu alebo bezpečné zdieľanie. O konkrétnej funkcii sa ešte nerozhodlo.

4. Zoskupte podobné problémy a ukážte dôkazy
Predstavme si 80 podnetov za dva mesiace. AI navrhne tieto tematické skupiny:
| Zistený problém | Počet záznamov | Overenie pred rozhodnutím |
|---|---|---|
| Nejasné zmeny termínov | 19 | pozrieť používateľské cesty a logy zmien |
| Zdieľanie stavu mimo aplikácie | 14 | rozhovory s tímami a príjemcami reportov |
| Príliš veľa upozornení | 12 | dáta o nastaveniach a kontext upozornení |
| Vyhľadávanie starých úloh | 9 | pozorovanie reálneho postupu |
Ide o modelové počty záznamov, nie o počet odlišných používateľov. Jeden podnet sa môže týkať dvoch problémov. Neuvádzajte preto ich súčet ako percento všetkých zákazníkov. Pred predložením manažmentu vyžiadajte od AI ku každej skupine konkrétne ID a 2–3 anonymizované citácie; vyberte aj príklady, ktoré navrhovanému zovšeobecneniu odporujú.
Prompt 2 – Register problémov
Z roztriedených podnetov vytvor register problémov.
Ku každému uveď: opis problému v jednej vete;
ID dôkazov; počet jedinečných zdrojov; počet jedinečných
organizácií len ak sa dá spoľahlivo určiť;
zasiahnutú úlohu používateľa; známe výnimky;
závažnosť ako pracovnú hypotézu; čo ešte nevieme.
Oddel frekvenciu od závažnosti a závažnosť od
obchodnej priority. Bez ďalších dát nenavrhuj termín
vydania ani konkrétnu technickú implementáciu.5. Preverte, či hlasné komentáre opisujú bežný problém
Sťažnosti na upozornenia môžu pochádzať len od administrátorov veľkých tímov. Preto výsledky porovnajte s analytikou: počet aktívnych používateľov príslušnej funkcie, miera dokončenia úloh, chyby pri pokuse o akciu, podiel opustených formulárov. Údaje z aplikácie však samy nepovedia, prečo sa ľudia správajú určitým spôsobom. Potrebujete aj rozhovor alebo pozorovanie.
Dôležitá je otázka: Koho vôbec nepočujeme? Používatelia, ktorí službu opustili, nemusia posielať spätnú väzbu. Rovnako ľudia so znevýhodnením môžu narážať na prekážky, ktoré bežný helpdesk nepomenuje. Zahrňte preto do ďalšieho výskumu aj menej zastúpené používateľské skupiny.
6. Z hypotéz vytvorte plán malých overení
Pri každom probléme rozhodnite, čo by vedelo zmeniť váš názor. Pri nejasných termínoch môže byť užitočný krátky test: dajte piatim používateľom úlohu nájsť poslednú zmenu termínu a pozorujte, kde sa zastavia. Päť rozhovorov však neslúži na výpočet percenta populácie; cieľom je objaviť bariéry a spresniť hypotézy.
Pri zdieľaní reportov ukážte používateľom jednoduchý návrh výstupu a opýtajte sa, čo v ňom potrebujú vidieť, ako často a komu ho môžu bezpečne poslať. Neoverujte len otázkou „Páči sa vám PDF export?“, pretože taká otázka podsúva riešenie. Užitočnejšie je pozorovať ich súčasný postup a zistiť, kde strácajú čas.
Metodiky GOV.UK Service Manual odporúčajú vyvodzovať používateľské potreby zo skutočného výskumu a pravidelne ich overovať. AI môže uľahčiť triedenie záznamov, nie nahradiť stretnutie s používateľom.
7. Výsledok pre rozhodovací tím
Pripravte jednostranový prehľad obsahujúci tri najlepšie podložené problémy. Pri každom uveďte dôkazy, známu frekvenciu, zasiahnutú úlohu, riziko neriešenia, otvorené otázky, plán ďalšieho overenia a vlastníka. Funkčnú prioritu potom určte spoločne s technickým a obchodným tímom podľa dopadu, náročnosti a stratégie produktu.
Uchovajte pôvodný export, schému kódovania a verziu promptu. Pri ďalšej analýze viete porovnať, či pribudli nové problémy, alebo sa len zmenilo pomenovanie starých. Ak sa rozhodnete funkcionalitu vytvoriť, zaznamenajte, ktorý používateľský problém mala riešiť a ako preveríte, že ho naozaj rieši.
Overiteľné zdroje (stav k 23. 10. 2026)
- GOV.UK Service Manual – poznávanie používateľských potrieb: https://www.gov.uk/service-manual/user-research/start-by-learning-user-needs
- GOV.UK Service Manual – analýza používateľského výskumu: https://www.gov.uk/service-manual/user-research/analyse-a-research-session
- GOV.UK Service Manual – plánovanie výskumu: https://www.gov.uk/service-manual/user-research/plan-user-research-for-your-service
- Európsky výbor pre ochranu údajov – anonymizácia a pseudonymizácia: https://www.edpb.europa.eu/topics/ai-and-technology/anonymisation-pseudonymisation_en
Prihlásiť / registrovať