راهنمای کامل ساخت محصول دیجیتال از صفر تا صد، همراه با مثال

گاهی وقت‌ها وسط یه تسک فنی سنگین، یه چیزی ته ذهنم رو قلقلک میده: اگه من بتونم تصمیم بگیرم، این فیچر بهتره کِی بره پروداکشن؟ اصلا این فیچر کاربردی و لازمه؟ کاربر دوستش داره یا فقط خودم فکر می‌کنم چیز خفنیه؟

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

به این سبک فکر کردن، تفکر پروداکتی می‌گن. یه مدل ذهنی که برای هر کسی که قراره مسئولیت یه محصول رو به‌عهده بگیره، ضروریه. فرقی نمی‌کنه CTO باشی، مدیر محصول، یا حتی دولوپری که تازه به تیم ملحق شده.

تو این مقاله قراره با هم یاد بگیریم:

• تفکر پروداکتی یعنی چی و چرا مهمه؟

• چطور از دل یه پروژه فنی، به تصمیم‌های پروداکتی برسیم؟

• پرسونای کاربر یعنی چی و چه کمکی به ما می‌کنه؟

• چطور رودمپ (Roadmap) بچینیم، Core Loop طراحی کنیم و متریک موفقیت محصول رو بسنجیم؟

• با مثال واقعی از یه فروشگاه اینترنتی که هنوز نرفته بازار ولی تیمش داره براش فکر استراتژیک می‌کنه

و همه‌چی رو با یه لحن ساده و کاربردی می‌گیم، نه با واژه‌های خشک.

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

چرا از پروژه‌های خودم مثال نمی‌زنم؟ چون هدف این مقاله اینه که مدل فکر کردن رو یاد بگیریم، نه فقط داستان یه ایده خاص رو.

تفکر پروداکتی یعنی چی؟ فرقش با فقط کد زدن چیه؟

یه روزهایی بود که فقط کد می‌زدیم. یه تسک می‌اومد تو تسک‌بورد، می‌دیدی که نوشته مثلاً:

امکان آپلود فایل اکسل برای محصولات اضافه بشه

بعد هم شروع می‌کردی یه پکیج نصب کردی، روت، کنترلر، ریکوئست فایل و سایر فایل‌های منطبق با پروژه رو نوشتی، تستش کردی و تمام.

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

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

تفکر پروداکتی یعنی چی؟

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

در واقع میشه گفت محصول روی چرایی تاکید داره و تکنیکال روی چگونگی.

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

مثال از دیجینورم

تیم فنی یه تسک گرفتن: فیلتر محصولات بر اساس نوع تغذیه (مثلاً گیاه‌خوار، وگان، بدون گلوتن)

حالا تفاوت دو مدل فکر رو ببین:

پس تفاوت کجاست؟

آیا باید حتماً مدیر محصول باشی که اینطوری فکر کنی؟

نه، ولی اگه می‌خوای یه CTO خوب باشی، یا می‌خوای تو استارتاپت تصمیم‌ساز بشی، باید این مدل فکر کردن رو یاد بگیری.
یادت باشه: کسی که فقط کد بلده، همیشه بهش دستور داده می‌شه.
ولی کسی که محصول رو می‌فهمه، خودش هم تصمیم‌گیرنده‌ست.

سوال‌هایی که یه آدم پروداکت‌فکر از خودش می‌پرسه:

• چرا این فیچر اصلاً باید ساخته بشه؟

• کاربر کیه؟ الان چی داره اذیتش می‌کنه؟

• آیا این فیچر مشکل واقعی رو حل می‌کنه یا فقط یه ایده‌ی قشنگه؟

• اگه این فیچر ساخته نشه، کاربر چی رو از دست می‌ده؟

• موفقیت این فیچر با چی سنجیده می‌شه؟ (کدوم متریک؟)

جمع‌بندی بخش اول

تفکر پروداکتی یه مهارت یک شبه نیست. اما از همین امروز می‌تونی تو تیم خودت این سؤال‌ها رو بپرسی، قبل از اینکه کدتو بنویسی و پوش (push) کنی.

