Kaip tyrimų ir plėtros komanda su Claude sutvarko tyrimo užrašus į produkto hipotezių sąrašą

Tyrimų ir plėtros komandos dažnai turi daug daugiau žinių, negu matosi oficialiuose dokumentuose. Po kelių klientų pokalbių, vidinių bandymų, demonstracijų ir pardavimų komandų pastabų atsiranda dešimtys užrašų. Vienur parašyta, kad vartotojui neaiški kaina. Kitur, kad importas neveikia su tam tikru failu. Trečiame pokalbyje klientas ne prašo naujos funkcijos, o bando apeiti dabartinį procesą.

Problema prasideda tada, kai šie užrašai iš karto virsta darbų sąrašu. Komanda pradeda sakyti „reikia naujo filtro“, „reikia paprastesnio importo“, „reikia geresnio prietaisų skydelio“, nors dar nėra aišku, kokia problema kartojasi, kam ji svarbiausia ir kaip patikrinti, ar sprendimas tikrai pakeis vartotojo elgesį.

Claude čia naudingas ne kaip idėjų generatorius, o kaip tyrimo medžiagos tvarkytojas. Jis gali padėti išskirti temas, atskirti faktus nuo prielaidų ir paruošti hipotezes, kurias galima patikrinti prieš pradedant didesnį kūrimą.

Kokia situacija

Įsivaizduokime produkto komandą, kuri renka pastabas apie naują duomenų importo modulį. Komanda turi:

• 8 klientų interviu santraukas
• 3 vidinių demonstracijų užrašus
• pardavimų komandos pastabas iš pokalbių su potencialiais klientais
• techninės pagalbos žinutes apie importo klaidas
• kelis konkurentų sprendimų pastebėjimus

Iš pirmo žvilgsnio atrodo, kad klientai prašo daug skirtingų dalykų. Vieni mini failų šablonus. Kiti kalba apie klaidų tekstus. Treti nori masinio taisymo. Tačiau po šiomis pastabomis gali slypėti viena stipresnė tema: vartotojai nežino, kodėl importas nepavyko, ir todėl negali patys ištaisyti klaidų.

Tikslas nėra iš karto sukurti sprendimą. Tikslas - paruošti patikrinamą hipotezę.

1. Pirmiausia sutvarkykite žalius užrašus

Pradėkite nuo tvarkos. Jeigu Claude gauna chaotiškus užrašus ir prašymą „paruošk produkto idėjas“, jis gali per anksti pereiti prie sprendimų. Geriau pirmu žingsniu paprašyti tik sutvarkyti medžiagą.

Veik kaip tyrimų ir plėtros komandos analitikas.

Kol kas nesiūlyk sprendimų ir nekurk produkto funkcijų. Pirmiausia sutvarkyk žemiau pateiktus tyrimo užrašus į vienodą struktūrą.

Paruošk lentelę lietuvių kalba su šiomis skiltimis:

1. Šaltinis.
2. Dalyvis arba kontekstas.
3. Pastebėta problema.
4. Tiksli citata arba trumpa pastabos santrauka.
5. Kuriame proceso žingsnyje tai įvyko?
6. Kokiai vartotojų grupei tai aktualu?
7. Įrodymo stiprumas: stiprus, vidutinis arba silpnas.
8. Kas dar neaišku?
9. Galima tema.

Taisyklės:

- jei informacijos trūksta, rašyk „neaišku“, o ne spėk;
- atskirk faktą nuo interpretacijos;
- nepervadink vartotojo problemos į produkto funkciją;
- jeigu pastaba yra tik vieno žmogaus nuomonė, aiškiai tai pažymėk;
- po lentele parašyk 5 svarbiausias vietas, kuriose trūksta duomenų.

Tyrimo užrašai:
[įklijuok interviu, demonstracijų, pagalbos arba pardavimų pastabas]

Ši užklausa sustabdo ankstyvą šuolį prie sprendimų. Komanda pirmiausia pamato, kokios pastabos turi įrodymų, kurios kartojasi ir kur dar nėra pakankamai informacijos.

