Jobs to Be Done Framework দিয়ে Customer Need বোঝা: ফিচারের আড়ালের আসল চাহিদা খুঁজুন

একটি SaaS টিমের কাছে কয়েকজন customer একই অনুরোধ করলেন—“রিপোর্টটা Excel-এ export করার ব্যবস্থা দিন।” টিমও ধরে নিল, এটাই গুরুত্বপূর্ণ Customer Need। feature বানানো হলো, release হলো, announcement গেল। কিন্তু কয়েক সপ্তাহ পর দেখা গেল, export feature খুব কম মানুষই ব্যবহার করছেন।

সমস্যা কোথায়?

Customer যা বলেছিলেন, টিম সেটাই বানিয়েছে। কিন্তু customer কেন Excel export চাইছিলেন, সেই প্রশ্নটি ঠিকভাবে করা হয়নি। হয়তো তাঁর আসল সমস্যা ছিল প্রতি সোমবার management meeting-এর আগে দ্রুত এমন একটি রিপোর্ট তৈরি করা, যেটি finance team-এর বাইরের মানুষও বুঝবে। Excel export ছিল সেই সমস্যার সম্ভাব্য একটি সমাধান, সমস্যাটি নিজে নয়।

Jobs to Be Done Framework বা JTBD Framework ঠিক এই জায়গাটাতেই কাজে আসে। এটি product team-কে feature request-এর পেছনে থাকা আসল Customer Need, পরিস্থিতি, Product Roadmap এবং প্রত্যাশিত অগ্রগতি বুঝতে সাহায্য করে।

বিপণন জগতে বহুল উদ্ধৃত একটি ধারণা আছে—“মানুষ কোয়ার্টার-ইঞ্চি ড্রিল কেনে না, তারা কোয়ার্টার-ইঞ্চি ছিদ্র চায়।” কথাটি প্রায়ই Theodore Levitt-এর সঙ্গে যুক্ত করা হয়। বাক্যটির সুনির্দিষ্ট উৎস নিয়ে আলোচনা থাকলেও মূল শিক্ষা পরিষ্কার: customer আপনার product নিয়ে যতটা আগ্রহী, তার চেয়ে বেশি আগ্রহী নিজের কাজটি শেষ করা নিয়ে।

JTBD সেই চিন্তাটিকে আরেক ধাপ এগিয়ে নিয়ে যায়।

Jobs to Be Done Framework আসলে কী বলে?

Jobs to Be Done-এর কেন্দ্রীয় ধারণাটি খুব সাধারণ: মানুষ সাধারণত কোনো product বা service শুধু productটির মালিক হওয়ার জন্য কেনে না। জীবনের একটি নির্দিষ্ট পরিস্থিতিতে কিছু অগ্রগতি করার জন্য সেটিকে ব্যবহার করে।

JTBD-এর ভাষায় বলা হয়, customer একটি product-কে কোনো “job” করার জন্য “hire” করেন।

এখানে job বলতে চাকরি বোঝানো হচ্ছে না। এটি হলো customer যে কাজটি সম্পন্ন করতে চান, যে সমস্যা থেকে বের হতে চান বা যে অবস্থায় পৌঁছাতে চান।

ধরা যাক, একজন মানুষ food delivery app ব্যবহার করছেন। বাইরে থেকে দেখলে job হলো “খাবার অর্ডার করা।” কিন্তু একটু গভীরে গেলে দেখা যেতে পারে, তাঁর আসল job:

“অফিস থেকে ক্লান্ত হয়ে ফেরার পর রান্নার ঝামেলায় না গিয়ে দ্রুত পরিবারের রাতের খাবারের ব্যবস্থা করা।”

এই job-এর সঙ্গে নির্দিষ্ট কোনো app-এর নাম জড়িত নয়। আজ তিনি একটি app ব্যবহার করছেন। কাল কাছের restaurant-এ ফোন করতে পারেন। পরশু frozen meal কিনতে পারেন। এমনকি বাড়ির জন্য একজন রান্নার লোক রাখাও একই পরিস্থিতিতে বিকল্প সমাধান হতে পারে।

এখানেই JTBD-এর একটি গুরুত্বপূর্ণ শিক্ষা আছে: আপনার competitor সব সময় আপনার মতো দেখতে আরেকটি product নয়।

