একটি SaaS প্রোডাক্টের প্রথম ৯০ দিনের রোডম্যাপ: লঞ্চের পর কোন সময়ে কী করবেন

লঞ্চের দিন ছোট একটি SaaS প্রোডাক্ট টিমের মধ্যে স্বাভাবিকভাবেই আলাদা উত্তেজনা থাকে। কয়েক মাসের তৈরি, ভাঙা, পরীক্ষা আর পরিবর্তনের পর অবশেষে সত্যিকারের ব্যবহারকারীরা প্রোডাক্টে ঢুকছেন। কেউ প্রথমবার নিবন্ধন করছেন, কেউ টাকা দিয়ে ব্যবহার শুরু করছেন, আবার কেউ এমনভাবে প্রোডাক্ট ব্যবহার করছেন, যেভাবে নির্মাতা দল হয়তো আগে ভাবেইনি।

কয়েক দিনের মধ্যেই সেই উত্তেজনার সঙ্গে বাস্তব চাপও এসে পড়ে।

একজন ব্যবহারকারী বলছেন, নিবন্ধনের পর কী করতে হবে বুঝতে পারছেন না। প্রথম অর্থপ্রদানকারী গ্রাহক এমন একটি সুবিধা চাইছেন, যা এমভিপি (MVP)-তে রাখা হয়নি। দু-একটি গুরুতর ত্রুটি ধরা পড়েছে। বিক্রয় দল বলছে, নির্দিষ্ট একটি সংযুক্তি সুবিধা থাকলে নতুন গ্রাহক আনা সহজ হবে। এর মধ্যেই বিনিয়োগকারী বা পরামর্শক বোর্ডের কেউ জানতে চাইছেন, “এরপর কী?”

এই জায়গাতেই নতুন SaaS প্রোডাক্টের প্রথম ৯০ দিনের রোডম্যাপ (SaaS product roadmap) দরকার হয়।

তবে এটি এমন কোনো পরিকল্পনা নয়, যেখানে ৪৩তম দিনে কোন সুবিধা চালু হবে এবং ৭১তম দিনে কোন সংযুক্তি আসবে—সব আগেই পাথরে খোদাই করে লিখে রাখা থাকবে। প্রথম ৯০ দিনের আসল লক্ষ্য হলো বাস্তব ব্যবহারকারীর কাছ থেকে শেখার গতি ঠিক রাখা।

কোন সমস্যা সত্যিই গুরুত্বপূর্ণ, কোনটি একজন গ্রাহকের বিশেষ চাহিদা, কোথায় মানুষ আটকে যাচ্ছে, কোন অনুমান ভুল প্রমাণিত হচ্ছে এবং কোথায় ছোট পরিবর্তন বড় উপকার দিতে পারে—এসব যত দ্রুত পরিষ্কার হবে, পরবর্তী প্রোডাক্ট কৌশল তত শক্ত ভিত্তির ওপর দাঁড়াবে।

রোডম্যাপের মৌলিক ধারণা, সুবিধার তালিকার সঙ্গে এর পার্থক্য এবং বিভিন্ন ধরনের রোডম্যাপ নিয়ে বিস্তারিত জানতে চাইলে প্রোডাক্ট রোডম্যাপ কী: Feature List-এর সঙ্গে পার্থক্য কোথায় পড়তে পারেন। এখানে সেই ভিত্তিকে নতুন SaaS প্রোডাক্ট লঞ্চের পর প্রথম তিন মাসে কীভাবে কাজে লাগানো যায়, সেটিই মূল বিষয়।

নতুন SaaS প্রোডাক্টের প্রথম ৯০ দিনের রোডম্যাপ আলাদা কেন?

কয়েক বছর ধরে চলা একটি SaaS প্রোডাক্টের হাতে সাধারণত অনেক ধরনের তথ্য থাকে। ব্যবহারকারীরা কীভাবে প্রোডাক্ট ব্যবহার করেন, কোথায় গিয়ে সরে যান, কী নিয়ে সহায়তা চান, কোন সুবিধা বেশি ব্যবহার করেন, কোন পরিবর্তনের পর ফল ভালো হয়েছে—এসব নিয়ে তুলনামূলক পরিষ্কার ধারণা তৈরি হয়।

নতুন প্রোডাক্টের হাতে সেই সুবিধা থাকে না।

লঞ্চের আগে যত গবেষণাই করা হোক, বাস্তব ব্যবহার শুরু হলে কিছু ধারণা বদলাবে। যে ধাপটি টিমের কাছে খুব সহজ মনে হয়েছিল, ব্যবহারকারীর কাছে সেটিই বিভ্রান্তিকর হতে পারে। যে সুবিধাকে “অবশ্যই দরকার” বলে মনে হয়েছিল, দেখা গেল খুব কম মানুষ সেটি ব্যবহার করছেন। আবার ছোট বলে বাদ দেওয়া কোনো সুবিধাই প্রথম অর্থপ্রদানকারী গ্রাহকদের কাছে সবচেয়ে প্রয়োজনীয় হয়ে উঠতে পারে।

তার ওপর চাপ আসে কয়েক দিক থেকে।