2. Grupuokite temas, o ne funkcijų pageidavimus

Kitas žingsnis - sugrupuoti pastabas pagal problemas. Čia svarbu ne skaičiuoti, kiek kartų paminėtas tas pats žodis, o suprasti, kokia vartotojo situacija kartojasi.

Pavyzdžiui, šios pastabos gali priklausyti tai pačiai temai:

• „Importas nepavyko, bet nežinau, ką taisyti.“
• „Klaidų faile yra per daug techninio teksto.“
• „Mūsų apskaitos žmogus turi kviesti programuotoją dėl paprasto failo.“
• „Klientas paklausė, ar sistema gali parodyti klaidas prieš importą.“

Paviršiuje tai skirtingi prašymai. Iš esmės tai gali būti tema apie savarankišką klaidų taisymą.

Remkis sutvarkyta tyrimo užrašų lentele ir sugrupuok pastabas į temas.

Nekurk produkto funkcijų. Ieškok pasikartojančių problemų, poreikių, baimių, neaiškumų ir darbo aplinkybių.

Kiekvienai temai pateik:

1. Temos pavadinimą.
2. Kas vyksta vartotojo situacijoje?
3. Kokiai vartotojų grupei tai aktualu?
4. Kuriuose proceso žingsniuose tai pasireiškia?
5. Kokie įrodymai tai patvirtina?
6. Kiek skirtingų šaltinių mini šią temą?
7. Koks galimas verslo poveikis?
8. Ko dar nežinome?
9. Kodėl ši tema gali būti svarbesnė už pavienį funkcijos prašymą?

Po lentelės išskirk 3 stipriausias temas ir paaiškink, kodėl jos stiprios.

Sutvarkyta tyrimo užrašų lentelė:
[įklijuok ankstesnio žingsnio lentelę]

Gera tema turi būti parašyta taip, kad žmogus suprastų problemą be papildomo paaiškinimo. Ne „importo patobulinimai“, o „vartotojai negali savarankiškai suprasti importo klaidų priežasties“.

3. Paverskite temas produkto hipotezėmis

Hipotezė nėra tiesiog idėja. Ji turi paaiškinti, ką tikimės pakeisti ir kodėl manome, kad tai įvyks.

Patogi forma:

Jeigu [vartotojų grupė] galės [sprendimo kryptis], tada [matuojamas elgesio pokytis], nes [įžvalga iš tyrimo]. Patikrinsime pagal [matavimo signalas].

Pavyzdžiui, silpna formuluotė būtų:

Reikia geresnio importo klaidų rodymo.

Geresnė hipotezė:

Jeigu nauji B2B klientai prieš importuodami duomenis galės pamatyti klaidų priežastis vienoje suvestinėje, sumažės rankinių taisymų per pirmą savaitę, nes interviu dalyviai kartojo, kad nežino, kodėl importas nepavyko. Patikrinsime su 5 klientais ir stebėsime, ar jie savarankiškai ištaiso bent 3 dažniausias klaidas.

Remkis tyrimo temų sąrašu ir paruošk produkto hipotezes.

Kiekviena hipotezė turi būti patikrinama. Nerašyk bendrų teiginių, tokių kaip „pagerinti patirtį“ arba „sukurti patogesnį sprendimą“.

Kiekvienai hipotezei pateik:

1. Hipotezės formuluotę.
2. Kuri tyrimo tema ją pagrindžia?
3. Kokie konkretūs įrodymai ją palaiko?
4. Kokiai vartotojų grupei ji skirta?
5. Kokį elgesio pokytį tikimės pamatyti?
6. Kaip tą pokytį matuosime?
7. Kas gali būti neteisinga šioje prielaidoje?
8. Pigiausias patikrinimo būdas.
9. Kokį sprendimą priimsime, jei hipotezė pasitvirtins?
10. Kokį sprendimą priimsime, jei hipotezė nepasitvirtins?

