AI युग में डेवलपर के नियम

 (bvp.com)
28 पॉइंट द्वारा GN⁺ 2025-10-27 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • AI agents और मानव डेवलपर एक साथ user और collaborator बनने वाले नए software environment को ध्यान में रखते हुए, 12 साल पहले प्रकाशित developer platform laws को AI paradigm के अनुरूप फिर से परिभाषित किया गया
  • 2025 में agentic development paradigm उभर चुका है, जिसमें AI agents डेवलपर्स के साथ मिलकर software को design, build, deploy और maintain करते हैं
  • Anthropic, Cursor, Port जैसे प्रमुख developer platform leaders की प्रत्यक्ष insights के आधार पर 8 मुख्य laws निकाले गए
  • agent experience (AX) और developer experience (DX) के संतुलन, model-friendly documentation, नई pricing strategy, platform engineers की बदलती भूमिका जैसे developer tools बाज़ार के संरचनात्मक बदलावों पर चर्चा
  • AI-प्रेरित software innovation की लहर में developer platforms नई infrastructure की अगली पंक्ति का नेतृत्व कर रहे हैं, और लगातार विकास तथा platform control defensibility के मुख्य तत्व के रूप में उभर रहे हैं

पृष्ठभूमि: डेवलपर नियमों का विकास

  • Bessemer Venture Partners द्वारा 2013 में प्रकाशित पहली "डेवलपर प्लेटफ़ॉर्म के 8 नियम" और 2019 का संशोधित संस्करण DevOps, open source, cloud-native architecture, और API-first ecosystem के उभार को ट्रैक करते थे
  • 2025 में agentic development नाम का एक नया paradigm उभरा है
    • AI agents डेवलपर्स के साथ मिलकर बड़े पैमाने पर software को design, build, deploy और maintain करते हैं
  • Anthropic, Cursor, Port, Fal AI, Fern, Render, Appwrite, Netlify, Recall, Vapi, Resolve AI, Graphite, Marimo, Resend जैसे industry leaders की प्रत्यक्ष insights को शामिल किया गया है

AI डेवलपमेंट प्लेटफ़ॉर्म के 8 नियम

नियम #1: agent experience (AX) डेवलपर experience (DX) जितना ही महत्वपूर्ण है

  • agent experience (AX) और developer experience (DX) दोनों पर समान ध्यान देना ज़रूरी है
    • DX, AX को सीधे complement और बेहतर बनाता है
    • documentation की comprehensiveness, API surface area, और आसानी से समझ आने वाले schema जैसी चीज़ें इंसानों और agents दोनों के लिए उपयोगी हैं
    • पिछले 5–10 वर्षों में OpenAPI spec, REST API, और SDK में किए गए निवेश का लाभ दोनों को मिल रहा है
  • Resend CEO की गवाही: DX सुधारने के लिए onboarding flow को optimize करने से agents द्वारा Resend के इस्तेमाल में भी बड़ा अंतर पड़ा

  • इंसानों और agents के लिए अलग-अलग सुविधाएँ

    • मानव डेवलपर अस्पष्ट documentation की व्याख्या कर सकते हैं और inconsistent API के अनुसार ढल सकते हैं
    • agents को structured और predictable interface की ज़रूरत होती है
      • comprehensive error handling वाले OpenAPI schema
      • multi-step workflow के लिए session persistence
      • WebSocket stream जैसे real-time feedback mechanisms
      • Netlify का deployment agent पूरे CI/CD pipeline में state बनाए रखता है और तुरंत build feedback देता है

  • Model Context Protocol (MCP) का उभार

    • MCP इस बात में मूलभूत बदलाव को दर्शाता है कि developer tools users को कैसे serve करते हैं
    • कई कंपनियाँ Prefect के FastMCP जैसे solutions से अपने MCP server host कर रही हैं
      • क्योंकि डेवलपर्स Cursor और Claude Code में काम करते हैं
      • IDE के भीतर डेवलपर्स agents को मज़बूत बनाकर platform के live data तक सीधी पहुँच और काम करने की क्षमता देते हैं

  • dashboard और API का एकीकरण

    • फिलहाल इंसान जानकारी इकट्ठा करने के केंद्रीय window के रूप में dashboard में सीधे login करते हैं
    • Recall जैसी टीमें dashboard की हर function को API से accessible बना रही हैं, ताकि agents भी problem-solving में योगदान दे सकें
    • agents के context switching (version control, integrations, API usage, production deployment) को कम या खत्म करने को लेकर अब भी अनसुलझे सवाल हैं
      • MCP server agents को dashboard या CLI में context switch किए बिना real-time information लाने और commands चलाने में सक्षम बनाते हैं

