Aliza Builds
36 subscribers
4 photos
8 links
Download Telegram
Channel created
1
درود.

من علیرضام و اینجا مسیر و فرآیند ساخت ایده‌های پروداکتیم رو مستند می‌کنم. از شناخت مسئله و تحقیق کاربر گرفته تا تصمیم‌های محصول، طراحی، توسعه و حتی اشتباه‌ها و تغییر مسیرها.


در حال حاضر روی Daruyar کار می‌کنم؛ یه اپلیکیشن مدیریت موجودی دارو تو خونه هست که تمرکزش روی نیازهای بیماران خاصه.
ایده دارویار از یه نیاز شخصی میاد ولی سعی می‌کنم با طی کردن فرآیند پروداکت دیسکاوری، از سوگیری‌های خودم جلوگیری کنم تا نهایتا محصولی ساخته شه که واقعا تو حل کردن مشکل و نیازی که تارگت کرده موفق باشه.


بیشتر سابقه کاری من در زمینه توسعه فرانت‌اند وب بوده، اما همیشه به ساخت محصول علاقه داشتم. حالا تصمیم گرفتم این پروژه رو فرصتی برای یادگیری عمیق‌تر Product Engineering ببینم و به جای ساختن محصول پشت درهای بسته، مسیر فکر کردن، تصمیم گرفتن و یاد گرفتن رو با دیگران به اشتراک بذارم.
1
⚜️ برنامه‌ی محتوایی

در یک پست ویرگول از انگیزه‌هام و چرایی شروع کردن این مسیر نوشتم و در ادامه برای تعامل بیشتر و به اشتراک‌ گذاشتن ساختارمندتر محتوا، تصمیم گرفتم همینجا ادامه بدم.

‏—————

⚜️ پست‌های اینجا با هشتگ‌های زیر دسته‌بندی می‌شن:

🔻 دسته‌بندی بر اساس محصول

#daruyar — اپلیکیشن مدیریت دارو در خانه، با تمرکز بر نیازهای بیماران خاص

🔻 دسته‌بندی بر اساس موضوع

#dev — محتواهای مرتبط با توسعه نرم‌افزار، معماری، برنامه‌نویسی و تصمیم‌های فنی.

#design — طراحی تجربه و رابط کاربری، طراحی سیستم و تصمیم‌های مرتبط با UX/UI.

#product — مسائل مربوط به محصول؛ از شناخت مسئله و نیاز کاربران تا مدیریت محصول و تصمیم‌های محصولی.

#ai — تجربه‌ها، ابزارها و ایده‌های مرتبط با هوش مصنوعی و نقش آن در فرایند توسعه محصول.

#bip — محتواهای مربوط به Build in Public؛ چالش‌ها و پشت‌صحنه‌ی کار.

🔻 دسته‌بندی بر اساس نوع

#decision — تصمیم‌هایی که گرفته‌ام، همراه با دلیل و بررسی گزینه‌های مختلف.

#question — سؤال‌ها، ابهام‌ها و موضوعاتی که هنوز در حال بررسی آن‌ها هستم.

#mistake — اشتباه‌ها، فرضیات نادرست و چیزهایی که اگر دوباره شروع کنم، متفاوت انجام می‌دهم.

#thinkingOutLoud — بلندبلند فکر کردن؛ به اشتراک گذاشتن فرایند فکر و تحلیل

#struggles — چالش‌های شخصی و درونی؛ مثل تردیدها، کمبود اعتماد به نفس، فرسودگی ذهنی و درگیری‌هایی که در مسیر ساخت محصول تجربه می‌کنم.

1
⚜️ برخی از ریسک‌های روان‌شناختی Build in Public

Overjustification Effect — ‏انگیزه از «حل مسئله» به «گرفتن لایک و توجه» منتقل می‌شود.

Social Reward Loop — مغز به چرخه‌ی دوپامین ناشی از انتشار محتوا و بازخورد اجتماعی وابسته می‌شود.

