Engineering আর Product-এর মধ্যে Data Silo
PM আর engineer ভিন্ন টুল, ভিন্ন ভাষা, আর ভিন্ন timeline ব্যবহার করে। Silo কীভাবে তৈরি হয় – আর আসলে কী ঠিক করে।
By Ellis Keane · 2026-03-16
কোনো এক সময়ে, "product-engineering alignment" একটা job title হয়ে গেছে, এমন কিছুর বদলে যা competent মানুষ একসাথে কাজ করলে এমনিতেই হতো। কোম্পানিরা এখন dedicated মানুষ hire করে যাদের পুরো কাজ হলো দুই গ্রুপ smart মানুষ – যারা একই Slack workspace-এ বসে, একই standup-এ যায়, আর theoretically একই goal-এ কাজ করে – তারা যেন আসলে বুঝতে পারে অন্য গ্রুপ কী করছে। Engineering আর product-এর মধ্যে যে data silo এটা necessary করে, সেটা মানুষের সমস্যা না। এটা tooling সমস্যা।
PM আর engineer যথেষ্ট communicate করে। সমস্যা হলো তারা সম্পূর্ণ ভিন্ন system-এ কাজ করে, আর সেই system-গুলোর মধ্যে যে silo তৈরি হয় সেটা structural – modern team কীভাবে টুল choose করে তার architecture-তে baked-in। কোনো পরিমাণ "let's align more often" এমন সমস্যা ঠিক করে না যেখানে টুলগুলোর নিজেদের একে অপরের ব্যাপারে কোনো awareness নেই। The result is a gap in cross-tool project visibility that no amount of extra syncs can close.
দুটো বাস্তবতা
আমি Sugarbug বানানোর নিজের অভিজ্ঞতা থেকে বলছি, কারণ আমরা প্রতিদিন এটা live করি আর abstract version-এর চেয়ে specifics বেশি useful মনে হয়।
PM side (আমাদের ক্ষেত্রে বেশিরভাগ আমি) থাকে Notion-এ। Spec সেখানে লেখা হয়, priority track হয়, customer conversation log হয়, feature request-এর running list প্রতি সপ্তাহে বাড়ে। Notion-এ "কেন" থাকে – কেন কিছু বানাচ্ছি, customer আসলে কী বলেছে, কোনো decision-এর পেছনে কোন strategic context আছে। Messy, sprawling, আর এক লাইন কোড লেখার আগে বেশিরভাগ important thinking এখানেই হয়।
এদিকে, engineer-রা থাকে Linear আর GitHub-এ। Linear-এ task, sprint cycle, dependency chain আর blocking issue। GitHub-এ কোড, pull request, review thread যেখানে মানুষ (আশা করি) constructively implementation detail নিয়ে তর্ক করে। এখানে "কীভাবে" আর "কখন" থাকে – কীভাবে কিছু বানানো হচ্ছে, কখন ship হবে, পথে কী আছে।
দুটো বাস্তবতাই accurate, দুটোই essential, আর একে অপর থেকে সম্পূর্ণ disconnected। তাদের মধ্যের gap-ই সেখানে requirement পুরোনো হয় আর rework জমতে শুরু করে।
Engineering আর Product-এর মধ্যে Data Silo আসলে কীভাবে তৈরি হয়
এটা deliberate choice ভাবতে মন চায় – কেউ ইচ্ছাকৃত তথ্য আলাদা রাখার সিদ্ধান্ত নিয়েছে। বাস্তবে, silo তৈরি হয় সম্পূর্ণ reasonable behavior থেকে যা কেউ ক্ষতিকর বলে intent করেনি।
PM Notion-এ spec লেখে, Slack-এ engineering channel-এ link করে, আর handoff শেষ মনে করে। Engineer spec পড়ে, তিনটা Linear issue বানায়, build শুরু করে। এখন পর্যন্ত সব কাজ করছে।
কিন্তু তারপর spec বদলায় – customer conversation priority shift করে, বা business context evolve করে। PM Notion doc update করে Slack-এ change নিয়ে note drop করে। Engineer, coding session-এ ডুবে থাকায়, ঘণ্টাখানেক Slack message দেখে না। ততক্ষণে পুরোনো spec-এর বিরুদ্ধে তিনটা feature-র দুটো build করে ফেলেছে, আর Linear-এর তৃতীয় issue এখনও এমন requirement reference করছে যা আর নেই।
কেউ অসাবধান ছিল না। কেউ "communicate করতে ব্যর্থ" হয়নি। তথ্য এক system-এ ছিল আর কাজ হচ্ছিল অন্যটায়, আর তাদের মধ্যে connective tissue ছিল একটা Slack message যা সঠিক মানুষ দেখার আগেই অন্য thread-এর নিচে চাপা পড়ে গেছে।
এটা বারবার হয় – প্রতিটা spec, প্রতিটা sprint, প্রতিটা quarter – আর drift compound হয়। Product মনে করে কী হচ্ছে আর engineering আসলে কী build করছে – তাদের মধ্যে gap প্রতিটা handoff-এ বাড়ে যেটা সঠিক সময়ে সঠিক মানুষের message notice করার ওপর নির্ভর করে।
"ভালো Communication" কেন এটা ঠিক করে না
আমি retrospective-এ বসেছি যেখানে action item ছিল "change বেশি proactively communicate করো," আর (ভালোবেসে বলছি) এটা organizational equivalent কাউকে বলা "আরেকটু organized হও।" শুনতে actionable, Confluence page-টা productive দেখায়, আর সমস্যা তৈরি করা system-এ কোনো পরিবর্তন আনে না। একই retro action item আমরা তিনবার run করেছি – আমি চেক করেছি।
ভালো communication engineering আর product-এর মধ্যে data silo solve না করার কারণ হলো communication ইতিমধ্যেই হচ্ছে – data আছে, decision নেওয়া হচ্ছে আর record হচ্ছে। শুধু এমন টুলে record হচ্ছে যেগুলো একে অপরের খবর রাখে না।
Notion জানে না যে spec তিনটা Linear issue-তে ভেঙে গেছে। Linear জানে না যে issue-র পেছনে requirement দুই ঘণ্টা আগে Notion-এ বদলে গেছে। GitHub-এর ধারণা নেই যে review-তে থাকা PR এমন feature implement করে যার priority PM-এর Notion board-এ এইমাত্র নেমে গেছে। প্রতিটা টুল ঠিক design অনুযায়ী কাজ করছে – শুধু একসাথে কাজ করার জন্য design করা হয়নি।
"সোমবার সকালে confirm করায় একটা dark comedy আছে যে তুমি যেসব টুলের জন্য pay করো সেগুলো weekend-এ চুপচাপ reality থেকে diverge করেনি।" – Ellis Keane
ফলে PM-রা spec বদলালে Notion থেকে Linear-এ manually mirror করে, engineer-রা Slack-এ PM-কে ping করে "এটা কি এখনও plan?" জিজ্ঞেস করতে, আর lead-রা সোমবার সকালে board cross-reference করে drift চেক করে। আমরা নিজেরা দেখেছি সপ্তাহে কয়েক ঘণ্টা যায় যা আসলে manual data synchronisation – এমন টুলের মধ্যে যেগুলো, theory-তে, ইতিমধ্যে একে অপরের খবর রাখার কথা।
Systems Fix আসলে দেখতে কেমন
দুটো টুলের মধ্যে gap দেখলে instinct হলো bridge বানানো – Zapier automation, webhook, sync script। সহজ, predictable flow-র জন্য (Linear issue "Done"-এ গেলে Notion status update করো), এটা ভালো কাজ করে।
কিন্তু engineering আর product-এর মধ্যে data silo-তে context জড়িত, শুধু status না। PM শুধু status field বদলায়নি; spec-এর একটা paragraph rewrite করেছে যেটা বদলে দেয় তিনটা Linear issue-র দুটোর জন্য "done" মানে কী। সাধারণ status webhook requirement-level change মিস করে, যদি না ওপরে diff logic আর semantic mapping add করো, যেটা বেশিরভাগ টিম কখনও বানাতে পৌঁছায় না।
তোমার আসলে দরকার এমন কিছু যেটা টুল জুড়ে data-র মধ্যে relationship বোঝে – শুধু "এই Notion page এই Linear issue-র সাথে linked" না, বরং "spec-এর এই section এই issue-র requirement describe করে, আর সেই section এইমাত্র বদলেছে।" Goal হলো spec edit-কে impacted issue-তে automatically map করা, কাউকে notice করে change propagate করার ওপর নির্ভর না করে।
এটাই sync layer আর নলেজ গ্রাফের পার্থক্য। Sync layer টুলের মধ্যে data copy করে। নলেজ গ্রাফ data কীভাবে relate করে সেটা track করে, relationship কখন বদলায় detect করে, আর যাদের জানা দরকার তাদের কাছে change surface করে।
Sugarbug-এ আমরা এভাবেই কাজ করছি – PM আর engineer যেসব টুল ইতিমধ্যে ব্যবহার করে (Notion, Linear, GitHub, Slack, Figma) সেগুলোকে নলেজ গ্রাফে connect করে spec, task, code, আর conversation-এর মধ্যে relationship maintain করে। আমরা এখনও early-তে আছি (সৎভাবে বলতে গেলে, semantic diff detection-কে scale-এ reliable করা নিয়ে অনেক কিছু এখনও বুঝতে পারিনি), কিন্তু core graph কাজ করছে আর ইতিমধ্যে এমন spec-drift ধরেছে যা rework হয়ে যেত।
Engineering আর product-এর মধ্যে data silo তৈরি হয় কারণ টুলগুলো structurally disconnected, মানুষ খারাপ communicate করে বলে না। Fix হলো relationship level-এ data connect করা, আরও communication channel add করা না।
এই সপ্তাহেই কী করতে পারো
আমি ভান করব না একমাত্র উত্তর "Sugarbug ব্যবহার করো।" এখনই, তোমার যে টুল চলছে সেগুলো দিয়েই, product-engineering data silo-র সবচেয়ে খারাপ effect কমাতে কিছু করতে পারো।
Cross-reference explicit, bidirectional, আর owned করো। প্রতিটা Notion spec-এর নিচে "Linear Issues" section থাকুক যেটা spawned issue-তে link করে, আর প্রতি Linear issue source spec-এ link করুক। প্রতি spec-এ একজনকে cross-reference-এর owner assign করো – পুরো টিম না, একজন, নাম সহ। "সবাই responsible" version ট্রাই করেছি আর (অনুমান করতে পারো) কেউই ছিল না। Link সময়ের সাথে drift করবে, কিন্তু named owner থাকলে drift notice হলে কাউকে ping করার জায়গা থাকে।
"Spec change" ritual establish করো trigger দিয়ে, reminder দিয়ে না। Spec materially বদলালে (typo না – actual requirement change), PM linked Linear issue update করবে Notion tab close করার আগে। পরে না, "সময় পেলে" না – tab close করার আগে। প্রতিটা affected issue-তে comment হবে এক লাইন: কী বদলেছে, updated section-এর link, আর issue-র acceptance criteria এখনও valid কি না। Physical action-এর সাথে (tab close) update বাঁধা memory-র ওপর নির্ভরের চেয়ে ভালো কাজ করে দেখেছি, কারণ memory-ই আসলে silo বানিয়েছে।
শুক্রবারে ১৫ মিনিটের priority-match check চালাও। একজন (সপ্তাহে rotate করো) PM-এর Notion-এর top ৫ priority আর engineering sprint-এর Linear-এর top ৫ পাশাপাশি তুলে ধরবে। প্রশ্ন "এগুলো কি identical?" না – হবে না, আর সেটা ঠিক। প্রশ্ন হলো "এদের কোনোটা কি actively একে অপরের বিরোধী?" PM-এর #১ priority sprint-এ কোথাও না থাকলে সোমবারে সেই conversation হওয়া দরকার, status update না।
এগুলো manual process, আর shelf life আছে। পাঁচ engineer আর দুই PM-এ tedious কিন্তু কাজ করে। পনেরো engineer, তিন PM, আর Figma যোগ করা design team-এ cross-tool relationship হাতে track করার চেয়ে দ্রুত বাড়ে। কিন্তু তোমাকে শেখাবে product engineering alignment-এর সবচেয়ে খারাপ gap আসলে কোথায় – আর সেই diagnostic value effort-এর worth, পরে পুরোটা automate করলেও।
Long-term fix Sugarbug হোক বা অন্য কিছু (আমরা obviously মনে করি সঠিক জিনিস বানাচ্ছি, কিন্তু biased), product management engineering collaboration সমস্যা তখনই resolve হয় যখন টুলগুলো নিজেই semantic level-এ connected হয়, আর মানুষ app-এর মধ্যে context shuttle করার বদলে decision নেওয়ায় focus করতে পারে। That means investing in shared cross-tool visibility for product and engineering and knowing what the team is doing without daily check-ins – both of which depend on connecting the data rather than adding more communication overhead.
তোমার manual cross-reference ধরে রাখলে, যতক্ষণ পারো চালাও। যদি একই retrospective action item communication নিয়ে বারবার আসতে থাকে, সমস্যা তোমার মানুষ না। তোমার data architecture।
Notion, Linear, GitHub, আর Slack-কে একটা নলেজ গ্রাফে connect করো – যাতে spec change স্বয়ংক্রিয়ভাবে সঠিক engineer-দের কাছে পৌঁছায়।
Q: Product-engineering টিমের জন্য Sugarbug setup করতে কত সময় লাগে? A: প্রাথমিক connection-এ প্রতি টুলে কয়েক মিনিট – OAuth-এর মাধ্যমে Linear, GitHub, Notion, Slack, আর Figma authenticate করো, আর Sugarbug সঙ্গে সঙ্গে নলেজ গ্রাফ বানানো শুরু করে। Graph এক-দুই দিনের মধ্যে meaningfully useful হয়ে যায়, existing data ingest করে spec, issue, আর conversation-এর মধ্যে relationship map করতে শুরু করে। Onboarding flow refine করছি, কিন্তু aim হলো account connect করা ছাড়া কিছু configure করতে না লাগা।
Q: Sugarbug কি Linear, Notion, বা আমাদের বিদ্যমান কোনো টুল replace করে? A: না। Sugarbug existing টুলের পাশে বসে connect করে – কিছু replace করে না। PM-রা Notion-এ spec লিখতে থাকে, engineer-রা Linear আর GitHub-এ কাজ করতে থাকে, আর Sugarbug তাদের মধ্যে relationship maintain করে যাতে transit-এ context হারিয়ে না যায়। এটাকে তোমার existing টুলের মধ্যে connective tissue ভাবো।
Q: Sugarbug কি Notion spec বদলালে সঠিক engineer-দের alert করতে পারে? A: আমরা যা বানাচ্ছি তার core অংশ এটা। Notion-এ spec বদলালে Sugarbug চিহ্নিত করে কোন Linear issue linked আর সেই issue-তে কাজ করা engineer-দের কাছে change surface করে। Semantic detection piece (কোন change material আর কোনটা cosmetic সেটা বোঝা) নিয়ে iterate করছি, কিন্তু cross-tool linking আর basic change detection কাজ করছে।
Q: এই সমস্যার জন্য sync tool আর নলেজ গ্রাফের পার্থক্য কী? A: Sync tool app-এর মধ্যে status change copy করে – Linear issue "Done"-এ গেলে Notion checkbox update করো। নলেজ গ্রাফ data কীভাবে relate করে সেটা track করে: এই spec এই তিনটা issue-র requirement describe করে, আর acceptance criteria বদলেছে, যেটা এখনও ship না হওয়া দুটো issue-কে affect করে। পার্থক্যটা সবচেয়ে বেশি matter করে যখন change semantic, শুধু status-level না।
Q: Product-engineering alignment কি communication সমস্যা না data সমস্যা? A: আমাদের অভিজ্ঞতায়, এটা প্রায় সবসময় data সমস্যা যাকে communication সমস্যা হিসেবে ভুল diagnose করা হয়। টিম communicate করছে – শুধু এমন টুলের মাধ্যমে যেগুলো একে অপরের খবর রাখে না। সেই টুলের মধ্যে data flow ঠিক করলে alignment issue resolve হতে থাকে যা কোনো পরিমাণ retro বা sync meeting পারেনি।