Prototype बनाम Product: कैसे जानें कि आपकी AI-बनाई ऐप सचमुच तैयार है

कुछ हफ़्ते पहले, मेरी जानने वाली एक founder ने therapists के लिए एक scheduling ऐप बनाई। पूरी चीज़ में उसे किसी AI app builder के साथ चार दिन लगे। यह वो करती है जो उसे चाहिए: therapists अपना calendar देख सकते हैं, clients appointments book कर सकते हैं, confirmations email से चली जाती हैं। यह काम करती है।

वो दो हफ़्ते से इसे घूर रही है और launch नहीं किया है।

जब मैंने पूछा क्यों, तो उसने कहा: “यह काम करती है, पर… यह तैयार नहीं लगती।”

मैंने पूछा वो क्या बदलेगी। उसने कहा: “मुझे नहीं पता। यही तो समस्या है।”

किसी AI app builder से बनाने में यह सबसे मुश्किल पल है। चीज़ functional है, पर “functional” और “मैं असली लोगों से इसे इस्तेमाल करने के लिए कहने में सहज महसूस करूंगा” के बीच एक खाई है। उस खाई को समझना — और यह जानना कि आप असल में उसके किस तरफ़ हैं — शिप करने और हमेशा के लिए सिर के अंदर की आवाज़ वाले दौर में अटके रहने के बीच का फ़र्क है।

“तैयार” का असल में मतलब क्या है

यह रहा वो फ़र्क जो मायने रखता है: एक prototype वो चीज़ है जिसका इस्तेमाल आप किसी आइडिया को परखने के लिए करते हैं। एक product वो चीज़ है जिसका इस्तेमाल आप किसी समस्या को हल करने के लिए करते हैं।

therapist scheduling ऐप एक prototype है। यह साबित करती है कि concept काम करता है। एक therapist इसे इस्तेमाल कर सकता है। पर सत्रह छोटी-छोटी चीज़ें हैं जो इसे कच्चा महसूस कराती हैं:

• Email confirmations सादे हैं। कोई logo नहीं, कोई custom branding नहीं, आम copy।
• Cancellations notifications नहीं भेजतीं। Clients बस नहीं आते।
• अगर कोई therapist पूरी तरह booked हो तो कोई waiting list नहीं है।
• Signup flow therapist की specialties जमा नहीं करता, तो practice type से filter करने का कोई तरीक़ा नहीं।
• Appointment से 24 घंटे पहले कोई reminder email नहीं भेजी जाती।

इनमें से कोई भी चीज़ ऐप को तोड़ती नहीं। ये सब किसी असली therapist को सोचने पर मजबूर करती हैं: “यह ऐसा लगता है जैसे मैंने इसे एक weekend में जोड़ लिया हो, न कि ऐसा कुछ जिसके लिए कोई मुझसे पैसे ले रहा हो।”

वो एहसास असली है, और वो मायने रखता है। एक prototype समस्या को सिद्धांत में हल करता है। एक product उसे अमल में हल करता है, उस असली इंसान के लिए जो उसे इस्तेमाल कर रहा है।

तीन सवाल जो prototype को product से अलग करते हैं

यह रहा मुश्किल हिस्सा: आप वो सब कुछ नहीं जान सकते जो ग़ायब है। आपका AI builder भी उसे नहीं जान सकता। तो आपको यह पता लगाने के लिए तीन झटपट सवाल चाहिए कि आप लकीर के किस तरफ़ हैं।

1. क्या आप इसे अपनी ही समस्या हल करने के लिए इस्तेमाल करेंगे?

यह वाला ईमानदार है, क्योंकि आपको अपने ही product के साथ सचमुच जीना पड़ता है।

अगर आप उस therapist scheduling ऐप के founder हैं, तो क्या आप इसे अपनी ही therapy appointments schedule करने के लिए इस्तेमाल करेंगे? “क्या आप कर सकते हैं” नहीं — क्या आप सचमुच इसे किसी email की लंबी कड़ी या एक साझा Google Doc के बजाय इस्तेमाल करेंगे?

अगर जवाब नहीं है, तो आप तैयार नहीं हैं। आपको ठीक-ठीक पता है कि क्या ग़लत है — आप इसे हर बार महसूस करते हैं जब आप ऐप खोलते हैं। अगर जवाब हां है, तो आप क़रीब हैं।

मैंने जिस founder का ज़िक्र किया वो अपने ही therapist signup से गुज़री। वो form पर अटक गई (book करने देने से पहले वो बहुत ज़्यादा जानकारी मांगता था)। उसने confirmation email देखी और सोचा कि वो अनाड़ी जैसी लगती है। वो सोचने लगी कि उसका therapist वो email कैसे पाएगा और क्या वो spam में चली जाएगी।