Illusion of Progress — صحبت کردن درباره‌ی پیشرفت، ممکن است احساس کاذب پیشرفت ایجاد کند و انگیزه‌ی ادامه را کاهش دهد.

Increased Cognitive Load — مدیریت محتوا بخشی از ظرفیت ذهنی را که باید صرف ساخت محصول شود، اشغال می‌کند.

Context Switching — جابه‌جایی مکرر بین توسعه و شبکه‌های اجتماعی، تمرکز عمیق را مختل می‌کند.

Social Validation Dependence — تصمیم‌های محصول به‌جای نیاز کاربر، تحت تأثیر نظر و تأیید دیگران قرار می‌گیرد.

Builder → Performer Shift — به‌تدریج تولید محتوا از ساخت محصول لذت‌بخش‌تر و اولویت‌دارتر می‌شود.

Public Accountability Stress — اعلام عمومی برنامه‌ها، در صورت تأخیر یا شکست، اضطراب و فشار روانی ایجاد می‌کند.

Reduced Freedom to Pivot‏ — به‌دلیل حضور مخاطب، تغییر مسیر یا کنار گذاشتن ایده‌ها سخت‌تر می‌شود.

Audience Effect — احساس دیده شدن باعث محافظه‌کاری، خودسانسوری و کاهش خلاقیت در تصمیم‌گیری می‌شود.

#bip
1
Aliza Builds
⚜️ برخی از ریسک‌های روان‌شناختی Build in Public ‏Overjustification Effect — ‏انگیزه از «حل مسئله» به «گرفتن لایک و توجه» منتقل می‌شود. ‏Social Reward Loop — مغز به چرخه‌ی دوپامین ناشی از انتشار محتوا و بازخورد اجتماعی وابسته می‌شود. ‏Illusion of Progress…

تا یاد دارم من همیشه با ذهنم دست به یقه بودم. درمورد build in public هم مردد بودم و کلی حس مبهم در راستای منصرف شدنم داشتم. با gpt صحبت کردم و گفتم چالش‌های روانشناختی اینکارو برام بگو و این موارد بالا رو برام لیست کرد. با دیدن‌شون وزنه ترازوی تصمیم‌گیریم به طرف انجام ندادنش سنگینی کرد. تقریبا مطمئن شدم که آره شروع کردن این مسیر تصمیم اشتباهیه.

با یه دوست خردمندی (که البته دیوانه هم هست) صحبت می‌کردیم و گفت: همه این‌هایی که اینجا لیست شده درسته ولی حتی برای انجام ندادنش هم میشه یه لیست از معایبش تهیه کرد. گاهی ما کلی زمان میذاریم و یه کاری که می‌خواییم درمورد انجامش تصمیم‌گیری کنیم رو کلی بررسی می‌کنیم ولی از اینور فراموش می‌کنیم که انجام ندادنش هم اون سر دیگه‌ی اون تصمیمه و باید اون هم بررسی شه و ببینیم در مقایسه با هم چه وضعیتی دارن.

اون گفتگومون توجه منو به دوتا نکته ساده اما مهم جلب کرد:

حتی تصمیم‌های درست هم بی‌عیب نیستن و صرفا مزایاشون ارزش به جون خریدن اون معایب رو داره.

انجام ندادن کاری و موندن تو موقعیت فعلی هم یک تصمیمه و باید از معایبش غافل نشد.

خلاصه که این‌ها رو کنار هم گذاشتم و در نهایت تصمیم‌ام شروع این مسیر بود.

#bip #lesson #decision
2
ویرگول اجازه انتشار رایگان پستم رو نمی‌داد و به اشتباه تبلیغاتی ارزیابیش می‌کرد. علاوه بر این، امکان تغییر نام‌ کاربری رو هم نمی‌داد. این شد که به فکر بالا آوردن وبلاگ شخصی بودم.

امروز به تیکتم جواب دادن و هر دو مشکل رو حل کردن.

در نهایت با توجه به اینکه اضافه کردن بخش کامنت‌ها تو وب‌سایت شخصی نیاز به بک‌اند داره. (میشه با Supabase ای چیزی سریع‌تر هم بالا آورد ولی خب فعلا ارزش‌اش رو نداره) با همون ویرگول پیش می‌ریم.

