بهعنوان مدیر محصول، همیشه بهمون میگن باید صدای کاربر باشی. اما بعضی وقتها، مخصوصاً وقتی محصولت تو بازارهای حساس و رگولهشده فعالیت میکنه، واقعیت اینه که کاربر اول تو، خودِ کاربر نهایی نیست.
من اخیراً عضو تیم محصولی در بازار مالی شدم، با تمرکز روی تأمین مالی جمعی. محصولی که قبل از رسیدن به هر کاربری، باید از هفتخان گرفتن مجوز از فرابورس عبور کنه. یعنی اولویتها، از طراحی گرفته تا تجربه کاربری و حتی ترتیب توسعهی فیچرها، نه بر اساس خواستههای کاربر، بلکه بر اساس نیازهای رگولاتور تعیین میشن.
فرض کن باید فرآیند ثبتنام رو طراحی کنی. بهعنوان یک PM دغدغهمند، احتمالاً دنبال کمترین اصطکاکی. ولی وقتی فرابورس الزام میکنه که احراز هویت چندمرحلهای، تطبیق اطلاعات هویتی با مراجع مختلف، و ذخیرهسازی لاگهای مشخصی انجام بشه، اون تجربهی دلچسب و مینیمال عملاً غیرممکن میشه.
در چنین شرایطی، ممکنه وسوسه بشی بگی: «این دیگه از کنترل من خارجه و قید فکر کردن به کاربر رو بزنی.»
اما دقیقاً همینجا جاییه که مدیر محصول بودن شروع میشه...
برای اینکه از این چالش عبور کنم، بهجای تقابل با قوانین، تصمیم گرفتم باهاشون هممسیر بشم. نه بهعنوان یک مانع، بلکه بهعنوان یک چارچوب. این رویکرد به من کمک کرد از یک وضعیت «محدودکننده» به یک موقعیت «قابل مدیریت» برسم.
تحلیلگر قوانین شدم، نه فقط دریافتکنندهی نیاز:
بهجای اینکه صرفاً چکلیستی از الزامات رو تحویل بگیرم، سعی کردم منطق پشت هر الزام رو بفهمم. اینکه چرا فلان فیلد باید اجباری باشه؟ چرا باید لاگ خاصی ذخیره بشه؟
فهم این منطق کمکم کرد تا با تیم طراحی، نسخههایی از فیچرها رو بسازیم که در عین رعایت قانون، تا حد ممکن تجربه کاربری رو حفظ کنن.
گاهی البته منطق مشخصی پشت برخی الزامات نبود. اما این هم نباید بهانهای برای کنار کشیدن میشد. وقتی متن قانون شفاف باشه، همیشه راهی هست که هم قانون رو رعایت کنه و هم کاربر رو آزار نده
از "نه" به "چطور؟" تغییر موضع دادم:
هر جا تیم گفت: «این تجربهی کاربری خوبی نیست»، سعی نکردم قانعشون کنم که الزام درسته یا شکایت کنم. تنها سوالی که مطرح کردم این بود:
«درسته... حالا چطور میتونیم این الزام رو با کمترین اصطکاک اجرا کنیم؟»
همین تغییر زاویه باعث میشد گفتوگو از سطح مقاومت، به سطح حل مسئله منتقل بشه.
داستان ساختیم، نه فقط فیچر:
بعضی فیچرها صرفاً برای گرفتن مجوز طراحی میشن. نه خوشگلان، نه مفید، و نه حتی گاهی قابل دفاع از دید کاربر. ولی بهجای اینکه صرفاً به چشم بار اضافی بهشون نگاه کنیم، سعی کردم با تیم طراحی و محتوا براشون داستان بسازیم. مثلاً یک گزارشگیری پیچیده که صرفاً برای ناظر بود، تبدیل شد به داشبورد تحلیلی قابلفهم برای کاربران حرفهای.
گاهی لازم نیست ماهیت فیچر رو تغییر بدی، فقط کافیه زاویهی دید کاربر بهش رو دوباره طراحی کنی.
ساخت محصول در فضای رگولهشده، مثل راه رفتن روی طنابیه بین خواستههای قانونگذار، انتظارات کاربر، و منطق تیم محصول.
و شاید بزرگترین مهارت مدیر محصول این فضا، نه طراحی تجربهی بینقص، بلکه خلق تعادلی قابلقبول در یک شرایط غیرایدهآله.
اگر جای جنگیدن با قوانین، سعی کنی بفهمیشون، میتونی راهی پیدا کنی برای اینکه هم محصول مجوز بگیره، هم کاربر حس کنه احترامش حفظ شده.
گاهی اولین وظیفهی ما اینه که زمین بازی قانونی رو بسازیم؛ بازی تجربه کاربری، بعداً شروع میشه.
