- GrubMarket द्वारा अधिग्रहित Butter के संस्थापक का 2020 से 5 वर्षों के अनुभव का संकलन
भाग 1: क्या नहीं करना चाहिए
शुरुआत: महामारी और डिजिटल ट्रांसफॉर्मेशन का अवसर
- 2020 की महामारी के दौरान, फूड इंडस्ट्री में डिजिटल ट्रांसफॉर्मेशन की संभावना देखकर Butter की स्थापना की गई।
- सामने आई समस्याएँ:
- शेफ अब भी हाथ से लिखे ऑर्डर फॉर्म और फोन/टेक्स्ट पर आधारित पारंपरिक तरीकों को पसंद करते थे
- थोक विक्रेता पुराने टेक स्टैक पर निर्भर थे (1990s ERP, Excel inventory management, कागज़ी चेक भुगतान)
- केवल ग्राहक ऑर्डर एंट्री में ही रोज़ 6 घंटे लगते थे
- समाधान की योजना:
- मुख्य workflows को capture करके और "system of record" की भूमिका निभाने वाले all-in-one cloud-based ERP से core workflow को डिजिटल बनाना
- payments, lending, payroll जैसी financial services को integrate करके customer value (ACV) को अधिकतम करना
- शेफ और थोक विक्रेताओं दोनों के लिए seamless communication process लाना, और DoorDash-स्टाइल ऑर्डर ऐप से platform network effect बनाना
((तेज़ी से unicorn बनी एक दूसरी ऑर्डर ऐप Choco से प्रभावित)
लेकिन असफलता हुई
- यह no-brainer सफलता लगेगा, ऐसा सोचा था, लेकिन हम पूरी तरह गलत थे
जाल 1: तकनीकी जटिलता और अत्यधिक customization
- लगा था कि ERP बनाना सरल होगा, लेकिन वास्तव में हर ग्राहक की अलग-अलग जरूरतों ने development resources खत्म कर दिए
- उदाहरण: keyboard shortcuts, data entry screen layout, specific invoice formats
- नतीजा: एक ऐसा customization-निर्भर product बन गया जो scale नहीं हो सकता था
जाल 2: लंबा sales cycle
- ERP system बदलना जटिल था, और कई departments की सहमति चाहिए थी:
- ग्राहक कंपनियाँ मौजूदा असुविधा के बावजूद बदलाव से बचती थीं
- restaurant के busy season में sales opportunities सीमित हो जाती थीं
- नतीजा: कम deal close rate (लक्ष्य का केवल 20~30%)
जाल 3: कम willingness to pay और revenue activation का लंबा चक्र
- अधिकांश ग्राहक कंपनियाँ कम margin (लगभग 5%) पर चल रही थीं:
- जो ग्राहक QuickBooks के लिए $80/माह दे रहे थे, उनके लिए ERP upgrade की लागत भारी थी
- अतिरिक्त fintech और ऑर्डर ऐप revenue को सक्रिय होने में भी लंबा समय लगा
जाल 4: बहुत ज़्यादा प्रयोग
- शुरुआती चरण में कई revenue models और network effects को एक साथ आज़माने की कोशिश की गई:
- एक भी clear success case हासिल किए बिना बहुत सारे मोर्चे खोल दिए गए
- नतीजा: team burnout और कम iteration speed
कठिन अनुभव से सीखे गए सबक
- Butter चलाते समय कई ऐसे पल आए जिन पर गर्व था:
- सफल onboarding के लिए रात 2 बजे उठना और warehouse में सोना
- ऐसा software बनाना जिसे ग्राहक पसंद करते थे—जटिल, लेकिन intuitive
- एक व्यवस्थित implementation guide विकसित करना
- लेकिन एक scalable venture business बनाने में असफल रहे
- सबक 1. केवल high-level hypotheses पर निर्भर मत रहिए:
- warehouse, field, और back-office workers से सीधे बात करके वास्तविक insights हासिल करनी चाहिए
- बातचीत का लक्ष्य "सच की खोज" होना चाहिए, न कि अपनी पुरानी सोच की पुष्टि
- सबक 2. सफल product बनाने के लिए ज़रूरी तत्व:
- ऐसे users पाना जो समस्या को गहराई से समझते हों:
- जब तक status quo बनाए रखने का दर्द बदलाव के friction से बड़ा नहीं होता, कोई system नहीं बदलता
- बदलाव कभी-कभी सिर्फ कुछ catalysts से भी हो सकता है
- पर्याप्त भुगतान क्षमता:
- यदि ग्राहक के पास समाधान वहन करने की आर्थिक क्षमता नहीं है, तो दिया गया value company की revenue sustainability नहीं बना सकता
- मौजूदा विकल्प से 10 गुना बेहतर product experience:
- ग्राहक जितना अधिक पारंपरिक होगा, उतना ही नाटकीय improvement ज़रूरी होगा
- यह समझते हुए approach करें कि ग्राहक इतने लंबे समय तक पुराने तरीके पर क्यों टिके रहे
- simplicity का महत्व:
- शुरुआती product सरल और आसानी से अपनाने योग्य होना चाहिए
- उदाहरण: fancy Japanese bidet बेचने के बजाय बुनियादी plumbing समस्या हल करने पर ध्यान देना
- सबक 3. business model और SaaS सफलता की शर्तें:
- deal size और sales cycle (deal speed) में संतुलन होना चाहिए।
- David Sacks का "The Difficulty Ratio":
- high ACV (Annual Contract Value) और low deal speed, या इसका उल्टा, संभव है
- लेकिन low ACV और slow deal speed का संयोजन विफलता की संभावना बढ़ाता है
- Butter के मामले में:
- अतिरिक्त revenue streams के बावजूद यह low deal speed और low ACV वाले zone में था
- खासकर total revenue activation cycle तक पहुँचने में deal speed बहुत धीमी थी
अंतिम विचार
- पीछे मुड़कर देखने पर, पारंपरिक प्रक्रियाओं और पुराने टेक पर निर्भर उद्योगों में vertical SaaS बनाने की जटिलता को हमने कम आंका
- सिर्फ digital solution देना adoption के लिए पर्याप्त नहीं था
- इसके बजाय, मौजूदा तरीके की तुलना में नाटकीय improvement देना ज़रूरी था, और
- उसे ऐसे तरीके से पेश करना ज़रूरी था जिसे ग्राहक समझ सके।
- यदि तुरंत सही fit का एहसास नहीं होता, तो ग्राहक परिचित पुराने तरीके पर ही टिके रहते हैं
- सबक: मौजूदा workflow का सम्मान करते हुए वास्तविक value साबित करने वाला approach ही सफलता की कुंजी है
शुरुआती बिंदु: पारंपरिक तरीकों से टकराव
- शुरुआती प्रयास:
- e-commerce के ज़रिए थोक विक्रेताओं की order entry process को modernize करने के उद्देश्य से tool बनाया गया
- समस्या:
- शेफ अब भी पारंपरिक तरीके (फोन, टेक्स्ट) पसंद करते थे और digital systems को आसानी से नहीं अपनाते थे
- नया system इतना value नहीं दे पा रहा था कि वह पुराने तरीके को पूरी तरह replace कर सके
- ग्राहक की राय सुनना:
- active users, churned users, और app विरोधियों सहित अलग-अलग customer groups से interviews किए गए
- निष्कर्ष यह था कि app के जरिए ऑर्डर करना फोन/टेक्स्ट/email की तुलना में 10 गुना बेहतर अनुभव नहीं था:
- real-time product availability और delivery status की visibility की कमी थी
- थोक विक्रेताओं की कठिनाइयों को समझना:
- वे अब भी घंटों चलने वाली manual order entry में फँसे थे
- AI अपनाने का विचार:
- unstructured data को संभालने के लिए large language models (LLMs) उपयुक्त थे
- AI के जरिए complex tasks को automate किया जा सकता था
- दुनिया के लगभग 80% data के unstructured होने के कारण एक paradigm shift की संभावना दिखी
- रणनीति में बदलाव:
- suppliers और operators को पूरी तरह digital workflow अपनाने के लिए मजबूर नहीं किया गया
- इसके बजाय, मौजूदा process को पूरक करने वाले AI-आधारित tools (जैसे Butter’s AI Order Assistant) बनाए गए:
- जिन्हें मौजूदा workflow में स्वाभाविक रूप से integrate होने के लिए डिज़ाइन किया गया।
- और जो तकनीकी रूप से पीछे रह गई food distribution industry को modernize करने का व्यावहारिक समाधान बने।
AI की ओर बदलाव: सिर्फ वादा नहीं, वास्तविक implementation
- AI सफलता की कुंजी:
- सिर्फ "ज़्यादा polished" product नहीं, बल्कि ऐसा product चाहिए जो वास्तव में user का काम पूरा करे
- AI Order Assistant:
- इस तरह डिज़ाइन किया गया कि शेफ और थोक विक्रेता अपनी मौजूदा process बदले बिना इसका उपयोग कर सकें
- मौजूदा workflow में सहज रूप से integrate होता है
- natural language processing आधारित order management:
- voice commands या text messages को process कर सकने वाले AI से प्रक्रिया सरल हुई
- full system replacement के बजाय add-on tool के रूप में दिया गया:
- इसलिए इसे जल्दी अपनाया जा सका
- और "digital transformation" की जटिल समस्या से बचा जा सका
- customer onboarding प्रक्रिया:
- email और voicemail data को ERP से जोड़कर structured purchase order data में बदला गया
- शेफ की preferences (उदाहरण: "2 boxes of shrimp") को digital system में store किया गया:
- past order patterns और order guides की मदद से product variations को सही ढंग से समझा गया।
- उदाहरण: AI यह अलग कर सकता था कि यह "4-6 Tiger Shrimp Frozen" है या "16-20 EZ Peel Shrimp"
- user feedback को शामिल करना:
- AI model से 100% accuracy की अपेक्षा नहीं की गई:
- व्यापक UX interviews के आधार पर users को AI output edit करने की सुविधा दी गई
- ERP shortcuts का उपयोग करके पूरा काम keyboard input से हो सके, इस तरह डिज़ाइन किया गया
- नतीजा:
- order processing time 96% से अधिक घट गया
- back-office staff को high-value tasks (quality control, customer relationship management) पर शिफ्ट किया जा सका
- GrubAssist तक विस्तार:
- GrubMarket द्वारा अधिग्रहण के बाद, AI Order Assistant को GrubAssist के रूप में विस्तारित किया गया
- मौजूदा ERP systems में natural language-आधारित business intelligence और analytics प्रदान किए गए।
- food industry के मौजूदा workflows को बाधित किए बिना seamless integration दी गई
- मौजूदा workflow के साथ integration ही AI सफलता की कुंजी है। बिना जटिल बदलाव के आसान adoption संभव होना चाहिए।
LLM products बनाने से मिले सबक
- तकनीकी सीमाओं को ध्यान में रखकर डिज़ाइन:
- LLM शक्तिशाली हैं, लेकिन reliability और speed के मामले में अब भी सीमाएँ हैं।
- प्रभावी डिज़ाइन से इन सीमाओं की भरपाई:
- उदाहरण: restaurant/retailers अगले दिन सुबह orders process करते हैं, इसलिए background processing के जरिए speed से समझौता कर, बेहतर reasoning क्षमता वाले models चुने जा सकते हैं।
- speed को प्राथमिकता दें, perfection बाद में खोजें:
- शुरुआती चरण में "perfect model" की तलाश में मत फँसिए।
- market entry के लिए सरल तकनीकें (जैसे RAG) इस्तेमाल करें:
- सही context दिया जाए तो सरल तरीके भी बहुत प्रभावी हो सकते हैं।
- base models बेहतर होते जाएँ, तो AI product भी अपने-आप बेहतर होता जाता है।
- fundamentals को मजबूत रखें:
- लचीला experimentation environment दें:
- modular architecture इस तरह डिज़ाइन करें कि model या feature बदलना आसान हो और तेज़ iteration संभव हो।
- साफ़ और measurable in-product feedback system का integration ज़रूरी है।
- interface product की सफलता या विफलता तय करता है:
- "perfect" model होने पर भी यह मानकर डिज़ाइन करें कि 20% काम में human verification लगेगा।
- interaction को सरल और intuitive बनाएँ ताकि user engagement बना रहे:
- user verification process को मजबूत करने से product improvement के लिए महत्वपूर्ण data मिलता है।
- unstructured knowledge को capture करना:
- पारंपरिक उद्योगों में महत्वपूर्ण जानकारी अक्सर digitized नहीं होती और लोगों की याददाश्त पर निर्भर रहती है।
- उदाहरण: यदि ग्राहक की preference सिर्फ sales rep Joey के दिमाग में है, तो उसे capture करने वाला interface बनाइए।
- ऐसी insights model differentiation को मजबूत करती हैं और लगातार data advantage देती हैं।
- feedback loop से accuracy में सुधार:
- केवल engineering से काम नहीं चलेगा:
- ऐसा seamless तरीका दें जिससे user feedback सीधे product के भीतर collect किया जा सके।
- feedback को tuning engine से जोड़कर अधिक accurate और contextually relevant outputs दिए जा सकते हैं।
मौजूदा systems के साथ मिलकर काम करना महत्वपूर्ण है
- व्यावहारिक चुनौतियाँ:
- AI solution कितना भी शानदार हो, यदि वह मौजूदा legacy ERP systems से integrate नहीं होता, तो उसका कोई अर्थ नहीं
- legacy systems को replace करने की कोशिश करने पर collaboration कठिन हो जाता है
- integration strategy:
- Butter के मामले में, ERP के साथ EDI (Electronic Data Interchange) या SFTP file exchange जैसे तरीकों से integration आवश्यक था
- legacy systems गहराई से जमे हुए होते हैं, इसलिए persuasion और architecture design दोनों जटिल होते हैं
- सफल रणनीति:
- मौजूदा products को बेहतर करने वाले add-on tools देना:
- ताकि ग्राहक मौजूदा infrastructure बनाए रखते हुए AI के लाभ उठा सकें
- मौजूदा network को मजबूत करते हुए यह दिखाना कि AI business और infrastructure providers दोनों के लिए positive-sum है
- तत्कालता की स्थिति:
- AI expertise तेज़ी से फैल रही है, और पहले धीमे रहे पारंपरिक service providers भी AI अपना रहे हैं
- तेज़ी से execute करें और मौजूदा players के साथ काम करें:
- सही strategy और differentiated approach के साथ market में उतरना होगा
- software के नए approach पर चेतावनी:
- "integrate and surround" approach वाले नए products:
- किसी खास business area (जैसे field sales) को पूरी तरह self-sufficient बनाना
- cost/revenue structure को अपने पक्ष में बदलना
- इन trends को समझना और सही partners चुनना महत्वपूर्ण है
- मुख्य सबक
मौजूदा systems के साथ मिलकर काम करें, और बिना full system replacement के भी स्पष्ट लाभ और सुधार दें
- low-risk, high-reward add-on tools के रूप में value दिखाकर तेज़ adoption को प्रेरित करें
भविष्य के लिए अंतर्दृष्टि
- पारंपरिक उद्योग और AI का मिलन-बिंदु:
- हाथ से लिखे रिकॉर्ड या audio data जैसे unstructured data पर निर्भर पारंपरिक उद्योग अब LLMs (large language models) के माध्यम से आधुनिक तकनीकी solutions तक पहुँच सकते हैं
- Vertical SaaS अब इन उद्योगों में धीरे-धीरे एक व्यावहारिक विकल्प बन रहा है
- AI को हर जगह लागू करने का प्रलोभन है, लेकिन सावधानीपूर्ण approach ज़रूरी है
- AI सफलता की कुंजी:
- तकनीक खुद नहीं, बल्कि Product-Market Fit ही सफलता का निर्णायक कारक है
- AI की प्रगति संभावनाएँ खोलती है, लेकिन product development के बुनियादी सिद्धांत नहीं बदलते:
- शुरुआत users और उनकी जरूरतों की स्पष्ट समझ से होती है
- तकनीक उसके बाद आती है
- मुख्य सबक:
- AI तब सबसे प्रभावी होता है जब वह मौजूदा process में सही ढंग से integrate हो
- मौजूदा तरीकों को उलटने की कोशिश न करें, बल्कि स्वाभाविक रूप से उनमें घुलने-मिलने वाला डिज़ाइन करें
- सवाल:
- "इस अवसर को सबसे पहले कौन पकड़ेगा?"
- समय निकलने से पहले जो इस अवसर का लाभ उठाएगा, वही जीतेगा
अभी कोई टिप्पणी नहीं है.