প্রথম গ্রাহকের অনুরোধ উপেক্ষা করা কঠিন। বিনিয়োগকারী অগ্রগতি দেখতে চান। প্রতিষ্ঠাতার নিজের কিছু পছন্দ বা অনুমান থাকে। প্রকৌশল দল স্থিতিশীলতা নিয়ে চিন্তিত। বিক্রয় দল এমন কিছু চাইতে পারে, যা পরের গ্রাহক প্রদর্শনীতে কাজে লাগবে।

এই পর্যায়ে রোডম্যাপের কাজ সব অনুরোধকে জায়গা দেওয়া নয়। বরং কোন সমস্যার উত্তর আগে খুঁজতে হবে এবং কোন কাজটি আপাতত না করাই ভালো—সেটি ঠিক করা।

প্রথম ৯০ দিনকে মোটামুটি ৩০ দিনের তিনটি পর্যায়ে ভাগ করলে পরিকল্পনা করা সহজ হয়। তবে এটি কোনো কঠোর নিয়ম নয়। কোনো ব্যবসাভিত্তিক SaaS-এ ব্যবহারকারীর প্রতিক্রিয়া পেতে বেশি সময় লাগতে পারে, আবার স্বয়ংক্রিয়ভাবে নিবন্ধন করে ব্যবহার করা যায় এমন প্রোডাক্টে দুই সপ্তাহেই অনেক সংকেত পাওয়া সম্ভব।

তাই তিন ভাগের এই কাঠামোকে ক্যালেন্ডারের কঠোর সূত্র না ভেবে একটি ব্যবহারিক পরিকল্পনার ছক হিসেবে দেখা ভালো।

SaaS লঞ্চের প্রথম ৩০ দিনে কী করা উচিত?

প্রথম মাসের সবচেয়ে বড় প্রলোভন হলো দ্রুত নতুন সুবিধা বানানো শুরু করা।

লঞ্চের তিন দিন পর একজন বললেন, Slack-এর সঙ্গে সংযোগ দরকার। আরেকজন বললেন, মোবাইল অ্যাপ ছাড়া কাজ হবে না। প্রথম অর্থপ্রদানকারী গ্রাহক বিশেষ ধরনের প্রতিবেদন চাইলেন। এমন সময় মনে হতে পারে, বাজার নিজেই যেন পরবর্তী রোডম্যাপ লিখে দিয়েছে।

আসলে বিষয়টি এত সহজ নয়।

প্রথম কয়েকজন ব্যবহারকারীর কথা অবশ্যই গুরুত্বপূর্ণ। কিন্তু তাঁদের প্রতিটি অনুরোধ পুরো বাজারের চাহিদা বোঝায় না। প্রথম মাসে টিমের মূল কাজ হওয়া উচিত—মানুষ প্রোডাক্ট ব্যবহার করতে গিয়ে কোথায় আটকে যাচ্ছে, সেটি দেখা।

আগে দেখুন ব্যবহারকারী মূল উপকার পর্যন্ত পৌঁছাতে পারছেন কি না

ধরা যাক, আপনার SaaS প্রোডাক্ট ছোট ব্যবসাকে চালান বা ইনভয়েস তৈরি করতে সাহায্য করে। প্রথম মাসে উন্নত প্রতিবেদন তৈরির অনুরোধ এল। কিন্তু নতুন ব্যবহারকারীদের বড় অংশ যদি প্রথম ইনভয়েসই তৈরি করতে না পারেন, তাহলে উন্নত প্রতিবেদন এখন সবচেয়ে জরুরি বিষয় নয়।

প্রথমে নিবন্ধন থেকে শুরু করে ব্যবহারকারী যে মুহূর্তে প্রথমবার প্রোডাক্টের মূল উপকার পান, সেই পথটি দেখুন।

ব্যবহারকারী কি অ্যাকাউন্ট খুলছেন, কিন্তু পরের ধাপে যাচ্ছেন না? প্রয়োজনীয় প্রাথমিক সেটআপ বুঝতে পারছেন না? কোনো অনুমতি (permission) দিতে গিয়ে আটকে যাচ্ছেন? গুরুত্বপূর্ণ বোতাম বা নির্দেশনা চোখে পড়ছে না? প্রথম কাজটি শেষ করতে অপ্রয়োজনীয় বেশি ধাপ পার হতে হচ্ছে?

এই ধরনের অনবোর্ডিংয়ের সংশোধন (onboarding fix) অনেক সময় বড় নতুন সুবিধার চেয়ে বেশি গুরুত্বপূর্ণ হয়।

কারণ ব্যবহারকারী যদি বর্তমান প্রোডাক্টের মূল্যই বুঝতে না পারেন, তাহলে আরও পাঁচটি নতুন সুবিধা যোগ করেও খুব বেশি লাভ হবে না।

ব্যবহারকারী কী বলছেন, তার পাশাপাশি কী করছেন সেটিও দেখুন

গ্রাহকের মতামত শুনতে হবে। তবে শুধু কথার ওপর নির্ভর করলেই চলবে না।

ধরা যাক, একজন ব্যবহারকারী বললেন, ড্যাশবোর্ড দেখতে আরও সুন্দর হওয়া দরকার। কিন্তু তাঁর ব্যবহারপথ দেখলে বোঝা গেল, আসল সমস্যা ড্যাশবোর্ডের নকশা নয়। তিনি প্রয়োজনীয় তথ্য আমদানি করতেই পারছেন না।