नियम #2: documentation को models और इंसानों दोनों की सेवा करनी चाहिए

  • engineering teams के भीतर documentation अक्सर अच्छी मंशा से लिखी जाती है, लेकिन ठीक से maintain नहीं होती
    • वह real-time changes को reflect नहीं कर पाती और outdated guides देती है
    • डेवलपर्स अधूरी या imperfect documentation के प्रति कुछ हद तक सहनशीलता दिखा देते हैं

  • LLM के लिए documentation की विशेषताएँ

    • LLM के लिए navigation, advertising, और JavaScript वाले complex HTML pages को LLM-friendly plain text में बदलना कठिन और inaccurate होता है
    • agents को एक ही accessible location पर उपलब्ध concise और expert-level information से बड़ा लाभ मिलता है
      • development environment जैसे use cases में यह खास तौर पर महत्वपूर्ण है, जहाँ LLM को programming docs और API तक तेज़ी से पहुँचना होता है
    • LLM को up-to-date structured API references और human तथा agent activities को track करने वाले audit logs की ज़रूरत होती है
      • यह information architecture पर बुनियादी पुनर्विचार की माँग करता है

  • Generative Engine Optimization (GEO)

    • जैसे SEO search engines में discoverability सुनिश्चित करता है, वैसे ही GEO यह सुनिश्चित करता है कि models documentation में सही जवाब को जल्दी parse और surface कर सकें
    • इससे डेवलपर्स का flow बना रहता है और वे context-switching search से बाधित नहीं होते

  • दोहरे उद्देश्य वाले technical docs

    • coding agents के प्रसार के साथ technical docs दोहरे उद्देश्य वाली product asset बन गई हैं
    • वे agents और मानव डेवलपर audience दोनों को प्रभावी ढंग से serve करती हैं
      • agents के लिए उचित versioning, change management, और discoverability
      • और मानव डेवलपर्स के लिए भी उपयोगी बने रहना
    • Fern के co-founder का अवलोकन: "डेवलपर्स polished docs sites चाहते हैं, और agents को parse करने के लिए clean Markdown चाहिए। टीमें docs-as-code approach की ओर बढ़ रही हैं, जिसमें वे पहले documentation को Markdown में लिखती हैं, फिर उसे developer-friendly website और llms.txt जैसी machine-readable files के रूप में publish करती हैं"

नियम #3: pricing strategy को onboarding friction कम करने पर केंद्रित होना चाहिए

  • pricing को cost structure और value delivery दोनों को ध्यान में रखना चाहिए
  • AI-native applications के लिए यह विशेष रूप से महत्वपूर्ण है
    • पारंपरिक SaaS में marginal cost of serving a user लगभग शून्य होती थी, लेकिन अब inference cost के कारण यह एक meaningful item बन गई है

  • डेवलपर-केंद्रित कंपनियाँ pricing के 3 रास्तों पर प्रयोग कर रही हैं

    • 1. usage-based pricing और बड़े customer accounts तक expansion
      • product की हैरतअंगेज़ उपयोगिता के कारण expansion
      • हर platform फिर से AI के साथ integrate हो रहा है, और हर wave की तरह डेवलपर्स ही आगे रहकर infrastructure और tools spending को drive कर रहे हैं
      • usage और monetization customers के साथ-साथ बढ़ते हैं (फिलहाल यह सबसे common pricing pattern है)
    • 2. enterprise की predictable spending के प्रति पसंद
      • vendors AI को add-on नहीं बल्कि core seat-based product experience का हिस्सा बनाकर integrate कर रहे हैं
      • अक्सर इसके साथ usage-based overage fees भी होती हैं
    • 3. outcome-based pricing या activity bundling
      • activities को meaningful business process में bundle करना और completed workflow के आधार पर billing

  • upsell trigger में अंतर

    • शुरुआती data संकेत देता है कि पारंपरिक डेवलपर्स और vibe coders के बीच upsell triggers अलग हो सकते हैं
    • build और shipping की constraints इस बात को प्रभावित करती हैं कि software creators किस चीज़ के लिए भुगतान करने को तैयार हैं
      • उदाहरण: vibe coders बनाम पारंपरिक डेवलपर्स के लिए CI/CD features

  • onboarding friction कम करना अब भी सर्वोच्च प्राथमिकता है

    • चाहे कोई भी रास्ता चुना जाए, सभी platforms अब भी onboarding friction कम करने पर सबसे अधिक केंद्रित हैं
      • आकर्षक free tier बनाए रखना
      • बेहतरीन documentation
      • मज़बूत developer community (जो scale पर onboarding friction कम करती है)
    • Resolve CEO की राय: "हम पुराने SaaS model को नए products पर थोपते नहीं हैं। value को outcomes से map होना चाहिए... जब agents वास्तविक engineering work करते हैं और system downtime कम करने, system reliability बनाए रखने, और delivery तेज़ करने जैसी measurable value देता है, तब pricing उचित लगती है"

