📌 از اینجا شروع کنید:

— من کی‌ام و اینجا کجاست؟

— برنامه محتوایی

‏— Build in Public: شروع یک مسیر
‌‏
‏

درود.

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


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


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

⚜️ برنامه‌ی محتوایی

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

‏—————

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

‏

⚜️ برخی از ریسک‌های روان‌شناختی 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

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

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

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

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

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

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

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

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

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

اولین پست خدمت شما: Build in Public - شروع یک مسیر

⚜️ چرا یاد گرفتن 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

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

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

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

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

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

#bip #ai
‏

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

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

تا الان دارویار رو همیشه اینطوری تو یه خط معرفی می‌کردم:

یه سیستم مدیریت موجودی دارو توی خونه‌، با تمرکز روی بیماران خاص.

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

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

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

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

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

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

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

#daruyar #decision

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

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

#daruyar #product #question

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

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

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

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

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

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


#daruyar #product #thinkingOutLoud

⚜️ پیچیدگی‌های ذاتی مسئله

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

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

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

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


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

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


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

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


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

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


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

#daruyar #product

‏⚜️ اعتبارسنجی فرضیه‌ها یا تکیه بر شهود

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

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

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

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


🔻 پی نوشت:

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

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

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

#daruyar #product #thinkingOutLoud

⚜️ دو زاویه دید متفاوت برای توصیف گزاره‌های Product Discovery

🔻 در Product Discovery برای نشون دادن رابطه‌مون با گزاره‌هایی که درباره‌ی محصول بیان می‌کنیم، می‌تونیم از یک‌سری Statement استفاده کنیم:

Observation, Assumption, Risk, Concern, Fact, Hypothesis, Claim, Decision

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

— بعضی از این عبارت‌ها مرز باریکی با هم دارن و ممکنه در ابتدا سردرگم‌کننده باشن. برای همین لازمه کمی بهشون فکر کنیم، مثال‌های مختلف رو مرور کنیم و در نهایت مرزهاشون رو برای خودمون شفاف‌تر کنیم. مثلاً Assumption، Claim و Hypothesis ممکنه به هم نزدیک به نظر برسن؛ یا همین‌طور Risk و Concern.

— یه نکته‌ی خیلی مهم به نظرم وجود داره. کار این Statementها Represent کردن وضعیت فعلی فهم ما از مسئله‌ست. این فهم ممکنه اشتباه باشه، اما اگر بتونه همون فهم اشتباه رو به‌درستی ابراز کنه، یعنی ما این قسمت از کارمون رو درست انجام دادیم.

— مثلاً ممکنه یه چیزی رو Decision بدونیم و به‌عنوان یک Decision Statement ثبت و مطرحش کنیم. بعداً شاید معلوم بشه اون تصمیم اشتباه بوده، ولی این مهم نیست. مهم اینه که در اون لحظه، اون موضوع واقعاً یک Decision بوده و باید با ادبیات متناسب با یک Decision Statement بیان می‌شده، نه مثلاً به شکل یک Assumption یا Risk.

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



🔻 یه سؤال توی ذهنم شکل گرفته بود که این عبارت‌ها چه فرقی با عبارت‌هایی مثل Pain Point، Needs، Wants، Job و... دارن؟

— به این نتیجه رسیدم که اون‌ها برچسب‌های مفهومی هستن، ولی این‌هایی که بالاتر گفتم، برچسب‌های رابطه‌ای هستن. یعنی به یک گزاره می‌شه از هر دو دسته برچسب نسبت داد و هر کدوم از یک بُعد به بیان دقیق‌ترش کمک می‌کنن.

— مثلاً وقتی توی مصاحبه می‌شنویم که مصاحبه‌شونده می‌گه «من فلان مشکل یا درد رو دارم»، در همون لحظه می‌دونیم جمله‌ای که داریم ثبت می‌کنیم، از نظر مفهومی یک Pain Point محسوب می‌شه. اما هم‌زمان باید حواسمون باشه که رابطه‌ی ما با این گزاره هنوز در حد یک Observation هست و هنوز هیچ تحلیلی روش انجام ندادیم.