Customer যে job সম্পন্ন করতে চাইছেন, সেই job-এর জন্য তিনি যেসব বিকল্প “hire” করতে পারেন, সেগুলোও আপনার প্রতিযোগী।

এই দৃষ্টিভঙ্গি প্রোডাক্ট স্ট্র্যাটেজি বদলে দেয়। তখন প্রশ্ন আর শুধু “competitor কোন feature দিয়েছে?” থাকে না। প্রশ্ন হয়, “মানুষ এখন এই কাজটি কীভাবে করছে, আর আমাদের product কেন সেই পদ্ধতির চেয়ে ভালো হবে?”

JTBD কোথা থেকে এল?

Jobs to Be Done-এর ইতিহাসকে একজন ব্যক্তি একটি নির্দিষ্ট দিনে তৈরি করেছেন—এভাবে বলা ঠিক হবে না। এর সঙ্গে innovation, marketing এবং customer behavior নিয়ে আগের বিভিন্ন চিন্তার যোগ আছে।

তবে আধুনিক business ও product management জগতে JTBD-কে ব্যাপকভাবে পরিচিত করার ক্ষেত্রে Harvard Business School-এর অধ্যাপক Clayton Christensen-এর ভূমিকা সবচেয়ে বেশি আলোচিত। তিনি product-এর বৈশিষ্ট্যের বদলে customer কোন পরিস্থিতিতে কোন অগ্রগতি করতে চাইছেন, সেটিকে innovation-এর গুরুত্বপূর্ণ unit হিসেবে তুলে ধরেন।

এই ধারণা বোঝাতে বহুল পরিচিত milkshake উদাহরণটি ব্যবহার করা হয়। একটি fast-food chain বুঝতে চাইছিল, মানুষ কেন milkshake কেনে। demographic profile বা milkshake-এর স্বাদ নিয়ে সরাসরি মতামতের বাইরে গিয়ে গবেষকেরা কেনার পরিস্থিতি বোঝার চেষ্টা করেন।

তখন দেখা যায়, একই product ভিন্ন পরিস্থিতিতে ভিন্ন job করতে পারে। কারও কাছে যাত্রাপথে সময় কাটানো এবং কিছুক্ষণ পেট ভরা রাখার একটি সুবিধাজনক উপায় হতে পারে milkshake। আবার অন্য পরিস্থিতিতে একই product-এর ভূমিকা একেবারে আলাদা হতে পারে।

এই উদাহরণের আসল শিক্ষা milkshake নয়। শিক্ষা হলো—product category দেখে customer motivation সব সময় বোঝা যায় না। Christensen-এর আলোচনায় এই case-টি JTBD বোঝানোর অন্যতম পরিচিত উদাহরণ হয়ে ওঠে।

JTBD-এর আশপাশে আরও গুরুত্বপূর্ণ ধারা তৈরি হয়েছে। Tony Ulwick customer যে ফলাফল অর্জন করতে চান, তাকে আরও পদ্ধতিগতভাবে ধরার জন্য Outcome-Driven Innovation বা ODI approach গড়ে তুলেছেন। তাঁর পদ্ধতিতে job এবং desired outcome-কে innovation decision-এর ভিত্তি হিসেবে দেখা হয়।

Bob Moesta এবং তাঁর সহযোগীদের কাজ JTBD interview, switching behavior এবং customer decision-এর timeline বোঝার পদ্ধতিকে বিশেষভাবে জনপ্রিয় করেছে। তাঁর কাজের সঙ্গে Four Forces of Progress model-টিও ঘনিষ্ঠভাবে যুক্ত।

তাই JTBD-কে একটি মাত্র fixed template হিসেবে দেখলে ভুল হবে। এটি বরং একই কেন্দ্রীয় চিন্তাকে ঘিরে তৈরি কয়েকটি সম্পর্কিত পদ্ধতি ও tool-এর পরিবার।

Customer Need বুঝতে JTBD কেন Persona-এর চেয়ে আলাদা?

User persona খারাপ কিছু নয়। সঠিক কাজে persona বেশ উপকারী। কিন্তু persona আর JTBD একই প্রশ্নের উত্তর দেয় না।

ধরা যাক, আপনার target customer সম্পর্কে লেখা আছে:

“২৮ বছর বয়সী, ঢাকায় থাকেন, চাকরিজীবী, মধ্যম আয়ের, smartphone ব্যবহার করেন এবং health-conscious।”

তথ্যগুলো marketing campaign চালাতে কাজে লাগতে পারে। কিন্তু তিনি মঙ্গলবার রাত ৮টায় dinner নিয়ে কী সিদ্ধান্ত নেবেন, সেটি এসব তথ্য থেকে নিশ্চিতভাবে জানা যাচ্ছে না।

JTBD হয়তো বলবে:

“ব্যস্ত কর্মদিবসে ২০ মিনিটের মধ্যে স্বাস্থ্যকর রাতের খাবারের ব্যবস্থা করতে চাই, যাতে রান্নার চাপ ছাড়াই নিজের খাবারের লক্ষ্য ধরে রাখতে পারি।”

এখন product team-এর সামনে অনেক বেশি কার্যকর context রয়েছে।

JTBD দৃষ্টিভঙ্গি বনাম ঐতিহ্যগত segmentation

একই বয়স, একই পেশা এবং একই শহরে থাকা দুই ব্যক্তি সম্পূর্ণ আলাদা কারণে একই product কিনতে পারেন। আবার demographic দিক থেকে একেবারেই আলাদা দুজন মানুষ একই job-এর জন্য একই solution বেছে নিতে পারেন।

এ কারণেই JTBD persona-কে ধ্বংস করতে আসে না; বরং persona যে প্রশ্নের উত্তর দিতে পারে না, সেটির উত্তর খোঁজে।

Job Statement কীভাবে লিখতে হয়?

JTBD practice-এ বহুল ব্যবহৃত একটি সহজ format হলো:

“যখন [পরিস্থিতি], আমি চাই [মোটিভেশন], যাতে [প্রত্যাশিত ফলাফল]।”

English-এ এটি প্রায়ই “When…, I want to…, so I can…” ধরনের statement হিসেবে লেখা হয়।

এটি JTBD-এর একমাত্র বা সর্বজনস্বীকৃত job-definition format নয়। বিভিন্ন JTBD পদ্ধতিতে job statement লেখার নিয়ম আলাদা হতে পারে। তবে customer-এর context, motivation এবং outcome একসঙ্গে ধরার জন্য এই conversational template product team-এর কাছে বেশ কার্যকর।

একটি ভালো job statement পড়ে তিনটি প্রশ্নের উত্তর পাওয়া উচিত।

কখন এই need তৈরি হচ্ছে?

Customer তখন কী করতে চাইছেন?

সফল হলে তাঁর জীবনে কী বদলাবে?

“আমি সহজ accounting software চাই”—এটি দুর্বল job statement। এখানে situation নেই, আসল motivation নেই, outcome-ও পরিষ্কার নয়।

তার বদলে যদি লেখা হয়—

“মাস শেষের সময় আমি দ্রুত আয়-ব্যয়ের হিসাব মিলিয়ে নিতে চাই, যাতে accountant-এর সাহায্যের জন্য অপেক্ষা না করেও business-এর নগদ অবস্থাটা বুঝতে পারি।”

এখন product team কাজ করার মতো তথ্য পেল।

Job Statement টেমপ্লেট ও উদাহরণ

Job statement লেখার সময় product-এর নাম ঢুকিয়ে দেওয়া সাধারণত ভালো ধারণা নয়।

“যখন project update দিতে হবে, আমি আমাদের dashboard খুলতে চাই…” বললে solution আগে থেকেই statement-এর মধ্যে ঢুকে গেল।

ভালো version হতে পারে:

“যখন management meeting-এর আগে project update তৈরি করতে হয়, আমি দ্রুত নির্ভরযোগ্য অগ্রগতির চিত্র বের করতে চাই, যাতে আলাদা আলাদা team-এর কাছ থেকে status সংগ্রহ করতে না হয়।”

এখন dashboard একটি সম্ভাব্য solution। একমাত্র solution নয়।

একই Job-এর Functional, Emotional ও Social দিক

Customer-এর কাজকে কেবল practical task হিসেবে দেখলে JTBD insight অসম্পূর্ণ থেকে যেতে পারে। অনেক সিদ্ধান্তে functional need-এর পাশাপাশি emotional এবং social dimension-ও থাকে।