नियम #4: AI डेवलपर टूल्स पर खर्च पारंपरिक बजट से बाहर जा रहा है

  • समर्पित AI बजट बनाने वाली कंपनियों की संख्या बढ़ रही है, जिससे खर्च की एक नई श्रेणी उभर रही है
    • शुरुआती चरण में यह CIO के माध्यम से संगठन के हर हिस्से तक जाता है
  • कई कंपनियां पहले से ही AI टूल्स पर खर्च और अतिरिक्त इंजीनियरों की भर्ती के बीच trade-off कर रही हैं
    • वे लगातार यह पूछ रही हैं कि क्या अतिरिक्त लोगों की भर्ती के बजाय agents के जरिए लक्ष्य हासिल किए जा सकते हैं

  • जूनियर इंजीनियरों का पूरक और प्रतिस्थापन

    • जैसा कि इतिहास में सेवा-केंद्रित उद्योगों को बेचने वाली अन्य vertical software कंपनियों में देखा गया है
    • coding agents को काम सौंपने और workflow के जरिए जूनियर इंजीनियरों का पूरक बनना और उन्हें प्रतिस्थापित करना शुरू हो रहा है
    • फोकस सिर्फ productivity बढ़ाने और लागत घटाने पर नहीं, बल्कि तकनीकी leverage को अधिकतम करने पर भी है
    • व्यक्ति पूरी तरह नई क्षमताएं हासिल कर रहे हैं, जिससे दूसरों पर उनकी निर्भरता घट रही है

  • बहु-हितधारक खरीद माहौल

    • यह एक जटिल बहु-हितधारक खरीद माहौल को दिखाता है, जहां बजट के स्रोत अधिक जटिल हो गए हैं
    • डेवलपर-नेतृत्व वाला GTM शोर-भरे प्रतिस्पर्धी माहौल में अब भी राजा है
    • कंपनियों के भीतर CIO, engineering leaders, product teams और individual developers सभी खरीद फैसलों को प्रभावित कर रहे हैं, क्योंकि non-deterministic system integration के लिए जरूरी guardrails के स्तर के कारण यह पिछली पीढ़ी के डेवलपर टूल्स से अलग है

  • सफलता के मापदंडों में बदलाव

    • तुरंत value और जादुई अनुभव के लिए consumer-level expectations की ओर बदलाव
    • पारंपरिक developer tool productivity metrics को outcome-based measurements से पूरक किया जा रहा है
      • idea से working prototype तक पहुंचने में लगने वाला समय
      • पूरे development cycle में कमी
      • business users की productivity में सुधार
    • Cursor का analysis सूक्ष्म metrics tracking पर केंद्रित है
      • दिखाई गई suggestions की संख्या, स्वीकार की गई suggestions, AI सहायता से बनी code lines, AI-generated suggestions की acceptance rate