প্রথম বক্তব্যকে সরাসরি নতুন সুবিধার অনুরোধ হিসেবে ধরলে টিম ভুল সমস্যা সমাধান করতে পারে।

এই পর্যায়ে তাই ব্যবহারকারীর মতামত, সহায়তার কথোপকথন এবং বাস্তব ব্যবহারের ধরন পাশাপাশি দেখা দরকার।

খুব জটিল ব্যবস্থা প্রয়োজন নেই। একটি সাধারণ নোটেও লেখা যেতে পারে—

• ব্যবহারকারী কোথায় আটকালেন
• তিনি কী করতে চাচ্ছিলেন
• বাধা এড়াতে অন্য কোনো উপায় নিয়েছেন কি না
• একই সমস্যা আর কারও হয়েছে কি না
• সমস্যাটি প্রোডাক্টের মূল উপকার পাওয়ার পথে বাধা কি না

লক্ষ্য এখনই বিশাল তথ্যবিশ্লেষণ ব্যবস্থা বানানো নয়। লক্ষ্য হলো নিজের অনুমানের বদলে বাস্তব ব্যবহারকে সিদ্ধান্তের ভিত্তি করা।

বাগ ঠিক করবেন, নাকি নতুন সুবিধা বানাবেন?

বাস্তব ব্যবহারকারী আসার সঙ্গে সঙ্গেই এই দ্বন্দ্ব শুরু হয়।

একদিকে নতুন প্রোডাক্টে শেখার গতি ধরে রাখা দরকার। নতুন কাজের ধারা, সংযুক্তি বা সুবিধা পরীক্ষা না করলে ব্যবহারকারী আসলে কী চান, সেটি জানাও কঠিন হয়ে যায়।

অন্যদিকে গুরুতর বাগকে “আমরা তো শুরুর পর্যায়ে” বলে ফেলে রাখার সুযোগ নেই।

বিশেষ করে এমন ত্রুটি, যা লগইন বন্ধ করে দেয়, তথ্য হারানোর ঝুঁকি তৈরি করে, অর্থ পরিশোধ আটকে দেয় বা প্রোডাক্টের মূল কাজটিই করতে দেয় না—এসব সাধারণ রোডম্যাপ ভেঙে আগে সমাধান করতে হতে পারে।

তবে উল্টো দিকেও ফাঁদ আছে।

“আগে সব বাগ শেষ করব, তারপর নতুন কিছু বানাব”—এমন নীতি নতুন SaaS প্রোডাক্টকে সহজেই ধীর করে দিতে পারে। ছোটখাটো সব ত্রুটি নিখুঁত করতে করতে বাজার থেকে শেখাই যদি বন্ধ হয়ে যায়, তাহলে প্রোডাক্ট সুন্দর হবে, কিন্তু সঠিক দিকে এগোচ্ছে কি না তা জানা যাবে না।

বাগ এবং নতুন সুবিধার মধ্যে কাজ ভাগ করার বিষয়টি বিস্তারিতভাবে বুঝতে চাইলে বাগ ফিক্স ও নিউ ফিচারের মধ্যে রিসোর্স ভাগ করবেন কীভাবে গাইডটি কাজে লাগবে।

শুরুর পর্যায়ের প্রোডাক্টে নতুন কিছু পরীক্ষা করার গতি জরুরি। কিন্তু ব্যবহারকারীকে পুরোপুরি আটকে দেওয়া গুরুতর বাগের জন্য আলাদা গুরুত্ব নির্ধারণের ব্যবস্থা প্রথম মাস থেকেই রাখা ভালো।

প্রথম মাস থেকেই Decision Log কেন রাখা দরকার?

ছোট টিমে প্রায়ই শোনা যায়, “আমরা তো চার-পাঁচজন মানুষ। কে কেন সিদ্ধান্ত নিয়েছি, সবাই জানি। আলাদা করে লেখার দরকার কী?”

দুই সপ্তাহ পরে দেখা যায়, কেউই পুরো কারণটা মনে করতে পারছেন না।

নতুন SaaS প্রোডাক্টের প্রথম ৯০ দিনে অনেক সিদ্ধান্ত খুব দ্রুত নিতে হয়। তখন সেগুলো ছোট মনে হলেও পরে সেগুলোই প্রোডাক্ট কৌশলের ভিত্তি হয়ে দাঁড়াতে পারে।

হয়তো টিম ঠিক করল, বড় প্রতিষ্ঠানের বদলে আপাতত ছোট এজেন্সিকে গুরুত্ব দেবে। মোবাইল অ্যাপের অনুরোধ এখনই নেওয়া হবে না। প্রথম বড় গ্রাহকের জন্য আলাদা কাজের ধারা বানানোর বদলে সবার জন্য সাধারণ পথটি ঠিক করা হবে। প্রতিদ্বন্দ্বী প্রতিষ্ঠানের জনপ্রিয় কোনো সুবিধা এখনই নকল করা হবে না।

দুই মাস পরে এসব সিদ্ধান্ত বদলাতেও পারে। সেটি সমস্যা নয়।

সমস্যা হয় যখন আগের সিদ্ধান্তটি কেন নেওয়া হয়েছিল, তখন কী জানা ছিল এবং কোন ঝুঁকি বিবেচনা করা হয়েছিল—সেটিই হারিয়ে যায়।

