# Jobs to Be Done چیست؟ چرا پرسونا برای شناخت مشتری کافی نیست؟ [منبع]() مدرس: سجاد ده شیری **Jobs to Be Done یا JTBD روشی برای نگاه‌کردن به مشتری از زاویه کاری هست که می‌خواهد انجام دهد و پیشرفتی که در یک موقعیت مشخص دنبال می‌کند\.** پرسونا ممکن هست به تو بگوید مشتری چند سالش هست، چه شغلی دارد، کجا زندگی می‌کند یا معمولاً از چه کانالی استفاده می‌کند\. این اطلاعات برای شناخت بازار، انتخاب کانال ارتباطی و حتی لحن محتوا می‌توانند مفید باشند\. اما وقتی یک مشتری واقعی روبه‌رویت نشسته و می‌خواهی بفهمی **چرا باید از تو خرید کند**، این اطلاعات به‌تنهایی کافی نیستند\. ممکن هست دو مشتری تقریباً یک پرسونای مشابه داشته باشند، اما برای انجام دو کار کاملاً متفاوت سراغ یک خدمت بیایند\. اینجا سؤال مهم دیگر این نیست که: **«این مشتری چه کسی هست؟»** بلکه باید بپرسی: **«این مشتری در این موقعیت دقیقاً می‌خواهد چه پیشرفتی ایجاد کند؟»** ## چرا پرسونا همیشه دلیل خرید را توضیح نمی‌دهد؟ فرض کن دو صاحب فروشگاه اینترنتی تقریباً هم‌سن هستند، کسب‌وکار مشابهی دارند و حتی از یک نرم‌افزار فروشگاهی استفاده می‌کنند\. از نظر پرسونا شاید خیلی شبیه هم باشند\. اما یکی ممکن هست دنبال راهی باشد که **گزارش فروش پایان ماه را سریع‌تر آماده کند** و دیگری بخواهد **فرایند آماده‌سازی و ارسال سفارش‌ها کمتر به نیروی انسانی وابسته باشد\.** محصولی که هر دو استفاده می‌کنند یکسان هست، اما کاری که تلاش می‌کنند انجام دهند یکسان نیست\. اگر فقط به مشخصات ظاهری مشتری نگاه کنی، این تفاوت مهم دیده نمی‌شود\. JTBD تلاش می‌کند همین لایه را پیدا کند: **مشتری چه تغییری می‌خواهد در وضعیت فعلی خودش ایجاد کند؟** ## مشتری محصول نمی‌خرد؛ برای انجام یک کار راه‌حل انتخاب می‌کند یکی از ایده‌های اصلی Jobs to Be Done این هست که مشتری محصول یا خدمت را به‌خاطر خود آن انتخاب نمی‌کند\. آن را وارد زندگی یا کسب‌وکارش می‌کند تا **به او کمک کند کاری را بهتر انجام دهد یا از وضعیت فعلی به وضعیت مطلوب‌تری برسد\.** فرض کن مشتری از تو می‌خواهد قابلیتی برای تولید خودکار برچسب مرسوله بسازی\. اگر فقط درخواست را ببینی، مسئله خیلی ساده به نظر می‌رسد: **«یک دکمه برای ساخت برچسب اضافه کن\.»** اما این هنوز Job نیست\. شاید مشتری هر روز برای آماده‌کردن سفارش‌ها زمان زیادی تلف می‌کند\. شاید هنگام واردکردن دستی اطلاعات اشتباه رخ می‌دهد\. شاید در ساعت‌های شلوغ، آماده‌سازی سفارش‌ها به گلوگاه کسب‌وکارش تبدیل شده\. در این حالت قابلیت «تولید خودکار برچسب» فقط **راه‌حل** هست\. برای فهم ارزش واقعی آن باید بفهمی مشتری با این قابلیت می‌خواهد **چه پیشرفتی ایجاد کند\.** ## چهار لنز عملی برای فهم Job مشتری در این جلسه برای اینکه Jobs to Be Done فقط یک مفهوم تئوری باقی نماند، از چهار زاویه عملی به مسئله نگاه می‌کنیم\. این چهار مورد تمام اجزای رسمی JTBD نیستند؛ یک چارچوب ساده هستند تا هنگام صحبت با مشتری راحت‌تر بتوانی از درخواست ظاهری عبور کنی و به مسئله واقعی نزدیک شوی\. ### موقعیت؛ مشتری چه زمانی و در چه شرایطی این کار را انجام می‌دهد؟ یک Job بدون موقعیت می‌تواند بیش از حد کلی باشد\. «گزارش فروش می‌خواهم» اطلاعات زیادی به ما نمی‌دهد\. اما وقتی بفهمیم مشتری **پایان هر ماه، قبل از جلسه حسابداری، باید فروش چند کانال را کنار هم قرار دهد**، مسئله روشن‌تر می‌شود\. موقعیت می‌تواند روی چیزی که مشتری واقعاً نیاز دارد اثر زیادی بگذارد\. یک قابلیت ممکن هست در شرایط عادی اهمیت کمی داشته باشد اما در یک موقعیت خاص تبدیل به بخش حیاتی تجربه مشتری شود\. به همین دلیل باید بفهمی: **این نیاز دقیقاً چه زمانی خودش را نشان می‌دهد؟** ### کار اصلی؛ مشتری واقعاً می‌خواهد چه چیزی را تمام کند؟ درخواست مشتری همیشه همان Job اصلی نیست\. مشتری ممکن هست بگوید: **«برای من خروجی اکسل بگذار\.»** اما خروجی اکسل احتمالاً هدف نهایی او نیست\. ممکن هست هدف واقعی این باشد که بتواند گزارش پایان ماه را بدون چند ساعت جمع‌آوری و مرتب‌کردن دستی اطلاعات تحویل دهد\. اگر فقط چیزی را که مشتری درخواست کرده بسازی، شاید Feature درستی تحویل بدهی اما **Job اصلی را کامل حل نکنی\.** سؤال بهتر این هست: **اگر این قابلیت را داشته باشد، مشتری با کمک آن دقیقاً چه کاری را می‌تواند تمام کند؟** ## نتیجه قابل‌حس؛ مشتری از کجا می‌فهمد کار بهتر شده؟ «بهبود تجربه»، «کارایی بیشتر» یا «فرایند بهتر» جمله‌های جذابی هستند، اما برای شناخت مشتری هنوز خیلی مبهم‌اند\. باید بفهمی نتیجه مطلوب مشتری چه شکلی هست\. مثلاً: **زمان کمتر** **خطای کمتر** **خروجی بیشتر** **ریسک پایین‌تر** **مراحل کمتر** هرچه بتوانی نتیجه را مشخص‌تر کنی، بهتر می‌فهمی مشتری چگونه موفقیت را قضاوت می‌کند\. در مثال گزارش فروش، شاید مسئله این نباشد که «گزارش‌گیری راحت‌تر شود»\. ممکن هست مشتری بخواهد کاری که الان یک ساعت طول می‌کشد، در چند دقیقه انجام شود\. این تفاوت مهم هست؛ چون حالا درباره یک **نتیجه قابل‌درک برای مشتری** حرف می‌زنیم، نه یک صفت کلی\. ## محدودیت و شرط؛ راه‌حل تحت چه شرایطی باید کار کند؟ گاهی خود Job را درست فهمیده‌ای، اما راه‌حل هنوز برای مشتری مناسب نیست چون یک محدودیت مهم را ندیده‌ای\. مثلاً مشتری می‌خواهد کاری انجام شود: **بدون آموزش پیچیده، بدون استخدام نیروی جدید، با بودجه مشخص، در حجم مشخص، یا بدون تغییر کل فرایند فعلی\.** این محدودیت‌ها حاشیه‌ای نیستند\. گاهی دقیقاً همان چیزی هستند که تعیین می‌کنند مشتری یک راه‌حل را انتخاب کند یا کنار بگذارد\. برای همین فقط نباید بپرسی: **«مشتری چه می‌خواهد؟»** باید بفهمی: **«تحت چه شرایطی حاضر هست این راه‌حل را بپذیرد؟»** ## Job را با Feature اشتباه نکن یکی از رایج‌ترین خطاها این هست که Feature را به‌جای Job بنویسیم\. مواردی مثل: **خروجی اکسل، چاپ خودکار برچسب، داشبورد مدیریتی یا اعلان پیامکی** همگی می‌توانند قابلیت باشند\. اما هیچ‌کدام به‌تنهایی توضیح نمی‌دهند مشتری واقعاً چه کاری می‌خواهد انجام دهد\. برای هر Feature باید بتوانی یک قدم عقب‌تر بروی و بپرسی: **«این قابلیت قرار هست به مشتری کمک کند چه کاری را بهتر انجام دهد؟»** اگر پاسخ این سؤال را ندانی، احتمال دارد چیزی بسازی که از نظر فنی کاملاً درست هست اما ارزش زیادی برای مشتری ایجاد نمی‌کند\. ## Jobs to Be Done جای پرسونا را کاملاً نمی‌گیرد هدف این جلسه این نیست که پرسونا را بی‌ارزش بدانیم\. پرسونا و اطلاعات جمعیت‌شناختی هنوز می‌توانند برای شناخت بازار، انتخاب کانال ارتباطی، طراحی پیام و تقسیم‌بندی مخاطبان مفید باشند\. اما برای پاسخ به سؤال **«چرا این مشتری در این موقعیت این راه‌حل را انتخاب می‌کند؟»** معمولاً باید عمیق‌تر برویم\. JTBD یک لایه دیگر به شناخت مشتری اضافه می‌کند: به‌جای تمرکز صرف روی اینکه **مشتری چه کسی هست**، روی این تمرکز می‌کنیم که **چه پیشرفتی می‌خواهد ایجاد کند و چه شرایطی روی تصمیم او اثر می‌گذارد\.** این دو نگاه می‌توانند کنار هم استفاده شوند، نه اینکه الزاماً یکی جای دیگری را بگیرد\. ## چرا شناخت Job فروش را هم ساده‌تر می‌کند؟ وقتی Job واقعی مشتری را بفهمی، دیگر مجبور نیستی برای فروش تمام قابلیت‌های محصول یا تمام مهارت‌هایت را توضیح بدهی\. می‌توانی روی همان چیزی تمرکز کنی که برای این مشتری اهمیت دارد\. اگر مسئله او کاهش زمان آماده‌سازی سفارش‌ها هست، لازم نیست ده قابلیت دیگر سیستم را توضیح بدهی\. اگر نگرانی اصلی او خطای انسانی هست، ارزش پیشنهادی تو باید همین مسئله را هدف بگیرد\. **شناخت بهتر Job باعث می‌شود درباره چیزی حرف بزنی که مشتری خودش برای آن اهمیت قائل هست\.** این همان نقطه‌ای هست که شناخت مشتری، ارزش پیشنهادی و فروش به هم وصل می‌شوند\. ## Job واقعی را از روی حدس ننویس یکی از خطرهای JTBD این هست که پشت میز بنشینی و تصور کنی دقیقاً می‌دانی مشتری چه می‌خواهد\. عبارت‌هایی که در ابتدا می‌نویسی فقط **فرضیه** هستند\. برای نزدیک‌شدن به Job واقعی باید سراغ اتفاقی بروی که در زندگی یا کسب‌وکار مشتری رخ داده، موقعیت را بفهمی و درباره چیزی که قبل از تصمیم خرید اتفاق افتاده سؤال کنی\. در ویدیوی این جلسه با مثال‌های عملی می‌بینی چطور از یک درخواست ظاهری عبور کنیم و با استفاده از **موقعیت، کار اصلی، نتیجه قابل‌حس و محدودیت‌ها** تصویر دقیق‌تری از چیزی بسازیم که مشتری واقعاً می‌خواهد انجام دهد\. ## در این جلسه چه چیزی یاد می‌گیری؟ در پایان این جلسه باید بتوانی بین **پرسونا، Feature و Job واقعی مشتری** تفاوت بگذاری\. یاد می‌گیری به‌جای متوقف‌شدن روی مشخصات مشتری یا چیزی که در اولین جمله درخواست کرده، چهار سؤال مهم‌تر را بررسی کنی: در چه موقعیتی قرار دارد؟ دقیقاً چه کاری می‌خواهد انجام دهد؟ چه نتیجه‌ای برایش اهمیت دارد؟ و راه‌حل تحت چه محدودیت‌هایی باید کار کند؟ این نگاه کمک می‌کند درخواست‌های مشتری را بهتر بفهمی و راه‌حلی پیشنهاد بدهی که به مسئله واقعی او نزدیک‌تر باشد\. اما وقتی چند Job، Pain، Gain و درخواست مختلف پیدا کردی، یک سؤال جدید ایجاد می‌شود: **کدام‌یک مهم‌تر هست و باید اول سراغ کدام بروی؟** جلسه بعد دقیقاً درباره همین مسئله هست؛ اولویت‌بندی درخواست‌های مشتری به شکلی که فقط بر اساس حدس و احساس تصمیم نگیری\. [دوره]()