नियम #5: डेवलपर की परिभाषा नाटकीय रूप से फैल रही है

  • AI अधिक लोगों के लिए software बनाना सुलभ कर रहा है और "डेवलपर" की परिभाषा को मूल रूप से विस्तृत कर रहा है
    • Zapier में 10 साल पहले किए गए seed investment से ही यह trend देखा जा रहा है
  • vibe coding और AI-assisted development के व्यापक प्रसार से builders की एक नई श्रेणी बन रही है, जो खुद code लिखे बिना या उसकी ज्यादा परवाह किए बिना custom software बना रही है

  • नए user cohort की विशेषताएं

    • Lovable, Bolt, Create, v0 जैसे platforms ऐसे users को developer platforms की ओर ला रहे हैं, जो पहले पारंपरिक रूप से केवल technical users को service देते थे
    • इस cohort को उनके सवालों के प्रकार से आसानी से पहचाना जा सकता है
      • उनमें अभी problem-solving क्षमता, error codes पढ़ने की समझ, database server और web server के बीच अंतर, या load balancer जैसी चीजों का अर्थ समझने की क्षमता नहीं है
    • ये users अक्सर prototyping और production के बीच के चरण में अटक जाते हैं
      • कंपनियां इस usage को quality revenue की बजाय efficient marketing के रूप में वर्गीकृत करती हैं
      • उम्मीद है कि समय के साथ यह बदलेगा, क्योंकि डेवलपर अधिक उच्च abstraction स्तर पर काम करना शुरू करेंगे

  • गैर-तकनीकी टीम सदस्यों की भूमिका का विस्तार

    • गैर-तकनीकी टीम सदस्य coding और कंपनी के मुख्य product के बाहर के engineering काम के लिए कीमती developer time को मुक्त कराने में मदद कर रहे हैं
    • सही tools दिए जाने पर:
      • AE तकनीकी products के लिए custom demos बना सकते हैं
      • marketers X पर साझा करने के लिए sample apps बना सकते हैं
      • content marketers technical blog posts लिख सकते हैं

  • मूल्यवान skills की पुनर्परिभाषा

    • domain expertise और customer communication हर भूमिका में coding skills से अधिक महत्वपूर्ण होते जा रहे हैं
    • systems thinking और अधिक महत्वपूर्ण हो रही है, क्योंकि काम low-level implementation से orchestration और strategy की ओर बढ़ रहा है
    • वे व्यक्ति और टीमें सफल होंगी जो समझती हैं कि जटिल हिस्से कैसे जुड़ते हैं, कहां automation पर भरोसा किया जा सकता है, और कब मानवीय हस्तक्षेप जरूरी है
    • software delivery पहले से कहीं तेज और आसान हो गई है, लेकिन डेवलपर की बदलती परिभाषा sustainable business के मूल सिद्धांतों के महत्व को फिर से स्थापित करती है
    • Netlify CEO: "अभी 1.7 करोड़ JavaScript developers हैं, और ये पारंपरिक डेवलपर्स हैं। लेकिन अगले 10 वर्षों में यह संख्या 10 करोड़ तक पहुंचने की उम्मीद है"

नियम #6: मजबूत network effects शुरुआती ecosystem positioning को बढ़ावा देते हैं

  • पारंपरिक developer कंपनियां open source, community contributions, integrations और plugins के जरिए network effects को बढ़ाती रही हैं
  • अब agentic development के प्रसार के साथ network effects को फिर से परिभाषित और पुनर्कल्पित किया जा रहा है

  • agents के बीच network effects

    • जब AI agents दूसरे agents से communicate और compose कर सकते हैं, तब वे अधिक उपयोगी हो जाते हैं, और इससे agent-to-agent network effects उभरते हैं
    • उदाहरण: meetings schedule करने वाला scheduling AI agent तब अधिक शक्तिशाली होता है जब वह किसी दूसरे व्यक्ति के travel agent, expense management agent और calendar agent से communicate कर सके
    • यह MCP जैसे protocols के जरिए संभव है

  • data network effects का amplification

    • context के कारण data network effects और मजबूत हो जाते हैं
    • AI agents के पास जितना अधिक context होगा, वे उतने अधिक वांछित काम पूरे कर पाएंगे
    • उस context को रखने वाले products का मूल्य बढ़ जाता है
    • Linear के Product Intelligence इसका एक उदाहरण है
      • उसके पास हजारों engineering teams के वास्तविक काम करने के तरीकों पर वर्षों से संचित data है
      • इससे task assignment suggestions, issue classification और product operations को सरल बनाना संभव होता है

  • integration lock-in प्रभाव का कमजोर होना

    • जहां integration lock-in प्रभाव परंपरागत रूप से switching costs पैदा करता था, वहां network effects कमजोर पड़ रहे हैं
    • Recall CEO David Gu: "अब अलग-अलग APIs के बीच switching पहले से कहीं आसान है, क्योंकि integration code इंसानों को manually लिखने की जरूरत नहीं होती; AI agents इसमें मदद कर सकते हैं"
    • MCP lock-in को और कम करता है, क्योंकि इससे AI agents अपने आप tools को खोज और integrate कर सकते हैं
    • LLM आम तौर पर evaluation process के दौरान options पर research करने और उन्हें synthesize करने का काम हर किसी के लिए आसान बना देते हैं

  • AI-नेतृत्व वाले recommendation माहौल में विरोधाभास

    • ऐसे ecosystem में जहां developer tools की recommendation decisions AI चला रहा है, मानवीय subjective feedback की भूमिका एक विरोधाभास पेश करती है
    • AI agents ease of use जैसी subjective preferences को नजरअंदाज कर केवल performance और latency जैसे objective performance metrics पर ध्यान दे सकते हैं
    • दूसरी ओर, समय के साथ सीखते हुए AI agents subjective human feedback पर और अधिक निर्भर भी हो सकते हैं
    • यह विरोधाभास बताता है कि सबसे उच्च गुणवत्ता वाले products किसी भी स्थिति में लाभ में रहते हैं
      • developer-led growth, product launches, documentation, educational content, conferences, community forums और reviews की अहमियत बहुत बढ़ जाती है
      • speed पहले से कहीं अधिक महत्वपूर्ण है, और first-mover advantage चक्रवृद्धि की तरह काम करता है

  • नेताओं के विविध दृष्टिकोण

    • ये नियम अब भी WIP हैं, और कंपनी leaders अलग-अलग दृष्टिकोण पेश कर रहे हैं
    • Vapi CTO Nikhil Gupta: "AI गैर-वस्तुनिष्ठ आधार वाले network effects को कमजोर करता है और वस्तुनिष्ठ network effects को मजबूत करता है। उदाहरण के लिए, लोग सोच सकते हैं कि Stripe की API दूसरों की तुलना में सबसे आसान है, लेकिन Stripe API और Ayden API की तुलना करते समय AI agents ease of use की परवाह नहीं करेंगे। लेकिन अगर Stripe अधिक reliable है, तो सभी AI agents वही चुनेंगे"
    • Resolve CEO Spiros Xanthos: "agent-first GTM hype नहीं, proof के बारे में है। अगर आप customer environment में पहुंचकर महत्वपूर्ण results देते हैं, तो adoption स्वाभाविक रूप से बढ़ता है। यही नई evangelism है"

