<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
    <channel>
        <title>نوشته های بابک حقیقی</title>
        <link>https://virgool.io/feed/@m_48141496</link>
        <description>Product Strategist</description>
        <language>fa</language>
        <pubDate>2026-04-14 04:45:35</pubDate>
        <image>
            <url>https://files.virgool.io/upload/users/4802083/avatar/dlgAYx.jpg?height=120&amp;width=120</url>
            <title>بابک حقیقی</title>
            <link>https://virgool.io/@m_48141496</link>
        </image>

                    <item>
                <title>چرا اکثر محصولات دیجیتال شکست می‌خورند؟</title>
                <link>https://virgool.io/@m_48141496/%DA%86%D8%B1%D8%A7-%D8%A7%DA%A9%D8%AB%D8%B1-%D9%85%D8%AD%D8%B5%D9%88%D9%84%D8%A7%D8%AA-%D8%AF%DB%8C%D8%AC%DB%8C%D8%AA%D8%A7%D9%84-%D8%B4%DA%A9%D8%B3%D8%AA-%D9%85%DB%8C-%D8%AE%D9%88%D8%B1%D9%86%D8%AF-mbsgpgb9e9n4</link>
                <description>درون محصول دیجیتال - چرا اکثر محصولات دیجیتال شکست می‌خورند؟ (مقاله ۲)چرا تیم‌های خوب هم گاهی محصولات بد می‌سازند؟!چند سال پیش، به یک استارتاپ ۱۵ نفره بعنوان مشاور ملحق شدم. بودجه خوبی داشتند. تیم باهوش، مدیرعامل با انگیزه، شش ماه روی محصولشان کار کرده بودند.اولین جلسه، محصول را بررسی کردیم. یک پلتفرم فروشگاهی با قابلیت چت که بر اساس موقعیت جغرافیایی نزدیکترین فروشگاه‌های مورد نیاز کاربر را نمایش می‌داد و کاربر می‌توانست با ارسال پیام نیاز خود را به فروشگاه‌های مورد نظر ارسال کند سپس بر اساس پاسخ فروشگاه‌ها و مقایسه آنها کالای مورد نظر را از فروشگاه منتخب سفارش می‌داد. بعلاوه کلی فیچر‌های جذاب دیگر هم در حال توسعه بودند.پرسیدم: “چند کاربر دارید؟”“گفتند: هنوز لانچ نکردیم. می‌خواهیم اول کامل بشود.”این جمله را خیلی شنیده‌ام. و هر بار، می‌دانم چه اتفاقی می‌افتد.اشتباه اول: ساختن قبل از فهمیدناکثر محصولات از همین‌جا شروع به شکست می‌خورند — نه وقتی لانچ می‌شوند، بلکه وقتی تصمیم می‌گیرند چه بسازند.آنها شش ماه مشغول کد نویسی و توسعه محصول بود. اما هیچ‌وقت با کاربران واقعی صحبت نکرده بودند. فرض کرده بودند می‌دانند مشکل چیست.فرض کردن راحت است. صحبت کردن و البته «درست صحبت کردن» سخت.هنگامی که در حال طراحی یک اپلیکیشن سفارش آنلاین غذا بودیم. مهمترین خواسته کاربر را “تسریع در ارسال غذا” فرض کرده بودیم.رفتیم با مردم صحبت کنیم. متوجه شدیم مشکل اصلی سرعت نیست. مشکل این است که نمی‌دانند چه بخورند. هر بار که می‌خواهند سفارش بدهند، ده دقیقه وقت می‌گذارند تا تصمیم بگیرند.اگر ما بدون صحبت با کاربران شروع به ساختن می‌کردیم، احتمالاً زمان و هزینه زیادی را می‌بایست صرف بخش‌های عملیاتی، لاجستیک و قابلیت‌های سیستمی مرتبط می‌کردیم. ولی سریعترین ارسال چیزی نبود که مردم می‌خواستند و فقط کافی بود به تعهد زمان ارسال مقید باشیم. قابلیت مهمتری که کاربران می‌خواستند کمک به تسریع تصمیم‌گیری در انتخاب غذا بود.درس اول: محصول خوب با فهمیدن شروع می‌شود، نه با ساختن.اشتباه دوم: عاشق راه‌حل شدن، نه مشکل!یک پدیده عجیب وجود دارد: وقتی تیمی شروع به ساختن چیزی می‌کند، عاشق آن می‌شود. حتی اگر کار نکند.در یک اپلیکیشن مدیریت پروژه، یک فیچر داشت که روی آن خیلی وقت گذاشته بودند: “نمودار وابستگی وظایف سه‌بعدی.”پرسیدم: “کسی این را خواسته؟”“گفتند نه، اما فکر می‌کنیم خیلی جالب است.”این جمله خطرناک است: “فکر می‌کنیم.”وقتی تیمی عاشق ایده‌اش می‌شود، دیگر نمی‌تواند ببیند که کار نمی‌کند. هر بازخورد منفی را نادیده می‌گیرد. هر نشانه شکست را توجیه می‌کند.من خودم این اشتباه را کرده‌ام. چند سال پیش، روی یک فیچر کار کردم که فکر می‌کردم انقلابی است. پنج ماه طراحی و پیاده سازی آن طول کشید. این قابلیت به تولید کنندگان محتوای سفر این امکان را می‌داد که یک برنامه سفر با جزئیات کامل مانند تصویر، متن، نقشه، تخمین هزینه و ... طراحی کنند و آنرا به اشتراک بگذارند یا حتی بفروشند. وقتی لانچ کردیم، فقط یک نفر از آن استفاده کرد و تا ماهها بعد دنبال کاربرانی مانند آن نفر بودیم ولی پیدا نشد.چرا؟ چون من عاشق راه‌حل بودم، نه مشکل. فراموش کرده بودم بپرسم: “آیا کاربر واقعاً این را می‌خواهد؟”درس دوم: عاشق مشکل باش، نه راه‌حل. راه‌حل‌ها می‌توانند تغییر کنند.اشتباه سوم: ساختن برای همه« هروقت کسی به شما گفت که محصول ما برای همه است! یعنی آن محصول برای هیچ‌کس نیست. »وقتی می‌خواهید برای همه بسازید، نمی‌توانید برای هیچکس، خوب بسازید. چون نیازهای آنها با هم متفاوت است. بعبارتی وقتی بخواهید همه را راضی کنید، یک محصول بی‌هویت ساخته می‌شود.بهترین محصولات برای یک گروه خاص ساخته می‌شوند. آن‌قدر خاص که آن گروه حس کند این محصول فقط برای آن‌ها ساخته شده.یک مثال: چند سال پیش با جمعی از دوستان نویسنده‌ام ملاقات کردم و متوجه شدم همه از یک اپلیکیشن یادداشت‌برداری خاص استفاده می‌کنند، وقتی آنرا بررسی کردم دیدم بسیار ساده است و هیچ امکان خاصی ندارد. در واقع آن اپلیکیشن فقط برای نویسنده‌ها ساخته شده بود، نه دانشجوها و نه مدیران. همین باعث شده بود که نویسنده‌ها عاشقش باشند. به نظرم طراحان ویراستار «ویرگول» هم با چنین درکی این محیط ویراستاری ساده را طراحی کرده‌اند.درس سوم: بهتر است ۱۰۰ نفر عاشق محصول شما باشند تا ۱۰,۰۰۰ نفر بی‌تفاوت.اشتباه چهارم: اضافه کردن به جای حذف کردنیک الگوی تکراری: تیم رقیب یک فیچر به محصولش اضافه می‌کند. مدیران می‌بینند و می‌گویند ما هم باید آن فیچر را داشته باشیم.یک الگوی تکراری دیگر: در نظرسنجی‌هایی که از کاربران درباره محصول می‌شود، بعضی‌ها می‌گویند: “کاش فلان فیچر را داشتید.”تیم محصول بدون بررسی دقیق، مشخص کردن شاخص‌های کلیدی و ... فیچر اول، بعد دوم، بعد سوم و ... را اضافه می‌کند.یک سال بعد، محصول کلی فیچر دارد که استفاده نمی‌شوند ولی باعث ایجاد پیچیدگی در تجربه کاربری، توسعه و نگهداری فنی محصول شده‌اند.این اتفاق برای خیلی از محصولات دیجیتال می‌افتد و وقتی ریشه‌یابی می‌کنم متوجه می‌شوم که آنها تلاش کرده‌اند نیازهای همه کاربران مختلف و درخواست‌های مدیران را برطرف کنند!محصول خوب مثل یک چاقوی تیز است — یک کار را عالی انجام می‌دهد. محصول بد مثل یک چاقوی سوئیسی است — همه کار می‌کند، اما هیچ‌کدام را خوب انجام نمی‌دهد.درس چهارم: قدرت در سادگی است و یک محصول خوب حاصل انتخاب نکردن‌ها است.اشتباه پنجم: فراموش کردن هدف اصلیآخرین اشتباه، خطرناک‌ترین است: «فراموش کردن هدف اصلی»تیم‌ها با یک مشکل واقعی شروع می‌کنند. اما در مسیر، گم می‌شوند. شروع می‌کنند به فکر کردن درباره رقبا، درباره سرمایه‌گذاران، درباره متریک‌ها.و یک روز، متوجه می‌شوند دارند چیزی می‌سازند که خودشان هم نمی‌خواهند.چقدر برای شما پیش آمده که متوجه شده‌اید که همکارانتان برای نیازی که قرار است محصول شما برطرف کند از اپلیکیشن‌ها و پلتفرم‌های دیگر استفاده می‌کنند.اگر خودتان یا کارکنانتان از محصولتان استفاده نمی‌کنید، چرا انتظار دارید دیگران استفاده کنند؟درس پنجم: اگر محصول شما مشکل شما را حل نمی‌کند، احتمالاً مشکل کس دیگری را هم حل نمی‌کند.پس چه باید کرد؟این اشتباهات را همه می‌کنیم. من هم کرده‌ام. تیم‌های بزرگ هم می‌کنند.اما تفاوت بین محصول موفق و شکست‌خورده این است: سرعت یادگیری.تیم‌هایی که موفق می‌شوند، زودتر متوجه اشتباهاتشان می‌شوند. زودتر تغییر می‌کنند. زودتر می‌پذیرند که اشتباه کرده‌اند.چک‌لیست ارزیابی:روی هر مورد تعمق کنید:آیا قبل از شروع ساخت، با حداقل ۱۰ کاربر بالقوه صحبت کرده‌اید؟آیا می‌توانید در یک جمله بگویید برای چه کسی می‌سازید؟ (نه “همه”)آیا خودتان از محصولتان استفاده می‌کنید یا محصولات مشابه را ترجیح می‌دهید؟آیا هنگامیکه فیچری به محصولتان اضافه کردید دلایلتان کافی بود؟آیا می‌توانید بگویید چرا این محصول را می‌سازید؟ (بدون اینکه به رقبا اشاره کنید)اگر به بیش از دو سوال “نه” گفتید، وقت آن رسیده که یک قدم به عقب برگردید و دوباره فکر کنید.سوال برای فکر کردن:آخرین باری که روی محصولی کار کردی و بعد متوجه شدی کسی نمی‌خواهد، کی بود؟ چه چیزی باعث شد متوجه شوی؟در مقاله بعدی، درباره چیزی صحبت می‌کنیم که اکثر تیم‌ها فراموش می‌کنند: تفاوت بین ساختن محصول و حل کردن مشکل.</description>
                <category>بابک حقیقی</category>
                <author>بابک حقیقی</author>
                <pubDate>Sat, 11 Apr 2026 00:05:28 +0330</pubDate>
            </item>
                    <item>
                <title>محصول خوب را احساس می‌کنیم، نمی‌بینیم!</title>
                <link>https://virgool.io/@m_48141496/%D9%85%D8%AD%D8%B5%D9%88%D9%84-%D8%AE%D9%88%D8%A8-%D8%B1%D8%A7-%D8%A7%D8%AD%D8%B3%D8%A7%D8%B3-%D9%85%DB%8C-%DA%A9%D9%86%DB%8C%D9%85-%D9%86%D9%85%DB%8C-%D8%A8%DB%8C%D9%86%DB%8C%D9%85-agrodv7o2dw5</link>
                <description>درون محصول دیجیتال - محصول خوب را احساس می‌کنیم، نمی‌بینیم! (مقاله۱)چرا بعضی اپلیکیشن‌ها در ۳۰ ثانیه تو را نگه می‌دارند و بعضی دیگر هرگز؟یک بار یک اپلیکیشن بانکی دانلود کردم. طراحی‌اش تمیز بود. رنگ‌ها حرفه‌ای. آیکون‌ها دقیق. همه چیز سر جایش. اما سه روز بعد پاکش کردم.چرا؟ نمی‌دانستم. فقط حس می‌کردم هربار که بازش می‌کنم، یک جور خستگی به سراغم می‌آید. انگار باید برای انجام هر کار ساده‌ای، انرژی بگذارم.این تجربه‌ای است که خیلی از ما داشته‌ایم — اپلیکیشن یا وب‌سایتی که روی کاغذ خوب به نظر می‌رسد، اما در واقعیت چیزی کم دارد. آن چیزی که کم دارد، یک فیچر نیست. یک احساس است.« محصول خوب مثل درِ باز است — وقتی از آن رد می‌شوی متوجه نمی‌شوی، اما وقتی بسته باشد کاملاً حس می‌کنی. »پس محصول خوب چیست؟جواب ساده‌ای نیست. اما یک چیز قطعی است: محصول خوب را با لیست فیچرها نمی‌توان تعریف کرد. نه تعداد امکانات، نه قیمت، نه حتی زیبایی ظاهری‌اش.محصول خوب آن است که کاربر را به هدفش می‌رساند — بدون اینکه کاربر بفهمد چطور این مسیر را طی کرد! وقتی درست کار می‌کند، نامرئی است و وقتی خراب است، همه جا خودش را نشان می‌دهد.پنج ویژگی که هر محصول دیجیتال موفقی آن‌ها را دارد: نه به‌عنوان چک‌لیست فنی — بلکه به‌عنوان لایه‌هایی که روی هم، آن احساس «درستی» را می‌سازند:چک‌لیست ارزیابی محصولهر مورد را با محصولی که الان روی آن کار می‌کنید بسنجید:ارزش واقعی: کاربر بعد از استفاده، وضعیتش بهتر شده؟ یا فقط «استفاده کرده»؟وضوح: کاربر از اول می‌داند کجاست و باید چه کند؟ بدون راهنما؟تجربه بدون اصطکاک: هر قدم اضافه‌ای که کاربر باید بردارد، یک دلیل موجه دارد؟اعتماد: کاربر حس می‌کند این محصول برای او ساخته شده، نه برای کسب درآمد از او؟رشدپذیری: با بزرگتر شدن نیاز کاربر، محصول هم رشد می‌کند؟برگردیم به آن اپلیکیشن بانکی. مشکلش چه بود؟ ارزش واقعی داشت. وضوح نسبی داشت. اما اصطکاک زیاد داشت. برای انتقال وجه باید از چهار صفحه رد می‌شدم. برای دیدن موجودی باید لاگین می‌کردم حتی اگر یک دقیقه پیش لاگین کرده بودم.این‌ها تصمیم‌های طراحی بودند. یا شاید تصمیم‌های امنیتی که کسی هزینه‌شان را برای کاربر حساب نکرده بود. در هر صورت محصول شکست خورده بود. نه چون زشت بود، بلکه چون خسته‌کننده بود.« بهترین محصول‌ها آن‌هایی نیستند که بیشترین فیچر را دارند. آن‌هایی هستند که کمترین مقاومت را در مسیر کاربر ایجاد می‌کنند. »سوال برای فکر کردن:آخرین اپلیکیشنی که پاک کردی چه بود؟ دلیلت را برای خودت بنویس — جای کدام ویژگی از ۵ لایه بالا خالی بود؟در مقاله بعدی (شماره ۲) بررسی می‌کنیم: چرا اکثر محصولات دیجیتال شکست می‌خورند؟</description>
                <category>بابک حقیقی</category>
                <author>بابک حقیقی</author>
                <pubDate>Fri, 10 Apr 2026 02:40:14 +0330</pubDate>
            </item>
            </channel>
</rss>