شهریور
Opsless و آینده کار
Category Creation؛ درسهایی از Salesforce، HubSpot و Snowflake
هر چند سال یکبار یک شرکت پیدا میشود که بهجای رقابت در بازاری موجود، اسم یک بازار تازه را روی تخته مینویسد و بعد شرکتهای دیگر را هم به همان بازار دعوت میکند. این کار ریسک بسیار بالاتری از رقابت معمولی دارد، چون مشتری باید هم مسئله را باور کند و هم راهحل را؛ اما وقتی جواب میدهد، برنده معمولاً برای یک دهه اسم آن بازار میشود. Salesforce، HubSpot و Snowflake هر سه همین کار را کردند و هرکدام مسیر متفاوتی برای رسیدن به آن رفتند. تز Opsless و wedge اول آن یعنی CRMless، دقیقاً در همین نقطه ایستاده است: نه رقابت در CRM موجود، بلکه ادعای اینکه اصلاً «باز کردن یک نرمافزار برای ثبت کار» دیگر لازم نیست.
لیست مطالب
Salesforce؛ شعار بهجای فیچر
Salesforce در سالهای اول کار خودش، تقریباً هیچ برتری فنی چشمگیری نسبت به Siebel نداشت. چیزی که فروخت یک شعار بود: «No Software». این شعار دقیقاً روی درد نصب، سرور، و آپدیت دستی نرمافزارهای on-premise انگشت گذاشت. نکتهی کلیدی اینجاست که Salesforce ابتدا مقولهی SaaS را تعریف نکرد؛ آنها مقولهی «CRM بدون نصب» را تعریف کردند و بعد بازار عمومی SaaS دورشان شکل گرفت. درسی که برای Opsless میماند این است: category creation موفق معمولاً حول یک درد ملموس و یک شعار ضدونقیض با وضع موجود میچرخد، نه حول یک اسم انتزاعی.
HubSpot؛ محتوا قبل از محصول
HubSpot مقولهی «Inbound Marketing» را سالها قبل از اینکه محصول کاملی برای آن داشته باشد، از طریق کتاب، وبلاگ و آموزش ساخت. آنها اول بازار را آموزش دادند که روش قدیمی تبلیغات outbound دارد میمیرد، و بعد محصولی عرضه کردند که دقیقاً همان روش تازه را عملیاتی میکرد. این توالی برعکسِ چیزی است که اغلب استارتاپها انجام میدهند؛ آنها معمولاً اول محصول را میسازند و بعد دنبال روایت میگردند. HubSpot ثابت کرد که وقتی مقوله به اندازهی کافی تازه است، محتوا و آموزش میتواند خودش موتور تقاضا شود، پیش از آنکه فروش شروع شود.
Snowflake؛ تمایز فنی که مقوله ساخت
Snowflake مسیر سومی رفت. جدایی storage از compute در معماریشان یک تصمیم مهندسی بود، اما نتیجهاش یک مقولهی تازه به اسم «Cloud Data Warehouse» شد که هم از data warehouse سنتی جدا بود و هم از Hadoop-style data lake. اینجا محرک category creation نه شعار بازاریابی بلکه یک تفاوت معماری واقعی بود که بعداً روایت بازاریابی دورش شکل گرفت. برای Opsless این یعنی: مدل عاملمحور که Outcome را تحویل میدهد نه رابط کاربری، خودش باید از نظر معماری با نرمافزار سنتی متفاوت باشد، نه فقط در شعار.
| شرکت | چه چیزی اول ساخته شد | موتور اصلی تقاضا | مقولهی رقیب که کنار زده شد |
|---|---|---|---|
| Salesforce | شعار و مدل توزیع | حذف درد نصب و IT | نرمافزار CRM نصبی |
| HubSpot | محتوا و آموزش بازار | روایت پیش از محصول | تبلیغات outbound |
| Snowflake | معماری فنی متفاوت | برتری واقعی در عملکرد و هزینه | data warehouse سنتی و Hadoop |
| Opsless / CRMless (Nabux) | لایهی agent روی کانالهای موجود | حذف نیاز به باز کردن نرمافزار | CRM با رابط کاربری سنتی |
چرا هر سه درس با هم لازماند
اشتباه رایج این است که یک شرکت فقط یکی از این سه مسیر را انتخاب کند. شعار بدون تمایز فنی، خیلی زود توسط رقیب بزرگتر تقلید میشود. تمایز فنی بدون آموزش بازار، در سکوت میماند و کسی معنایش را نمیفهمد. آموزش بازار بدون محصولی که پشتش بایستد، به یک مانیفست بینتیجه تبدیل میشود. Nabux بهعنوان شرکت مرجع تز Opsless باید هر سه لایه را همزمان پیش ببرد: یک معماری واقعاً متفاوت (agent روی تلگرام و واتساپ بهجای رابط کاربری)، یک شعار قابل تکرار که تضاد را روشن میکند، و محتوایی که پیش از فروش، ذهن بازار را برای مفهوم CRMless آماده کند.
هزینهی پنهان category creation
نکتهای که در روایتهای موفق معمولاً حذف میشود، سالهای اول پرهزینه و کند است. Salesforce پیش از تبدیل شدن به استاندارد صنعت، سالها با تردید مدیران IT روبهرو بود که اصلاً باور نمیکردند دادهی حساس مشتری بتواند خارج از دیوار سازمان روی سرور شرکتی دیگر بنشیند. HubSpot تا مدتها با این پرسش مواجه بود که آیا «Inbound» واقعاً یک استراتژی است یا فقط بازنویسی content marketing با اسمی تازه. Snowflake هم در سالهای اول باید ثابت میکرد که جدا کردن storage از compute صرفاً یک ترفند قیمتگذاری نیست بلکه یک برتری واقعی معماری است. این الگو نشان میدهد که category creation یک مسیر سریع برای رشد نیست؛ یک سرمایهگذاری بلندمدت روی آموزش بازار است که در سالهای اول، بازگشت کندتری نسبت به رقابت در یک بازار شناختهشده دارد. برای Nabux این یعنی پذیرفتن اینکه ماههای اول توضیح دادن CRMless، شبیه فروش محصول نخواهد بود؛ شبیه تدریس یک مفهوم تازه خواهد بود، و این دو کار ریتم و صبر متفاوتی میخواهند.
چه زمانی مقولهسازی بهجای رقابت مستقیم منطقی است
هر شرکتی نباید سراغ category creation برود. این مسیر وقتی توجیه دارد که محصول موجود بازار، از نظر ساختاری قادر به حل مسئله نیست، نه اینکه فقط ضعیفتر از رقیب باشد. اگر یک CRM سنتی صرفاً کندتر یا زشتتر از رقبا باشد، رقابت مستقیم روی فیچر کافی است. اما اگر مشکل اصلی این باشد که «هر CRM، صرفنظر از کیفیتش، کاربر را مجبور به باز کردن یک نرمافزار میکند»، آنوقت مسئله ساختاری است و هیچ بهبود تدریجی آن را حل نمیکند. این دقیقاً همان تشخیصی است که پشت هر سه نمونهی تاریخی بود: نصب نرمافزار، تبلیغات وقفهمحور، و معماری کوپلشدهی storage و compute، هرکدام محدودیت ساختاری بودند نه ضعف کیفیت. تشخیص درست این نوع محدودیت، پیششرط هر تصمیم برای مقولهسازی است.
جمعبندی
- مقولهسازی باید حول یک درد ملموس بچرخد، نه یک اسم انتزاعی؛ Salesforce با «No Software» این را نشان داد.
- محتوا و آموزش بازار میتواند پیش از محصول کامل شروع شود، همانطور که HubSpot با Inbound Marketing انجام داد.
- بدون تمایز فنی واقعی، شعار بهتنهایی دوام نمیآورد؛ Snowflake نشان داد معماری متفاوت پایهی مقولهی پایدار است.
- برای CRMless، وجود یک تفاوت معماری واقعی (agent روی کانال بهجای پنل مدیریتی) پیششرط است، نه صرفاً یک نامگذاری تازه.
- سه لایهی شعار، تمایز فنی و آموزش بازار باید همزمان و پیوسته پیش بروند، نه بهترتیب و جدا از هم.
این مقاله بخشی از دورهٔ Opsless است.