— بعد از مصاحبه، وقتی داده‌ها رو تحلیل کردیم، ممکنه همون Pain Point رو در کنار چند مورد دیگه به شکل یک Job بازنویسی کنیم. اما حالا رابطه‌ی ما با اون Job دیگه Observation نیست؛ بلکه یک Assumption محسوب می‌شه.

— می‌تونم حدس بزنم که شاید دارم موضوع رو بیش از حد پیچیده می‌کنم، ولی فعلاً این‌طور حس نمی‌کنم. در این لحظه احساس می‌کنم اضافه کردن این بُعد رابطه‌ای، کمک می‌کنه با اصطکاک ذهنی کمتری فکر کنم.

— چون قبلاً همیشه یه حس مبهمی داشتم که مثلاً این Pain Pointای که نوشتیم، صرفاً یک فرض ضعیف از درد کاربره یا واقعاً تقریباً مطمئنیم که دردش همینه؟ چرا توی این ابزارها جایی برای تفکیک و مدل کردن میزان اعتمادمون به یک گزاره، یا به عبارتی همین رابطه‌ای که باهاش داریم، وجود نداره؟ البته اون موقع این مسئله انقدر برام شفاف نبود. فقط یه حس مبهم داشتم که یه جای کار می‌لنگه و همون ابهام مدام اذیتم می‌کرد.

— هنوزم سواله برام که چرا واقعا تو ابزارهای مختلفی که تو Miro مثلا وجود داره این رو لحاظ نکردن. می‌دونم مثلا Assumption map رو داریم ولی اونجا فرض شده همه‌ی گزاره‌هایی که میاریم داخلش Assumption هستن ولی جاهایی که با هم قاطی‌ان اینا، مثل Business Model Canvas یا Value Proposition Canvas چیزی براش نیست.

— من تصمیم گرفتم با گذاشتن Dot Vote های رنگی که تو Miro هست، روی استیکی نوت‌ها اون تفکیک رو قائل شم برای خودم.

💬 اگر شما هم تجربه‌ی مشابهی داشتید یا راه‌حل بهتری برای مدل کردن این موضوع می‌شناسید، خوشحال می‌شم توی کامنت‌ها share کنید.

#product #thinkingOutLoud

بالاتر به چهار نگرانی اساسی درمورد دارویار اشاره کرده بودم. در ادامه، نتیجه‌گیری‌هایی که درباره هرکدوم داشتم رو توضیح می‌دم و بعد هم از قدم بعدی‌ای که می‌خوام سراغش برم می‌گم:
‏

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

— این مشکل تقریباً در همه‌ی سیستم‌هایی وجود داره که یک digital state نمایانگر یک وضعیت فیزیکی در دنیای واقعی باشه. سینک نگه داشتن این دو همیشه یک چالشه.

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

— اما توی اپ ما، سینک موندن موجودی وابسته به اینه که خود بیمار مصرفش رو ثبت کنه. برای اینکه اصطکاک این کار کم بشه، تصمیم دارم از optimistic log استفاده کنم.

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

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

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

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

— راهکاری که بهش رسیدم اینه که خودِ «اعتماد به موجودی» رو هم داخل اپ مدل کنم و براش یک visual representation داشته باشم؛ چیزی که در مرکز توجه کاربر قرار بگیره. یعنی به‌جای اینکه فقط عدد موجودی نمایش داده بشه، به کاربر هم گفته بشه که این عدد تا چه حد قابل اعتماده. همچنین یک CTA هم در اختیارش قرار بگیره تا با مرور، تأیید یا رد کردن لاگ‌های مصرف، بتونه این اعتماد رو دوباره بازیابی کنه.

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


✅ نتیجه‌گیری

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

#daruyar #product #decision