پرداخت برای کاربر شاید فقط چند ثانیه طول بکشد، اما پشت همین تجربه ساده، شبکه‌ای از بانک، PSP، سوئیچ، رگولاتوری، مدیریت ریسک و تسویه قرار دارد. محمدحسین غفارلوی‌مقدم، معاون محصول پرداخت الکترونیک پاسارگاد، می‌گوید بلوغ یک محصول پرداخت زمانی شکل می‌گیرد که این پیچیدگی در سیستم مدیریت شود و به تجربه کاربر منتقل نشود. از نگاه او، صنعت پرداخت نیز در سال‌های آینده باید از «پردازش تراکنش» به سمت «حل مسئله» حرکت کند و ارزش شرکت‌های پرداخت بیش از تعداد تراکنش‌ها، با مسئله‌ای سنجیده شود که برای کسب‌وکار و مشتری حل می‌کنند.
غفارلوی‌مقدم، در گفت‌وگو با راه پرداخت از منطق انتخاب و اولویت‌بندی مسائل در مدیریت محصول، نقش داده و هوش مصنوعی در کشف نیاز مشتری، نسبت میان سادگی تجربه کاربر و پیچیدگی صنعت پرداخت و مسیر آینده شرکت‌های PSP گفت.
به عقیده او، محصول را باید با نتیجه‌ای که برای مشتری و کسب‌وکار ایجاد می‌کند سنجید، نه با تعداد قابلیت‌هایی که توسعه داده شده‌اند.
چه چیزی در مسیر حرفه‌ای شما را به حوزه محصول علاقه‌مند کرد و اساساً جذابیت «ساختن یک محصول» برای شما چیست؟
آنچه از ابتدا برای من درحوزه محصول جذابیت داشت، قرار گرفتن در نقطه‌ای بود که مسئله مشتری، منطق کسب‌وکار و ظرفیت تکنولوژی به یکدیگر می‌رسند.
به مرور برای من روشن شد که محصول صرفاً ساختن یک نرم‌افزار یا اضافه کردن یک قابلیت جدید نیست. بخش مهم‌تر محصول، انتخاب مسئله درست است؛ اینکه بدانیم چه چیزی واقعاً ارزش حل شدن دارد و چرا باید برای حل آن سرمایه‌گذاری کنیم.
این موضوع در صنعت پرداخت اهمیت بیشتری پیدا می‌کند. برای یک تجربه بسیار ساده مثل انجام یک پرداخت، پشت صحنه می‌تواند متکی بر شبکه‌ای پیچیده از PSP، بانک، سوئیچ، رگولاتوری، مدیریت ریسک، تسویه و زیرساخت باشد. به اعتقاد من هنر محصول این است که این پیچیدگی را در سیستم مدیریت کند و تا حد ممکن آن را به تجربه مشتری منتقل نکند.
بنابراین جذابیت ساختن محصول برای من صرفاً در ساختن نیست؛ در حل یک مسئله واقعی و مشاهده اثری است که آن راه‌حل در رفتار مشتری و کسب‌وکار ایجاد می‌کند.
به همین دلیل امروز سؤال: چه چیزی نسازیم؟ به اندازه سؤال: چه چیزی بسازیم؟ اهمیت دارد.
یک مدیر محصول چطور تشخیص می‌دهد یک مسئله واقعاً ارزش حل کردن دارد؟ در شرایطی که ایده و درخواست زیاد است، چه زمانی باید به یک ایده «نه» گفت و چه چیزی را نباید ساخت؟
در سازمان‌های محصول محور، به نظرم یکی از مهم‌ترین مهارت‌ها تشخیص تفاوت بین درخواست، مسئله و راه‌حل است.
اینکه یک مشتری یا یک واحد سازمانی Feature خاصی را درخواست کرده، به این معنی نیست که الزاماً همان Feature باید ساخته شود. ابتدا باید بفهمیم مسئله واقعی چیست، چه کسانی با آن مواجه‌اند، شدت و فراوانی آن چقدر است و حل آن چه اثری ایجاد می‌کند.
من معمولاً مسئله را از چند زاویه بررسی می‌کنم: ارزش برای مشتری، ارزش برای کسب‌وکار، هم‌راستایی با استراتژی، امکان‌پذیری، هزینه، ریسک و زمان‌بندی. بعد سؤال مهم‌تری مطرح می‌شود: آیا این مسئله در مقطع فعلی ارزش سرمایه‌گذاری دارد یا نه؟
ممکن است مسئله‌ای واقعی و حتی مهم باشد، اما امروز نسبت به مسائل دیگری که منابع محدود سازمان را به خود اختصاص می‌دهند، اولویت نداشته باشد.
تیم محصول باید بتواند نه بگوید، اما این «نه» نباید سلیقه‌ای باشد.
نه گفتن حرفه‌ای یعنی بتوانیم توضیح دهیم که چرا یک ایده را در این مقطع وارد Roadmap نمی‌کنیم؛ مثلاً چون شواهد کافی از مسئله نداریم، اثر آن پایین است، هزینه یا پیچیدگی آن بالاست، با استراتژی شرکت هم‌راستا نیست یا راه‌حل ساده‌تر و کم‌ریسک‌تری برای همان مسئله وجود دارد. حتی در برخی موارد پاسخ «نه» به مسئله نیست؛ نه به راه‌حل فعلی است.
به اعتقاد من حداقل سه نوع ایده و یا فیچر را نباید بسازیم:
- اول، مورادری که مسئله واقعی و قابل اثباتی پشت آن وجود ندارد.
- دوم، مواردی که صرفاً به دلیل صدای بلند یک Stakeholder وارد Roadmap شده ولی ارزش قابل تعمیمی برای مشتریان یا کسب‌وکار ایجاد نمی‌کند.
- سوم، راه‌حلی که هنوز فرضیات کلیدی آن را Validate نکرده‌ایم و برای ساخت کامل آن باید هزینه زیادی پرداخت کنیم.
در این موارد ترجیح می‌دهم ابتدا با Prototype ،Experiment یا یک نسخه محدود، فرضیه را آزمایش کنیم.
اینجا هوش مصنوعی می‌تواند به عنوان دستیار یک مدیر محصول کمک زیادی کند. هم می‌تواند در همین فرایند اولویت‌بندی کمک کند. وقتی هزاران Ticket پشتیبانی، Feedback مشتری، درخواست فروش و داده رفتاری داریم، هوش مصنوعی می‌تواند این داده‌ها را دسته‌بندی کند، الگوهای تکرارشونده را پیدا کند و فرصت‌های احتمالی را سریع‌تر شناسایی کند.
مشتری همیشه دقیقاً می‌داند چه می‌خواهد؟ نقش تیم محصول در کشف نیازهایی که هنوز به‌درستی بیان نشده‌اند چیست و محدودیت‌های صنعت پرداخت تا چه حد دست محصول را برای پاسخ به این نیازها می‌بندند؟
مشتری معمولاً درد و مسئله خودش را بهتر از ما می‌شناسد، اما لزوماً بهترین فرد برای تعریف راه‌حل نیست. تفاوت مهمی بین Customer Need و Customer Solution Request وجود دارد.
مثلاً ممکن است یک پذیرنده بگوید: «من یک داشبورد جدید می‌خواهم .اما تیم محصول نباید بلافاصله سراغ ساخت داشبورد برود. باید بپرسد: چرا؟ کار محصول فهم نیاز پشت درخواست مشتری است.»
شاید مسئله اصلی این باشد که پذیرنده نمی‌تواند مغایرت‌های مالی خود را پیدا کند، وضعیت تسویه را به‌درستی نمی‌بیند یا عملکرد شعبه‌هایش را مقایسه نمی‌کند.
در این حالت ممکن است درخواست مشتری داشبورد باشد، اما مسئله واقعی Visibility یا Reconciliation باشد.
موضوع discovery باید بخشی از عادت دائمی تیم محصول باشد. ما باید به‌صورت مستمر با مشتری صحبت کنیم، رفتار او را ببینیم، داده‌ها را تحلیل کنیم، Prototype بسازیم و فرضیات خودمان را تست کنیم. محصول باید بتواند از صدای مشتری، داده و رفتار او به Insight و Opportunity برسد.
اما در صنعت پرداخت، طبیعتاً Constraintهای بیشتری نسبت به بسیاری از صنایع دیگر داریم؛ رگولاتوری، امنیت، KYC، مدیریت ریسک، الزامات بانک‌ها، شاپرک، تسویه و زیرساخت بخشی از فضای تصمیم‌گیری محصول را محدود می‌کنند.
اما من این محدودیت‌ها را لزوماً به معنای محدود شدن تیم محصول نمی‌دانم. اتفاقاً مدیریت محصول در یک صنعت Regulated یعنی پیدا کردن راه‌حل مناسب درون Constraintها.
با افزایش سرویس‌ها و قابلیت‌های پرداخت، چطور می‌توان پیچیدگی پشت سیستم را از کاربر پنهان داشت؟ به نظر شما یک محصول پرداختی بالغ چه میزان از پیچیدگی خود را نباید به کاربر منتقل کند؟
پرداخت ذاتاً صنعت پیچیده‌ای است و با اضافه شدن سرویس‌های جدید، این پیچیدگی بیشتر هم می‌شود. اما به اعتقاد من نباید انتظار داشته باشیم کاربر این پیچیدگی را بفهمد.
من بین System Complexity و User Complexity تفاوت می‌گذارم. ممکن است سیستم ما برای مدیریت امنیت، ریسک، تسویه یا الزامات رگولاتوری پیچیده باشد و حتی لازم باشد این پیچیدگی را حفظ کنیم؛ اما این پیچیدگی نباید الزاماً به تجربه کاربر منتقل شود.
برای کاربر، یک پرداخت باید به یک تجربه ساده تبدیل شود: چه اتفاقی افتاد؟ موفق شد یا نشد؟ اگر نشد، چرا و قدم بعدی چیست؟
بنابراین به نظرم بلوغ محصول زمانی اتفاق می‌افتد که پیچیدگی را حذف نمی‌کنیم، بلکه آن را در جای درست مدیریت می‌کنیم.
کاربر نباید بداند پشت یک پرداخت موفق چه تعداد سرویس، بانک، سوئیچ، کنترل ریسک و فرایند تسویه فعال شده است.
این پیچیدگی باید برای سیستم قابل مدیریت باشد، نه برای کاربر قابل مشاهده. از طرفی هوش مصنوعی هم می‌تواند در آینده به کاهش Cognitive Load کاربر کمک کند؛ یعنی سیستم بر اساس Context تشخیص دهد در هر لحظه چه اطلاعاتی برای کاربر ضروری است و چه اطلاعاتی صرفاً باعث شلوغی تجربه می‌شود.
البته در محصولات مالی باید بین سادگی و شفافیت تعادل برقرار کرد. ساده‌سازی نباید به معنی پنهان کردن اطلاعات مهم، هزینه، ریسک یا وضعیت مالی کاربر باشد.
اگر بخواهید با یک معیار بفهمید یک محصول واقعاً موفق شده، چه چیزی را اندازه می‌گیرید؟ تعداد تراکنش، درآمد، نگهداشت یا معیاری فراتر از این‌ها؟
من فکر نمی‌کنم یک Metric یکسان برای همه محصولات وجود داشته باشد. معیار موفقیت باید از Outcome اصلی محصول استخراج شود. برای مثال در یک محصول پرداخت، تعداد تراکنش قطعاً Metric مهمی است، اما به‌تنهایی نمی‌تواند موفقیت محصول را توضیح دهد. ممکن است تعداد تراکنش بالا برود ولی Revenue یا Margin کاهش پیدا کند؛ یا تراکنش زیاد شود اما نرخ موفقیت پایین باشد، هزینه عملیاتی افزایش پیدا کند یا کاربران Retain نشوند. بنابراین ترجیح می‌دهم یک North Star Metric متناسب با مدل محصول داشته باشیم و در کنار آن مجموعه‌ای از Metrics مکمل را ببینیم؛ از جمله درآمدMargin ، Conversion ،Retention، کیفیت سرویس، Cost و Risk.
برای من Output با Outcome متفاوت است. اینکه یک Feature را Launch کرده‌ایم، Output است. این که آن Feature باعث شده Conversion بهتر شود، هزینه کاهش پیدا کند، مشتری بیشتری فعال بماند یا Revenue افزایش پیدا کند، Outcome است.
در نهایت محصول را باید با Outcome آن قضاوت کرد، نه با تعداد قابلیت‌هایی که تولید کرده است.
یکی از روندهای مهم جهانی، حرکت از یک ابزار پرداخت منفرد به سمت اکوسیستم‌هایی است که مواردی مانند کیف پول، اعتبار، وفاداری، مدیریت تراکنش و ابزارهای کسب‌وکار را ترکیب می‌کنند. این تغییر چه افقی برای توسعه در صنعت پرداخت ایجاد می‌کند؟
به نظرم مهم‌ترین تغییر این است که پرداخت از یک Transaction به بخشی از یک Customer Journey تبدیل می‌شود.
در مدل سنتی، سؤال این بود که چگونه یک تراکنش را با امنیت و پایداری بالا پردازش کنیم.
اما وقتی به سمت اکوسیستم حرکت می‌کنیم، سؤال بزرگ‌تر می‌شود: چطور می‌توانیم بخشی از مسئله مالی و تجاری مشتری را حل کنیم؟
برای یک کسب‌وکار، پرداخت فقط نقطه دریافت پول نیست. در ادامه آن موضوعاتی مثل تسویه، مغایرت‌گیری، تحلیل، وفاداری، اعتبار، مدیریت جریان نقدینگی و حتی رشد کسب‌وکار مطرح می‌شود.
بنابراین به نظرم PSP می‌تواند از یک Payment Processor به یک Business Enablement Platform تبدیل شود.
البته اکوسیستم به این معنی نیست که هر شرکتی باید همه سرویس‌ها را خودش بسازد.
اتفاقاً در این مدل، API ،Partnership ،Open Architecture و استفاده از قابلیت‌های شرکا اهمیت بیشتری پیدا می‌کند.
سؤال اصلی این نیست که: چه چیزهایی می‌توانیم خودمان بسازیم؛ سؤال این است که: در کدام بخش از زنجیره ارزش، مزیت رقابتی واقعی داریم و کجا بهتر است با شریک مناسب کار کنیم؟
بنابراین آینده اکوسیستم صرفاً «سرویس‌های بیشتر» نیست؛ سرویس‌های هوشمندتر و مرتبط‌تر است.
اگر پنج سال آینده صنعت پرداخت را تصور کنیم، چه چیزی که امروز «محصول پرداخت» می‌نامیم دیگر به‌عنوان محصول دیده نخواهد شد؟ و از نگاه شما مهم‌ترین تغییری که باید در تعریف سرویس پرداخت در ایران ببینیم چیست و چه ارزشی برای کسب‌وکار و کاربر ایجاد می‌کند؟
اگر بخواهم پنج سال آینده را تصور کنم، فکر می‌کنم بخش قابل توجهی از چیزی که امروز به‌عنوان «محصول پرداخت» می‌شناسیم، به تدریج از دید کاربر به یک Capability یا Infrastructure تبدیل خواهد شد.
همان‌طور که امروز کاربر درباره بسیاری از زیرساخت‌های اینترنت فکر نمی‌کند، احتمالاً در آینده پرداخت هم بیش از پیش در دل تجربه‌های دیگر قرار می‌گیرد و کمتر خودش را به‌عنوان یک محصول مستقل به کاربر نشان می‌دهد.
کاربر الزاماً نمی‌خواهد «یک ابزار پرداخت» داشته باشد؛ می‌خواهد مسئله‌اش در سریع‌ترین، امن‌ترین و ساده‌ترین شکل ممکن حل شود.
در ایران هم به نظرم تغییر مهم این است که تعریف سرویس پرداخت باید از Transaction Processing به سمت Problem Solving حرکت کند. یعنی ارزش شرکت های پرداخت صرفاً در این نباشد که چه تعداد تراکنش پردازش کرده، بلکه در این باشد که چه مسئله‌ای از کسب‌وکار یا کاربر را بهتر حل کرده است.
برای کسب‌وکار می‌تواند به معنای افزایش Conversion، بهبود تسویه و نقدینگی، کاهش هزینه، مدیریت بهتر مشتری، تصمیم‌گیری مبتنی بر داده باشد و برای کاربر هم می‌تواند به معنای تجربه ساده‌تر، انتخاب مناسب‌تر، امنیت بیشتر، دریافت خدمات متناسب‌تر با نیاز واقعی باشد.
نقش هوش در این آینده بسیار اثرگذار است. هوش مصنوعی می‌تواند نحوه طراحی و ارائه سرویس پرداخت را تغییر دهد. امروز بخش زیادی از سرویس‌ها بر اساس یک Rule ثابت و یک تجربه نسبتاً یکسان به همه کاربران ارائه می‌شوند. در آینده می‌توانیم به سمت سرویس‌هایی برویم که Context-Aware ،Predictive و Personalized هستند. از طرف دیگر، هوش مصنوعی خود فرایند مدیریت محصول را هم تغییر خواهد داد؛ از کشف نیاز و تحلیل Feedback گرفته تا Prototype، تحلیل داده، پیش‌بینی و بهینه‌سازی بعد ازاستقرار محصول.
در نهایت فکر می‌کنم آینده صنعت پرداخت، آینده تراکنش‌های بیشتر نیست؛ آینده ارزش بیشتر از هر تراکنش است.
اگر بتوانیم پرداخت را از یک رویداد مالی به نقطه‌ای برای شناخت بهتر مشتری، حل مسئله کسب‌وکار و ارائه خدمات هوشمندتر تبدیل کنیم، آن‌وقت محصول در صنعت پرداخت از یک لایه عملیاتی به یک مزیت رقابتی واقعی تبدیل می‌شود.