ধরা যাক, একজন freelancer invoice তৈরি করার tool ব্যবহার করছেন।

Functional job হয়তো invoice বানিয়ে client-কে পাঠানো।

কিন্তু এখানেই গল্প শেষ নয়।

তিনি হয়তো নিশ্চিত হতে চান যে invoice-এ ভুল হবে না। এটি emotional dimension-এর সঙ্গে যুক্ত। আবার client-এর কাছে তাঁকে সংগঠিত ও professional দেখাক—এটি social dimension।

তিন ধরনের Job

এই তিনটি dimension product messaging-এ বড় পার্থক্য তৈরি করতে পারে।

একটি invoice tool যদি শুধু বলে, “PDF invoice তৈরি করুন”, সেটি functional job বলছে।

আর যদি বলে, “দুই মিনিটে পরিষ্কার, client-ready invoice পাঠান”—তাহলে functional outcome-এর পাশাপাশি professionalism-এর social signal-ও ধরা পড়ছে।

সব product-এর ক্ষেত্রে তিনটি dimension সমান গুরুত্বপূর্ণ হবে না। কাজ হলো interview থেকে বোঝা—কোন dimension decision-এ সত্যিই প্রভাব ফেলছে।

Four Forces of Progress কীভাবে Customer-এর সিদ্ধান্ত বোঝায়?

Customer কেন পুরোনো solution ছেড়ে নতুন কিছু ব্যবহার শুরু করেন, তা বোঝার জন্য JTBD practice-এ Four Forces of Progress একটি পরিচিত model। এটি বিশেষভাবে Bob Moesta ও তাঁর সহযোগীদের কাজের সঙ্গে যুক্ত। Model-টিতে switching decision-কে চারটি competing force-এর টানাপোড়েন হিসেবে দেখা হয়।

দুটি force change-এর দিকে ঠেলে দেয়: Push এবং Pull।

দুটি force change আটকে রাখে: Anxiety এবং Habit।

এটিকে JTBD-এর একমাত্র model ভাবা উচিত নয়। বৃহত্তর JTBD toolkit-এর মধ্যে customer switching behavior বোঝার এটি একটি জনপ্রিয় পদ্ধতি।

Four Forces of Progress

এখানে product team-এর জন্য একটি গুরুত্বপূর্ণ শিক্ষা আছে। শুধু Pull বাড়ালেই sale হবে না।

আপনি যত feature যোগ করছেন, customer-এর চোখে product আকর্ষণীয় হচ্ছে। কিন্তু একই সঙ্গে যদি setup কঠিন মনে হয়, data migration নিয়ে ভয় থাকে বা team training-এর ঝামেলা বাড়ে, তাহলে Anxiety-ও বাড়ছে।

আবার customer বর্তমান solution নিয়ে খুব খুশি না হলেও Habit শক্তিশালী হতে পারে।

“হ্যাঁ, spreadsheet ঝামেলার। কিন্তু অন্তত সবাই জানে কোথায় কী আছে।”

এমন একটি বাক্যকে হালকাভাবে নেওয়া উচিত নয়। এটি সরাসরি switching friction-এর ইঙ্গিত।

Customer Interview-এ JTBD Insight কীভাবে বের করবেন?

JTBD research করার সময় সবচেয়ে বড় ভুলগুলোর একটি হলো customer-কে hypothetical ভবিষ্যৎ নিয়ে বেশি প্রশ্ন করা।

“আমরা যদি এই feature দিই, আপনি ব্যবহার করবেন?”

Customer ভদ্রভাবে “হ্যাঁ” বলতেই পারেন। কিন্তু সেই উত্তর purchase behavior সম্পর্কে খুব বেশি নিশ্চয়তা দেয় না।

JTBD interview-এ বরং সাম্প্রতিক কোনো বাস্তব decision বা switch-এর গল্প পুনর্গঠন করা বেশি কার্যকর। এই ধরনের interview-কে অনেক practitioner switch interview বা timeline-based interview বলেন। Moesta-এর JTBD পদ্ধতিতেও decision-এর timeline এবং switching forces বোঝার ওপর জোর দেওয়া হয়।

সাম্প্রতিক সিদ্ধান্ত থেকে শুরু করুন

ধরা যাক customer তিন সপ্তাহ আগে আপনার project management tool ব্যবহার শুরু করেছেন।