वो अपने ही product को वैसे इस्तेमाल नहीं कर रही थी जैसे कोई paying customer करता। जब उसने किया, तो उसे ठीक करने के लिए दस चीज़ें मिलीं।

2. क्या आपने इसे तीन ऐसे लोगों को दिखाया है जो आप नहीं हैं?

संभावित यूज़र्स से बात करना बनाने से ज़्यादा मुश्किल है, और ज़्यादातर founders इसे छोड़ देते हैं क्योंकि वो launch पर लोगों को चौंकाना चाहते हैं। यह एक ग़लती है।

आपको किसी focus group की ज़रूरत नहीं। आपको तीन ऐसे लोग चाहिए जो आपके हिसाब से आपके customer जैसे हों। therapist ऐप के लिए, वो तीन असली therapists हैं।

यह रहा जो आप ढूंढ रहे हैं: वो कहां उलझते हैं? वो कहां झिझकते हैं? वो किस बारे में पूछते हैं? “वो इसके बारे में क्या सोचते हैं?” नहीं (लोग बहुत भले होते हैं)। उनसे कहें कि वो असल में वो काम करें — एक appointment book करें, एक confirmation email भेजें, कुछ cancel करें।

जब founder ने अपनी therapist ऐप तीन therapists को दिखाई, तो उनमें से दो ने पूछा: “क्या मैं इसके नियम बना सकता हूं कि मैं कब उपलब्ध हूं? जैसे, मैं नए clients सिर्फ़ गुरुवार को देखता हूं, और मैं दोपहर 2 बजे से पहले double-book नहीं करता।” ऐप में एक calendar था, पर नियम नहीं। उसने prototype इस हिसाब से बनाया था कि उसके ख़याल से scheduling कैसे काम करती है, न कि therapists असल में कैसे काम करते हैं।

वो product जानकारी है। आप उसे किसी spec से अंदाज़ा नहीं लगा सकते थे।

3. अगर आप इसे दस असली यूज़र्स को दे दें तो क्या टूटेगा?

यह सबसे मुश्किल सवाल है क्योंकि इसके लिए आपको अपने edge cases के बारे में सचमुच सोचना पड़ता है।

therapist ऐप के लिए:

• अगर कोई client एक ही समय पर दो appointments book करने की कोशिश करे तो क्या होता है? (ऐप जांचती नहीं।)
• अगर कोई therapist appointment cancel करे तो क्या होता है? क्या clients को अपने-आप सूचना मिलती है? (नहीं।)
• अगर किसी client का email address ग़लत हो तो? क्या उसे शुरू से किए बिना ठीक करने का कोई तरीक़ा है? (नहीं।)
• अगर किसी therapist की तबीयत ख़राब हो और उसे एक हफ़्ते के लिए अपना calendar बंद करना पड़े तो? (उसे हर appointment हाथ से delete करना पड़ेगा।)

ये bugs नहीं हैं। ऐप crash नहीं होती। पर ये कागज़ से लगी कटन जैसे हैं। दस असली यूज़र्स और असली edge cases के साथ, आप पहले ही हफ़्ते में इन सबसे टकराएंगे।

एक product edge cases को संभालता है। उन सबको नहीं — कुछ चीज़ें इंतज़ार कर सकती हैं। पर वो जो असली यूज़र्स के साथ पहले दो हफ़्तों में होती हैं, उन्हें काम करना चाहिए।

कैसे तय करें: तीन-परत वाला टेस्ट

यह पता लगाने के लिए इसका इस्तेमाल करें कि आप कहां हैं:

Layer 1: Core flow — क्या happy path काम करता है? क्या कोई यूज़र वो मुख्य काम कर सकता है जिसके लिए आपकी ऐप बनी है?

therapist scheduler के लिए: हां। कोई sign up कर सकता है, appointment book कर सकता है, confirmation पा सकता है। यह काम करता है।

Layer 2: असली इस्तेमाल से आने वाले edge cases — आपने इसे तीन असली यूज़र्स को दिखाया है। क्या वो किसी ऐसी चीज़ से टकराए जो आपने नहीं बनाई थी? क्या वो कहीं उलझे?

therapist scheduler के लिए: हां। तीनों therapists को नियम-आधारित availability चाहिए थी। एक उलझ गया क्योंकि email confirmation बहुत आम लगी। एक ने appointments bulk-delete करने की कोशिश की और नहीं कर पाया।

Layer 3: Polish और professionalism — क्या यह ऐसा लगता है कि आपको परवाह है? या ऐसा लगता है कि आपने इसे जैसे-तैसे जोड़ लिया?

therapist scheduler के लिए: यह जैसे-तैसे जुड़ा लगता है। Email confirmations सादे हैं। कोई custom branding नहीं। कुछ ग़लत होने पर कोई error message नहीं, तो अगर कुछ टूटता है, तो यूज़र को कोई अंदाज़ा नहीं कि क्या हुआ।