اولین پست خدمت شما: Build in Public - شروع یک مسیر
🔥41
Please open Telegram to view this post
VIEW IN TELEGRAM
⚜️ چرا یاد گرفتن Product Thinking این‌قدر ذهنم رو خسته می‌کنه؟

هر بار که می‌خوام یه مفهوم جدید توی Product یاد بگیرم، یه فشار ذهنی عجیبی حس می‌کنم. یه مدت بود داشتم فکر می‌کردم این حس از کجا میاد و به نظرم سه تا دلیل داره:

🔻 ۱. ذهنم دنبال جواب قطعیه.

فکر می‌کنم این عادت از بک‌گراند فنی‌م اومده. توی مسائل فنی معمولاً صورت‌مسئله شفاف‌تره و خیلی وقت‌ها یه جواب درست یا حداقل یه راه‌حل بهینه وجود داره. ولی مسائل محصولی این‌جوری نیستن. خیلی‌هاشون از جنس Wicked Problem هستن؛ یعنی نه جواب قطعی دارن، نه مسیر حل مشخص.

شاید اگر این تفاوت رو واقعاً بپذیرم، دیگه از خودم انتظار نداشته باشم که برای هر سؤال یه جواب نهایی پیدا کنم. شاید فقط باید به خودم زمان بدم تا کم‌کم با ابهام راحت‌تر بشم.

🔻۲. زیادی درگیر ابزارها و مدل‌ها می‌شم.

یه چیز دیگه که متوجهش شدم اینه که گاهی بیش از حد درگیر ابزارها و مدل‌های ذهنی می‌شم. هر بار یه ابزار یا مدل جدید می‌بینم، یه حس FOMO میاد سراغم که «اینم باید یاد بگیرم، وگرنه یه چیزی کم دارم.» ولی هرچی بیشتر فکر می‌کنم، بیشتر به این نتیجه می‌رسم که شاید این فقط یه خطای ذهنیه.

ذهن ما حتی بدون اینکه اسم مدل‌ها رو بدونه، خودش دائم داره مدل‌سازی می‌کنه. مدل‌های ذهنی فقط کمک می‌کنن این مدل‌سازی شفاف‌تر بشه. اصلاً ارزششون هم به این نیست که کاملاً درست باشن؛ به اینه که به درد بخورن.

در مورد ابزارها هم همین‌طوره. ممکنه بهترین ابزار دنیا رو نداشته باشم، ولی اگر روی همون ابزاری که دارم مسلط باشم، معمولاً می‌تونم کارم رو جلو ببرم.
یادداشت‌برداری مثال خوبیه. قلم و کاغذ از Notion یا Obsidian محدودتره، ولی هنوز هم می‌شه باهاش یادداشت‌های خوب و کاربردی نوشت. نمی‌گم ابزار مهم نیست. فقط فکر می‌کنم قبل از اینکه برم یه ابزار جدید یاد بگیرم، بهتره از خودم بپرسم: برای چه هدف و کارکردی میخوام این ابزار رو یاد بگیرم؟ 

🔻۳. گم شدن


هرچی بیشتر بهش فکر می‌کنم، حس می‌کنم مشکل اصلی نه ابزارها هستن، نه مدل‌های ذهنی. مشکل اینه که وسط مسیر، گم می‌شم و با یه صفحه مشکی (بسته به تنظیمات تم مغزتون می‌تونه برای شما سفید هم باشه)  مواجه میشم و عملا مغزم به بن‌بست می‌خوره و نمی‌دونه از کجا مسئله رو از سر بگیره. همین باعث می‌شه از این مقاله به اون مقاله برم، از این مدل و ابزار به اون یکی، بدون اینکه واقعاً بدونم دنبال چی می‌گردم.

🔻راهکاری که فکر می‌‌کنم جواب بده:

فکر می‌کنم اگر یک فریمورک شخصی بسازم و ذهنم رو مرتب کنم، این مشکلات هم حل بشن. یعنی چی؟ برای من، بالاترین سطحی که می‌تونم ازش به ساخت محصول نگاه کنم، Product Life Cycle ئـه.

اگر کل فرآیند ساخت محصول رو به Stageهای مختلف بشکنم و هر Stage رو هم به Substageهای کوچیک‌تر تقسیم کنم، اون وقت برای هر مرحله می‌تونم یه Context مشخص بسازم.

منظور از Context چیه؟ مثلاً Product Discovery رو می‌تونیم به Solution Validation ،Problem Validation و ... بشکنیم.
بعد برای هر کدوم از این مرحله‌ها، Context رو می‌تونیم مجموعه‌ای از این سوالات در نظر بگیریم:

— هدف این مرحله چیه؟
— چه Modelهایی اینجا به دردم می‌خورن؟
— چه Heuristicهایی معمولاً جواب می‌دن؟
— چه ابزارهایی براش بلدم و تو جعبه ابزارم هست؟
— خروجی این مرحله باید چی باشه؟

این سؤال‌ها کمک می‌کنن قبل از اینکه برم دنبال ابزار یا مدل جدید، بتونم یه نقشه‌ای داشته باشم که مثل گیم‌ها موقع گم شدن، بهش رجوع کنم.

احتمالاً نسخه اولش خیلی ناقص و حتی اشتباه از آب درمیاد. ولی اشکالی نداره، مهم اینه که در حال حاضر برای مغز من قابل فهم باشه و چرخش برام بچرخه.

از همه مهم‌تر، فکر نمی‌کنم یه Framework درست برای همه وجود داشته باشه. ممکنه یه مدل ذهنی یا یه ابزار برای من خیلی کاربردی باشه، ولی برای یکی دیگه جواب نده. هر چند البته که میشه از هم ایده گرفت.

💭 نگاه شما چیه؟ نکته‌ای هست که بخوایید اضافه کنید؟

#product #thinkingOutLoud
1
ممکنه بعضی وقتا پیام‌های این کانال رو که می‌خونید حس کنید لحن متن‌ها دقیقاً لحن خودم نیست، یا حتی فکر کنید AI توی آماده شدنشون نقش داشته.

واقعیتش اینه که برای اینکه بتونم زمان و انرژیم رو بهتر مدیریت کنم، مجبورم سعی کنم با کمترین هزینه، بیشترین خروجی رو بگیرم.

روشی که بهش رسیدم اینه که اول با ابزارهای تبدیل گفتار به نوشتار، هر چی توی ذهنمه رو به شکل یه Brain Dump ثبت می‌کنم. یعنی ایده‌ها، ترتیب مطالب و حتی بخش زیادی از جمله‌بندی‌ها از خودمه و AI متن رو از صفر نمی‌نویسه.

بعدش فقط از AI می‌خوام متن رو یه کم مرتب‌تر و روون‌تر کنه؛ با این تأکید که ساختار جمله‌ها، منظور و سبک بیانم حفظ بشه و فقط متن محاوره‌ای‌تر و خوش‌خوان‌تر بشه، چون خروجی اولیه معمولاً زیادی رسمی و کتابی درمیاد.

خلاصه اینکه حضورتون برام خیلی ارزشمنده و اصلاً دوست ندارم وقتتون با محتوایی که کامل توسط AI تولید شده هدر بره. چیزی که می‌خونید همچنان حرف‌ها و نگاه خودمه؛ AI فقط کمک می‌کنه همون حرف‌ها شفاف‌تر و راحت‌تر منتقل بشن.

#bip #ai
4
⚜️ بیاید کمی بیشتر درباره دارویار صحبت کنیم =)

اینکه چطور به این ایده رسیدم، الان تو چه مرحله‌ای هستم و چرا تصمیم گرفتم مسیر توسعه‌ش رو یه کم تغییر بدم.

تا الان دارویار رو همیشه اینطوری تو یه خط معرفی می‌کردم:
یه سیستم مدیریت موجودی دارو توی خونه‌، با تمرکز روی بیماران خاص.