এই কারণেই Product Decision Log রাখলে Team কীভাবে উপকৃত হয়—এই অভ্যাসটি প্রথম মাস থেকেই নেওয়া উপকারী।

এখানে বড় নথি দরকার নেই। সিদ্ধান্ত কী ছিল, কেন নেওয়া হয়েছিল, কী তথ্যের ভিত্তিতে নেওয়া হয়েছিল এবং কোন পরিস্থিতিতে সেটি আবার দেখা হবে—এটুকুই অনেক।

প্রথম ৯০ দিনে বিশেষভাবে লিখে রাখার মতো সিদ্ধান্ত

Decision Log-এর উদ্দেশ্য ভবিষ্যতে কে ঠিক ছিল, কে ভুল ছিল—সেটি প্রমাণ করা নয়। এর আসল কাজ হলো, পরবর্তী সিদ্ধান্ত নেওয়ার সময় আগের প্রেক্ষাপট যেন হারিয়ে না যায়।

দিন ৩০–৬০: এখন কি Prioritization দরকার?

প্রথম মাসের শেষে সাধারণত একটি গুরুত্বপূর্ণ পরিবর্তন আসে।

টিমের হাতে তখন আর শুধু লঞ্চের আগের ধারণা থাকে না। কিছু বাস্তব মতামত পাওয়া গেছে। কিছু ব্যবহারের ধরন চোখে পড়েছে। কোন বাগ বারবার হচ্ছে বোঝা যাচ্ছে। কয়েকটি সুবিধার অনুরোধও হয়তো একাধিক ব্যবহারকারীর কাছ থেকে এসেছে।

কিন্তু এখনো তথ্য খুব বেশি নয়।

ঠিক এই জায়গায় অনেক দল দুই রকম ভুল করে। কেউ পুরোপুরি নিজের অনুভূতির ওপর রোডম্যাপ চালাতে থাকে। আবার কেউ এমন ভারী নম্বরভিত্তিক পদ্ধতি চালু করে, যার হিসাব দেখতে খুব নির্ভুল হলেও ভেতরের বেশির ভাগ সংখ্যাই আসলে অনুমান।

দিন ৩০–৬০-এ দরকার হালকা কিন্তু সচেতন অগ্রাধিকার নির্ধারণ।

কম তথ্যের পর্যায়ে ICE কেন কাজে লাগতে পারে

নতুন SaaS প্রোডাক্টে কোনো সুবিধা কত মানুষের কাছে পৌঁছাবে, তার নির্ভরযোগ্য হিসাব করা কঠিন।

হাতে যদি এখনো ব্যবহারকারীর সংখ্যা কম থাকে, তাহলে তিন মাস পরে কতজন একটি নির্দিষ্ট সুবিধা ব্যবহার করবেন—এটি খুব নিশ্চিতভাবে বলা সম্ভব নয়।

এই কারণেই RICE, ICE ও MoSCoW: কোন Prioritization Framework কখন ব্যবহার করবেন গাইডে যেমন ব্যাখ্যা করা হয়েছে, ব্যবহারকারীর তথ্য কম এবং দ্রুত কিছু পরীক্ষা করার প্রয়োজন থাকলে ICE অনেক ক্ষেত্রে RICE-এর তুলনায় সহজভাবে শুরু করা যায়।

ICE-এ সাধারণভাবে তিনটি বিষয় দেখা হয়—সম্ভাব্য প্রভাব, নিজের ধারণার ওপর আস্থা এবং কাজটি কত সহজে করা সম্ভব।

এখানে নম্বরটিকেই চূড়ান্ত সত্য ভাবা ঠিক নয়। বরং একই মানদণ্ডে কয়েকটি সম্ভাব্য কাজ পাশাপাশি বসিয়ে আলোচনা করাই আসল সুবিধা।

ধরা যাক, টিমের সামনে চারটি কাজ আছে—

অনবোর্ডিংয়ের একটি ধাপ কমানো, নতুন একটি সংযুক্তি যোগ করা, প্রতিবেদনের একটি সুবিধা তৈরি করা এবং মূল্য নির্ধারণের পাতা পরীক্ষা করা।

প্রশ্ন হতে পারে: কোনটি সফল হলে বর্তমান বড় সমস্যায় সবচেয়ে বেশি প্রভাব পড়বে? কোনটির পক্ষে বাস্তব ব্যবহার বা গ্রাহকের মতামত আছে? কোনটি তুলনামূলক কম সময়ে পরীক্ষা করা সম্ভব?

এভাবে “কে বেশি জোরে বলেছে” তার বদলে “কোন কাজের পক্ষে তুলনামূলক ভালো প্রমাণ আছে” সেটি সামনে আসে।

প্রথম গ্রাহকের কথা গুরুত্ব দিয়ে শুনুন, তবে পুরো প্রোডাক্ট কৌশল তাঁর হাতে দেবেন না

প্রথম অর্থপ্রদানকারী গ্রাহক অবশ্যই গুরুত্বপূর্ণ। তিনি শুধু আগ্রহ দেখাননি, টাকা দিয়েও প্রোডাক্ট ব্যবহার করছেন।

