डिज़ाइनर गलत लड़ाई के लिए चाकू तेज़ कर रहे हैं

• AI ने product implementation की लागत और समय को काफी घटा दिया है, लेकिन क्या और किसके लिए बनाना है यह तय करने वाली strategy bottleneck अब भी बनी हुई है
• design industry की चर्चा roles/production capability/taste/standards जैसे अच्छा कैसे बनाएं पर केंद्रित है, लेकिन product को सच में मारने वाला प्रतिद्वंद्वी market है—जिसके पास उदासीनता, alternatives और switching costs हैं
• जब implementation महंगा था, तब सीमित पैसा और समय गलत ideas को पहले से validate करने के लिए मजबूर करते थे; लेकिन सस्ते iteration ऐसे products को भी polished बनाते रहने की संरचना बनाते हैं जिन्हें रोक देना चाहिए
• standards और taste, विकल्पों की बाढ़ में अच्छे परिणाम चुनने के लिए जरूरी हैं, लेकिन वे किसी ऐसे product को बेहतरीन quality से बनाने की समस्या नहीं रोकते जिसे कोई चाहता ही नहीं
• AI युग में सबसे बड़ा leverage production speed नहीं, बल्कि यह तय करने की क्षमता है कि क्या अस्तित्व में रहने लायक है, किसकी कौन-सी समस्या अभी क्यों हल करनी चाहिए

---

Implementation आसान हो गया, लेकिन product नहीं मिला

• एक company ने ढाई साल में चार बार product बनाया और फिर से बनाया, लेकिन अब भी यह जवाब नहीं दे सकी कि product किसके लिए है
  • voice interface, polished web app और high-quality problem-solving engine तक implement किए, लेकिन रुचि दिखाने वाले customers तक नहीं पहुंच सकी
  • implementation bottleneck नहीं था, इसलिए कई ideas आजमाए जा सके, लेकिन attempts के बीच स्पष्ट decision-making या process नहीं था
• उस product की तुलना ऐसी biotech company से की गई जो बीमारी ठीक कर सकने वाले molecules तो invent कर लेती है, लेकिन manufacturing/distribution system और patients कौन हैं, यह नहीं जानती
• product बनाने की लागत लगभग गायब हो जाने की स्थिति में भी सफलता तय करने वाले reason for existence और target customer पर पर्याप्त चर्चा नहीं होती
• Roman Pichler का product strategy framework execution से ऊपर रखे जाने वाले core choices को दो सवालों में समेटता है
  • product किसके लिए है
  • उस व्यक्ति को product क्यों चाहिए होना चाहिए
• product organization की भूमिका implementations produce करना नहीं, बल्कि यह तय करना है कि क्या बनाना worth है

Design industry गलत समस्या पर निशाना लगा रही है

• AI के बाद design पर चर्चा कई रूप लेती है, लेकिन ज्यादातर product को कैसे बनाया जाए तक ही सीमित रहती है
  • Lisa Demchenko मानती हैं कि product designers specs लिखने वालों से system designers की ओर बढ़ रहे हैं
  • Andrea Grigsby AI द्वारा मुश्किल से replace की जा सकने वाली competitiveness के रूप में taste पेश करती हैं
  • Patrick Neeman browser wars खत्म करने वाले web standards alliance को AI युग की response strategy के रूप में सुझाते हैं
• roles/production capability/taste/standards/systems सभी output की quality से जुड़े हैं, लेकिन यह जवाब नहीं देते कि वह output शुरू से ही मौजूद होना चाहिए या नहीं
• industry ने work quality पर sophisticated चर्चा विकसित की है, लेकिन क्या यह काम करना चाहिए इस सवाल पर कमजोर है

असली प्रतिद्वंद्वी market की reality है

• product organization के अंदर designers/developers/processes competitors नहीं, बल्कि एक ही goal की ओर बढ़ने वाले members हैं
• product को अंतिम रूप से reject कर सकने वाला प्रतिद्वंद्वी वे वास्तविक लोग और market हैं जिन्हें product चाहिए होना चाहिए
  • market यह नहीं देखता कि team ने कितनी मेहनत की
  • वह rules नहीं बताता, product बनते समय conditions बदल देता है, और बिना कारण बताए ignore कर सकता है
  • indifference/alternatives/switching costs/limited attention product से competition करते हैं