“আমাদের product কেন পছন্দ করেছেন?” দিয়ে শুরু না করে জিজ্ঞেস করা যায়:

“প্রথম কখন মনে হয়েছিল বর্তমান পদ্ধতিটা আর ঠিকভাবে কাজ করছে না?”

এই প্রশ্ন customer-কে opinion নয়, একটি ঘটনা মনে করতে বাধ্য করে।

তারপর timeline ধরে এগোন।

প্রথম সমস্যা কখন বোঝা গেল?
সেদিন কী ঘটেছিল?
তখন কী ব্যবহার করছিলেন?
প্রথমে নিজে কোনো workaround করেছিলেন কি?
কখন নতুন solution খোঁজা শুরু করলেন?
কোন কোন বিকল্প দেখেছিলেন?
কেন সেগুলো নেননি?
কোন বিষয়টি প্রায় purchase থামিয়ে দিয়েছিল?
শেষ পর্যন্ত কোন ঘটনার পরে সিদ্ধান্ত নিলেন?

“কেন?” প্রশ্নটি দরকার, কিন্তু বারবার সরাসরি “কেন?” বললে interview interrogation-এর মতো শোনাতে পারে।

তার বদলে বলুন:

“ওই সময় আর কী ঘটছিল?”

“এটা নিয়ে একটু বিস্তারিত বলবেন?”

“আগের পদ্ধতিতে তখন কী করতেন?”

“সেটা যদি কাজ করছিল, তাহলে নতুন কিছু খুঁজতে হলো কেন?”

এ ধরনের প্রশ্ন থেকে context বের হয়।

Customer-এর ভাষা ধরে রাখুন

Interview-এর পর শুধু নিজের interpretation লিখবেন না।

Customer যদি বলেন, “প্রতি শুক্রবার মনে হতো কিছু একটা বাদ পড়েছে”—এই বাক্যটি মূল্যবান। এখানে সম্ভবত emotional job আছে: নিশ্চিন্ত থাকা, control অনুভব করা।

Product team এটিকে সঙ্গে সঙ্গে “needs better task visibility” বানিয়ে ফেললে customer-এর আসল ভাষার একটি অংশ হারিয়ে যায়।

Research note-এ raw language এবং interpretation আলাদা রাখলে পরের analysis অনেক পরিষ্কার হয়।

শুধু নতুন customer-এর সঙ্গে কথা বলবেন না

Recent switch গুরুত্বপূর্ণ, কারণ decision-এর স্মৃতি তখন তুলনামূলকভাবে স্পষ্ট থাকে। তবে যারা trial করে কিনেননি, পুরোনো পদ্ধতিতে ফিরে গেছেন বা দীর্ঘদিন decision পিছিয়েছেন, তাঁদের গল্পও Anxiety ও Habit সম্পর্কে শক্তিশালী insight দিতে পারে।

Product discovery-তে শুধু “happy customer” শুনলে picture অসম্পূর্ণ থাকবে।

JTBD Insight থেকে Feature Priority কীভাবে ঠিক করবেন?

JTBD research শেষ করে একটি সুন্দর workshop board বানিয়ে রেখে দিলে খুব বেশি লাভ নেই। Insight-কে product decision-এর সঙ্গে যুক্ত করতে হবে।

শুরুতে যে Excel export feature-এর কথা বলা হয়েছিল, সেখানে ফিরে যাই।

Customer বললেন, “Excel export দরকার।”

Feature request হিসেবে নিলে solution হলো export button।

কিন্তু interview-এ যদি বের হয়—

“সোমবার সকালে leadership meeting-এর আগে পাঁচটি জায়গা থেকে data নিয়ে update বানাতে হয়। আমি এমন কিছু চাই, যাতে দশ মিনিটের মধ্যে decision-ready report তৈরি হয়।”

তাহলে product team-এর সামনে নতুন solution space খুলে যায়।

Excel export একটি option হতে পারে। কিন্তু automated weekly report, shareable summary link, scheduled email, presentation-ready view—এগুলোর কোনোটি হয়তো job আরও ভালোভাবে সম্পন্ন করবে।

JTBD feature request বাতিল করার কৌশল নয়। এটি feature request-এর পেছনের reason বোঝার পদ্ধতি।

Prioritization-এ Job-কে reference point বানান