তবে সেই কারণে তাঁর প্রতিটি চাহিদা রোডম্যাপের এক নম্বরে চলে যাবে—এমন নয়।

ধরা যাক, একটি ব্যবসাভিত্তিক SaaS-এর প্রথম গ্রাহক বিশেষ একটি তথ্য রপ্তানির ধরন চাইছেন। তাঁর কাজের জন্য এটি সত্যিই জরুরি। কিন্তু একই ধরনের আরও গ্রাহকেরও কি একই প্রয়োজন আছে, সেটি তখনো জানা নেই।

সরাসরি তৈরি শুরু করার বদলে কয়েকটি প্রশ্ন করা দরকার।

একই গ্রাহকগোষ্ঠীর আরও মানুষ কি এটি চাইছেন? সুবিধাটি না থাকলে মূল কাজ বন্ধ হয়ে যায়, নাকি বিকল্প কোনো উপায় আছে? এটি কি প্রোডাক্টের নির্ধারিত দিকের সঙ্গে যায়? একবার বানালে ভবিষ্যতে এটি রক্ষণাবেক্ষণের চাপ কতটা বাড়াবে?

প্রথম গ্রাহককে উপেক্ষা করবেন না। আবার প্রথম গ্রাহকের নিজস্ব কাজের ধরনকেই পুরো বাজারের চাহিদা বলে ধরে নেবেন না।

দিন ৬০–৯০: তাৎক্ষণিক সমস্যার পেছনে ছোটা থেকে প্রথম পরিকল্পিত উদ্যোগে যাওয়া

প্রথম দুই মাস যদি কাজে লাগানো যায়, তাহলে দিন ৬০–৯০-এ রোডম্যাপের চরিত্র কিছুটা বদলাতে শুরু করে।

অনিশ্চয়তা তখনো থাকবে। কিন্তু টিমের হাতে কিছু বাস্তব প্রমাণও থাকবে।

কোন ধরনের ব্যবহারকারী সবচেয়ে বেশি উপকার পাচ্ছেন, কোথায় বারবার সমস্যা হচ্ছে, অনবোর্ডিংয়ের কোন ধাপে মানুষ আটকে যাচ্ছেন, কী ধরনের অনুরোধ একাধিক জায়গা থেকে আসছে এবং কোন পুরোনো অনুমান দুর্বল হয়ে গেছে—এসব নিয়ে অন্তত প্রাথমিক ধারণা তৈরি হওয়ার কথা।

এখন প্রথমবারের মতো তুলনামূলকভাবে সচেতন একটি উদ্যোগ বেছে নেওয়া যায়।

এটি বড় কোনো নতুন সুবিধা হতেই হবে, এমন নয়।

হতে পারে অনবোর্ডিং নতুনভাবে সাজানো, প্রতিবেদন তৈরির পথ সহজ করা, গুরুত্বপূর্ণ একটি সংযুক্তি যোগ করা, দলগতভাবে কাজ করার ছোট একটি সুবিধা তৈরি করা কিংবা মূল্য নির্ধারণ পরীক্ষা করা।

মূল পার্থক্য হলো, এবার কাজটি শুধু “একজন গ্রাহক বলেছেন” বলে শুরু হচ্ছে না। একটি পরিষ্কার সমস্যা এবং প্রত্যাশিত ফল মাথায় রেখে শুরু হচ্ছে।

এই পর্যায়ে এক পাতার PRD-ও যথেষ্ট হতে পারে

ছোট আর্লি স্টেজ স্টার্টআপে ২০ পাতার নথি লিখতে গিয়ে উন্নয়নকাজ থামিয়ে রাখা যেমন দরকার নেই, তেমনি “আমরা ছোট দল, তাই কিছু লিখে রাখি না”—এটিও ভালো অভ্যাস নয়।

দিন ৬০–৯০-এ যখন প্রথম সচেতনভাবে নির্ধারিত কোনো উদ্যোগ নেওয়া হবে, তখন অন্তত একটি সংক্ষিপ্ত PRD থাকা ভালো।

Product Requirement Document বা PRD কীভাবে লিখবেন গাইডে যেমন বলা হয়েছে, ছোট বা প্রাথমিক পর্যায়ের দলের জন্য এক পাতার PRD-ই অনেক ক্ষেত্রে যথেষ্ট হতে পারে।

সেখানে অন্তত কয়েকটি বিষয় পরিষ্কার থাকুক—

সমস্যাটি কী? কার সমস্যা? এখন কেন এটি করা হচ্ছে? কী কী এই কাজের মধ্যে থাকবে? কী থাকবে না? সফল হয়েছে কি না বোঝার জন্য কোন সংকেত দেখা হবে? এখনো কোন প্রশ্নের উত্তর জানা নেই?

এই অল্প লেখাই নকশা, প্রকৌশল, পণ্য এবং প্রতিষ্ঠাতার মধ্যে একই কাজ নিয়ে ভিন্ন ভিন্ন ধারণা তৈরি হওয়া অনেকটাই কমিয়ে দিতে পারে।

৯০ দিনের রোডম্যাপে কোন পর্যায়ে কোন অভ্যাস বা পদ্ধতি কাজে লাগে?

প্রথম দিন থেকেই সব ব্যবস্থা পূর্ণ মাত্রায় চালু করতে হবে না। ছোট টিমের জন্য সেটি অযথা কাজও বাড়াতে পারে।