تا همین اواخر فکر می‌کردم باید محصولی بسازم که برای همه بیماران خاص کاربرد داشته باشه، اما هرچی بیشتر فکر کردم، متوجه شدم احتمالاً این انتخاب درستی برای شروع نیست.

فهمیدم مدیریت دارو تو بیماری‌های مختلف تفاوت‌های زیادی داره. الگوی مصرف دارو، شکل‌های دارویی، محدودیت‌ها و حتی ترجیح افراد برای مدیریت موجودی با هم فرق می‌کنه. مثلاً یه فرد مبتلا به دیابت بیشتر با قلم انسولین، کارتریج، سوزن و نگهداری دارو تو دمای مناسب سروکار داره، اما تو تالاسمی معمولاً فرد هم‌زمان چند دارو با شکل‌های مختلف مصرف می‌کنه و مدیریت موجودی اهمیت بیشتری پیدا می‌کنه؛ مثلاً اینکه داروها بر اساس تاریخ انقضا (First Expired, First Out) مصرف بشن یا بر اساس ترتیب ورود به موجودی (First In, First Out). همین تفاوت‌ها باعث می‌شه طراحی راهکاری که از همون اول همه این سناریوها رو پوشش بده، بیش از حد پیچیده بشه.

از طرف دیگه، این اولین تجربه جدی من تو Product Discovery‌ ئه، برای همین ترجیح می‌دم دامنه مسئله رو تا جای ممکن کوچیک نگه دارم تا بتونم عمیق‌تر درکش کنم، فرضیه‌ها رو بهتر اعتبارسنجی کنم و در نهایت محصولی بسازم که واقعاً برای کاربرها ارزش ایجاد کنه.

📌 به همین خاطر، تصمیم گرفتم فقط روی یه بیماری تمرکز کنم: تالاسمی.

دلیل این انتخاب فقط آشنایی من با این بیماری نیست. سال‌هاست خودم باهاش زندگی می‌کنم و خیلی از چالش‌هایی که دارویار قراره حل کنه رو از نزدیک تجربه کردم. علاوه بر این، دسترسی خوبی به جامعه هدف دارم و همین موضوع انجام مصاحبه، گرفتن بازخورد و اعتبارسنجی ایده‌ها رو خیلی ساده‌تر می‌کنه.

البته این موضوع یه چالش هم داره. وقتی خودت بخشی از مسئله‌ای، ممکنه ناخواسته تو تعریف مسئله یا انتخاب راه‌حل‌ها دچار سوگیری بشی. به خاطر همین سعی می‌کنم تا جای ممکن به اصول Product Discovery پایبند بمونم و تصمیم‌ها رو بر اساس داده، مصاحبه و نیاز واقعی کاربرها بگیرم، نه صرفاً تجربه شخصی خودم.

امیدوارم با این رویکرد بتونم قدم‌به‌قدم دارویار رو به محصولی تبدیل کنم که واقعاً برای کاربرهاش مفید، ارزشمند و قابل اتکا باشه.

#daruyar #decision
2
تا اینجا ایده دارویار رو داریم که تو دل خودش یه فهمی از مسئله رو داره و همراه با یه راهکار پیشنهادی هستش. ولی می‌دونیم که هم درک ما از مسئله و هم خود راهکار، پر از فرضیه‌ان و باید اعتبارسنجی بشن.

اگه قرار باشه Product Discovery رو از همین نقطه شروع کنیم، اولین قدمتون چیه؟ و چرا؟

#daruyar #product #question
2
الان یکی‌دو روزه دارم درباره‌ی Product Discovery می‌خونم؛ اینکه اولین قدم دقیقاً چیه و اصلاً باید از کجا شروع کرد.

به این رسیدم که برای شروع بهتره Domain Map ساخت. با اینکه تمرکز پروژه‌مون روی مدیریت مصرف دارو برای بیماران تالاسمیه، ولی بهتره یک قدم عقب‌تر برگشت و اول یه Life Domain Map از کل زندگی بیمار ترسیم کرد. داشتن یه تصویر کامل‌تر از زندگی کاربر هدف باعث میشه تصمیمات آگاهانه‌تری تو حوزه تمرکزمون بگیریم.