Backlog review-এর সময় একটি feature সম্পর্কে প্রশ্ন করা যায়:

এই feature কোন job-কে সাহায্য করছে?

Job-এর কোন অংশ এখন customer-এর জন্য কঠিন?

এটি Push কমাবে, Pull বাড়াবে, নাকি Anxiety কমাবে?

কোন customer situation-এ featureটি দরকার?

যদি team এই প্রশ্নগুলোর পরিষ্কার উত্তর দিতে না পারে, featureটির গুরুত্ব আবার যাচাই করার কারণ আছে।

“Competitor-এর কাছে আছে” একা product strategy নয়।

Messaging ও Positioning-এ JTBD কেন শক্তিশালী?

অনেক landing page feature দিয়ে শুরু হয়।

“AI-powered analytics.”
“Advanced dashboard.”
“Real-time collaboration.”

এসব capability দরকার হতে পারে। কিন্তু customer প্রথমে নিজের পরিস্থিতি চিনতে চান।

ধরা যাক, project manager-এর job হলো:

“Weekly leadership meeting-এর আগে বিভিন্ন team-এর progress দ্রুত এক জায়গায় আনতে চাই, যাতে meeting status সংগ্রহে না গিয়ে decision নেওয়ায় ব্যয় হয়।”

তাহলে messaging হতে পারে:

“Meeting-এর আগের রাত আর status update জোগাড় করে কাটাতে হবে না।”

এখানে customer নিজের struggle চিনতে পারছেন।

তারপর feature দিয়ে দেখানো যায় product কীভাবে job সম্পন্ন করছে।

JTBD-based positioning-এর শক্তি এখানেই। Product কী—সেটি বলার আগে customer কেন সেটির দরকার অনুভব করছেন, সেই context সামনে আসে।

JTBD Segmentation কোথায় কাজে লাগে?

একই product-এর সব customer একই job-এর জন্য সেটি hire করেন না।

একটি online course platform কেউ চাকরি বদলের জন্য ব্যবহার করতে পারেন। কেউ current job-এ promotion-এর জন্য। অন্য কেউ নিজের business চালাতে নির্দিষ্ট skill শিখতে পারেন।

তিনজনের demographic profile কাছাকাছি হলেও তাঁদের motivation আলাদা। আবার demographic profile ভিন্ন হলেও job এক হতে পারে।

Product strategy-এর ক্ষেত্রে এই পার্থক্য গুরুত্বপূর্ণ, কারণ job ভেদে onboarding, content recommendation, pricing expectation এমনকি success metric-ও বদলে যেতে পারে।

তবে একটি সতর্কতা আছে। প্রতিটি interview থেকে নতুন “segment” বানালে research দ্রুত অকার্যকর হয়ে যাবে।

Pattern খুঁজতে হবে।

কোন situation বারবার আসছে? কোন struggling moment একই ধরনের? কোন desired outcome-এর জন্য মানুষ একই trade-off করছে?

সেখান থেকে অর্থবহ job-based segment তৈরি হয়।

Product-Market Fit বুঝতেও JTBD সাহায্য করতে পারে

Product-market fit শুধু মানুষ product ব্যবহার করছে কি না—এই প্রশ্ন নয়। তারা কোন পরিস্থিতিতে product-টি বেছে নিচ্ছে এবং আগের alternative-এর তুলনায় এটি job কত ভালোভাবে সম্পন্ন করছে, সেটিও গুরুত্বপূর্ণ।

JTBD research দেখাতে পারে customer আসলে কোন category-তে আপনার product-কে ভাবছেন।

আপনি হয়তো নিজেকে “team collaboration platform” বলেন। কিন্তু interview-এ বারবার শোনা গেল customer আপনাকে মূলত client approval দ্রুত পাওয়ার জন্য ব্যবহার করছেন।

এটি গুরুত্বপূর্ণ প্রোডাক্ট ইনসাইট।

এর অর্থ এই নয় যে একটি interview শুনেই positioning বদলে ফেলতে হবে। বরং consistent pattern পাওয়া গেলে সেটি প্রোডাক্ট মার্কেট ফিট, onboarding এবং acquisition strategy নিয়ে নতুন hypothesis তৈরি করতে পারে।

JTBD ব্যবহার করতে গিয়ে কোথায় সবচেয়ে বেশি ভুল হয়?