বরং কোন সময়ে কোন অভ্যাস সবচেয়ে বেশি মূল্য দেয়, সেটি বোঝা বেশি গুরুত্বপূর্ণ।

এখানে সময়সীমা শুধু নির্দেশক।

২৬তম দিনেই যদি যথেষ্ট ভালো সংকেত পাওয়া যায়, তাহলে অগ্রাধিকার নির্ধারণ শুরু করতে ৩০তম দিনের অপেক্ষা করার দরকার নেই।

আবার ৭০তম দিনেও যদি বোঝা না যায় ব্যবহারকারীরা মূল কাজটিই ঠিকমতো করতে পারছেন কি না, তাহলে শুধু ক্যালেন্ডারের দিকে তাকিয়ে বড় নতুন উদ্যোগ শুরু করাও বুদ্ধিমানের কাজ হবে না।

৯০ দিনের রোডম্যাপ বিনিয়োগকারী বা প্রথম দিকের গ্রাহকদের কীভাবে দেখাবেন?

নতুন প্রোডাক্টের ক্ষেত্রে সবচেয়ে অস্বস্তিকর প্রশ্নগুলোর একটি হলো—

“আগামী তিন মাসে ঠিক কী কী আসছে?”

এই প্রশ্নের উত্তরে অতিরিক্ত নির্দিষ্ট হওয়া খুব সহজ।

ধরা যাক, বিনিয়োগকারীদের সামনে বলা হলো—১৮ সেপ্টেম্বর বিশ্লেষণ ড্যাশবোর্ড, ২ অক্টোবর মোবাইল অ্যাপ, ২১ অক্টোবর Slack সংযোগ চালু হবে।

দেখতে খুব গোছানো। কিন্তু নতুন SaaS প্রোডাক্টে ২০তম দিনের ব্যবহারকারীর প্রতিক্রিয়াই হয়তো পুরো অগ্রাধিকার বদলে দিতে পারে।

তখন টিমের সামনে দুটি খারাপ পথ থাকে। হয় জানা সত্ত্বেও পুরোনো প্রতিশ্রুতির পেছনে দৌড়াতে হবে, নয়তো আগের সময়সূচি ভাঙতে হবে।

দ্বিতীয়টি স্বাভাবিক হলেও, আগের উপস্থাপন যদি অতিরিক্ত নিশ্চিত ভাষায় করা হয়ে থাকে, তাহলে বিশ্বাসযোগ্যতায় আঘাত লাগতে পারে।

নতুন ও অনিশ্চিত প্রোডাক্টের ক্ষেত্রে Stakeholder-দের কাছে Roadmap উপস্থাপন করার কৌশল গাইডে ব্যবহৃত Now/Next/Later কাঠামো বেশি মানানসই।

Now-এ থাকতে পারে: অনবোর্ডিংয়ের বাধা দূর করা, গুরুতর বাগ ঠিক করা, প্রথম ব্যবহারকারীদের ব্যবহার ঘনিষ্ঠভাবে দেখা।

Next-এ থাকতে পারে: সবচেয়ে বেশি প্রমাণ পাওয়া সমস্যার ওপর একটি পরিকল্পিত উদ্যোগ।

Later-এ থাকতে পারে: গুরুত্বপূর্ণ মনে হচ্ছে, কিন্তু আরও তথ্য দরকার—এমন সংযুক্তি বা নতুন সুবিধার ক্ষেত্র।

এভাবে বিনিয়োগকারী বা পরামর্শক বোর্ড দিকনির্দেশনা দেখতে পান, কিন্তু টিমকে অযথা এমন তারিখের প্রতিশ্রুতি দিতে হয় না, যা নতুন তথ্য আসার সঙ্গে সঙ্গে অচল হয়ে যেতে পারে।

প্রথম দিকের গ্রাহকদের ক্ষেত্রেও একই সতর্কতা দরকার।

“বিষয়টি আমাদের পরিকল্পনায় আছে” এবং “১৭ অক্টোবর এটি অবশ্যই চালু হবে”—এই দুটি কথা এক নয়।

প্রথম ৯০ দিনের রোডম্যাপে যে ভুলগুলো বেশি হয়

যাচাইয়ের আগেই “সম্পূর্ণ প্রোডাক্ট” বানাতে যাওয়া

লঞ্চের পর অনেক প্রতিষ্ঠাতার মনে হয়, এমভিপির অসম্পূর্ণতা যত দ্রুত সম্ভব ঢেকে ফেলতে হবে।

ফলে ব্যবহারযোগ্যতা, সংযুক্তি, প্রতিবেদন, সেটিংস, স্বয়ংক্রিয় কাজ—সব একসঙ্গে রোডম্যাপে ঢুকে যায়।

সমস্যা হলো, তখন কোন কাজ ব্যবহারকারীকে সত্যি মূল্য দিচ্ছে সেটি শেখার সুযোগ কমে যায়।

নতুন প্রোডাক্টের প্রথম দায়িত্ব সম্পূর্ণ হওয়া নয়। বরং এতটা কার্যকর হওয়া, যাতে সত্যিকারের মানুষ ব্যবহার করতে পারেন এবং তাঁদের কাছ থেকে নির্ভরযোগ্য শিক্ষা পাওয়া যায়।