नियम #7: प्लेटफ़ॉर्म इंजीनियर autonomous flow architect के रूप में विकसित हो रहा है

  • प्लेटफ़ॉर्म इंजीनियरिंग की भूमिका software management से autonomous engineering flow बनाने तक फैल रही है
  • प्लेटफ़ॉर्म इंजीनियर सभी तकनीकी टीमों के user experience के लिए ज़िम्मेदार हैं
  • संगठन के भीतर इसका महत्व hiring urgency में भी लगातार अधिक दिख रहा है

  • ज़िम्मेदारी के दायरे में बदलाव

    • अब प्लेटफ़ॉर्म इंजीनियरों को इन तकनीकी क्षमताओं की ज़रूरत है
      • स्पष्ट human oversight चरणों के साथ agentic flow design करना
      • agents द्वारा गलत काम किए जाने के जोखिम को संभालने के लिए मज़बूत guardrails लागू करना
      • uptime और reliability से आगे बढ़कर system और information architecture की ownership लेना
    • agents रोज़मर्रा के काम संभालें, जबकि सबसे जटिल रणनीतिक फ़ैसलों के लिए AI control center बनाना

  • software engineer की भूमिका में बदलाव

    • जब AI agents वास्तविक code generation का बड़ा हिस्सा संभालने लगते हैं, तो software engineers कारीगर से अपने सिस्टम के product owner में बदलते हैं
    • इस बुनियादी बदलाव का मतलब है कि engineers implementation details की तुलना में outcomes में ज़्यादा रुचि लेने लगते हैं

  • नए workflow की आवश्यकताएँ

    • मज़बूत testing और monitoring बेहद महत्वपूर्ण हो जाते हैं
    • documentation को सिर्फ code structure नहीं, बल्कि system behavior भी समझाना चाहिए
    • code review syntax checks से business logic और architecture decisions के validation की ओर शिफ्ट होता है

  • संगठनात्मक निहितार्थ

    • इसके निहितार्थ individual productivity से आगे तक जाते हैं
      • teams को knowledge transfer के लिए नई प्रक्रियाओं की ज़रूरत होती है
      • जब इंसान मूल implementation logic को पूरी तरह नहीं समझते, तो incident response और कठिन हो जाता है
      • जब generated code इंसानों के पढ़ने लायक नहीं रहता, तो technical debt अलग तरीके से जमा होता है
    • जब engineer अपने code के लेखक नहीं बल्कि operator बन जाते हैं, तब system reliability बनाए रखने के लिए observability, automated testing, और architecture governance में भारी निवेश की ज़रूरत होती है

  • validation bottleneck

    • जैसे-जैसे AI अभूतपूर्व गति से code बनाता है, मुख्य bottleneck code लिखने से correctness validation की ओर शिफ्ट होता है
    • यह development speed को बुनियादी रूप से बदल देता है
      • teams कुछ ही मिनटों में हज़ारों lines of code बना सकती हैं
      • लेकिन यह जाँचने में कहीं ज़्यादा समय लगता है कि वह इच्छित रूप से काम करता है, मौजूदा systems के साथ ठीक से integrate होता है, और security व performance requirements को पूरा करता है
    • बेहतर testing frameworks, real-time validation tools, और visual confirmation systems के ज़रिए validation speed को optimize करने वाली कंपनियों को AI-assisted development cycle में बड़ा फ़ायदा मिलता है

  • Render CEO का नज़रिया

    • "प्लेटफ़ॉर्म management में सबसे महत्वपूर्ण लगातार बदलाव infrastructure management से developer workflow optimization की ओर शिफ्ट है"
    • engineering teams अब यह समझ रही हैं कि custom internal development और deployment platforms को बनाना और maintain करना अक्सर एक non-differentiated काम होता है जो core business से resources खींच लेता है
    • Render जैसी managed platforms का उपयोग करके base infrastructure संभालने देने पर प्लेटफ़ॉर्म इंजीनियर higher-value automation पर फ़ोकस कर सकते हैं