यह रहा नियम:

• तीनों layers काम कर रहे हैं? आप एक product हैं। शिप करें।
• Layers 1 और 2, पर 3 नहीं? आप 80% तैयार हैं। एक दिन polish पर लगाएं।
• Layer 1 काम कर रहा है, layers 2 और 3 नहीं? आप एक prototype हैं। अभी शिप मत करें।
• Layer 1 मज़बूत नहीं है? आप तैयार नहीं हैं। बनाते रहें।

therapist ऐप Layer 1 और Layer 2 की सीमा पर अटकी थी। Core flow काम करता था, पर असली therapists को इसमें कुछ टुकड़े ग़ायब मिले। तो founder के पास एक विकल्प था: अपने AI builder के साथ एक और हफ़्ता लगाकर वो features जोड़ें जो therapists को सचमुच चाहिए, या जो था उसी के साथ launch करके उन्हें बाद में जोड़ें।

(उसने उन्हें जोड़ा। तीन दिन लगे। अब यह एक product है।)

जो चीज़ इसे मुश्किल बनाती है

इतने सारे founders के यहां अटकने की वजह यह है कि बनाना मज़ेदार है और शिप करना डरावना।

बनाना आपके AI tool के साथ एक बातचीत है। आपके पास एक आइडिया होता है, आप उसे बताते हैं, tool उसे अमल में लाता है। एक feedback loop है जो मिनटों में चलता है। शिप करना अलग है। आप publish दबाते हैं, और अगर कुछ ग़लत है, तो असली इंसानों को पता चल जाता है। दोबारा मौक़ा नहीं।

तो हम शिप न करने की वजहें ढूंढते हैं। “यह काफ़ी polished नहीं है।” “मुझे एक और feature जोड़ना चाहिए।” “अगर fonts ग़लत हुए तो?” और छह हफ़्ते बाद, आप अब भी किसी ऐसी चीज़ पर बैठे हैं जो काम करती है पर तैयार नहीं लगती, और आपने खुद को मना लिया है कि यह fonts की वजह से है।

यह fonts की वजह से नहीं है।

यह आमतौर पर इसलिए है कि आपने किसी असली यूज़र के साथ समय नहीं बिताया, या आपने कुछ ऐसा बनाया जो आपके सिर में मायने रखता था पर असली लोगों के काम करने के तरीक़े में ठीक नहीं बैठता। वो ठीक हो सकता है। बस इसके लिए यह मानना पड़ता है कि आप वो नहीं जानते जो आप नहीं जानते, और फिर किसी ऐसे इंसान से बात करने जाना जो जानता है।

Launch की तैयारी वाली checklist

इसका इस्तेमाल करें। यह छोटी और ईमानदार है।

• मैंने असली काम करने के लिए इसे खुद इस्तेमाल किया है, और यह काम कर गया (demo-mode वाले तरीक़े से नहीं, बल्कि सचमुच)।
• मैंने इसे तीन ऐसे लोगों को दिखाया है जो असल में इसे इस्तेमाल करेंगे, और जिन चीज़ों पर वो उलझे थे उन्हें मैंने ठीक कर दिया है।
• हर वो error जो हो सकती है उसका एक message है जो यूज़र को बताता है कि उसके बारे में क्या करना है (“error” नहीं, बल्कि असली मार्गदर्शन)।
• अगर यह छह महीने तक आख़िरी वर्शन रहा तो भी मैं ठीक रहूंगा (मतलब: यह इतना पूरा है कि उपयोगी रहे, भले ही मैं इसे फिर कभी न छुऊं)।
• मैं असली यूज़र्स से जो सीखूंगा उसके लिए मैं उससे ज़्यादा उत्साहित हूं जितना खालीपन में और features जोड़ने के लिए।

अगर आप पांचों खाने ✓ कर सकते हैं, तो आप तैयार हैं। Launch करें।

अगर नहीं कर सकते, तो मत करें। पर इस बारे में ख़ास रहें कि क्यों। “यह तैयार नहीं लगती” कोई वजह नहीं है। “असली therapists को availability नियम चाहिए और वो मैंने अब तक नहीं बनाया” एक वजह है। वो अमल में लाने लायक है। वो ठीक हो सकता है। अटके होने और एक राह पर होने के बीच का यही फ़र्क है।

therapist ऐप के founder ने उसे कल शिप कर दिया। उसका पहला paying customer है। Product परफ़ेक्ट नहीं है, पर वो असली है, और उसका customer पहले से ही उसे बता रहा है कि आगे क्या बनाए। तभी आप जानते हैं कि आप तैयार हैं: तब नहीं जब ऐप परफ़ेक्ट हो, बल्कि तब जब आप यह सीखने के लिए तैयार हों कि इसे इस्तेमाल करने वालों के लिए परफ़ेक्ट का असल में मतलब क्या है।