প্রত্যেক গ্রাহকের অনুরোধকে সমান জরুরি ধরা

একজন ব্যবহারকারী একটি সুবিধা চাইলেন—এটি একটি সংকেত।

একই ধরনের দশজন ব্যবহারকারী একই সমস্যার কথা বললেন—এটিও সংকেত।

কিন্তু দুটির গুরুত্ব এক নয়।

প্রতিটি অনুরোধ লিখে রাখুন, পুনরাবৃত্ত ধরণ খুঁজুন এবং অনুরোধের পেছনে আসল সমস্যাটি বোঝার চেষ্টা করুন।

কেউ “Excel-এ তথ্য পাঠানোর সুবিধা চাই” বললে সঙ্গে সঙ্গে বোতাম বানানোর আগে জিজ্ঞেস করা যেতে পারে, সেই তথ্য নিয়ে তিনি এরপর কী করেন।

উত্তর শুনে হয়তো বোঝা যাবে, সমস্যার ভালো সমাধান অন্য কিছু।

“আমরা ছোট টিম” বলে কিছুই লিখে না রাখা

ছোট টিমে বড় আকারের নথিপত্রের দরকার কম—এ কথা ঠিক।

কিন্তু কোনো নথিই দরকার নেই—এটি ঠিক নয়।

বিশেষ করে কাজের পরিধি, প্রত্যাখ্যাত অনুরোধ, লক্ষ্য গ্রাহক, অগ্রাধিকার এবং বড় সিদ্ধান্তের কারণ কয়েক সপ্তাহের মধ্যেই ভুলে যাওয়া খুব সহজ।

এক পাতার PRD এবং কয়েক লাইনের Decision Log অনেক ক্ষেত্রেই যথেষ্ট।

বিনিয়োগকারীদের অতিরিক্ত তারিখনির্ভর রোডম্যাপ দেখানো

৯০ দিনের প্রতিটি কাজের পাশে নির্দিষ্ট তারিখ বসালে পরিকল্পনাটি দেখতে শক্ত মনে হয়।

কিন্তু নতুন প্রোডাক্টে অনিশ্চয়তা এত বেশি যে সেই নির্ভুলতার অনেকটাই কাগজে-কলমে থাকে।

অগ্রাধিকার বদলালে তখন শুধু সময়সূচি ভাঙে না, বাইরের মানুষ মনে করতে পারেন টিম পরিকল্পনা রাখতে পারছে না।

যেখানে তারিখ সত্যিকার অর্থে প্রতিশ্রুতি নয়, সেখানে ফলাফল, বিষয়ভিত্তিক অগ্রাধিকার এবং Now/Next/Later ব্যবহার করা বেশি বাস্তবসম্মত।

শুধু নতুন সুবিধার পেছনে ছুটে বাগ জমতে দেওয়া

নতুন সুবিধা দেখাতে ভালো লাগে। বিনিয়োগকারীকে বলা যায়, “এই মাসে তিনটি নতুন জিনিস এনেছি।”

বাগ ঠিক করার কাজ এতটা চোখে পড়ে না।

ফলে নতুন সুবিধা এগোয়, আর সহায়তার অনুরোধ, সাময়িক বিকল্প ব্যবস্থা এবং ব্যবহারকারীর বিরক্তি ধীরে ধীরে জমতে থাকে।

একসময় নতুন সুবিধা বানানোর গতিও কমে যায়, কারণ প্রতিটি পরিবর্তন পুরোনো অস্থিতিশীলতার ওপর বসছে।

আবার শুধু ঘষামাজা করতে গিয়ে শেখা বন্ধ করা

এর উল্টো ভুলও হয়।

প্রোডাক্টের প্রতিটি ছোট অ্যানিমেশন নিখুঁত, প্রতিটি অস্বাভাবিক পরিস্থিতি সামলানো হয়েছে, সেটিংস পাতা ঝকঝকে—কিন্তু টিম এখনো জানে না মানুষ মূল সমস্যার সমাধানের জন্য টাকা দিতে আগ্রহী কি না।

স্থিতিশীলতা দরকার। নিখুঁততা নয়।

একটি ভালো ৯০ দিনের রোডম্যাপ আসলে কোন প্রশ্নগুলোর উত্তর দেবে?

ভালো প্রথম-৯০-দিনের রোডম্যাপ দেখলে টিমের কয়েকটি গুরুত্বপূর্ণ প্রশ্নের উত্তর মোটামুটি পরিষ্কার হওয়া উচিত।

এখন ব্যবহারকারীর সবচেয়ে বড় সমস্যা কী?

আমরা কোন ধারণাটি যাচাই করার চেষ্টা করছি?

কোন কাজগুলো সচেতনভাবেই এখন করছি না?

কোন নতুন তথ্য পেলে বর্তমান অগ্রাধিকার বদলাবে?

৯০ দিন শেষে কোন বিষয়ে আজকের তুলনায় বেশি নিশ্চিত হতে চাই?

শেষ প্রশ্নটি বিশেষ গুরুত্বপূর্ণ।

“৯০ দিনের মধ্যে আমরা পাঁচটি নতুন সুবিধা চালু করব”—এটি কাজের ফলের সংখ্যা।