مخصوصا وقتی یه پروژه هنوز نرفته بازار (مثل فروشگاه دیجینورم)، تو بهترین زمان برای شکل دادن به محصول هستی. حالا نوبت توئه که فقط کدنویس نباشی، بلکه طراح تجربه هم باشی.

این سوالات یه مفهوم آشنا رو به یادت نمیاره؟ آره، منظورم پرسونای کاربره.

پرسونا چیه؟ چرا باید از دید کاربر به محصول نگاه کنیم؟

فرض کن داری برای فروشگاه دیجینورم یه فیچر طراحی می‌کنی:

پیشنهاد غذای سالم برای سبد خرید کاربران بر اساس سابقه خریدشون

ایده باحاله، فنی هم جذابه. ولی یه سوال اساسی این وسطه:

این فیچر دقیقاً برای کیه؟

اگه جوابش این باشه: «واسه همه کاربرا»، بدون که داری راهو اشتباه میری. چون هیچ فیچری "برای همه" نیست.
تو باید بدونی که اون آدمی که قراره از این فیچر استفاده کنه، چه زندگی‌ای داره، دغدغه‌ش چیه، و اصلاً چرا اومده سراغ فروشگاه تو.

پرسونا یعنی چی؟

پرسونا یعنی یه نمایه خیالی اما واقعی از یه کاربر هدف.

انگار داری یه شخصیت خلق می‌کنی که می‌تونه نماینده‌ی صدها یا هزاران نفر از مشتری‌هات باشه.

نه صرفاً یه دیتاپوینت مثل سن و جنسیت، بلکه یه انسان با رفتار، احساس، نیاز، انگیزه، و حتی ترس!

چرا ساختن پرسونا مهمه؟

چون تا وقتی ندونی داری برای کی می‌سازی، نمی‌تونی تصمیم بگیری:

• این فیچر اصلاً لازمه یا نه؟

• توی چه لحظه‌ای از سفر کاربر باید نشونش بدی؟

• چطوری باید UI و متن و زمان‌بندی‌ش باشه؟

• اصلاً انتظار چه تعاملی ازش داریم؟

مثال از فروشگاه دیجینورم

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

پرسونا ۱: علیرضا، کارمند مجرد

پس چی یاد گرفتیم؟
برای علیرضا، ما باید:

• دسته‌بندی آماده ولی سالم بسازیم

• توی صفحه اصلی یا سبد خریدش، غذاهای آماده پیشنهاد بدیم

• تایم نوتیفمون باید بعد ساعت کاری باشه (مثلاً ۱۸ تا ۲۰)

پرسونا ۲: نسترن، مادر دو فرزند

نتیجه؟
برای نسترن، بهتره:

• پیشنهادهای سبد خانواده با تخفیف نشون بدیم

• محتوای آموزشی سبک مثل چی بخوریم که هم بچه‌ها بخورن هم سالم باشه براش بفرستیم

• توی تجربه خرید، از اصطلاحات پیچیده تغذیه‌ای استفاده نکنیم

پرسونا ۳: کیوان، ورزشکار منظم

چی درمیاد از این؟
برای کیوان لازمه:

• فیلتر دقیق برای «پروتئین بالا»، «بدون قند»، «بدون لاکتوز» بسازیم

• مقایسه محصولات با هم فراهم کنیم (مثلاً بین دو برند کره بادام زمینی)

• رابط کاربری اَپِمون یه حس تخصصی بهش بده، نه فقط عام‌پسند

پس چی شد؟

وقتی این سه پرسونا رو داشته باشیم:

• می‌دونیم هر فیچر برای کی ساخته می‌شه

• طراحی‌ها هدف‌دارتر می‌شن

• تبلیغات هدفمندتری اجرا می‌شن

• تیم فنی بهتر می‌فهمه چطور تست کنه یا اولویت بده