یه تشبیه باحال هم برای خودم پیدا کردم؛ همون‌طور که توی دنیای بازی‌ها از Map برای navigate کردن در جهان بازی استفاده می‌کنیم، از Domain Map هم می‌شه برای navigate کردن در فهم خودمون از مسئله استفاده کرد.

این Map برای من خیلی شبیه مپ بازی‌های Metroidvania است؛ اولش ناقصه و به مرور کامل‌تر می‌شه؛ درست مثل فهم‌مون از مسئله. همینطور باید توجه داشت که جواب درست و غلطی هم وجود نداره و ممکنه آدمای مختلف جور دیگه‌ای مپ کنن. مادامی که کمک می‌کنه شفاف‌تر فکر کنیم و ذهن‌مون مرتب بشه، یعنی داره کارش رو درست انجام میده.

در مجموع، همه‌ی این‌ها برام ارزشمند بود و واقعاً حس می‌کردم دارم چیزهای جدید یاد می‌گیرم. اما هم‌زمان یه حس آزاردهنده هم داشتم؛ اینکه هرچی بیشتر می‌خونم، انگار بیشتر از خود پروژه و دارویار فاصله می‌گیرم. یه جور حس درجا زدن؛ انگار به‌جای نزدیک‌تر شدن به مسئله، مدام دارم درباره‌ی روش‌های نزدیک شدن به مسئله مطالعه می‌کنم.

الان بیشتر به این نتیجه رسیدم که وقتشه دوباره برگردم به خود مسئله و دارویار رو تو مرکز توجهم قرار بدم. ببینم مهم‌ترین ریسک‌ها چی هستن، چه ابهام‌هایی وجود داره و کدوم فرضیه‌ها باید validate بشن. نمی‌خوام اون‌قدر درگیر فریم‌ورک‌ها و مفاهیم بشم که از مسئله‌ی واقعی فاصله بگیرم.


#daruyar #product #thinkingOutLoud
4
⚜️ پیچیدگی‌های ذاتی مسئله

فکر می‌کنم قبل از اینکه برم سراغ مصاحبه با کاربرها و اعتبارسنجی Pain Pointها، نیازها و Jobهایی که انتظار دارم دارویار برای کاربرهاش انجام بده، بهتره اول به یک سری پیچیدگی‌های ذاتی مسئله فکر کنم. پیچیدگی‌هایی که اگه بهشون پرداخته نشه، حتی بهترین طراحی و تجربه کاربری هم نمی‌تونه محصول رو به موفقیت برسونه.

چالش‌هایی که تا الان تونستم برای دارویار تشخیص بدم این‌ها هستن:

🔻قابل اتکا بودن موجودی نمایش داده شده در اپلیکیشن

ارزش دارویار زمانی شکل می‌گیره که کاربر بتونه به موجودی نمایش‌داده‌شده اعتماد کنه و بر اساسش تصمیم بگیره. اما چون به‌روز نگه داشتن موجودی تا حد زیادی به مشارکت خود کاربر وابسته‌ست، به مرور ممکنه بین موجودی واقعی و اطلاعات داخل اپ اختلاف ایجاد بشه. اگر به‌روز نگه داشتن این اطلاعات برای کاربر زحمت بیشتری از ارزشی که دریافت می‌کنه داشته باشه، احتمالاً اعتمادش رو از دست می‌ده و کم‌کم استفاده از محصول رو کنار می‌ذاره.


🔻اعتماد کاربران به ثبت اطلاعات

دارویار برای اینکه بتونه ارزش ایجاد کنه، به اطلاعات موجودی داروهای کاربران نیاز داره. اما ممکنه بعضی از کاربران به خاطر نگرانی‌های مربوط به حریم خصوصی، ترس از سوءاستفاده یا حتی حساسیت ناشی از کمبود دارو، حاضر نباشن موجودی واقعی خودشون رو ثبت کنن.