“৯০ দিন শেষে আমরা বুঝতে চাই কোন ধরনের গ্রাহক সবচেয়ে নিয়মিত উপকার পাচ্ছেন এবং তাঁদের প্রথমবার সফলভাবে প্রোডাক্ট ব্যবহার করার পথে প্রধান বাধা কোথায়”—এটি শেখার লক্ষ্য।

আর্লি স্টেজ স্টার্টআপে দ্বিতীয় ধরনের উত্তরই ভবিষ্যতের প্রোডাক্ট কৌশলকে বেশি সাহায্য করে।

৯০ দিনের পর রোডম্যাপ কোথায় যাবে?

প্রথম ৯০ দিনের রোডম্যাপ সফল হয়েছে কি না, সেটি দেখে বোঝার উপায় এই নয় যে প্রথম দিনে লেখা প্রতিটি কাজ ৯০তম দিনেও হুবহু একই ছিল।

বরং বাস্তব ব্যবহারকারীর কাছ থেকে নতুন কিছু শেখার পর রোডম্যাপ বদলানো অনেক ক্ষেত্রেই স্বাস্থ্যকর লক্ষণ।

কোনো সুবিধা পিছিয়ে যেতে পারে। একটি নির্দিষ্ট গ্রাহকগোষ্ঠী বেশি গুরুত্বপূর্ণ হয়ে উঠতে পারে। প্রথমে বড় মনে হওয়া কোনো সমস্যা পরে তেমন গুরুত্বপূর্ণ না-ও থাকতে পারে। আবার খুব ছোট বলে ধরে নেওয়া কোনো বাধাই বড় হয়ে সামনে আসতে পারে।

প্রথম তিন মাস শেষে নতুন SaaS প্রোডাক্টের সবচেয়ে মূল্যবান সম্পদ শুধু নতুন কোড নয়।

টিমের হাতে তখন আগের চেয়ে ভালো প্রমাণ, পরিষ্কার অগ্রাধিকার, লিখে রাখা গুরুত্বপূর্ণ সিদ্ধান্ত এবং পরের কয়েক মাসে কোন সমস্যায় সময় দেওয়া উচিত—সে বিষয়ে তুলনামূলক শক্ত ধারণা থাকা দরকার।

ভালো রোডম্যাপ ভবিষ্যৎ নিখুঁতভাবে বলে দেওয়ার চেষ্টা করে না। এটি অনিশ্চয়তার মধ্যে সঠিকভাবে শেখার শৃঙ্খলা তৈরি করে।

আর নতুন SaaS প্রোডাক্টের ক্ষেত্রে প্রথম ৯০ দিনে শেখার সেই মানই ঠিক করে দেয়, পরের রোডম্যাপ সত্যিকারের প্রোডাক্ট কৌশল হবে, নাকি শুধু জমে থাকা অনুরোধের তালিকা হয়ে থাকবে।

প্রায়শই জিজ্ঞাসিত প্রশ্ন

লঞ্চের প্রথম মাসে কি নতুন সুবিধা বানানো উচিত?

একেবারেই বানানো যাবে না—এমন কোনো নিয়ম নেই। তবে প্রথম মাসে বড় নতুন কাজ শুরু করার আগে অনবোর্ডিংয়ের বাধা, গুরুতর বাগ এবং বাস্তব ব্যবহারপথ বোঝা বেশি জরুরি। ছোট কোনো সুবিধা বা পরীক্ষা যদি গুরুত্বপূর্ণ ধারণা যাচাই করতে সাহায্য করে, তাহলে সেটি যৌক্তিক হতে পারে।

৯০ দিনের রোডম্যাপ কি বিনিয়োগকারীকে দেখানো উচিত?

হ্যাঁ। তবে এটিকে নিশ্চিত প্রকাশ-তারিখের ক্যালেন্ডার হিসেবে দেখানো ঠিক নয়। নতুন SaaS প্রোডাক্টে অনিশ্চয়তা বেশি থাকে, তাই Now/Next/Later, বিষয়ভিত্তিক অগ্রাধিকার বা প্রত্যাশিত ফলের ভাষায় রোডম্যাপ দেখানো বেশি বাস্তবসম্মত।

নতুন SaaS প্রোডাক্টের জন্য RICE নাকি ICE ভালো?

একক উত্তর নেই। তবে প্রথম দিকে ব্যবহারকারীর তথ্য কম থাকলে এবং দ্রুত কয়েকটি সম্ভাব্য কাজের মধ্যে অগ্রাধিকার ঠিক করতে হলে ICE তুলনামূলক সহজ হতে পারে। পরে পর্যাপ্ত তথ্য জমলে RICE-এর মতো বিস্তারিত পদ্ধতি বিবেচনা করা যায়।

প্রথম ৯০ দিনেই কি PRD দরকার?

প্রতিটি ছোট সংশোধনের জন্য নয়। তবে দিন ৬০–৯০-এর দিকে যখন টিম প্রথম পরিকল্পিত উদ্যোগ নেয়, তখন একটি সংক্ষিপ্ত PRD রাখা ভালো। ছোট দলের জন্য এক পাতাও যথেষ্ট হতে পারে, যদি সমস্যা, লক্ষ্য, কাজের পরিধি, সাফল্য বোঝার সংকেত এবং খোলা প্রশ্নগুলো পরিষ্কার থাকে।