Paruošk ne daugiau kaip 7 hipotezes. Pabaigoje išrink 2, kurias verta tikrinti pirmiausia, ir paaiškink kodėl.

Tyrimo temos:
[įklijuok temų sąrašą]

Šis žingsnis padeda komandai kalbėti ne apie nuomones, o apie patikrinamus teiginius.

4. Rinkitės pigiausią kitą patikrinimą

Ne kiekviena hipotezė reikalauja kurti naują produkto dalį. Kartais pakanka vieno ekrano eskizo, rankinio patikrinimo, trumpo pokalbio arba vidinio bandymo su realiais duomenimis.

Tyrimų ir plėtros komandos dažnai praranda laiką, nes tikrina sprendimą per brangiai. Jeigu dar neaišku, ar vartotojams problema pakankamai svarbi, nereikia iš karto kurti pilno sprendimo.

Remkis žemiau pateikta produkto hipoteze ir pasiūlyk pigiausią būdą ją patikrinti.

Nesiūlyk iš karto kurti pilnos produkto funkcijos, jei galima patikrinti paprasčiau.

Pateik 4 patikrinimo variantus:

1. Pokalbio patikrinimas.
2. Ekrano eskizo arba prototipo patikrinimas.
3. Rankinis patikrinimas su realiais duomenimis.
4. Susidomėjimo patikrinimas be pilno kūrimo.

Kiekvienam variantui pateik:

- ką tiksliai padarysime;
- kiek žmonių arba duomenų pavyzdžių reikia;
- kiek laiko tikėtina užtrukti;
- kokį signalą matuosime;
- kokia būtų sėkmės riba;
- kokia didžiausia šio patikrinimo rizika;
- kada šis būdas netinka.

Pabaigoje rekomenduok vieną patikrinimą ir paaiškink, kodėl jis yra geriausias pirmam žingsniui.

Hipotezė:
[įklijuok hipotezę]

Pavyzdžiui, importo klaidų suvestinę galima patikrinti dar prieš kūrimą:

• paimti 5 realius klaidų failus
• rankiniu būdu paruošti aiškią klaidų suvestinę
• parodyti ją vartotojams
• paprašyti jų pataisyti failą pagal suvestinę
• stebėti, ar jie supranta, ką reikia daryti

Jeigu vartotojai vis tiek nesupranta, problema gali būti ne suvestinės nebuvimas, o pati duomenų struktūra arba jų darbo procesas.

5. Paruoškite sprendimo santrauką vadovui

Vadovui nereikia visų užrašų. Jam reikia aiškios, pagrįstos ir trumpai skaitomos santraukos:

• ką sužinojome
• kokios temos stipriausios
• kokias hipotezes siūlome tikrinti
• ko dar neverta kurti
• koks kitas pigiausias veiksmas

Paruošk trumpą sprendimo santrauką tyrimų ir plėtros vadovui.

Santrauka turi būti dalykiška, aiški ir tinkama sprendimui priimti. Nerašyk ilgos ataskaitos.

Naudok šią struktūrą:

1. Tyrimo kontekstas.
2. 3 stipriausios temos.
3. Kokie įrodymai jas pagrindžia?
4. Kokios 2 produkto hipotezės siūlomos pirmam patikrinimui?
5. Kodėl jos svarbios verslui?
6. Koks pigiausias kitas patikrinimas?
7. Ko nerekomenduojama kurti dabar?
8. Kokios prielaidos dar nepatvirtintos?
9. Kokio sprendimo reikia iš vadovo?

Taisyklės:

- atskirk faktus nuo prielaidų;
- nenaudok pernelyg užtikrintų formuluočių, jei įrodymų mažai;
- aiškiai parašyk, kokių duomenų trūksta;
- nurodyk, ką komanda sužinos po kito patikrinimo.

Tyrimo temos:
[įklijuok temų sąrašą]

Hipotezės:
[įklijuok hipotezių sąrašą]

Patikrinimo variantai:
[įklijuok patikrinimo variantus]