Feature request-কে Job ধরে নেওয়া

“Dark mode চাই”, “PDF download চাই”, “WhatsApp integration চাই”—এসব solution request।

প্রথম প্রশ্ন হওয়া উচিত, “কোন পরিস্থিতিতে এটি দরকার হচ্ছে?”

WhatsApp integration-এর নিচে হয়তো job হলো field sales team-এর কাছে update পৌঁছানো, যারা email খুব কম দেখে।

Job বুঝলে integration বানাবেন কি না, সেই decision অনেক পরিষ্কার হয়।

Functional Job-এই থেমে যাওয়া

“টাকা পাঠানো”, “report বানানো”, “hotel বুক করা”—এসব functional description।

কিন্তু টাকা পাঠানোর সময় customer নিশ্চিন্ত থাকতে চান যে ভুল account-এ যাবে না। Client report পাঠালে competent দেখাতে চান। পরিবারের জন্য hotel বুক করলে ভুল decision নেওয়ার ভয় এড়াতে চান।

Emotional ও social job উপেক্ষা করলে customer decision-এর গুরুত্বপূর্ণ অংশ বাদ পড়তে পারে।

Job Statement এত broad করা যে কোনো product-এ চলে

“যখন কাজ করি, আমি সময় বাঁচাতে চাই, যাতে productive হতে পারি।”

এটি শুনতে সুন্দর। কিন্তু product decision নেওয়ার জন্য প্রায় অকেজো।

কোন কাজ? কোন পরিস্থিতিতে? এখন কী কারণে সময় নষ্ট হচ্ছে? “Productive” হওয়ার অর্থ কী?

ভালো job statement-এর যথেষ্ট stability দরকার, আবার এমন specificity-ও দরকার যাতে team বাস্তবে decision নিতে পারে।

JTBD-কে একবারের workshop বানানো

একটি workshop করে পাঁচটি job statement লিখে wall-এ লাগিয়ে রাখলেই customer research শেষ হয়ে যায় না।

Market বদলায়। নতুন alternative আসে। Customer-এর switching anxiety বদলায়। Product নতুন segment-এ যায়।

JTBD-কে documentation exercise না বানিয়ে ongoing ইউজার রিসার্চ habit হিসেবে রাখা বেশি কার্যকর।

নতুন customer interview, churn conversation, sales call এবং support request—সব জায়গা থেকেই job hypothesis যাচাই করা যায়।

একটি ছোট টিম কীভাবে JTBD শুরু করতে পারে?

JTBD শুরু করতে বিশাল research department দরকার নেই।

প্রথমে product-এর পুরো market বুঝতে যাওয়ার বদলে একটি গুরুত্বপূর্ণ decision বেছে নিন। যেমন:

“কেন customer trial শুরু করার পর paid plan নিচ্ছেন?”

অথবা:

“কেন freelancer spreadsheet ছেড়ে আমাদের invoicing tool ব্যবহার শুরু করছেন?”

এরপর সাম্প্রতিক সেই decision নেওয়া কয়েকজন customer-এর সঙ্গে timeline-based interview করুন।

Interview শেষে আলাদা আলাদা quote গুনে সিদ্ধান্ত নেবেন না। একই ধরনের pattern পাশাপাশি রাখুন।

কোথায় Push তৈরি হয়েছে?
কোন Pull সবচেয়ে আকর্ষণীয় ছিল?
কোন Anxiety বারবার এসেছে?
কোন Habit switch আটকে দিয়েছে?
Customer আসলে কোন outcome-এর দিকে যেতে চেয়েছেন?

তারপর একটি provisional job statement লিখুন।

এটিকে চূড়ান্ত সত্য ধরে নেবেন না। নতুন interview-এর সঙ্গে মিলিয়ে দেখুন। প্রয়োজনে ভাষা বদলান।

সেখান থেকে product backlog, landing page messaging বা onboarding-এর একটি decision বেছে নিয়ে JTBD insight ব্যবহার করুন।

এই শেষ ধাপটি গুরুত্বপূর্ণ। Research decision বদলাতে না পারলে research document যত ভালোই হোক, business value সীমিত থাকবে।

পরের Feature বানানোর আগে এই একটি প্রশ্ন করুন