🔻ریسک‌های حقوقی و رگولاتوری

دارویار با اطلاعات دارویی کاربران سروکار داره و ممکنه در آینده قابلیت‌هایی مثل شناسایی داروهای مازاد یا ایجاد ارتباط بین بیماران رو هم اضافه کنه. همین موضوع می‌تونه حساسیت نهادهای قانون‌گذار رو برانگیزه. اگر محصول به‌عنوان ابزاری برای توزیع غیرمجاز دارو یا فعالیت خارج از چارچوب قوانین شناخته بشه، ممکنه با محدودیت‌های قانونی، الزام به تغییر محصول یا حتی توقف فعالیت روبه‌رو بشه.


🔻وابستگی ارزش محصول به کمبود دارو

الان بخش زیادی از ارزش پیشنهادی دارویار روی مدیریت موجودی در شرایط کمبود دارو بنا شده. اگر کاربر در شرایطی باشه که دارو همیشه به‌راحتی در دسترسه، احتمالاً انگیزه زیادی برای ثبت و مدیریت موجودی خودش نخواهد داشت. در نتیجه، ارزش محصول برای بخشی از کاربران کمتر می‌شه و ممکنه بازار هدف، کوچک‌تر از چیزی باشه که الان تصور می‌کنیم.


موارد مطرح شده به ترتیب الویت بودن. باید روی این‌ها فکر و به نوعی وجود داشتن‌شون رو ولیدیت کنم و ببینم چطور می‌شه هندل‌شون کرد.

#daruyar #product
1
⚜️ اعتبارسنجی فرضیه‌ها یا تکیه بر شهود

درسته که همیشه توصیه می‌شه بر اساس فرضیات پیش نریم، ولی فکر می‌کنم این نباید باعث بشه به این اشتباه بیفتیم که هر فرضیه‌ای حتماً باید اعتبارسنجی بشه. اعتبارسنجی هم هزینه‌ی خودش رو داره. به نظرم کاملاً منطقیه که اگر احساس می‌کنیم هزینه‌ی اعتبارسنجی از ارزش اطلاعاتی که قراره به دست بیاریم بیشتره، با همون فرض جلو بریم.

مثلاً درباره‌ی چالش‌هایی که در پیام قبلی آوردم، می‌دونم که «اعتماد کاربران به ثبت اطلاعات» یه فرضیه‌ست و طبق آموزه‌های Product باید ولیدیت بشه. اما چون راهکاری که براش در نظر دارم (offline-first بودن اپ)، چالش بعدی یعنی «ریسک‌های حقوقی و رگولاتوری» رو هم تا حد زیادی پوشش می‌ده و در عمل هزینه‌ی اضافه‌ای هم برام نداره، به نظرم منطقیه که بدون ولیدیت کردن اون فرضیه، همین مسیر رو ادامه بدم.

یه صدایی توی مغزم می‌گه: «خب، اینکه فکر می‌کنی offline-first بودن این مشکل رو حل می‌کنه هم خودش یه فرضیه‌ست!»
جوابش اینه که: آره، هست. ولی خب... می‌گی چیکاااار کنم؟ =)))

جدا از شوخی، واقعاً فکر می‌کنم مرز بین اینکه کجا باید ولیدیت کنیم و کجا می‌تونیم به قضاوت خودمون تکیه کنیم، یه مهارته که به مرور و با شکل گرفتن شهود بهتر، متعادل‌تر می‌شه.


🔻 پی نوشت:

همین متن رو به GPT دادم و در تأیید این ایده به مفهوم Value of Information (VOI) اشاره کرد:


اطلاعات ذاتاً ارزشمند نیست؛ ارزش اطلاعات به این بستگی داره که آیا باعث می‌شه تصمیم بهتری بگیریم یا نه.


به نظرم این نگاه، معیار خوبی برای تصمیم گرفتن درباره‌ی اعتبارسنجی فرضیاته.

#daruyar #product #thinkingOutLoud
1