Lesson 6: User Research & Discovery

வரையறை: User research என்றால் கட்டுவதற்கு முன் (BEFORE) உண்மையான users பற்றிக் கற்றுக்கொள்வது - அவர்களின் பிரச்சனைகள், பழக்கங்கள், எரிச்சல்கள். Discovery என்பது எதைக் கட்டுவது தகுந்தது என்று கண்டுபிடிக்கும் முழுச் செயல்முறை.

இது ஏன் முக்கியம்: ஊகிக்கும் PMs தவறான பொருளை அழகாகக் கட்டுவார்கள். ஒரு உண்மையான user-உடன் ஒரு மணி நேரம், ஒரு வார உள் விவாதத்தை விடச் சிறந்தது.

எப்படிச் செய்வது:

• User interviews: கருத்துகள் அல்ல, கடந்தகால நடத்தை (PAST behavior) பற்றிக் கேள். "ஒரு நல்ல ஊழியர் கடைசியாக விலகியதைப் பற்றிச் சொல்லுங்கள்" - இது வேலை செய்யும். "நீங்கள் dashboard பயன்படுத்துவீர்களா?" - இது இல்லை; மரியாதைக்காக எல்லோரும் ஆம் என்பார்கள்.
• Users இப்போதுள்ள product அல்லது மாற்று வழியைப் பயன்படுத்துவதைப் பார். அவர்கள் செய்வது (DO) உண்மை; சொல்வது (SAY) கருத்து.
• Support tickets, reviews-ஐப் படி - users இலவசமாக, தங்கள் சொந்த வார்த்தைகளில் புகார் சொல்கிறார்கள்.

உதாரணம்: உன் HR attrition platform-க்கு, HR-இடம் "உங்களுக்கு alerts வேண்டுமா?" என்று கேட்காதே. "உங்களை ஆச்சரியப்படுத்திய கடைசி ராஜினாமா பற்றிச் சொல்லுங்கள் - எப்போது தெரிந்தது, அடுத்து என்ன செய்தீர்கள்?" என்று கேள். அவர்களின் கதை எந்த feature request-ஐயும் விட உண்மையான பிரச்சனையை நன்றாகக் காட்டும்.

முக்கியக் கருத்து: users தீர்வுகளை design செய்வதில் பலவீனமானவர்கள், ஆனால் பிரச்சனைகளை விவரிப்பதில் சிறந்தவர்கள். Feature request-ஐ அல்ல, பிரச்சனையைக் கேள்.

Definition: User research means learning about real users BEFORE you build - their problems, habits, and frustrations. Discovery is the whole process of finding out what is worth building.

Why it matters: PMs who guess build the wrong thing beautifully. One hour with a real user beats a week of internal debate.

How to do it:

• User interviews: ask about PAST behavior, not opinions. "Tell me about the last time a good employee quit" works. "Would you use a dashboard?" does not - everyone says yes to be polite.
• Watch users use the current product or workaround. What they DO is truth; what they SAY is opinion.
• Read support tickets and reviews - users complain for free, in their own words.

Example: for your HR attrition platform, don't ask HR "do you want alerts?" Ask "tell me about the last resignation that surprised you - when did you find out, and what did you do next?" Their story shows the real problem better than any feature request.

Key point: users are bad at designing solutions but great at describing problems. Listen for the problem, not the feature request.

Definition: User research का मतलब है बनाने से पहले (BEFORE) असली users के बारे में सीखना - उनकी problems, habits और frustrations. Discovery वो पूरा process है जिससे पता चलता है कि क्या बनाने लायक है।

यह क्यों ज़रूरी है: जो PMs अंदाज़ा लगाते हैं, वो गलत चीज़ खूबसूरती से बना देते हैं। एक असली user के साथ एक घंटा, एक हफ़्ते की internal बहस से बेहतर है।

इसे कैसे करें:

• User interviews: opinions नहीं, PAST behavior के बारे में पूछो। "मुझे पिछली बार के बारे में बताइए जब एक अच्छे employee ने छोड़ा" - यह काम करता है। "क्या आप dashboard use करेंगे?" - यह नहीं; politeness में सब हाँ कह देते हैं।
• Users को current product या workaround use करते हुए देखो। वो जो करते (DO) हैं, वो सच है; जो कहते (SAY) हैं, वो opinion है।
• Support tickets और reviews पढ़ो - users मुफ़्त में, अपने शब्दों में complain करते हैं।

Example: आपके HR attrition platform के लिए HR से मत पूछो "क्या आपको alerts चाहिए?" पूछो "पिछले उस resignation के बारे में बताइए जिसने आपको चौंकाया - आपको कब पता चला, और फिर आपने क्या किया?" उनकी story असली problem को किसी भी feature request से बेहतर दिखाती है।

Key point: users solutions design करने में कमज़ोर हैं, लेकिन problems बताने में बहुत अच्छे। Feature request नहीं, problem सुनो।

Definition: User research na, build pannurathukku MUNNADI real users pathi therinjuukkaradhu - avanga problem, habits, frustrations. Discovery na, enna build panna worth nu kandupidikira full process.

Adhu yen important: guess panni build panna PM, thappana product ah azhaga build pannuvaaru. Oru mani neram real user kitta pesunadhu, oru vaaram internal debate ah vida mel.

Epdi pannuradhu:

• User interviews: opinions illa, PAST behavior kekkanum. "Kadaisiya oru nalla employee quit pannapo enna nadandhuchu?" nu kekkanum. "Dashboard use pannuveengala?" nu kekka koodadhu - ellarum polite ah yes soluvanga.
• Users ippo product ah epdi use pannranga nu paarungga. Avanga PANNRADHU dhaan truth; SOLRADHU opinion.
• Support tickets and reviews padinga - users free ah, avanga own words la complain pannuvanga.

Example: un HR attrition platform ku, "alerts venuma?" nu kekka vendaam. "Kadaisiya surprise resignation pathi sollunga - eppo therinjuchu, aprom enna pannineenga?" nu kelu. Avanga story dhaan real problem ah kaattum, feature request illa.

Key point: users solution design panna weak, aana problems solla strong. Feature request illa, problem ah kelu.

Definition: User research ka matlab hai banane se pehle (BEFORE) real users ke baare mein seekhna - unki problems, habits aur frustrations. Discovery woh poora process hai jisse pata chalta hai ki kya banane layak hai.

Yeh kyun important hai: jo PMs guess karte hain, woh galat cheez khoobsurti se bana dete hain. Ek real user ke saath ek ghanta, ek hafte ki internal debate se better hai.

Ise kaise karein:

• User interviews: opinions nahi, PAST behavior ke baare mein poocho. "Mujhe pichhli baar ke baare mein bataiye jab ek achhe employee ne chhoda" - yeh kaam karta hai. "Kya aap dashboard use karoge?" - yeh nahi; politeness mein sab haan keh dete hain.
• Users ko current product ya workaround use karte hue dekho. Woh jo karte (DO) hain, woh sach hai; jo kehte (SAY) hain, woh opinion hai.
• Support tickets aur reviews padho - users free mein, apne words mein complain karte hain.

Example: aapke HR attrition platform ke liye HR se mat poocho "kya aapko alerts chahiye?" Poocho "pichhle us resignation ke baare mein bataiye jisne aapko chaunkaya - aapko kab pata chala, aur phir aapne kya kiya?" Unki story real problem ko kisi bhi feature request se better dikhati hai.

Key point: users solutions design karne mein kamzor hain, lekin problems batane mein bahut achhe. Feature request nahi, problem suno.