در بخش بعدی مقاله، می‌ریم سراغ ساختار تصمیم‌گیری حرفه‌ای با ابزارهایی مثل:

• رودمپ

• Core Loop

• متریک ستاره شمالی (North star Metric)

که همش از دل همین پرسونای بالا درمیاد.

از پرسونا تا تصمیم‌گیری – چطوری رودمپ، کور لوپ و متریک ستاره شمالی رو بچینیم؟

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

بریم سراغ ابزارهایی که هر تیم فنی-محصولی باید بلد باشه و استفاده کنه:

رودمپ چیه و چرا باید داشته باشیم؟

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

اما فرق یه رودمپ خوب با یه لیست فیچر چیه؟

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

نمونه رودمپ سه‌ماهه برای دیجینورم

ماه اول: زیرساخت و هسته اولیه

• ساخت سیستم ورود / ثبت‌نام با موبایل

• طراحی صفحه لیست محصولات

• ساخت سبد خرید اولیه

• اضافه کردن برچسب‌ محصولات (پروتئین بالا، بدون شکر، و...)

هدف: آماده‌سازی ساختار پایه برای نمایش و خرید محصول، هماهنگ با نیاز کیوان (پرسونای ورزشکار)

ماه دوم: بهبود تجربه کاربر

• سیستم پیشنهاد هوشمند (بر اساس دسته‌بندی یا سابقه خرید)

• اضافه کردن فیلتر پیشرفته برای محصولات خاص

• شروع نوتیف‌های شخصی‌سازی‌شده (پیشنهاد امروز، تخفیف شخصی)

هدف: پاسخ به نیاز علیرضا و نسترن که دنبال پیشنهاد و راحتی هستن

ماه سوم: وفادارسازی و رشد

• اضافه‌کردن برنامه وفاداری یا تخفیف پلکانی

• امکان ثبت آدرس متعدد و خرید سریع

• راه‌اندازی کمپین دعوت از دوستان

هدف: رشد ارگانیک با حفظ کاربران فعلی + افزایش تعامل

چطور اولویت‌گذاری کنیم؟

برای هر فیچر توی رودمپ، از خودت بپرس:

• این فیچر به کدوم پرسونا کمک می‌کنه؟

• چه مشکلی رو براش حل می‌کنه؟

• بعد از پیاده‌سازی این فیچر، چه رفتاری از کاربر انتظار داریم؟

• می‌تونیم نتیجه‌ش رو اندازه‌گیری کنیم یا نه؟

Core Loop چیه و چطوری طراحی‌ش کنیم؟

Core Loop همون چیزیه که باعث می‌شه کاربر دوباره و دوباره برگرده سراغ محصول. یه چرخه‌ی ساده اما اثرگذار از تجربه.

مثالی از دیجینورم:

Core Loop پیشنهادی:

1. کاربر محصولی می‌خره

2. براساس خریدش، محصولات مشابه یا مکمل پیشنهاد داده می‌شه

3. تخفیف کوچیکی برای خرید بعدی می‌گیره

4. میاد دوباره می‌خره

و این چرخه ادامه پیدا می‌کنه.

مثال از پرسونا:

• نسترن وقتی خریدشو تموم می‌کنه، تو صفحه «تشکر از خرید» یه پیشنهاد «سبد تغذیه خانواده برای هفته آینده» می‌بینه

• چون از پیشنهاد خوشش میاد و تخفیف ۱۰٪ هم داره، می‌ره سراغ خرید بعدی

نتیجه؟
کاربر با هر خرید، یه حلقه جدید از تعامل رو شروع می‌کنه.

متریک ستاره شمالی چیه؟

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

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

اشتباه رایج:

خیلیا فکر می‌کنن تعداد ثبت‌نام کاربر یا بازدید از سایت متریک خوبیه.

اما یه NSM واقعی اونیه که ارزش محصولت رو منعکس کنه.

برای دیجینورم چی می‌تونه باشه؟

تعداد سبدهای خرید کامل‌شده در ماه که شامل حداقل یک محصول سالم پیشنهادی هستن

