تلهٔ گسترش بیرویهٔ دامنه: چطور به قابلیتهایی که خوب به نظر میرسند اما نیستند نه بگوییم
چیزی ساختید که کاربران دوستش دارند. حالا قابلیتهایی میخواهند که منطقی به نظر میرسند اما اپ را به ده جهت مختلف میکشانند. اینجا میگوییم چطور تصمیم بگیرید کدام درخواستها را بسازید و کدام را مؤدبانه رد کنید.
اپی منتشر کردید. کاربران سر رسیدند. و حالا صندوق ورودیتان پر از درخواستهای قابلیت است که همهشان مثل ایدههای خوبی به نظر میرسند.
«میشود خروجی به اکسل اضافه کنیم؟» منطقی است. «میشود فاکتورها خودکار فرستاده شوند؟» معقول است. «میشود با Stripe یکپارچه شویم؟» پول واقعی همانجاست. «میشود یک اپ موبایل اضافه کنی؟» همه این را میخواهند. «میشود این را برای مشتریهای خودمان وایتلیبل کنیم؟» اوه، حالا اینجا یک مدل کسبوکار هست.
هر درخواست بهتنهایی هوشمندانه به نظر میرسد. کنار هم، انگار دارید پنج محصول مختلف میسازید.
این گسترش بیرویهٔ دامنه (scope creep) است، و بیش از آنکه مشکلات فنی تا به حال از پا انداخته باشند، اپهای کوچک ساختهشده با هوش مصنوعی را از پا درمیآورد. نه به این خاطر که قابلیتها را میسازید — بلکه به این خاطر که در تلاش برای ساختنشان وقت، پول یا عقلتان ته میکشد.
چطور گسترش بیرویهٔ دامنه یک اپ کارآمد را میکشد
اتفاقی که میافتد این است. به سه درخواست اول بله میگویید چون معقول به نظر میرسند. از اپساز هوش مصنوعیتان میخواهید آنها را اضافه کند. بهجای یک هفته دو هفته طول میکشد چون هر قابلیت جدید به کد موجود برمیخورد. حالا اپی دارید که پنج کار انجام میدهد، سهتایشان را خوب و دوتایشان را همینجوری.
بعد درخواست چهارم میرسد: «میشود سطوح دسترسی مختلف داشته باشیم؟» ناگهان باید در هر صفحه از نو فکر کنید چه کسی چه چیزی را میبیند. این یک قابلیت نیست؛ این یک تغییر در معماری است. از اپساز هوش مصنوعیتان میخواهید انجامش دهد. به همهچیز دست میزند. دو هفته سه هفته میشود. اپ کندتر میشود چون به هر نما منطق اضافه کردهاید.
تا درخواست هشتم، دیگر برای کاربران اصلیتان چیز جدیدی منتشر نمیکنید چون آنقدر مشغولید که ماشینِ درخواستهای قابلیت را بچرخانید. کسانی که سه ماه پیش عاشق اپ بودند کلافهاند چون هیچکدام از چیزهایی که خواسته بودند تمام نمیشود. کسانی که درخواستهای جدید میدهند کلافهاند چون قابلیتها قرنها طول میکشند.
چیزی ساختید که کار میکرد. با تلاش برای اینکه همهچیز باشید آن را شکستید.
چارچوب تصمیمگیری
به یک دروازه نیاز دارید. هر درخواست قابلیت از سه پرسش عبور میکند:
پرسش ۱: این به این اپ تعلق دارد، یا یک اپ متفاوت است؟
اولین اپ شما یک کار را واقعاً خوب انجام میدهد. یک اپ زمانبندی، چیزها را زمانبندی میکند. یک اپ فاکتور، فاکتور صادر میکند. اینها اپهای متفاوتیاند. اگر کسی از اپ زمانبندیتان بخواهد فاکتور صادر کند، شما در حال افزودن یک قابلیت نیستید — دارید از یک اپ زمانبندی میخواهید حسابداری کند. این یک محصول متفاوت است.
یک آزمون خوب: «اگر این قابلیت را برمیداشتم و بهصورت مستقل منتشرش میکردم، مردم میخواستند بخرندش؟» اگر بله، احتمالاً به یک اپ متفاوت تعلق دارد. اگر پاسخ این است که «نه، فقط بهعنوان بخشی از آن چیز بزرگتر معنا دارد»، آنوقت دامنهٔ درستی را میسازید.
درخواستهایی مثل «با CRM ما یکپارچه شو» خواهید گرفت. معنای واقعیاش این است که «خودت CRM خودت باش». این یک اپ متفاوت است. میتوانید بعداً با یک CRM یکپارچه شوید. نمیتوانید به اندازهٔ یک CRM قابلیت اضافه کنید بدون اینکه خودتان به یک CRM تبدیل شوید.
پرسش ۲: این برای بیشتر کاربرانتان مشکلی را حل میکند، یا فقط برای همین یک نفر؟
یک مشتری عاشق اپ شماست و ایدهٔ یک قابلیت دارد. این یک مشکل واقعی است که او دارد. همچنین یک مشکل واقعی است که فقط او دارد.
اگر بیست کاربر دارید و یکی چیزی میخواهد، بررسی کنید: آیا آن نوزده نفر دیگر هم منتظر این هستند، یا فقط به ذهن این شخص رسیده؟ میتوانید مستقیم از او بپرسید: «پیش از شما، فکر کردهاید از کس دیگری بپرسید که آیا به این نیاز دارد؟» معمولاً پاسخ نه است.
این پرسش خطرناک است چون آن یک مشتری که درخواست میدهد ممکن است مهمترین مشتریتان باشد. شاید لازم باشد راضی نگهش دارید. این یک تصمیم کسبوکاری است، نه یک تصمیم محصولی. اما با چشمان باز پیش بروید: اگر چیزی برای یک مشتری بسازید، اپتان را رشد نمیدهید، بلکه دارید یک کسبوکار مشاوره راه میاندازید.
پرسش ۳: هزینهٔ این چیست و هزینهاش برای ایدهٔ اصلی چقدر است؟
همهچیز هزینهای دارد. خروجی به اکسل، زمان مهندسی برایتان هزینه دارد. به اپ شما پیچیدگی تحمیل میکند. تمرکز هزینه میبرد. بهجای یک بهینهسازی کارایی که کاربرانتان هر روز از آن گله دارند این را بسازید، یک انتخاب کردهاید.
ملموس بپرسید: «اگر این را بسازم، چه چیزی را نمیسازم؟» اگر پاسخ این است که «هیچی، وقت بینهایت داریم»، صادق نیستید. نداریم. زمان محدود است.
هزینه برای ایدهٔ اصلی اغلب نامرئی است. وقتی عمیقاً درگیر درخواستهای قابلیت هستید، نگهداری همان چیز اصلیای را که مردم بهخاطرش عاشقتان بودند رها میکنید. هسته کندتر میشود. هسته پرباگتر میشود. هسته رهاشده به نظر میرسد. و سرانجام مردم میروند چون اپی که عالی کار میکرد حالا همینجوری کار میکند و کارهایی میکند که هرگز برایشان طراحی نشده بود.
یک مثال واقعی: فرم پذیرش
کسی یک فرم سادهٔ پذیرش مشتری ساخت. مشتریها پرش میکنند، مربی بازبینیاش میکند، قرار میگذارند. این همان اپ است.
درخواست یک: «میتوانم پذیرشهای فوری را علامت بزنم؟» بله، این یک گونهٔ دیگر از جریان کار اصلی است. بسازش.
درخواست دو: «میتوانم پذیرشها را برای سوابقم به اکسل خروجی بگیرم؟» این یک قابلیت سندی است. کار اپ نیست. پذیرشها در اپ زندگی میکنند. اگر به اکسل نیاز دارند، میتوانند کپی-پیست کنند. اما باشد، خروجی شاید بهعنوان یک راحتی منطقی باشد. بسازش.
درخواست سه: «میشود پذیرشها بهصورت خودکار رویداد تقویم بسازند؟» حالا دارید زمانبندی میکنید. اپ برای پذیرش بود، نه زمانبندی. اگر کسی هر دو را میخواهد، احتمالاً یک سیستم زمانبندی واقعی میخواهد، نه یک وصلهٔ سرهمبندیشده که یکی را به دیگری بچسباند. مؤدبانه رد کن.
درخواست چهار: «میشود مربیها پیگیریِ پذیرش را از طریق پیامک بفرستند؟» حالا یک سیستم ارتباطی هستید. نه.
تا درخواست سه، به مرز رسیدهاید. اپ یعنی پذیرش. هر چیز دیگری یک اپ متفاوت است. میتوانید بعداً با آن اپها یکپارچه شوید. نمیتوانید بدون تبدیلشدن به آن اپها، آنها را اضافه کنید.
چطور نه بگوییم
سختترین بخش، خودِ گفتنش است. نمیخواهید کاربرانتان را کلافه کنید.
صادق باشید: «ایدهٔ خیلی خوبی است، اما این یک محصول متفاوت از چیزی است که اینجا میسازیم. چیزی که ما میسازیم [همان یک کار شماست]. اگر بخواهیم زمانبندی یا فاکتور یا کارهای CRM انجام دهیم، در همهشان همینجوری خواهیم بود و در هیچکدام عالی.»
اغلب مشتری درک میکند. درخواست داده چون ایده به ذهنش رسیده، نه چون دارد شما را محک میزند.
گاهی مقاومت میکنند. «اما من به هر دو نیاز دارم.» همانجاست که توصیه میکنید: از اپ زمانبندیِ واقعی استفاده کن. از اپ فاکتورِ واقعی استفاده کن. از CRM واقعی استفاده کن. بعد از این اپ برای کاری که خوب انجامش میدهد استفاده کن. این پاسخ صادقانه است.
وسوسهٔ همهچیز بودن
سختترین بخش ساختن یک محصول کوچک، نهگفتن است. نه گفتن مثل جا گذاشتن پول روی میز حس میشود. اگر آن مشتری واقعاً حاضر بود بابت هر دو پول بدهد چه؟ اگر آن قابلیت شما را ده برابر بزرگتر میکرد چه؟
شاید. اما اگر آن را منتشر نکنید، محصول دهبرابرْ بزرگتری نیستید. یک محصول نیمهتمام هستید که پنج کار را بد انجام میدهد. کسانی که عاشق هسته بودند کلافهاند. کسانی که قابلیتهای جدید را میخواستند کلافهاند. و خودتان را به گوشهای راندهاید که افزودن هر چیز جدید، یعنی اول بازنویسی پنج چیز قدیمی.
محصولهایی که رشد میکنند آنهایی هستند که یک کار را واقعاً خوب انجام میدهند، و بعد با احتیاط اضافه میکنند. از روز اول تلاش نمیکنند Salesforce باشند. آنها اپی هستند که وقتی نیاز دارید آن یک کار را انجام دهید سراغش میروید، و اپی که وقتی این کار را میکنید به سریع و قابلاتکا بودنش اعتماد دارید.
نه بگویید. از هسته محافظت کنید. این کار را بکنید، و چیزی خواهید ساخت که مردم واقعاً میخواهند از آن استفاده کنند.