درخواست قابلیتی که واقعاً باید بسازید (و چطور تشخیصش دهید)

همهٔ درخواست‌های قابلیت یکسان آفریده نشده‌اند. بعضی اپتان را بهتر می‌کنند. بعضی شما را مشهور می‌کنند. بعضی تا ابد حواستان را پرت می‌کنند. این هم روش تشخیص آن‌هایی که واقعاً اهمیت دارند.

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

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

کدام سه تا؟

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

سیگنال‌هایی که اهمیت دارند

سیگنال ۱: تکرار خودانگیخته

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

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

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

سیگنال ۲: راه‌حل دور‌زدن اهمیت دارد

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

اما آن‌ها می‌مانند، که یعنی برای استفاده از اپتان به آن قابلیت نیاز ندارند. برای استفادهٔ بهتر از اپتان به آن نیاز دارند. این با یک مانع فرق دارد.

قابلیت‌هایی که بیش از همه اهمیت دارند آن‌هایی‌اند که اصلاً مانع استفادهٔ مردم از اپتان می‌شوند. قابلیت‌هایی که خوب است داشته باشید آن‌هایی‌اند که مردم دورشان می‌زنند.

به این توجه کنید که کدام درخواست‌ها مانع‌اند. کسی می‌گوید «تا وقتی X را انجام ندهی نمی‌توانم از این استفاده کنم» در برابر کسی که می‌گوید «خیلی خوب می‌شد اگر X را داشتی». آن تمایز طلاست.

سیگنال ۳: قابلیت با مدل کسب‌وکار همراه می‌شود

بعضی قابلیت‌ها راه‌های کاملاً جدیدی برای کسب درآمد باز می‌کنند. «برای مشتری‌هایم فاکتور بفرست» مدل کسب‌وکاری را باز می‌کند که در آن بابت فاکتورسازی هزینه می‌گیرید. «خروجی به Salesforce» درآمد یکپارچه‌سازی را باز می‌کند. «برچسب‌سفید برای فروشندگان مجدد» یک کانال شریک را باز می‌کند.

اما ترفند اینجاست: نمی‌دانید آن مدل‌ها کار می‌کنند یا نه تا وقتی که از قبل دارید عرضه می‌کنید. نمی‌توانید حول آن‌ها برنامه‌ریزی کنید. فقط می‌توانید بعد از عرضه و دیدن اینکه مردم واقعاً ازشان استفاده می‌کنند، متوجهشان شوید.

موفق‌ترین قابلیت‌های اضافه‌شده آن‌هایی‌اند که عرضهٔ قابلیت بازاری را آشکار می‌کند که نمی‌دانستید وجود دارد. شما خروجی ساختید. معلوم می‌شود شرکت‌ها می‌خواهند خروجی شما را در جریان کاری‌شان جاسازی کنند. حالا یک داستان یکپارچه‌سازی دارید که برنامه‌ریزی‌اش نکرده بودید.

قابلیت‌ها را بسازید چون کاربرانتان به آن‌ها نیاز دارند. بعد تماشا کنید ببینید آیا کاربرانتان به شیوه‌ای به آن‌ها نیاز دارند که کسب‌وکار جدیدی می‌سازد. اول مدل کسب‌وکار را پیش‌بینی نکنید.

سیگنال ۴: درخواست برای کمک

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

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

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

اول با آزمایش‌کننده‌ها بسازید. هر چیز دیگری ثانوی است.

وسوسهٔ ساختن قابلیت پرستیژی

هر محصولی یک قابلیت دارد که اگر عرضه‌اش کنید، شما را تأثیرگذارتر جلوه می‌دهد. برای اپ‌های زمان‌بندی، یکپارچه شدن با Calendly است. برای اپ‌های کار، یکپارچه شدن با Slack است. همه می‌دانند آن‌ها چه‌اند. همه آن‌ها را می‌خواهند.

اما نکته اینجاست: همه دارند آن‌ها را از یک نفر دیگر هم می‌گیرند. اگر قابلیت شما بهترین و آسان‌ترین یکپارچگی با Slack نباشد، فقط به اپتان پیچیدگی اضافه می‌کند بدون اینکه شما را مشهور کند.

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

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

چطور واقعاً تصمیم بگیرید

وقتی دسته‌ای از درخواست‌های قابلیت دارید که همه از آزمون «آیا این در دامنه است؟» می‌گذرند، آن‌ها را بر اساس این‌ها رتبه‌بندی کنید:

  1. چند کاربر (مستقل) خواسته‌اند؟ بیشتر بهتر است.
  2. این یک مانع است یا خوب-است-داشته‌باشیم؟ موانع فوری‌ترند.
  3. آیا کاربرانتان امروز می‌توانند این را دور بزنند؟ اگر نه، مهم‌تر است.
  4. آیا کسی به شما در آزمایش این کمک می‌کند؟ اگر بله، اول این را بسازید.
  5. آیا این بازاری جدید را آشکار می‌کند؟ اگر شاید، آن یک امتیاز است، نه یک دلیل.

بعد به همان ترتیب بسازید. نه ترتیب تأثیرگذار-به-نظر-رسیدن. نه ترتیب بزرگ‌ترین مشتری‌تان. ترتیب سیگنال واقعی از مردمی که از اپتان استفاده می‌کنند.

قابلیتی که نمی‌سازید (فعلاً)

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

آن صداقت بیش از آنچه فکر می‌کنید اهمیت دارد. کاربران ترجیح می‌دهند بدانند که قرار نیست انجامش دهید تا اینکه شش ماه منتظر بمانند و امیدوار باشند.

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

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