শুরুতে যে team Excel export বানিয়েছিল, তাদের ভুল feature তৈরি করা নয়। ভুলটি ছিল feature request পাওয়ার পর conversation থামিয়ে দেওয়া।

Customer যখন বলেন, “আমার এই feature দরকার”, তখন সেটিকে answer না ভেবে clue হিসেবে দেখুন।

জিজ্ঞেস করুন:

“শেষবার কখন আপনার এই feature-এর দরকার হয়েছিল? তখন আপনি আসলে কী করার চেষ্টা করছিলেন?”

এই একটি প্রশ্ন থেকেই অনেক সময় conversation product থেকে progress-এর দিকে চলে যায়।

Jobs to Be Done-এর আসল মূল্য সেখানেই। JTBD Framework আপনাকে customer-এর প্রতিটি কথার আক্ষরিক অনুবাদ করে backlog বানাতে শেখায় না। বরং feature, persona এবং product category-এর নিচে থাকা Customer Need খুঁজে বের করতে শেখায়।

Customer আপনার software ব্যবহার করতে ঘুম থেকে ওঠেন না। তাঁর নিজের কাজ আছে, চাপ আছে, deadline আছে, অন্য মানুষের প্রত্যাশা আছে। সেই পরিস্থিতির মধ্যে আপনার product-এর একটি ছোট ভূমিকা রয়েছে।

সেই ভূমিকা যত পরিষ্কারভাবে বুঝবেন, প্রোডাক্ট স্ট্র্যাটেজি তত কম অনুমানের ওপর দাঁড়াবে। আর পরেরবার feature request এলে সরাসরি solution নিয়ে আলোচনা শুরু না করে আগে job-টা খুঁজুন।

সেখান থেকেই ভালো product discovery শুরু হয়।

সাধারণ জিজ্ঞাসা

JTBD আর User Persona-এর মধ্যে পার্থক্য কী?

User Persona সাধারণত customer কে—তাঁর ভূমিকা, আচরণ, লক্ষ্য বা কখনো demographic বৈশিষ্ট্য—সে সম্পর্কে একটি profile দেয়। JTBD মূলত জানতে চায়, নির্দিষ্ট পরিস্থিতিতে customer কী অগ্রগতি করতে চাইছেন এবং কেন কোনো solution বেছে নিচ্ছেন।

দুটি একসঙ্গে ব্যবহার করা যায়। Persona customer context বুঝতে সাহায্য করতে পারে, আর JTBD purchase বা usage motivation-এর গভীরে যেতে পারে।

ছোট স্টার্টআপ কি JTBD Framework ব্যবহার করতে পারে?

হ্যাঁ। ছোট startup-এর জন্য বরং JTBD খুব ব্যবহারিক হতে পারে, কারণ সীমিত development resource কোথায় ব্যবহার করা হবে সেটি বুঝতে গভীর Customer Need জানা জরুরি।

শুরুতে বড় research program না চালিয়ে সাম্প্রতিক purchase, switch বা churn decision নিয়ে কয়েকটি গভীর কাস্টমার ইন্টারভিউ থেকেই useful hypothesis তৈরি করা যায়।

JTBD interview-এ কী ধরনের customer বেছে নেওয়া ভালো?

যাঁরা সম্প্রতি একটি গুরুত্বপূর্ণ decision নিয়েছেন তাঁদের দিয়ে শুরু করা সুবিধাজনক। যেমন নতুন product কিনেছেন, পুরোনো solution ছেড়েছেন, trial নিয়ে purchase করেননি অথবা ব্যবহার শুরু করে আবার আগের পদ্ধতিতে ফিরে গেছেন।

সাম্প্রতিক ঘটনা নিয়ে কথা বললে vague opinion-এর বদলে decision-এর timeline, trigger এবং trade-off বের করা সহজ হয়।

JTBD কি শুধু নতুন product তৈরির জন্য?

না। নতুন product idea যাচাইয়ের পাশাপাশি existing product-এর feature prioritization, positioning, onboarding, sales messaging, customer research এবং প্রোডাক্ট ডিসকভারিতেও JTBD ব্যবহার করা যায়।

মূল প্রশ্ন একই থাকে: customer কোন পরিস্থিতিতে কী progress করতে চাইছেন, এবং বর্তমান solution সেই কাজ কোথায় ভালো বা খারাপ করছে?