आप और आपका प्रोडक्ट मैनेजर इस बात पर असहमत हैं कि आगे क्या बनाना है। आप इसे कैसे सुलझाते हैं?

फैसले के अधिकार को बहस से अलग कीजिए। क्या और क्यों प्रोडक्ट का है, कैसे और कितने समय में इंजीनियरिंग का, और ज़्यादातर असहमतियां अधिकार की नहीं, किसी साझा अनजान चीज़ की होती हैं। धारणाएं सामने लाइए, डेटा या कोई सस्ता प्रयोग लाइए, और तकनीकी पसंद नहीं, यूज़र तथा बिज़नेस के नतीजों की भाषा में बहस कीजिए। फिर भी गतिरोध रहे तो विकल्पों के एक साझा लिखित बयान के साथ मिलकर escalate कीजिए।

पहले मैं देखता हूं कि यह मेरा फैसला है भी या नहीं, क्योंकि क्या बनेगा यह प्रोडक्ट का है और कैसे तथा कितने समय में यह मेरा, और बहुत सारा गढ़ा हुआ टकराव इंजीनियरिंग लीडर्स के परोक्ष रूप से roadmap के फैसले लेने की कोशिश से आता है। अगर मेरी आपत्ति असल में लागत या जोखिम की है, तो मैं उसे उनकी भाषा में कहता हूं। यह नहीं कि यह डिज़ाइन गलत है, बल्कि यह कि इस तरीके का मतलब है कि हम चौथी तिमाही में enterprise contract को बिना एक और rebuild के सपोर्ट नहीं कर पाएंगे, और यह रहा छह हफ्ते का फर्क। यह ऐसी बिज़नेस दलील है जिसे वे तौल सकते हैं, और आधे मौकों पर वही अपने आप उनका मन बदल देती है। आमतौर पर हम नीचे पड़ी असली असहमति ढूंढ लेते हैं, जो अक्सर एक ही अनजान चीज़ के बारे में अलग अलग अंदाज़ा होती है, और फिर काम का सवाल यह होता है कि पता लगाने का सबसे सस्ता तरीका क्या है। पिछली बार हमने महीना भर बहस करने की जगह एक हफ्ते में दो ग्राहकों के लिए एक कटा छंटा वर्जन बनाया, और डेटा ने मामला उनके पक्ष में तय कर दिया, मेरे नहीं। जब हम सच में सहमत न हो पाएं तो हम विकल्पों के एक लिखित बयान के साथ साथ मिलकर साझा लीडरशिप के पास जाते हैं, क्योंकि अलग अलग एक दूसरे के पीछे से जाना ही साझेदारियों के मरने का तरीका है।