Gera santrauka padeda vadovui ne tik pritarti idėjai, bet ir suprasti, kokios rizikos lieka nepatikrintos.

6. Pasidarykite pakartojamą įgūdį komandai

Jeigu komanda tyrimo užrašus tvarko dažnai, verta turėti pastovią instrukciją. Tuomet kiekvienas komandos narys gali naudoti tą patį formatą, o rezultatai tampa lengviau lyginami.

Sukurk Claude įgūdžio instrukciją tyrimų ir plėtros komandai.

Įgūdžio paskirtis:
Iš žalių tyrimo užrašų, klientų interviu, demonstracijų pastabų ir pagalbos žinučių paruošti temų sąrašą, produkto hipotezes ir kitą patikrinimo veiksmą.

Instrukcijoje turi būti:

1. Kada naudoti šį įgūdį.
2. Kokius duomenis vartotojas turi pateikti.
3. Kaip atskirti faktus nuo prielaidų.
4. Kaip grupuoti temas.
5. Kaip rašyti produkto hipotezes.
6. Kaip parinkti pigiausią patikrinimo būdą.
7. Kokio formato rezultatus pateikti.
8. Kokiais atvejais sustoti ir paprašyti daugiau informacijos.
9. Kokios formuluotės draudžiamos, nes jos per anksti pereina prie sprendimų.

Rašyk lietuvių kalba, aiškiai ir praktiškai. Instrukcija turi tikti įdėti į SKILL.md failą.

Toks įgūdis ypač naudingas, kai tyrimo medžiagą renka keli žmonės. Vienas pokalbis su klientu netampa atskira nuomone, o patenka į bendrą įrodymų sistemą.

Ko Claude neturėtų daryti

Yra kelios aiškios ribos:

• Claude neturėtų iš vieno komentaro padaryti didelės produkto krypties.
• Claude neturėtų painioti vartotojo prašymo su tikrąja problema.
• Claude neturėtų rašyti, kad hipotezė „įrodyta“, jei yra tik keli interviu.
• Claude neturėtų slėpti neaiškumų, nes būtent jie dažnai lemia kitą tyrimo veiksmą.
• Claude neturėtų pakeisti komandos sprendimo, nes atsakomybė lieka žmonėms.

Geriausias naudojimas - kai Claude padeda komandai mąstyti tvarkingiau, o ne greičiau patvirtinti jau turimą nuomonę.

Kuo remiasi ši darbo eiga

Šiame straipsnyje naudojama kelių gerai žinomų produktų tyrimo principų logika:

• Product Talk aprašomas galimybių, sprendimų ir eksperimentų medis padeda nešokti tiesiai nuo problemos prie vieno sprendimo.
• Product Talk eksperimentų šablonas pabrėžia, kad prieš tikrinimą reikia aiškiai įvardyti rizikingą prielaidą, matavimo signalą ir sprendimą po rezultato.
• Maze tyrimų analizės vadove siūloma pradėti nuo duomenų sutvarkymo, kodavimo ir temų išskyrimo, o tik tada formuluoti įžvalgas.
• Atlassian komandos žaidimų knygoje siūloma klientų grįžtamąjį ryšį versti aiškiomis temomis ir veiksmais, kuriuos gali naudoti produkto ir dizaino vadovai.

Praktinis rezultatas

Po šios darbo eigos komanda turėtų turėti:

• sutvarkytą tyrimo užrašų lentelę
• pasikartojančių temų sąrašą
• įrodymų stiprumo įvertinimą
• 5-7 produkto hipotezes
• 1-2 pirmiausia tikrintinas hipotezes
• pigiausią kitą patikrinimo veiksmą
• trumpą sprendimo santrauką vadovui

Svarbiausias pokytis yra ne tai, kad komanda parašo daugiau dokumentų. Svarbiausia, kad ji mažiau kuria remdamasi nuojauta ir greičiau sužino, kuri problema iš tiesų verta kūrimo laiko.