چرا این خوبه؟

• فقط بازدید یا ورود نیست، یعنی کاربر داره خرید می‌کنه

• فقط خرید نیست، یعنی داره پیشنهادهای سالم رو می‌پذیره

• مستقیم نشون می‌ده محصول داره چطور رفتار خرید سالم رو جا می‌ندازه

چند مثال دیگه برای درک بهتر:

جمع‌بندی

• رودمپ خوب یعنی بدونی چی رو کی و چرا می‌سازی

• Core Loop یعنی ایجاد رفتار تکرارشونده و وابسته

• ستاره شمالی یعنی بدونی موفقیت واقعی محصولت با چی سنجیده می‌شه

این سه ابزار، ستون فقرات تفکر پروداکتی هستن.

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

متریک‌های شکست، ریزش کاربر (Churn)، و اینکه چطوری محصول رو بهتر کنیم قبل از اینکه دیر بشه.

ریزش کاربر، متریک‌های هشدار و اصلاح محصول قبل از سقوط

یکی از بزرگ‌ترین توهم‌های پروداکتی اینه که چون کاربر اومده، پس مونده!

نه عزیز، اومدن مهم نیست، موندن مهمه.
و اینجا دقیقاً جاییه که متریک‌های Retention و Churn میان وسط.

Churn Rate چیه؟

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

اگه یه کاربر ثبت‌نام کنه ولی هیچ‌وقت خرید نکنه، یا یه بار خرید کنه ولی دیگه وارد اپ نشه، این یعنی Churn.

Retention Rate چیه؟

ریتِنشن یعنی بازگشت کاربر یا به زبون ساده یعنی اینکه تونستی کاربر رو نگه داری و کاملا برعکس Churn است.
یعنی چند درصد از کاربرهایی که روز اول اومدن، روز ۷ هم باهاتن؟ روز ۳۰ چی؟ روز ۹۰؟

مثالی از دیجینورم:

فرض کن در ماه اول ۱۰۰۰ نفر ثبت‌نام کردن.

این یعنی ۹۱۰ نفر دیگه برنگشتن! تازه شاید از اون ۹۰ نفر هم فقط ۲۰ تا خرید انجام داده باشن.

چرا کاربرها ریزش می‌کنن؟

دلایلش خیلی گسترده‌ست ولی معمولاً به یکی از این ۵ مورد برمی‌گرده:

1. ارزش واقعی محصول رو دریافت نکردن

2. UI/UX پیچیده یا گیج‌کننده بوده

3. زمان مناسبی وارد تعامل نشدن

4. فیچرها با نیازشون هم‌راستا نبوده

5. رقیب دیگه‌ای تجربه‌ی بهتری ارائه داده

چطوری ریزش رو اندازه‌ بگیریم؟

یکی از ابزارهای خوب برای این کار Cohort Analysis یا آنالیز کوهورت هست.

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

مثال آنالیز کوهورت برای دیجینورم:

این جدول نشون می‌ده که تو هفته دوم، وضعیت retention بدتر شده. شاید آپدیتی زدی که تجربه‌ی کاربری رو بدتر کرده؟ یا تبلیغاتی کردی که آدمای اشتباهی رو جذب کرده؟

نکته: جدول بالا میگه که مثلا ۱۴ روز بعد از هفته اول ۱۸۰ نفر و ۱۴ روز بعد از هفته دوم ۱۲۰ نفر بازگشت داشتیم.

چه متریک‌هایی باید دائم چک بشن؟ (متریک‌های هشدار)

چطور جلوی Churn رو بگیریم؟

1. آنبوردینگ ساده و هدایت‌شده بساز

   • تو روز اول، کاری نکن کاربر فقط بگرده. هدایتش کن به یه موفقیت کوچیک.

2. پیشنهادهای شخصی‌سازی‌شده بده

   • همون پرسوناها رو یادت هست؟ فیچرها رو با توجه به اون طراحی کن.