• production capability नजदीक से quality बढ़ाने वाला चाकू है, और strategy की तुलना ऐसी बंदूक से की गई है जिसकी range market reality तक पहुंच सकती है
• industry gunfight में उतरते हुए भी production capability नाम के सुंदर चाकू को और तेज करने पर focused है

महंगी implementation cost जो validation कराती थी

• products के fail होने की मुख्य वजह button colors या code anti-patterns से ज्यादा यह है कि गलत चीज को confidence से बनाया गया और किसी ने समय रहते रोका नहीं
• 2009 में Manhattan East Village में bar Destination खोलते समय आसपास कम से कम छह competing venues थे
  • craft beer place/sports bar/Irish pub/dive bar/gay bar/German-style venue पहले से मौजूद थे
  • खर्च करने से पहले आसपास की जगहों की study करने पर strategy बनी कि neighborhood living room जैसा space, जहां पूरे दिन रहा जा सके, खाली है
  • $150,000 funds, 6 weeks और सिर्फ एक chance था, इसलिए गलत bar बनाने का निर्णय सहन नहीं किया जा सकता था
• money/time/physical effort जैसी constraints ideas गलत होने पर cost लगने से पहले honestly validate करने के लिए मजबूर करती थीं
• implementation cost कोई refined strategy tool नहीं थी, लेकिन bad decisions रोकने वाली आखिरी accidental safety device की तरह काम करती थी

सस्ते experiments रोकने की क्षमता कमजोर करते हैं

• AI से implementation तेज और सस्ती हो जाए तो idea अच्छा है या नहीं, यह जांचने के लिए रुकने की वजह घटती है, और अगले iteration पर बढ़ते जाना आसान हो जाता है
• Cloud Native Patterns का experiment cost reduction pattern बताता है कि experimentation cost जितनी घटती है, failed ideas छोड़ने का pressure उतना कमजोर होता है, और पहले से लगाए गए effort से बंध जाने की tendency product को लंबे समय तक बनाए रख सकती है
• जब कई attempts हर एक तेज, plausible और finished product जैसे दिखते हैं, तो team इसे progress समझने की भूल कर सकती है
  • ढाई साल बाद भी यह बात देर से पता चल सकती है कि वे actual customer value से नहीं जुड़े
• AJ Sunder की build vs buy comparison मानती है कि जब meaningful software एक afternoon में बनाया जा सके, तो मूल सवाल “हम खुद क्यों न बनाएं?” में बदल जाता है
  • यह choice ऐसे technical debt और operational burden में बदल सकती है जो explicitly decide नहीं किए गए थे
• Andrew Bosworth के product principles पहले humans की problem खोजने और फिर पूछने से शुरू होते हैं कि क्या इसे solve किया जा सकता है
• हर process को तेज करने से आप केवल सही destination पर जल्दी नहीं पहुंचते, बल्कि finished product जैसा दिखने वाले गलत destination पर भी जल्दी पहुंचते हैं

गायब हुई cost team पर shift हो जाती है

• जब implementation cost budget में दिखती थी, तो budget approval decision-making को force करता था; लेकिन implementation लगभग free हो जाए तो cost गायब नहीं होती, team पर transfer हो जाती है
• सब कुछ बनाकर reaction देखने का तरीका strategy नहीं, बल्कि end point के बिना चलने वाली emergency drill जैसा है
  • ऐसे pivots दोहराए जाते हैं जिनकी वजह explain नहीं की जा सकती
  • members की nights और focus खर्च होते हैं
  • output अधिक सुंदर या मजबूत हो सकता है, लेकिन पिछले 6 महीनों की human cost दिखाई नहीं देती
• decision के बिना दोहराई जाने वाली emergencies team को मजबूत नहीं करतीं, बल्कि burn out करती हैं, और जिन capable लोगों के पास दूसरे options हैं वे पहले जा सकते हैं

अच्छा बना product और जरूरी product अलग हैं