नियम #8: defensibility का मतलब लगातार evolution और platform control है

  • मूल रूप से platform बनने का अर्थ है ऐसा scalable infrastructure बनाना जिस पर और जिसके साथ third parties build कर सकें
    • ऐसा ecosystem सक्रिय करना जो जितने अधिक users योगदान दें और जितना अधिक वास्तविक community love दिखाएँ, उतना अधिक मूल्यवान बने

  • SaaS युग से निरंतरता

    • यह अवधारणा SaaS युग से लगातार बनी हुई है
    • AI युग defensibility के कुछ खास pillars को और ऊँचा उठाता है

  • प्रमुख defensibility तत्व

    • 1. entry point control
      • जैसे GitHub का code repository ownership या VS Code का text editor dominance
      • यह platform को स्थापित user behavior के ऊपर functionality बढ़ाने का रणनीतिक अधिकार देता है
    • 2. data advantage
      • यह proprietary product datasets और company-specific context के ज़रिए प्रकट होता है, जो ऐसे features सक्षम करता है जिन्हें competitors copy नहीं कर सकते

  • सबसे बुनियादी बदलाव: continuous evolution

    • continuous evolution सबसे महत्वपूर्ण है
    • सबसे अच्छे platforms कई AI models, data sources, और workflows को सक्रिय रूप से orchestrate करके autonomous actions करते हैं
      • उनके पास ecosystem से आने वाला unique data होने की प्रवृत्ति होती है
      • वे agentic और customer interactions से मिलने वाले real-time feedback loops के लिए data का तेज़ी से उपयोग कर सकते हैं

  • गति का महत्व

    • speed अहम है, और यह अतिरिक्त functionality देने तथा strategy बनाने—दोनों में महत्वपूर्ण है
    • कंपनियों को SaaS युग की तुलना में बहुत पहले Act 2 और Act 3 vision के बारे में सोचना होगा
    • यह आगे कैसे evolve करता है, इसे देखना दिलचस्प होगा

  • Port CEO का नज़रिया

    • "काम करने के तरीके को बदलने वाला पहला होना महत्वपूर्ण है। product perspective से देखें तो ऐसी चीज़ बनाना ज़रूरी है जो लगातार evolve करती रहे"
    • "उदाहरण के लिए CRM जैसी platform — कोई उसे manage करता है, control करता है, उसके बारे में opinion रखता है, और core building blocks से iterate करता है"

अतिरिक्त अनुशंसित पठन सामग्री

संबंधित पढ़ाई

1 टिप्पणियां

 
progdesigner 2025-10-28

इसलिए क्या करना चाहिए, यह अभी तक किसी को भी नहीं पता
तेज़ी से प्रतिक्रिया देना और बदलते रहना ही जीवित रहने की रणनीति बन जाने वाला
ऐसा दौर लगता है