3. نوتیف هوشمند و به‌موقع بفرست

   • نه زیاد، نه دیر. نه کلی، نه عمومی.

4. استفاده از تخفیف یا امتیاز برای برگشت

   • کسی که ۷ روز نیومده، براش یه کد تخفیف ۲۴ ساعته بفرست

5. بازخورد واقعی بگیر

   • ساده‌ترین راه: یه فرم یا یه نوتیف بفرست که بپرسه: "چرا دیگه نیومدی؟ چی اذیتت کرد؟"

مثال نهایی از دیجینورم:

علیرضا (پرسونا اول)، هفته‌ی اول ثبت‌نام کرده ولی هیچ خریدی نکرده.
آنالیز کوهورت نشون می‌ده که ۷۰٪ کسایی که مثل علیرضا خرید نکردن، هیچ‌وقت هم برنگشتن.

راه‌حل؟
یه نوتیف (نوتیف اپلیکیشن موبایل یا SMS)‌ با این متن:

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

نتیجه‌گیری

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

مسیر تبدیل شدن به یک CTO با ذهن پروداکتی (جمع‌بندی + دستورالعمل عملیاتی)

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

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

۱. ذهنیت پروداکتی چیه؟ یادمون نره...

• همیشه بپرس «چرا؟» قبل از اینکه بپرسی «چطور؟»

• بدون که کار تو فقط تحویل کد نیست؛ تو داری یه تکه از تجربه‌ی کاربر رو می‌سازی

• به جای “فیچرزدن”، دنبال “حل مسئله” باش

• همه‌ی کارهات باید یه “پرسونا” پشتش باشه. اگه نباشه، داری برای خلا می‌سازی

• اولویت بده به چیزی که باعث رفتار واقعی می‌شه، نه فقط «قشنگ به نظر میاد»

۲. دستورالعمل عملیاتی برای ساخت محصول درست

۳. مهارت‌هایی که باید جدی یاد بگیری

اینا چیزاییه که یه CTO یا محصول‌ساز واقعی بهشون نیاز داره:

• Behavioral Design: چطور عادت ایجاد کنی؟

• Product Metrics: با عدد حرف بزن، نه فقط حس

• User Research: بفهم کاربر چی می‌خواد، نه اینکه فقط فکر کنی می‌دونی

• Prioritization Techniques: یاد بگیر چی رو کی و چرا انجام بدی (مثلاً RICE یا MoSCoW)

• Storytelling: بتونی تصمیماتت رو برای تیم، مدیر یا سرمایه‌گذار توضیح بدی

۴. ضدالگوهایی که باید حواست باشه

۵. تمرین‌هایی برای تقویت تفکر پروداکتی

این تمرین‌ها رو برای خودم هم نوشتم، چون یادگیری‌اش دائمیه:

1. هر فیچری که نوشتی رو با پرسونا تطبیق بده. اگه جواب نداشتی برای "این به درد کی می‌خوره؟" فیچر رو متوقف کن.

2. هر هفته یک بار جلسه تحلیل رفتار کاربر بذار. حتی اگه فقط یه کاربر، یه ایمیل فرستاده.

3. هر تسک فنی جدید، باید یه متریک خروجی داشته باشه. مثلاً انتظار داری بعدش نرخ خرید بره بالا؟ زمان موندن کاربر افزایش پیدا کنه؟

4. با تیم غیرفنی صحبت کن. مارکتینگ، پشتیبانی، فروش... اونا خط مقدم تعامل با کاربرن.

5. فیچرهایی که استفاده نمی‌شن رو حذف کن. این نشونه بلوغه. نه ضعف.

نتیجه‌گیری

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

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

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

کتاب Inspired از Marty Cagan: این کتاب با نام الهام بخش توسط انتشارات هورمزد ترجمه و چاپ شده

کتاب Lean Product & Lean Analytics

پادکست‌های Lenny’s Podcast یا Product Thinking

یا راهنمای عملی Reforge سر بزنید

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