• standards product को सही तरीके से implement कराते हैं, taste output की quality बढ़ाता है, और AI जितने infinite outputs produce करेगा, दोनों की importance उतनी बढ़ेगी
• Jakob Nielsen की AI curation चर्चा मानती है कि idea generation practically free हो जाने से options produce करने की बजाय अच्छे options चुनने की discernment दुर्लभ हो जाती है
• standards और taste दोनों बेहतर choices करने की abilities हैं, लेकिन वे उस situation को नहीं रोकते जहां कोई भी न चाहने वाले product को perfect quality और specs से implement किया जा रहा हो
• Marty Cagan का product teams और feature teams distinction features efficiently ship करने वाली teams और customer problems solve करने वाली teams में फर्क करता है
  • अगर गलत चीज ship कर रहे हैं, तो shipping efficiency का कोई value नहीं
  • AI से “क्या implement किया जा सकता है” वाला feasibility risk काफी घटा है, लेकिन “क्या यह अस्तित्व में होना चाहिए” वाला value risk जस का तस है
• Gale Robins क्या बनाना है यह पता लगाने वाली activities और outputs को short game, और क्या बनाना worth है यह judge करने की ability को long game में बांटती हैं
  • AI ने short game को तेज बनाया है, लेकिन long game की difficulty कम नहीं की

Customers product को hire क्यों करते हैं

• Clayton Christensen का Jobs to Be Done मानता है कि customers product itself नहीं खरीदते, बल्कि किसी specific job को पूरा करने के लिए product को hire करते हैं
• McDonald’s milkshake study में बड़ी संख्या सुबह 8 बजे से पहले commuters को sold होती थी
  • commuters लंबी और उबाऊ drive का समय काटने और lunch तक पेट भरा रखने के लिए milkshake चुनते थे
  • असली competitor दूसरा milkshake नहीं, bagel और boredom थे
• जब performed होने वाला job मिल जाए तो product design clear हो जाता है, लेकिन वह job miss हो जाए तो सबसे खूबसूरत product भी चुना नहीं जाता
• AI यह खुद जाने बिना कि customer किस job के लिए product hire करता है, लगातार नए milkshakes बना सकता है

Skift ने चार टांगें कैसे काटीं

• Rafat Ali ने Skift शुरू करते समय content strategy को चार legs के रूप में design किया था
  • article aggregation
  • curation
  • syndication
  • original reporting
• initial structure logical था और investors को explain करने में अच्छा था, लेकिन actual readers ने aggregated headlines में interest नहीं दिखाया
• चार legs घटकर तीन, फिर दो रह गए, और venture investors जो plan सुनना चाहते थे उसे छोड़ने के बाद ही working product मिला
• product build करना मुश्किल नहीं था; public market में लोग क्या चाहते हैं यह discover करना और जो नहीं चाहते उसे remove करना core था
• उस समय चार elements implement करने में real time और money लगता था, इसलिए performance को detail में देखकर cut किया जा सकता था
• वही launch AI युग में किया जाए तो कुछ दिनों में न सिर्फ चारों चीजें, बल्कि unrequested features तक complete हो सकती हैं
  • हर feature finished product जैसा दिखेगा, और क्या remove करना है यह बताने वाले signals easy implementation process में दब सकते हैं

Decision ही बची सबसे महत्वपूर्ण skill है

• excellent quality product discussion में शामिल होने की basic condition है, लेकिन well-made होने का मतलब सही product होना नहीं है
• AI lunch से पहले सैकड़ों answers बना सकता है, लेकिन वास्तव में needed answer क्या है यह judge नहीं कर सकता
• Buzz Usborne का discovery और delivery distinction मानता है कि delivery cost घटने की situation में क्या बनाना है तय करने वाली layer तक automate कर दी जाए, तो जो बचता है वह बस वही average software है जिसे हर कोई तेज और सस्ते में बनाता है
• जब implementation slow और expensive थी, गलत product बनाने की mistake लंबी production process में छिप सकती थी; implementation cost घटने से judgment ability की कमी सीधे उजागर होती है
• product के जिम्मेदार व्यक्ति का highest leverage इन तीन चीजों को decide करने में है
  • क्या existence worth है
  • किसके लिए है
  • अभी क्यों जरूरी है
• Roman Pichler जिस strategy-execution gap की बात करते हैं, उसके execution side पर roadmap/ritualized process/launch activities से busy रहा जा सकता है, लेकिन वे decision की responsibility का substitute नहीं हो सकते
• Joe Smiley की design maturity discussion senior people को strategy के बजाय production-floor emergencies में लगाए जाने की situation पर चर्चा करती है
• जिस युग में कोई भी कुछ भी बना सकता है, उसमें क्या बनाना worth है यह जानने की ability ही बचा हुआ core leverage है, और market के conclusion देने से पहले product organization को पहले decide करना होगा