নতুন কোনো অ্যাপ বা সফটওয়্যার বানানোর ক্ষেত্রে বড় ঝুঁকিটি অনেক সময় কোডে নয়, অনুমানে। কয়েক মাস ডেভেলপমেন্ট করার পর দেখা যেতে পারে, যে সমস্যার সমাধান করা হয়েছে সেটি সম্ভাব্য গ্রাহকের কাছে ততটা গুরুত্বপূর্ণ নয়। কিংবা সমাধানটি তাদের ভালো লাগলেও নিয়মিত ব্যবহার বা টাকা দেওয়ার মতো আগ্রহ তৈরি হচ্ছে না।
Concierge MVP বা কনসিয়র্জ এমভিপি এই ঝুঁকি কমিয়ে শুরুতেই বাস্তব গ্রাহকের কাছ থেকে শেখার একটি পদ্ধতি। ভবিষ্যতে সফটওয়্যার দিয়ে যে সেবা স্বয়ংক্রিয় করার পরিকল্পনা আছে, সেটি প্রথমে মানুষ হাতে-কলমে দেয়। এতে পূর্ণাঙ্গ পণ্য তৈরির আগেই বোঝা যায়—সমস্যাটি সত্যিই আছে কি না, প্রস্তাবিত সমাধান কাজে লাগছে কি না এবং এর জন্য গ্রাহক যথেষ্ট সময়, তথ্য বা অর্থ দিতে প্রস্তুত কি না।
Lean Startup Productions-এর ব্যাখ্যায় Concierge হলো এমন এক ধরনের MVP, যেখানে ভবিষ্যতে স্বয়ংক্রিয় করার কথা থাকা সেবাটি প্রথমে ম্যানুয়ালি দেওয়া হয়। এতে বড় প্রযুক্তিগত অবকাঠামো তৈরি না করেও গ্রাহকের সঙ্গে সরাসরি কাজ করে শেখা যায়।
MVP মানে কম ফিচারের অসম্পূর্ণ সফটওয়্যার নয়
Minimum Viable Product বা MVP-কে প্রায়ই “পূর্ণ পণ্যের ছোট সংস্করণ” হিসেবে দেখা হয়। কোনো কোনো ক্ষেত্রে সেটি ঠিক হতে পারে, কিন্তু MVP-এর উদ্দেশ্য শুধু ফিচার কমানো নয়।
Eric Ries-এর সংজ্ঞায় MVP হলো নতুন পণ্যের এমন একটি সংস্করণ, যা সর্বনিম্ন প্রচেষ্টায় গ্রাহক সম্পর্কে সর্বাধিক যাচাইকৃত শিক্ষা সংগ্রহের সুযোগ দেয়। অর্থাৎ কত কম ফিচার রাখা হলো, তার চেয়ে বেশি গুরুত্বপূর্ণ হলো পরীক্ষাটি কী শেখাচ্ছে।
এই কারণে MVP কখনো সীমিত ফিচারের সফটওয়্যার হতে পারে, আবার কখনো একটি ল্যান্ডিং পেজ, হাতে পরিচালিত সেবা বা অন্য ধরনের ছোট পরীক্ষা হতে পারে।
ধরা যাক, কেউ এমন একটি অ্যাপ বানাতে চান, যা ছোট ব্যবসার বিক্রির তথ্য দেখে প্রতি সপ্তাহে কোন পণ্য কতটা পুনরায় অর্ডার করা উচিত তা জানাবে।
সরাসরি অ্যাপ বানাতে গেলে ডেটাবেস, ব্যবহারকারী অ্যাকাউন্ট, হিসাবের নিয়ম, ড্যাশবোর্ড, নোটিফিকেশনসহ অনেক কিছু তৈরি করতে হবে।
Concierge MVP-তে কয়েকটি ব্যবসার কাছ থেকে বিক্রির তথ্য নেওয়া যেতে পারে। উদ্যোক্তা সেই তথ্য স্প্রেডশিটে হাতে বিশ্লেষণ করে ইমেইল বা মেসেজে পুনরায় অর্ডারের পরামর্শ পাঠালেন।
গ্রাহক ভবিষ্যৎ পণ্যের মূল ফলটি পেলেন। কিন্তু পুরো সফটওয়্যার তৈরি করতে হলো না।
এখন বোঝার মতো কিছু বাস্তব প্রশ্ন তৈরি হয়:
- ব্যবসাটি নিয়মিত প্রয়োজনীয় তথ্য দিতে পারছে কি না;
- দেওয়া পরামর্শ বাস্তবে ব্যবহার করছে কি না;
- একই ধরনের সহায়তা আবার চাইছে কি না;
- কোন অংশটি বেশি মূল্যবান মনে হচ্ছে;
- সেবাটির জন্য অর্থ দেওয়ার আগ্রহ আছে কি না;
- কোন কাজ বারবার একইভাবে করতে হচ্ছে।
এই তথ্যগুলোই পরে বলে দিতে পারে, সফটওয়্যারে আসলে কোন অংশ তৈরি করা প্রয়োজন।
কনসিয়র্জ এমভিপি কীভাবে কাজ করে
সাধারণভাবে Concierge MVP-তে ভবিষ্যৎ সফটওয়্যার যে ফল দেওয়ার কথা, সেটি শুরুতে প্রতিষ্ঠাতা বা ছোট একটি দল ম্যানুয়ালি দেয়।
ধরা যাক, ভবিষ্যৎ পণ্যটি ব্যবহারকারীর বাজেট, সময় ও পছন্দ অনুযায়ী ব্যক্তিগত ভ্রমণ পরিকল্পনা তৈরি করবে।
শুরুতেই জটিল স্বয়ংক্রিয় সুপারিশব্যবস্থা বানানোর দরকার নেই। একটি সাধারণ ফর্মে প্রয়োজনীয় তথ্য নেওয়া যেতে পারে। এরপর একজন মানুষ নিজে গবেষণা করে পরিকল্পনা তৈরি করে ইমেইল বা অন্য উপায়ে গ্রাহককে দিতে পারেন।
এ ধরনের পরীক্ষায় মূলত চারটি বিষয় দেখা হয়।
সমস্যা: লক্ষ্য গ্রাহকের কাছে সমস্যাটি আসলেই যথেষ্ট গুরুত্বপূর্ণ কি না।
সমাধান: প্রস্তাবিত সেবা সেই সমস্যাটি কার্যকরভাবে কমাতে পারছে কি না।
ব্যবহার: ফলটি পাওয়ার পর গ্রাহক সেটি বাস্তবে কাজে লাগাচ্ছেন কি না।
ব্যবসায়িক সম্ভাবনা: সেবাটির জন্য অর্থ দিতে বলা হলে তিনি রাজি কি না, অথবা অন্য কোনো অর্থবহ প্রতিশ্রুতি দেখাচ্ছেন কি না।
Stripe-এর ব্যবসায়িক ধারণা যাচাইয়ের নির্দেশিকাতেও সম্ভাব্য গ্রাহকের সঙ্গে সরাসরি কথা বলা, ছোট সংস্করণ পরীক্ষা করা, শুরুতেই মূল্য যাচাই করা এবং মানুষ কী বলছে তার পাশাপাশি বাস্তবে কী করছে তা দেখার ওপর জোর দেওয়া হয়েছে।
Concierge MVP আর Wizard of Oz MVP এক নয়
দুটো পদ্ধতিতেই পুরো প্রযুক্তিগত ব্যবস্থা তৈরি না করে মানুষের শ্রম ব্যবহার করা হতে পারে। তাই এগুলো প্রায়ই একসঙ্গে গুলিয়ে ফেলা হয়।
পার্থক্যটি শুধু “গ্রাহক জানেন কি না” দিয়ে বোঝালে পুরো চিত্রটি পাওয়া যায় না।
Concierge পরীক্ষায় সাধারণত মানুষই গ্রাহকের সামনে সেবার প্রধান মাধ্যম হিসেবে কাজ করে। প্রয়োজন শোনা, তথ্য নেওয়া, ফল তৈরি করা এবং সেটি পৌঁছে দেওয়ার ক্ষেত্রে সরাসরি মানবিক যোগাযোগ থাকে। সম্পূর্ণ Concierge পরীক্ষায় আলাদা করে তৈরি কোনো সফটওয়্যার না থাকলেও চলে।
Wizard of Oz পরীক্ষায় ব্যবহারকারীর সামনে সফটওয়্যার বা একটি কার্যকর ইন্টারফেস থাকতে পারে, কিন্তু পেছনের কিছু কাজ মানুষ ম্যানুয়ালি করে। সেই মানবিক কাজ ব্যবহারকারীর কাছে দৃশ্যমান নাও হতে পারে।
Mind the Product-এর ১৯ মার্চ ২০২৬-এর ব্যাখ্যায় Wizard of Oz-কে “software front end, human back end” এবং Concierge-কে “human front end” দিয়ে আলাদা করা হয়েছে।
যেমন, কোনো ওয়েবসাইটে ব্যবহারকারী নিজের প্রয়োজন লিখে Submit চাপলেন, আর পেছনে একজন কর্মী হাতে ফল তৈরি করে দিলেন—এটি Wizard of Oz-এর কাছাকাছি।
অন্যদিকে ব্যবহারকারী সরাসরি একজন ব্যক্তিকে নিজের প্রয়োজন জানালেন, সেই ব্যক্তি গবেষণা করে সমাধান দিলেন—এটি Concierge পরীক্ষার স্বাভাবিক উদাহরণ।
বাস্তবে দুই পদ্ধতির সীমা সব সময় একেবারে পরিষ্কার নয়। নাম নিয়ে বেশি ভাবার চেয়ে কোন অনুমানটি পরীক্ষা করা হচ্ছে এবং কোন অংশটি হাতে চলছে, সেটি পরিষ্কার রাখা বেশি দরকার।
আরও পড়ুনঃ No-code MVP বানানোর আগে Scope কীভাবে ছোট করবেন
কোন ধরনের আইডিয়ায় Concierge MVP বেশি কার্যকর
যে পণ্যের মূল ফল শুরুতে মানুষের শ্রম দিয়ে দেওয়া সম্ভব, সেখানে এই পদ্ধতি বিশেষভাবে কাজে লাগে।
যেমন:
- ব্যক্তিগত সুপারিশ বা পরিকল্পনা;
- ব্যবসায়িক তথ্য বিশ্লেষণ;
- দুই পক্ষের মধ্যে উপযুক্ত মিল খুঁজে দেওয়া;
- বুকিং বা সময়সূচির কাজ;
- নির্দিষ্ট তথ্য খুঁজে সাজিয়ে দেওয়া;
- ছোট প্রতিষ্ঠানের পুনরাবৃত্ত প্রশাসনিক কাজ;
- কনটেন্ট নির্বাচন বা সাজানো;
- বিশেষায়িত রিপোর্ট তৈরি।
এখানে উদ্দেশ্য মানুষ দিয়ে স্থায়ীভাবে একই কাজ চালিয়ে যাওয়া নয়। বরং হাতে কাজটি চালিয়ে বোঝা—ভবিষ্যৎ সফটওয়্যারে ঠিক কোন অংশটি দরকার এবং কোনটি দরকার নেই।
শুরুর পর্যায়ে এমন কাজ ইচ্ছাকৃতভাবে হাতে করার ধারণা স্টার্টআপ জগতেও পরিচিত। Paul Graham-এর ২০১৩ সালের Do Things that Don’t Scale প্রবন্ধে তিনি দেখিয়েছেন, প্রথম দিকের ব্যবহারকারী নিজে খুঁজে আনা এবং ছোট সংখ্যক গ্রাহকের সঙ্গে খুব কাছ থেকে কাজ করা থেকে এমন তথ্য পাওয়া যেতে পারে, যা পরে পণ্য তৈরিতে কাজে লাগে।
যেখানে Concierge MVP একা যথেষ্ট নয়
সব ব্যবসায়িক ধারণা এই পদ্ধতিতে পুরোপুরি যাচাই করা সম্ভব নয়।
কোনো পণ্যের মূল মূল্য যদি নতুন হার্ডওয়্যার, অত্যন্ত দ্রুত রিয়েল-টাইম প্রক্রিয়াকরণ, নির্দিষ্ট প্রযুক্তিগত কর্মক্ষমতা বা বড় নেটওয়ার্কের ওপর নির্ভর করে, তাহলে মানুষের হাতে কাছাকাছি একটি ফল তৈরি করে বাজারের আগ্রহ সম্পর্কে কিছু শেখা যেতে পারে। কিন্তু ভবিষ্যৎ প্রযুক্তিটি প্রয়োজনীয় মানে কাজ করবে—এটি প্রমাণ হয় না।
Fashion Metric-এর উদাহরণেও Concierge পর্যায় তাদের সম্ভাব্য সমাধান ও প্রয়োজনীয় ইনপুট সম্পর্কে শেখায়। পরে প্রযুক্তিগত ব্যবস্থা আলাদাভাবে তৈরি ও পরীক্ষা করতে হয়েছে।
চিকিৎসা, আর্থিক সিদ্ধান্ত, আইন, নিরাপত্তা বা সংবেদনশীল ব্যক্তিগত তথ্যের সঙ্গে যুক্ত সেবায় আরও সতর্কতা প্রয়োজন। স্থানীয় আইন, পেশাগত দায়িত্ব, গোপনীয়তা এবং প্রয়োজনীয় অনুমোদন আলাদাভাবে যাচাই করতে হবে।
সফটওয়্যার বানানোর আগে Concierge MVP চালাবেন যেভাবে
১. একটি নির্দিষ্ট অনুমান বেছে নিন
“মানুষ আমার অ্যাপ পছন্দ করবে”—এটি পরীক্ষার জন্য যথেষ্ট নির্দিষ্ট নয়।
এর বদলে লেখা যায়:
ছোট অনলাইন বিক্রেতারা প্রতি সপ্তাহে বিক্রির তথ্য দিলে, সেই তথ্য থেকে তৈরি পুনরায় অর্ডারের সুপারিশ তারা বাস্তবে ব্যবহার করবে।
এখানে কী পরীক্ষা করা হচ্ছে, তা পরিষ্কার।
একই পরীক্ষায় অনেকগুলো অনুমান ঢুকিয়ে দিলে ফল ভালো বা খারাপ হওয়ার কারণ বোঝা কঠিন হয়ে যায়।
২. লক্ষ্য গ্রাহকের পরিধি ছোট রাখুন
“সব ব্যবসা” বা “সব শিক্ষার্থী” দিয়ে শুরু করলে একই সমস্যার পুনরাবৃত্তি হচ্ছে কি না বোঝা কঠিন।
তার বদলে লক্ষ্য গোষ্ঠী হতে পারে:
- Instagram-নির্ভর ছোট পোশাক বিক্রেতা;
- স্বাধীন রেস্তোরাঁ;
- অনলাইনে পড়ান এমন ব্যক্তিগত শিক্ষক;
- ছোট ডিজিটাল এজেন্সির প্রকল্প ব্যবস্থাপক।
ছোট ও নির্দিষ্ট গোষ্ঠী দিয়ে শুরু করলে কোন সমস্যা বারবার আসছে, সেটি তুলনা করা সহজ হয়।
৩. ভবিষ্যৎ পণ্য যে ফল দেবে, সেটিই আগে হাতে দিন
এ পর্যায়ে অ্যাপের অভিনয় করার দরকার নেই। গ্রাহকের প্রয়োজনীয় ফলটি পৌঁছে দিলেই পরীক্ষা শুরু হতে পারে।
ভবিষ্যৎ সফটওয়্যার যদি মাসিক খরচ বিশ্লেষণ করে রিপোর্ট দেওয়ার কথা হয়, প্রথম পরীক্ষায় তথ্য স্প্রেডশিটে সাজিয়ে হাতে রিপোর্ট তৈরি করা যায়।
চাকরিপ্রার্থীর সঙ্গে উপযুক্ত চাকরির সুযোগ মেলানোর সেবা হলে শুরুতে হাতে কয়েকটি প্রাসঙ্গিক সুযোগ বেছে পাঠানো যেতে পারে।
ফর্ম, স্প্রেডশিট, ইমেইল, মেসেজিং অ্যাপ বা ভিডিও কল অনেক Concierge পরীক্ষার জন্য যথেষ্ট।
৪. পরিচিতজনের প্রশংসাকে বাজারের প্রমাণ ভাববেন না
বন্ধু বা পরিচিত মানুষ আইডিয়াটি ভালো বলেছেন—এটি দুর্বল সংকেত।
পরীক্ষার জন্য এমন মানুষ দরকার, যাদের বাস্তবে সমস্যাটি আছে এবং যারা ভবিষ্যতে লক্ষ্য গ্রাহক হতে পারেন।
Paul Graham-ও শুরুর দিকে প্রতিষ্ঠাতাদের নিজের হাতে ব্যবহারকারী সংগ্রহের ওপর জোর দিয়েছেন।
৫. ম্যানুয়াল কাজের প্রতিটি ধাপ নথিবদ্ধ করুন
কাজটি যদি পুরোপুরি ব্যক্তিনির্ভর হয়ে যায়, পরে কোন অংশটি সফটওয়্যার দিয়ে বদলানো দরকার তা বোঝা কঠিন হবে।
লিখে রাখুন:
- গ্রাহকের কাছ থেকে কী তথ্য নিতে হচ্ছে;
- কোন তথ্য পাওয়া কঠিন;
- কোন ধাপে সবচেয়ে বেশি সময় যাচ্ছে;
- কোন কাজ বারবার একইভাবে হচ্ছে;
- কোথায় মানুষের বিচার প্রয়োজন;
- কোন অংশ নিয়মে পরিণত করা সম্ভব;
- গ্রাহক কোথায় আটকে যাচ্ছেন।
পরে পণ্যের প্রয়োজনীয়তা নির্ধারণে এই নোট অনেক বেশি কাজে দেবে।
৬. প্রশংসার চেয়ে আচরণকে বেশি গুরুত্ব দিন
“আইডিয়াটা ভালো”—এই মন্তব্য দিয়ে ব্যবসার চাহিদা প্রমাণ হয় না।
এর চেয়ে শক্তিশালী সংকেত হলো, গ্রাহক:
- প্রয়োজনীয় তথ্য দিতে সময় দিচ্ছেন;
- দেওয়া ফল ব্যবহার করছেন;
- আবার সেবাটি নিতে ফিরছেন;
- অন্যদের কাছে সেবাটির কথা বলছেন;
- নির্ধারিত মূল্য দিতে রাজি হচ্ছেন।
Stripe-এর নির্দেশিকাতেও দাম আগেভাগে পরীক্ষা এবং গ্রাহক কী বলছেন তার পাশাপাশি কী করছেন—যেমন ফিরে আসছেন বা অন্যকে বলছেন কি না—সেটি পর্যবেক্ষণের পরামর্শ রয়েছে।
বিনামূল্যের পরীক্ষা থেকেও সমস্যা ও ব্যবহারের ধরন সম্পর্কে শেখা যায়। তবে কেউ বিনামূল্যে সেবা নিয়েছেন—এটিকে অর্থ দিয়ে কেনার ইচ্ছার প্রমাণ ধরে নেওয়া উচিত নয়।
বাস্তব Concierge MVP উদাহরণ: Fashion Metric
Lean Startup Productions-এর প্রকাশিত Fashion Metric কেসটি Concierge পরীক্ষার একটি পরিষ্কার উদাহরণ।
কোম্পানিটির প্রথম ধারণা ছিল এমন একটি মোবাইল অ্যাপ তৈরি করা, যেখানে পোশাক কেনার সময় ছবি পাঠিয়ে ব্যক্তিগত stylist-এর কাছ থেকে তাৎক্ষণিক পরামর্শ পাওয়া যাবে। সম্ভাব্য গ্রাহকদের সঙ্গে কথা বলে দলটি দেখতে পায়, তাদের প্রথম অনুমানের চেয়ে পুরুষদের সঠিক মাপের পোশাক খুঁজে পাওয়ার সমস্যাটি বেশি গুরুত্বপূর্ণ।
তারা সঙ্গে সঙ্গে পূর্ণ সফটওয়্যার তৈরি করেনি।
প্রথমে একটি সাধারণ ল্যান্ডিং পেজে আগ্রহীদের ইমেইল সংগ্রহ করা হয়। এরপর ফোনে শরীরের গঠন ও মাপসংক্রান্ত প্রশ্ন করা হতো। সম্ভাব্য প্রশ্নগুলো Google Doc-এ রাখা হয়েছিল। সেই তথ্যের ভিত্তিতে হাতে শার্ট বেছে সরবরাহ করা হতো এবং পরে ফিট কেমন হয়েছে, তা জানতে প্রতিক্রিয়া নেওয়া হতো।
এই ম্যানুয়াল পর্যায় থেকেই দলটি বুঝতে পারে, কোন ধরনের প্রশ্ন কার্যকর, কোন উত্তর কম নির্ভরযোগ্য এবং গ্রাহক সমস্যাটি সমাধান করতে কতটা চেষ্টা করতে প্রস্তুত।
পরে এই শেখার ভিত্তিতেই প্রযুক্তিগত ব্যবস্থা তৈরি ও আরও পরীক্ষা করা হয়।
এই উদাহরণের গুরুত্বপূর্ণ দিক হলো, কোড লেখার আগেই প্রথম ধারণাটি বাস্তব গ্রাহকের সামনে পরীক্ষা হয়েছিল। ফলে দলটি শুধু সমাধান নয়, সমস্যাটিকেও নতুন করে বুঝতে পেরেছিল।
বাংলা বাজারে একটি সম্ভাব্য প্রয়োগ
ধরা যাক, একজন উদ্যোক্তা এমন একটি সফটওয়্যার বানাতে চান, যা ছোট রেস্তোরাঁকে বিক্রির তথ্য দেখে পরদিন কত কাঁচামাল কিনতে হবে তার সুপারিশ দেবে।
পূর্ণ সফটওয়্যার বানানোর আগে কয়েকটি উপযুক্ত রেস্তোরাঁর সঙ্গে Concierge MVP চালানো যেতে পারে।
রেস্তোরাঁ প্রতিদিন বিক্রির প্রয়োজনীয় তথ্য পাঠাবে। উদ্যোক্তা সেই তথ্য স্প্রেডশিটে সাজিয়ে পরদিনের সম্ভাব্য কেনাকাটার তালিকা হাতে তৈরি করে পাঠাবেন।
এখানে কয়েকটি গুরুত্বপূর্ণ বিষয় সামনে আসবে। গ্রাহক কি নিয়মিত তথ্য দিতে পারছেন? সুপারিশ ব্যবহার করছেন? কোনো দরকারি তথ্য বারবার অনুপস্থিত থাকছে? এই সহায়তার জন্য অর্থ দিতে আগ্রহী?
যদি দেখা যায় বেশির ভাগ রেস্তোরাঁ প্রয়োজনীয় তথ্যই নিয়মিত দিতে পারে না, তাহলে প্রথম সমস্যা উন্নত পূর্বাভাস ব্যবস্থা বানানো নাও হতে পারে। পণ্যটিকে আগে হয়তো তথ্য সংগ্রহের কাজ সহজ করতে হবে।
এ ধরনের ফলকে ব্যর্থতা হিসেবে দেখা ঠিক নয়। বরং বড় ডেভেলপমেন্টের আগেই ভুল অনুমান ধরা পড়েছে।
যে ভুলগুলো পরীক্ষার ফল দুর্বল করে
প্রত্যেক গ্রাহকের জন্য পুরো সেবা বদলে ফেলা
Concierge মানে ব্যক্তিগত যোগাযোগ, কিন্তু প্রতিবার সম্পূর্ণ আলাদা সমাধান দিলে কোন অংশটির চাহিদা বারবার দেখা যাচ্ছে তা বোঝা কঠিন হবে।
মূল সেবা আর ব্যতিক্রমী অনুরোধ আলাদা করে লিখে রাখা ভালো।
খুব তাড়াতাড়ি স্বয়ংক্রিয় করা
একটি কাজ কয়েকবার করতে বিরক্ত লাগলেই তার জন্য সফটওয়্যার বানানো প্রয়োজন—এমন নয়।
আগে দেখা দরকার, কাজটি লক্ষ্য গ্রাহকদের ক্ষেত্রেও নিয়মিত হচ্ছে কি না এবং সেটি স্বয়ংক্রিয় করলে ব্যবহারকারীর জন্য বাস্তব সুবিধা তৈরি হবে কি না।
শুধু মতামত সংগ্রহ করা
সাক্ষাৎকার দরকার, কিন্তু ভবিষ্যতে কী করবেন—এ নিয়ে মানুষের বক্তব্য সব সময় বাস্তব আচরণের সঙ্গে মেলে না।
তাই ফিরে আসা, ফল ব্যবহার করা, প্রয়োজনীয় তথ্য দেওয়া এবং মূল্য দেওয়ার মতো আচরণও দেখতে হবে।
সফলতার মানদণ্ড পরে ঠিক করা
পরীক্ষার আগে লিখে রাখুন, কোন অনুমান যাচাই করা হচ্ছে এবং কী ধরনের ফল পেলে পরবর্তী ধাপে যাওয়া হবে।
নইলে ফল পাওয়ার পর নিজের সুবিধামতো তার অর্থ বদলে ফেলার ঝুঁকি থাকে।
মানুষের শ্রমের খরচ ভুলে যাওয়া
একজন গ্রাহকের জন্য যদি কয়েক ঘণ্টা কাজ লাগে, সেটিও গুরুত্বপূর্ণ তথ্য।
ভবিষ্যৎ সফটওয়্যার হয়তো সময় কমাতে পারবে। তবে কোন ধাপটি ব্যয়বহুল এবং কোনটি স্বয়ংক্রিয় করা অর্থপূর্ণ—সেটি Concierge পর্যায়েই বোঝার চেষ্টা করা উচিত।
কখন সফটওয়্যার তৈরির দিকে যাওয়া যুক্তিযুক্ত
Concierge MVP-এর উদ্দেশ্য যত দিন সম্ভব হাতে কাজ চালিয়ে যাওয়া নয়। বরং কোন কাজটি সফটওয়্যার দিয়ে করা উচিত, তার প্রমাণ তৈরি করা।
স্বয়ংক্রিয়করণ নিয়ে ভাবার মতো কয়েকটি সংকেত হলো:
- একই সমস্যা একাধিক উপযুক্ত গ্রাহকের মধ্যে বারবার দেখা যাচ্ছে;
- গ্রাহকেরা দেওয়া ফল নিয়মিত ব্যবহার করছেন;
- কাজের কিছু ধাপ একইভাবে পুনরাবৃত্ত হচ্ছে;
- ম্যানুয়াল কাজের নির্দিষ্ট অংশ সময় বা সক্ষমতার বাধা হয়ে দাঁড়াচ্ছে;
- অর্থ প্রদান বা অন্য শক্তিশালী প্রতিশ্রুতির সংকেত পাওয়া যাচ্ছে;
- কোন অংশটি সফটওয়্যার করলে গ্রাহক ও ব্যবসা—দুই পক্ষেরই বাস্তব সুবিধা হবে, তা পরিষ্কার হচ্ছে।
তারপরও পুরো পণ্য একসঙ্গে বানানোর প্রয়োজন নেই। সবচেয়ে বেশি পুনরাবৃত্ত বা ব্যয়বহুল ধাপটি আগে স্বয়ংক্রিয় করে আবার পরীক্ষা করা যেতে পারে।
MVP-এর জন্য কোনো সর্বজনীন সময়সীমা নেই। কত দিন Concierge পদ্ধতি চালাতে হবে, তা নির্ভর করবে কোন প্রশ্নের উত্তর খোঁজা হচ্ছে এবং পর্যাপ্ত শেখা হয়েছে কি না তার ওপর।
প্রথমে যে সিদ্ধান্তটি নেওয়া দরকার
Concierge MVP-কে শুধু “কোড ছাড়া MVP” ভাবলে ধারণাটি ছোট হয়ে যায়।
এর আসল কাজ হলো বড় প্রযুক্তিগত বিনিয়োগের আগে বাস্তব গ্রাহকের সঙ্গে ভবিষ্যৎ সেবাটি হাতে চালিয়ে দেখা। এতে বোঝা যায় সমস্যাটি যথেষ্ট গুরুত্বপূর্ণ কি না, মানুষ সমাধানটি ব্যবহার করছে কি না এবং কোন কাজটি পরে সফটওয়্যার দিয়ে স্বয়ংক্রিয় করা উচিত।
তাই শুরুতেই “কোন প্রযুক্তি দিয়ে অ্যাপ বানাব?” প্রশ্নে যাওয়ার আগে আরও একটি প্রশ্ন করা বেশি বাস্তবসম্মত:
ভবিষ্যৎ সফটওয়্যার যে ফল দেবে, সেই ফলটি কি কয়েকজন সম্ভাব্য গ্রাহককে এখন মানুষ দিয়ে দেওয়া সম্ভব?
সম্ভব হলে ছোট একটি Concierge MVP দিয়ে শুরু করা যেতে পারে। আর যদি গ্রাহকেরা সেবাটি ব্যবহার না করেন বা যথেষ্ট আগ্রহ না দেখান, সেটিও মূল্যবান ফল। কারণ তখন বড় বাজেট ও কয়েক মাসের ডেভেলপমেন্টের আগেই অনুমানটি নতুন করে ভাবার সুযোগ থাকে।
শেষ কথা
Concierge MVP-এর আসল মূল্য কম খরচে কিছু চালু করা নয়; বরং বড় বিনিয়োগের আগে ভুল অনুমান ধরতে পারা। সম্ভাব্য গ্রাহক যদি হাতে দেওয়া সেবাটিও ব্যবহার না করেন, প্রয়োজনীয় তথ্য দিতে না চান বা অর্থ দিতে আগ্রহ না দেখান, তাহলে পূর্ণ সফটওয়্যার বানানো সেই সমস্যার সমাধান করবে না।
তাই শুরুতে প্রযুক্তির চেয়ে শেখাকে অগ্রাধিকার দিন। ছোট পরিসরে বাস্তব গ্রাহকের সঙ্গে কাজ করুন, কোন অংশে তারা সত্যিকারের মূল্য পাচ্ছেন তা দেখুন, তারপর প্রয়োজনীয় অংশটুকু স্বয়ংক্রিয় করুন। এইভাবে Concierge MVP একটি আইডিয়াকে দ্রুত “সফল” ঘোষণা করে না; বরং কোন আইডিয়ায় আরও সময় ও অর্থ দেওয়া যুক্তিযুক্ত, সেই সিদ্ধান্তটি পরিষ্কার করে।
প্রায়শই জিজ্ঞাসিত প্রশ্ন
Concierge MVP করতে কি একেবারেই কোড ব্যবহার করা যাবে না?
না। Concierge MVP মানে কোড ব্যবহার নিষিদ্ধ নয়। ল্যান্ডিং পেজ, ফর্ম, স্প্রেডশিট বা বিদ্যমান সফটওয়্যার ব্যবহার করা যেতে পারে। মূল বিষয় হলো ভবিষ্যৎ পণ্যের যে অংশটি এখনও প্রমাণিত নয়, সেটি পূর্ণাঙ্গভাবে তৈরি না করেও গ্রাহকের কাছে মূল সেবা পৌঁছে দেওয়া।
Concierge MVP এবং prototype কি একই?
না। Prototype সাধারণত নকশা, ব্যবহারকারীর মিথস্ক্রিয়া বা কোনো প্রযুক্তিগত ধারণা পরীক্ষা করতে ব্যবহৃত হয়। Concierge MVP-তে মূল প্রশ্ন থাকে বাস্তব গ্রাহক সমস্যাটি অনুভব করছেন কি না এবং প্রস্তাবিত সেবা তাদের কাছে যথেষ্ট মূল্য তৈরি করছে কি না।
Concierge MVP কি বিনামূল্যে দিতে হবে?
বাধ্যতামূলক নয়। পরীক্ষার উদ্দেশ্য যদি মানুষ অর্থ দিতে রাজি কি না বোঝা হয়, তাহলে বাস্তব মূল্য পরীক্ষা করা বেশি তথ্য দেয়। আবার প্রথম পর্যায়ে সমস্যা ও কাজের ধাপ বোঝাই যদি লক্ষ্য হয়, সীমিত বিনামূল্যের পরীক্ষাও কাজে লাগতে পারে। তবে বিনামূল্যে ব্যবহারকে অর্থপ্রদানের চাহিদার সমান ধরে নেওয়া উচিত নয়।
